Mvp And The Innovators Dilemma

The previous post showed what happens to products after maturity: they either earn a second S-curve or decline. Instagram did. Facebook did not. The difference came down to what the product team built and when.

That question -- what to build, and when, and how to know if it is worth building at all -- is sharpest in the seed stage, before any curve exists. This is where most developers spend the earliest part of their careers. The instincts that work in a mature codebase actively harm a product still finding its footing.

The Minimum Viable Product

The seed stage is not a single product being built slowly. It is a rapid sequence of experiments. You have an idea. You build a version. A user sees it and tells you it is wrong. You rebuild it. That cycle might happen five times before you have something that holds.

Each iteration needs to be real enough for the person testing it to understand what the product is trying to do. A sketch on paper is not enough. A broken prototype is not enough. The product has to be functional and usable. But it absolutely cannot take three months to build, because if the feedback is "this is wrong," those three months were wasted.

This is where the concept of an MVP -- Minimum Viable Product -- becomes essential.

An MVP is not a bad product. It is not a half-built product. It is the minimum version of a product that:

• Delivers the core value proposition clearly enough for a real user to understand it
• Is functional enough to be used without confusion
• Can be built and iterated on quickly

The "minimum" in MVP is not about quality. It is about scope. You build the smallest possible set of features that proves the idea works. You leave out everything that is not necessary to test the core hypothesis.

Creating MVPs quickly is itself a skill. Developers and PMs who can move through the build-test-learn-rebuild loop fast are among the most valuable people in any early-stage team, because the speed of that loop determines how quickly a company finds something worth scaling.

ExpandThe four-step MVP validation sequence: problem interview, WhatsApp test, mobile website, native app -- with a bail-out path if behaviour never shows up

Validating Before You Build: The Danzo Framework

Consider a product called Danzo -- a service where you could hire a person with a bike to do errands for you. Buy something. Deliver something. Perform any short task within a city, for a small fee. A concierge service on demand.

How would you validate that this is a business worth building? The wrong answer is: build the app, then find out.

The first step is not a product decision at all. It is a problem interview.

Go to potential users before writing a single line of code. Ask them directly: do you face situations where you need someone to run an errand, and would you pay Rs. 50 for 15 minutes or Rs. 200 for an hour for someone to do it? This is not a survey. It is a conversation. You are trying to determine whether the problem is real, frequent, and painful enough that people would actually pay to solve it.

If the answer is consistently no -- the problem does not exist the way you imagined it -- you have saved yourself months of building something no one wants.

If the answer is yes, you do not yet build an app.

The WhatsApp Test

The second step is the cheapest possible live test. Create a WhatsApp number. Tell the people who said they would use the service: "Message this number when you need someone. I will send a rider."

Then wait.

If the people who told you they needed this service do not message for a week -- people who explicitly said they would -- the idea is not validated. There is a gap between what people say they will do and what they actually do. That gap is the most important signal in the seed stage.

If nobody messages, do not build the app.

If people do message -- and keep coming back -- you have evidence that the behaviour is real. Not just the stated preference, but the actual behaviour. That is the moment to take the next step, and even then, the next step is not an app.

One Platform, Not All Platforms

The instinct when you have early product-market fit signals is to build everything simultaneously -- iOS app, Android app, desktop website, mobile website. That instinct is wrong at the seed stage.

Building one platform well and proving the model on it is more valuable than building all platforms poorly. The question is which one.

If your users will access the product primarily from a desk -- in an office, at home, working on a computer -- a desktop website is the right starting point. If your users will be on the move, accessing the service quickly from a phone, a mobile website (accessible from any browser, no download required) is the right starting point.

A native app comes after the mobile website proves the demand. The app takes longer to build, requires a separate download step, and adds a significant barrier to the first-time user. At the validation stage, that barrier costs you signal.

Validate on one platform. Scale on many.

A Year Wasted: The Jaipur iOS Startup

The consequences of skipping this validation sequence are not theoretical.

A startup founder in Jaipur spent an entire year building a group buying platform for Tier 4 shopkeepers -- small shops selling staples like flour and lentils. The model was sound: help these shopkeepers aggregate their orders into bulk purchases, lowering the per-unit cost.

He hired a developer. The developer knew iOS. The founder had an iPhone. They built an iOS app. They tested it with one shopkeeper the founder knew well -- a person who owned ten shops and, unusually for the area, also had an iPhone. Everything worked. The app was good.

They released it. Nobody used it.

The reason: every other shopkeeper in the area had an Android device. The single person they had tested with was not representative of the actual user base in any way that mattered. An entire year of development produced an iOS app that the target users could not install.

The first question should have been: what device does a Tier 4 shopkeeper in Jaipur use? A ten-minute walk into the area would have produced the answer immediately.

This is the seed stage failure mode. Not bad code. Not a broken product. A product built for the wrong person, because no one asked the right question before building.

The Developer Who Asks Why

The Jaipur story is instructive specifically because it is not just a founder failure. The developer who worked on that project for a year could have asked, at any point: who are the actual users of this product, and what phones do they have?

That question is not outside a developer's remit. It is not a PM-only concern. Any person building a product should ask it before writing the first line of code, because the answer directly shapes what you build.

A developer who understands product management does not just write better code. They prevent the wrong product from being written at all.

Zepto: Applying the Framework to a Live Product

Zepto delivers groceries and essentials in under ten minutes across Indian cities. It operates through dark stores -- small, non-public warehouses positioned every few kilometres in dense urban areas -- rather than through physical shops or traditional supply chains.

Zepto recently closed a funding round valuing the company at approximately $5 billion. That number eliminates seed and decline from the options. A seed-stage product has not validated its model. A declining product does not attract billion-dollar investments. Zepto is definitively in the growth stage: its core value proposition works, users are growing, and the business is scaling that proven model.

The way growth-stage expansion looks in practice is visible in what Zepto is doing beyond groceries. It launched Zepto Cafe, delivering food in under ten minutes. It added Decathlon products. These are maturity-approaching moves: the core product is working, so the team is adding use cases to increase the frequency of reasons a user opens the app.

The Pivot: KiranaKart to Zepto

Zepto did not start as Zepto. It started as KiranaKart -- a platform attempting to digitise the neighbourhood grocery (kirana) store experience by helping existing kirana shops go online and take orders digitally.

KiranaKart failed within six months. The MVP did not produce the behaviour the founders were looking for.

The founders did not shut down. They identified what was still working -- the demand for fast household essentials delivery -- and pivoted to a fundamentally different supply model. Instead of partnering with existing shops, they built dark stores. Instead of listing existing inventory at existing locations, they controlled the inventory and the locations. The product became Zepto.

This is the pivot: when the MVP reveals that the current approach will not work, and you use that signal to change direction before the runway runs out. The pivot is not failure. It is the seed stage working as designed -- rapid iteration, honest signal reading, willingness to change.

The code written for KiranaKart was not wasted. It taught the team what the real user behaviour was. The next codebase benefited from that learning.

The Innovator's Dilemma: Why Google Did Not Ship ChatGPT First

Google had a conversational AI product ready before ChatGPT launched publicly. One documented signal: in 2022, a Google engineer named Blake Lemoine went to the press claiming that the company's LaMDA language model had become sentient. Google fired him. Whether the claim was accurate is beside the point -- the fact that a Google engineer could make this claim at all, publicly, before ChatGPT had launched, tells you something about how far along Google's internal AI work was.

Google chose not to release it.

The reason is not that the technology was not ready. The reason is that Google is the most mature search product in history, and a mature product at trillion-dollar scale has fundamentally different constraints than a startup.

The first constraint is revenue. Google makes money when users click sponsored links. A conversational AI that gives direct answers removes the click. The entire revenue architecture of Google Search depends on the behaviour of link-clicking, and launching a product that eliminates that behaviour would require Google to simultaneously destroy and rebuild its business model.

The second constraint is trust. Google has spent more than two decades building the expectation that when you search for something, the results are reliable. Every AI model -- including Google's -- produces hallucinations: confident, fluent, wrong answers.

For a startup, a hallucination is a known limitation users tolerate. For Google, a hallucination at scale erodes a trust relationship that took twenty years to build.

When Gemini was publicly demonstrated and gave an incorrect answer in its launch video, hundreds of billions of dollars in market cap were erased within hours. To put that number in context: the market cap Google lost in a single day from one wrong demo answer was itself larger than OpenAI's total valuation at the time.

OpenAI's errors do not produce that same impact. The trust relationship is newer. Users expect imperfection from a product that has existed for two years.

ChatGPT was allowed to be wrong in ways that Google could not afford. That asymmetry is what let a startup become a household name while a trillion-dollar company with better resources watched from the side.

By the time Google had navigated the revenue conflict and the trust risk and felt confident enough to launch Gemini publicly, ChatGPT had embedded itself into how a generation of users thinks about AI-assisted work. The first-mover position in the AI era was surrendered not by technical failure, but by the weight of maturity-stage conservatism.

This is the Innovator's Dilemma -- introduced by Clayton Christensen in his 1997 book of the same name. It describes the dynamic where successful, mature companies fail to adopt disruptive innovations not because they lack the capability, but because the innovation threatens the very things that made them successful.

A startup's weakness -- no established revenue, no brand reputation to protect -- is also its advantage. It can experiment freely. It can be wrong publicly. It can ship fast and learn from failure without the existential consequences that the same failure would carry for a mature incumbent.

NVIDIA: A Second S-Curve Nobody Planned

NVIDIA was founded in 1993 to build graphics processing units for the gaming industry. For much of its history it was a mature, stable hardware company -- consistently profitable, but not exciting. Most people outside gaming did not think about it.

Then transformer-based AI models arrived. ChatGPT demonstrated publicly what these models could do. And every technology company in the world suddenly needed the specific kind of parallel processing that NVIDIA's GPUs provide.

NVIDIA's Q2 FY2025 results (quarter ending July 2024) showed revenue of $30 billion -- a 122% increase year-over-year. For a hardware company that has been operating for over three decades, that rate of growth is not normal. It is the growth stage, restarted, on a new product category that did not exist as a mass market a few years ago.

NVIDIA did not create the AI wave. What it had built over thirty years -- GPU architecture with massive parallel processing capability -- happened to be exactly what the AI wave needed.

You cannot always predict what will restart your S-curve. You can make sure you are building something worth restarting.

Growth vs. Maturity: The Profit Margin Distinction

One more distinction is worth understanding when reading quarterly results or assessing a company's actual position.

Growth stage: Both users and revenue are increasing. Profit is growing faster than the user base. This matches the four-stage framework exactly -- the curve is still steep and rising. The business is not just getting bigger -- it is getting more efficient as it scales.

Maturity stage: The user base is largely stable. Revenue is stable. But profit margins are improving -- not because the company is doing something structurally new, but because it is optimising. Cost reduction, process improvement, infrastructure efficiency.

Decline stage: Users are declining. Revenue is declining. Margins may temporarily improve through cost cuts, but the trajectory is downward.

A company with steadily improving profit margins but a flat user base is not in the growth stage. It is in the maturity stage executing well on operations. That is healthy, but it is not the same as growth -- and conflating the two leads to building for the wrong constraints.

For a developer or PM: the answer to "what should we build next?" is fundamentally different depending on which of these states you are in. A maturity-stage company needs engineering that makes things cheaper and more reliable. A growth-stage company needs engineering that scales fast and handles ten times more users by next quarter.

Answering the growth question with maturity-stage solutions, and vice versa, is one of the most common and most avoidable failures in product organisations.

The product lifecycle is not a checklist you run once. Every quarter, products move -- sometimes visibly, sometimes not. The frameworks in this chapter -- seed, growth, maturity, crisis, MVP, validation, Innovator's Dilemma -- give you a vocabulary for reading those movements accurately.

That vocabulary is what separates developers who build the right thing from developers who build a technically excellent thing nobody needed.

The Essentials

1. Validate before you build. The Danzo framework: problem interview, WhatsApp test, single platform, then native app. Never build the full product before proving the behaviour is real. Stated intent is not the same as actual behaviour.

2. The Innovator's Dilemma is real and affects the largest companies. Google had conversational AI before ChatGPT and chose not to release it. The reason was not technology -- it was the weight of protecting a trillion-dollar revenue model and two decades of trust. Startups can afford to be wrong in ways mature companies cannot. That asymmetry is why disruption keeps happening.

3. Growth is the rate of change, not the absolute position. Doubling from 100 to 200 users is the same relative growth as 1 million to 2 million. And improving profit margins with a flat user base is a maturity signal, not a growth signal. Conflating the two means building for the wrong stage.

Further Reading and Watching

• Clayton Christensen on How to Build a Disruptive Business -- Startup Grind -- Clayton Christensen in conversation explaining the Innovator's Dilemma and how disruptive companies are built around constraints rather than features.
• The Innovator's Dilemma -- Clayton Christensen (1997) -- The primary source for the Innovator's Dilemma concept. Required reading for anyone working at a product company at scale.
• NVIDIA Q2 FY2025 Earnings Release -- The source for the 122% year-over-year revenue growth figure cited in the NVIDIA section.