The User Problem
Solar power has a problem: the sun doesn't negotiate.
In India, solar generators had two bad options:
Option 1: Long-term contracts at lower rates
Sell power to factories or consumers at a discount because you can't guarantee when or how much you'll generate. Safe, but you're leaving money on the table.
Option 2: Sell on the exchange and face penalties
Get higher market rates, but if your actual generation doesn't match your commitment, you pay penalties. Without accurate forecasting, this was essentially gambling.
The users caught in this trap:
- Solar plant operators and pool operators who needed day-ahead generation forecasts to bid on exchanges
- Government load dispatch centers (like POSOCO) who needed demand and aggregated generation forecasts to balance the grid
The root problem: India had almost no solar forecasting infrastructure. Plant operators were flying blind.
The Decision
I led the product effort across three parallel tracks:
Track 1: Data Acquisition
We needed weather data that didn't exist in the Indian market. I led the contract negotiation to acquire weather data from an Indian government agency—making Kreate the first company in India to pursue this type of data from an Indian entity (rather than international providers) for commercial solar forecasting.
We secured a year's worth of assessment data to validate the approach. This was foundational—without it, the ML models had nothing to learn from.
Track 2: Model Development
I worked directly with ML scientists and data engineers on:
- Evaluating ML algorithms for solar prediction
- Defining data requirements and quality standards
- Discovering solar plant configurations (different setups = different prediction challenges)
- Coordinating data pipelines to feed the models
- Testing model accuracy against real generation data
My role wasn't to build the models—it was to ensure the models solved the right problem with the right data.
Track 3: Product & Adoption
The predictions were useless if nobody used them. I owned:
- UX/UI design of the forecasting application
- User feedback loops to improve predictions
- Implementation support for adopting generators
- Pilot program coordination with India's national grid operator for a one-year contract run
The Build
The data challenge:
Indian weather data was fragmented and low-resolution. Weather data from an Indian government agency gave us the granularity we needed—cloud cover, irradiance, temperature—at the specific locations where solar plants operated.
Negotiating with a government agency isn't like signing up for an API. It required understanding their data formats, their processes, their concerns. We were asking them to support a commercial use case they'd never served before.
The model iteration:
Solar forecasting isn't one model—it's a system. Different plant configurations (fixed panels vs. tracking systems, different inverter setups) behave differently under the same weather conditions.
I led discovery sessions with solar operators to understand their specific setups, then worked with data engineers to ensure our training data captured this variation.
We tested continuously: model prediction vs. actual generation vs. exchange settlement. Every percentage point of accuracy improvement translated directly to customer savings.
The government pilot:
POSOCO needed aggregated forecasts for grid balancing. Getting a government entity to pilot new technology required building trust—demonstrating accuracy, ensuring reliability, proving we understood their operational constraints.
The web application:
All of this had to be encapsulated in a product users could actually use. I coordinated with developers to build the REDFx web application—turning complex ML predictions into actionable forecasts that traders could integrate into their daily workflows.
Strategic Impact
The Lesson
How I apply this now:
AI/ML products aren't about the algorithm. They're about the ecosystem: data acquisition, model validation, user adoption, and measurable business impact.
My data principle: The best ML model is useless without the right training data. Sometimes getting that data is the hardest part of the product. I spent months on government agency negotiations—not glamorous, but foundational.
My validation approach: "7% accuracy improvement" means nothing without business context. I validate by tracking actual customer outcomes. The $1.2M wasn't a projection—it was measured.
My role in ML products: I don't build models. I ensure models solve real problems, get fed real data, and deliver real value. That's product management.
My adoption mindset: Predictions only create value if users trust them enough to change their behavior. Building that trust requires constant feedback, iteration, and proof.