AI-Native Product Leadership
From an Initial AI Bet to a Proven, Buildable MVP
Took an early AI product bet through deep discovery, hands-on prototyping, daily client iteration, and user validation. From 0→1 to an MVP engineering could build.
The Challenge
The engagement started with a bet based on initial research. A good place to start. Not yet a product. The idea was that AI could turn fragmented operational signals into something genuinely useful for decision-makers. But the hypothesis still had to survive contact with real users. We needed to work out which problem actually stood, what evidence people would trust, and what the first product should do. There was also a delivery team waiting for something concrete. The job was to move fast without turning assumptions into requirements and calling that discovery.
The Approach
I started with my own AI-enabled research and built an AI-native product system around the work: research, synthesis, documentation, prototyping, decision tracking, and quality checks. Then I built the first working prototypes myself. The client and I reviewed the actual product daily, and I turned those conversations straight into the next iteration. Once the prototype was strong enough to test properly, I recruited users and ran expert interviews directly against it. No abstract questions about whether the idea sounded nice. We put something in front of people and used their reactions to test the problem, the hypothesis, the language, and the value. When the core hypothesis stood up, I locked the first MVP scope and wrote the product requirements document. Engineering built against that definition while I kept the prototype moving beyond the MVP, showing how the product could evolve without quietly pushing more work into the first release. Discovery, prototype, requirements, and delivery all moved in tandem.
The Outcome
I took the product from 0→1 to MVP state. That is where this case study stops. No invented scale story and no pretending an MVP is already a mature business. The team had a validated problem, a working prototype, a locked first scope, and a product requirements document engineering could execute against. The client could see and challenge the product every day while it was still cheap to change. The bigger proof for me was the operating model: AI did not just make prototyping faster. It gave one product lead the leverage to run discovery, strategy, prototyping, documentation, and iteration as one connected system, with the quality staying high throughout.
This kind of work usually runs as interim Head of Product.
Companies I've worked with
More Work
Other Case Studies
Founder / 0→1
Building RevoBill: From Side Project to SaaS
Designed, built, launched, and operate a SaaS product solo, taking it from zero to paying customers with no marketing budget.
Engineering Culture
Making Developer Experience a Business Priority
Turned DevEx from an engineering-internal concern into a company-wide north star metric, moving a mid-sized SaaS org to the 75th percentile for developer experience in its cohort.
Payments & Infrastructure
Unifying Billing Across Three Legacy Systems
Led the strategic migration of the company's entire subscription base from three fragmented legacy systems into a single source of truth.
Got a Problem That Looks Like This?
One discovery call: 30 minutes, no pitch. Bring the messiest version of it.