AI/ML Product Management

REDFx Solar Forecasting

How we built India's first ML-powered solar forecasting system and saved customers $1.2M. First in India to acquire weather data from an Indian agency for commercial solar forecasting.

PM Skills Demonstrated
  • AI/ML Product Strategy
  • Data Acquisition
  • Stakeholder Navigation
  • Outcome Validation
REDFx Solar Forecasting

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 Insight

Accurate forecasting could transform the economics of solar power in India. If generators could predict tomorrow's output with confidence, they could:

  • Bid on exchanges at higher rates
  • Avoid penalties for missed commitments
  • Make solar competitive with conventional power

But building this required solving problems nobody in India had tackled commercially:

  1. Weather data: You can't predict solar generation without granular weather data. Nobody in India was providing this at the resolution we needed.
  2. ML models: The algorithms existed, but they needed to be trained on Indian conditions—different weather patterns, different solar configurations, different grid requirements.
  3. User adoption: Even with accurate predictions, users would need to trust and integrate them into their trading workflows.

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

$1.2M

Verified Customer Savings

Calculated by comparing before/after earnings and penalty reductions. Not a projection—measured.

Industry First

Weather Data Acquisition

First Indian company to acquire weather data from an Indian agency for commercial solar forecasting.

7%

Accuracy Improvement

Over baseline methods—every percentage point translated to customer savings.

Government Pilot

National Grid Operator

One-year pilot program with India's national grid operator (POSOCO).

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.