SkyRipple began purely as a technical escalation. Having previously engineered synthetic data generation pipelines for the healthcare sector during my time at Onix, I wanted to apply that same architectural rigor - ripping a database apart, building a knowledge graph, and wrapping it in a simulation layer - to the aviation industry.
But a simulation without a target user is just a sandbox. To transform SkyRipple from a heavy mathematical backend into a viable enterprise product, I had to stop thinking like a systems engineer and start thinking like a Product Manager.
Here is how I used the CIRCLES method to guide this transformation.
01. Comprehend the Situation & Identify the Customer
The Trap
When you model 582,000 real flights and synthesize 2.4 million passenger itineraries down to the minute, the immediate temptation is to build a product for everyone.
Initially, I found myself building for the "Aviation Enthusiast." I was designing interfaces where a user could click on a specific aircraft, view a rich seat map, and drill down into individual passenger profiles - their names, connection flights, and age demographics. The data was all there in the backend.
The Pivot
But as the simulation revealed the brutal financial reality of airline delays - specifically the 5.19x cost multiplier when a local disruption cascades nationally - the core customer became glaringly obvious. The end-user wasn't an aviation geek looking at a flight tracker.
The user was an Airline Duty Manager sitting in an Operations Control Center (OCC) at 2:00 AM.
- Their Context: High cognitive overload, massive financial pressure, and managing chaotic, competing priorities (crew legality, gate availability, aircraft maintenance).
- Their Goal: Stop the multi-day financial bleeding caused by a network disruption.
02. Report the Customer's Needs
Once the Duty Manager was identified as the core user, their primary needs crystallized:
Speed over Granularity
They don't care about passenger names; they care about missed connection aggregates.
Actionable Intelligence
They don't need a visualization of the problem; they need a mathematically verified recovery solution.
Trust
They operate in a highly regulated, zero-margin-for-error environment. They cannot rely on an LLM that might hallucinate financial savings.
03. Cut: Ruthless Prioritization
This is where the hardest product decisions were made. To serve the Duty Manager, I had to kill my darlings.
I entirely scrapped the "FlightRadar24-esque" features. I removed the aircraft photos, the granular seat-map UIs, and the individual passenger tracking features. I had spent weeks modeling that synthetic data, but surfacing it in the UI violated the core product mandate:
"If it doesn't help the OCC recover network costs, it's visual noise."
By cutting the enthusiast features, I cleared the roadmap to build what actually mattered: the 5-Agent Arbitrated Financial Simulator.
04. Evaluate: Two Hard Trade-offs
Building this system required making two massive architectural and product compromises.
Trade-off A: Scope vs. Performance
I initially wanted a hyper-realistic airport environment that modeled the exact number of ground staff and terminal gates. However, calculating dynamic ground-staff movements across 300+ airports introduced massive computational latency.
The Decision
I explicitly chose to hardcode terminal capacities and abstract the ground crew variables. Whether there are 3 or 15 baggage handlers at a gate does not fundamentally alter the macro-financial cascade of a 2-hour runway closure at O'Hare. This sacrifice in micro-realism guaranteed the macro-system could execute a multi-day national disruption scenario in under 20 seconds.
Trade-off B: The Go-to-Market Strategy
The full 5-Agent OCC simulation is computationally heavy. Running parallel financial simulations for a continuous month takes several minutes. While an airline enterprise will gladly wait 5 minutes for a calculation that saves them $145,000, a recruiter, portfolio visitor, or prospective buyer looking for immediate Time-to-Value (TTV) will bounce if forced to wait.
The Decision
I bifurcated the product. I kept the heavy backend Python engine private, and built SkyRipple Lite - a zero-latency, serverless interactive client for public deployment. By pre-computing massive multi-day scenarios and packaging them as a static web export, I allowed users to instantly experience the simulation's analytical depth without sitting through backend compute times. It proves the capability exists, while strictly optimizing for immediate user engagement.
05. Summarize: The Final Positioning
By strictly adhering to the user's operational needs, SkyRipple evolved into its final form.
Instead of an exploratory dashboard, it became an Agentic AI operations platform. By defining the strict "Gemini Proposes, Code Disposes" boundary, we solved the user's trust issue. And by creating SkyRipple Lite, we solved the market accessibility issue.
The Takeaway
SkyRipple is proof that deep technical execution only generates value when it is ruthlessly aligned with a user's operational reality. Building the engine required engineering; deciding what not to build required product strategy.