Product Life Cycle

Most products trace a similar revenue curve. Sales barely move at first, then climb steeply, hold high for a while, and slowly fall away. Before that shape had a name, every bend in it got blamed on people. The ad budget was too small, sales wasn't hungry enough, the feature list was too thin.

So the same meeting kept repeating itself. Signups that had been growing 40 percent a quarter come in at 12 percent, the CEO says to double the marketing budget, and marketing runs twice as much of the same ad. When the number still doesn't move, someone swaps out the person running the channel. If the real cause is that almost everyone who wanted the product has already bought it, none of that helps. The company just spent twice as much money saying the same thing to the same people.

The opposite mistake comes from the same place. A product that shipped three months ago gets a national ad campaign behind it. Nobody has established yet who the product is actually for, so the campaign brings in a crowd, most of the crowd leaves in the first week, and the invoice is the only thing left behind. The two errors point in opposite directions and share one cause: somebody acted before checking where the product was in its life.

The product life cycle is a way of checking that position first. It came out of marketing literature in the 1950s as a way to describe the sales curve of consumer goods, and it transfers to software without much adjustment. Its central claim is that the same number means different things in different stretches of the curve. Twelve percent quarterly growth is a warning sign for a product the market barely knows about, and a sign of healthy footing for one that has already sold to most of the people who will ever buy.

Inside the product field, this term sits in the group that tracks where a product stands over time. Its neighbor there is the chasm, the specific gap that opens early in the arc. Early adopters take a risk on something new, the mainstream market waits until it sees other people using it, and demand can drop to nothing in between.

Four terms sit under this one, and all four are names for stretches of the arc. There is only one grouping to make, since the four run in sequence and no product skips ahead.

1. Introduction — the product has just reached the market and is working on being known at all. Few people have heard of it, so revenue is small and the cost of reaching anyone is high. The work here is closer to verification than to selling. If a team can't establish product-market fit — proof that what got built matches what a specific market wants — the next stretch never arrives. For Pagedeck this was the stretch of months when thirty invited teams were the entire user base and every new signup was still a conversation. Users are few in this stretch but unusually vocal. They put up with rough edges and explain exactly which ones hurt, and one piece of that feedback can reshape the two stages that follow.
2. Growth — demand climbs quickly. Users arrive roughly in proportion to how much reach the team buys, and each month's signups beat the month before. The trap is that heavy inflow hides outflow. A thousand people joining and three hundred leaving every month still produces a rising total, and the day inflow stalls, those three hundred become the whole story. This is also the stretch where competitors show up in the same market, which is why a lead built here is worth more than the same lead built later.
3. Maturity — growth flattens and competition sharpens. Most of the people who were going to buy have bought, so the price of one more user keeps climbing. Revenue is at its largest but stops increasing. The weight of the work shifts from bringing new people in toward keeping the people already there and earning more from each of them: repricing, adding a higher tier, extending the product into an adjacent market. The common misread here is treating flat growth as a product defect. Once nearly everyone who would use the thing is using it, no amount of added features returns the signup curve to its old shape.
4. Decline — demand falls. The cause is usually one of two things: a newer product does the same job better, or the job itself has gone away. Document software installed on a company's own servers losing ground to something you open in a browser is the first case; fax software disappearing along with fax machines is the second. Three options exist in this stretch — cut maintenance cost and collect cash from the remaining customers, rebuild the product and send it back to an earlier stage, or end it.

Lining the four up shows that the question a team is holding changes from stage to stage. In introduction the question is whether anyone actually wants this. In growth it becomes how fast the people who want it can be reached. Maturity turns it into how much more can be earned from the people already here, and decline into when and how to let go. A team holding all four questions at once answers none of them, which is what a launch team is doing when it spends two months designing an enterprise tier.

What separates the stages is the shape of the numbers, not the calendar. A product isn't in growth because it turned one, or in maturity because it turned five. Teams making the call usually put three readings side by side: whether quarterly growth is rising or falling, whether competing products in the same market are multiplying, and which way the cost of acquiring one new user is moving. Falling growth alongside rising acquisition cost says growth is ending. Falling growth alongside falling acquisition cost usually says one advertising channel changed, not that the stage did. When the reading is ambiguous, wait a quarter. Calling a stage change off a single quarter turns a holiday or a season into a structural story.

Stage length varies enormously. A product riding a trend can pass through introduction and growth in six months and be in decline the following year, while accounting software that is a nuisance to replace can hold maturity for more than a decade. The chasm between introduction and growth isn't universal either. The further a product departs from how people already work, the deeper that gap runs, because the mainstream buyer has to change a habit and not merely a tool.

One more distinction is worth holding onto: a product's stage and a company's stage are separate things. Startup stages are drawn by funding raised and headcount. A company that just closed a Series A can easily be selling one product in introduction and another in maturity at the same time.

"We're in maturity and spending like we're in introduction. Move the money from new-user ads to keeping the ones we have."

Acquiring another user has gotten expensive, so the budget should shift toward reducing churn.

"That's not a decline signal, it's one channel breaking. Everything else is flat."

A call to separate shrinking demand from a single blocked path into the product.

"Before we can get to growth we have to fix retention this quarter. Pouring more in now just runs out the bottom."

Ads won't help while the people they bring don't stay, so the order of work should change.

Pagedeck makes this call once a quarter. Mia puts three readings next to each other for each product — quarterly growth, the cost of acquiring one user, and the share still active four months later — and settles the stage before anything else gets discussed. Last quarter free-plan growth fell from 44 percent to 15 percent, and because acquisition cost rose at the same time, the team called it the end of growth. That one call changes every decision that follows.

Ravi came in with a proposal to double the search ad budget and it was put on hold in that room. Engineering time went instead toward shortening how long it takes a team that has already signed up to create its second document. What Grace watches in this meeting is whether the products are in different stages from each other. If the free plan is at the end of growth while the enterprise tier is still in introduction, company budget tilts toward the second. Writing the call down happens in the same session: one line saying free plan is late growth and enterprise is introduction, with the three numbers behind it alongside. When the call changes next quarter, that record shows exactly what moved.

The most common mistake is assuming a product advances to the next stage on its own if it survives long enough. The curve printed in every textbook runs smoothly from left to right, so it reads as a path a product walks. But that curve was drawn afterward, from products that made it all the way. A large share of what reaches the market stalls in introduction, and the growth section of their curve never gets drawn at all. Left in place, this assumption keeps a failing product alive for two years on the strength of the phrase "we're still early." Teams that have been burned write down, at launch, the number and the date that would count as reaching the next stage — a hundred paying teams within six months, say — so the decision to rebuild or stop rests on a figure instead of a mood. The number does not have to be the right one; it only has to exist before the quarter that tests it. Without the date, "early" becomes a place to park a decision, because the explanation that covers a bad quarter covers the next eight just as well.

The second mistake is reading decline as the stage where you shut things down. The name invites it. Decline describes falling revenue, not vanished profit. Stop spending to acquire new users and the margin on the customers who remain can be the fattest the product has ever produced; a ten-year-old product maintained by one engineer can still collect several hundred thousand dollars a year. The way back isn't sealed off either. Rebuild the same job in a different form and that product starts a fresh introduction. Read decline as a shutdown notice and you cut off thousands of customers who are still paying and still working in the thing. Refuse to acknowledge the stage at all and you keep feeding people and ad budget into something that isn't coming back. So the first move in decline isn't deciding whether to end the product — it's putting maintenance cost and remaining revenue side by side. Only after that comparison does one of the three paths make sense, and the answer differs by product even inside the same company.