The Four Stages

The previous post traced three separate failures at DoubtNut -- all to the same root: building with a mental model of the user that did not match reality. Product management is the practice of getting that model right before the code is written.

But knowing your user is only half the picture. The other half is knowing where your product is in its life -- because that changes everything about what you should be building, and how carefully.

Every Product Follows the Same Shape

Every product follows the same pattern. Not every founder admits it, but the shape is consistent enough that mathematicians gave it a name: the sigmoid curve.

You do not need the formula. You need the shape.

Start at zero. Rise slowly at first, then steeply, then level off into a plateau. Then either curve upward again or fall. That is the life of every product ever built -- from Facebook to DoubtNut to whatever you are working on right now.

ExpandThe product life cycle: seed, growth, maturity, and the crisis point where products either earn a second S-curve or begin to decline

Understanding which part of that curve you are on is one of the most practically useful things a developer can know. It directly determines how you should be writing code.

Stage 1: Seed

The seed stage begins when someone has an idea and starts building it.

At this point, you have no users. You may have a few colleagues testing it. You are running rapid iterations -- building a version, seeing if it does what you think it does, changing it, building again. The product that exists today might look completely different in two weeks.

The priority at this stage is speed, not quality. You need to ship something people can actually touch, because until a real user interacts with your product you are guessing about everything. A clean, well-structured, fully scalable codebase is worthless if you build the wrong thing.

Spending three months perfecting the architecture before validating the core idea is one of the most common and most costly mistakes in early-stage product development.

Some bugs are acceptable here. The goal is not a polished product. The goal is proof that the core idea is worth building.

Stage 2: Growth

Growth begins when users start arriving on their own.

The defining characteristic of the growth stage is daily incremental gain -- more users today than yesterday, more revenue this week than last week. The curve is steep and rising. This is the moment that looks exciting from the outside and is genuinely terrifying from the inside.

The growth stage is the hardest stage to code for, because it requires two things that are in direct tension with each other.

You have to ship fast. Tomorrow the business wants five times the users you had today. Features need to go out continuously. The window for each release is short. Waiting is not an option.

And you cannot ship bugs. At the seed stage, a rough experience is acceptable -- you have a handful of users who understand they are early adopters. In the growth stage, a first-time user who hits a crash or a broken flow will never come back. They will also tell others. Negative word of mouth at scale undoes the marketing budget that brought those users in.

Fast and stable, at the same time. This is why growth-stage engineering is genuinely difficult, and why the teams that navigate it well become the ones that dominate their market.

Stage 3: Maturity

Maturity is the plateau. The curve has levelled off.

At maturity, the number of new users joining your product each day is roughly equal to the number leaving it. Churn rate equals new acquisition rate. Revenue is stable but no longer compounding.

This is the stage where engineering finally gets to pay down its debt. The rapid shipping of the growth stage typically means a codebase full of quick fixes, tightly coupled services, and architectural decisions made under pressure. Maturity is when teams introduce proper structure -- moving from monoliths to microservices, making testing coverage a serious standard, writing documentation that does not immediately rot.

The code gets cleaner. The processes get more deliberate. The engineering culture matures alongside the product.

Stage 4: The Crisis Point

After maturity comes the most consequential moment in a product's life.

The plateau cannot hold indefinitely. At some point the balance tips: more users leave than join. If the team has been building well -- innovating, solving real user problems, adding features that expand who the product is useful for -- the curve bends upward before the decline sets in. A new chapter of growth begins, sometimes called a second S-curve.

If the team has not been building well -- shipping low-quality features, losing sight of the user, allowing competitors to solve problems the core product has been ignoring -- the curve bends downward. The decline follows a consistent three-phase pattern: drift, denial, death. Users start drifting -- opening the app less, not returning after a bad experience. Then denial sets in -- users stop acknowledging the product exists at all, routing around it entirely. Then the product dies.

No product has ever maintained the maturity plateau indefinitely. Every product either earns a second growth phase or begins dying. There is no third option.

How Your Code Should Change Across the Curve

The most practical takeaway from the product life cycle is this: the right way to write code in one stage is the wrong way in another.

Stage	Code priority	Bug tolerance	Hiring signal
Seed	Speed to ship, prove the idea	Some bugs OK	Hustle, versatility
Growth	Fast AND stable, scalable	Very low -- users won't return	Speed + quality under pressure
Maturity	Structure, modularity, testability	Near zero -- incidents wipe market cap	Deep quality, thoroughness
Crisis/Decline	Innovation or moat-building	Low	Depends on direction

The developers who stay valuable across the entire curve are the ones who understand which dial to turn up depending on where they are -- and who ask which stage they are in before writing the first line.

Why the Maturity Stage Has No Tolerance for Bugs

In the seed stage, bugs are forgivable. The user base is tiny, expectations are low. A crash is an inconvenience, not a catastrophe.

In the growth stage, bugs are damaging but survivable. Users who hit a problem may leave, but many will return if the product's core value is strong enough. The brand is still being built, and there is some goodwill in the system.

In the maturity stage, bugs can be existential -- and their consequences last far longer than the incident itself.

The CrowdStrike outage on July 19, 2024 is the case study. A single faulty configuration update crashed 8.5 million Windows devices globally -- causing flight cancellations, hospital disruptions, and payment failures.

The financial cost ran into the billions. The reputational cost was immediate and severe.

But the immediate crash was only the first wave. In the weeks that followed, CrowdStrike's competitors began using the incident in their sales pitches. A security vendor walking into a contract negotiation could now open with: "We do not go down the way CrowdStrike did."

A real failure at scale becomes a permanent reference point. CrowdStrike's analysts noted future revenue projections would take a hit not just from customer attrition, but from deals that would never be signed -- because the incident had become a competitive narrative. The one thing that cushioned CrowdStrike from immediate collapse: enterprise security customers are typically locked into multi-year contracts. Mass defection was structurally difficult even for customers who wanted to leave. The reputational damage outlasted the technical incident regardless.

In the maturity stage, a serious failure does not end when the systems come back online. It becomes a story competitors use for years.

This is also reflected in how mature companies hire differently from startups. A startup looks for engineers who can ship fast, handle ambiguity, and turn things around quickly. A mature company looks for engineers who write code that will not break under load, that is thoroughly tested, and that other engineers can read and maintain years later. Neither standard is wrong. They are calibrated to the stage.

The Essentials

1. Every product follows the sigmoid curve: seed, growth, maturity, crisis. After the plateau, it either earns a second S-curve or starts to decline. Which one happens is determined by what the product and engineering teams built during the plateau -- not after it tips.

2. The right code at one stage is the wrong code at another. Seed prioritizes speed over quality. Growth requires speed AND stability simultaneously. Maturity demands structure, modularity, and testability. Applying the wrong standard costs you -- either a missed validation window or a production incident that becomes a competitive narrative.

3. In the maturity stage, bugs are not just bugs. They become reference points that competitors use in sales pitches for years. CrowdStrike's outage did not end when their servers came back online.

Further Reading and Watching

• The Product Life Cycle 101: The Growth and Decline of a Product -- A concise walkthrough of the four stages with real product examples. Good paired viewing with this post.
• Exploit the Product Life Cycle -- HBR (1965) -- The foundational Harvard Business Review article that introduced the product life cycle into business thinking. Still the clearest original framing of the concept.

The framework is most useful when applied to real products. The next post maps Facebook, WhatsApp, Instagram, Gmail, and Google Search to the curve -- and some of the answers are more surprising than you would expect.