New Product Development Process: 7 Classic Stages

A software team inherits a product development template built for a consumer packaged goods company: seven stages, ending in one "commercialization" milestone. They hit every stage on schedule, reach commercialization, and then keep shipping updates for the next three years, because that's just what software does. Nobody ever updates the template to say so.

That gap exists because the new product development process most teams inherit traces back to a classic framework first documented decades ago. It laid out seven sequential stages that successful physical-product launches tended to follow, and the framework has outlived whoever first named it.

This article is for the product lead who's inherited this classic framework and needs to know which parts of it genuinely apply to software, and which don't.

Key Takeaways

• The classic new product development process has seven stages: new product strategy, idea generation, screening and evaluation, business analysis, development, testing, and commercialization.
• The framework comes from a classic study of physical product launches, not software specifically.
• Robert Cooper's later Stage-Gate evolution added go/no-go decision points between stages, which maps onto software far more cleanly than the original linear version.
• Two of the seven classic stages, test marketing and commercialization, don't have a clean equivalent in software, where launch is usually iterative rather than a single event.
• Forcing every classic stage onto a digital build produces the same failure as skipping the framework entirely: a process that looks rigorous but doesn't match how the work actually happens.

The 7 Classic Stages

New product development process stages run in a specific, deliberate sequence in the original model, each one a checkpoint before real investment happens.

1. New product strategy sets the criteria a new product idea has to satisfy before anyone spends real time on it, tied to the company's broader objectives.

2. Idea generation casts a wide net for concepts that might satisfy that strategy. The original research behind this framework found that companies needed roughly seven ideas to find one that eventually succeeded.

3. Screening and evaluation filters that wide net down to the ideas worth real investigation, ranked against criteria like strategic fit and resource requirements.

4. Business analysis is the detailed investigation stage: market size, projected costs, and expected return, done before any serious development spending.

5. Development turns the surviving concept into an actual product, the stage most people think of first when they hear "product development," even though it's fifth in the original sequence.

6. Testing validates the product with real users or a limited market before full launch, catching problems while they're still cheap to fix.

7. Commercialization is full-scale launch: production ramps up, marketing goes wide, and the product reaches its complete target market.

From Linear Stages to Stage-Gate

Robert Cooper's stage-gate process for new product development, introduced in 1988, changed the framework's most important limitation: the original model had no formal way to kill a bad idea partway through.

Cooper's Stage-Gate system, developed at the Product Development Institute, inserted a go/no-go decision gate between each stage, forcing a deliberate choice to continue funding a project rather than letting momentum carry it forward by default. That single change is closer to how a well-run software project should work than the original linear model ever was.

The gates matter more than the stages they sit between. A team can run the exact same seven activities as the classic model and still fail the same way it always did, if nothing at any point actually has the authority to stop the work.

The gate is the mechanism that makes screening and business analysis mean something beyond paperwork.

Decision signal: if a team can't point to a specific decision point where a project could have been killed and wasn't, the gates exist on a slide deck and nowhere else.

Where the Classic Process Holds Up for Software, and Where It Doesn't

The early stages of the classic model translate well. New product strategy is close to what a product strategy document should already state. Idea generation and screening map cleanly onto discovery and prioritization work most product teams already do.

This is exactly where digital product development as a discipline built its own separate stage list rather than inheriting the classic one wholesale, keeping what mapped cleanly and replacing what didn't.

Business analysis holds up too, in spirit if not in exact form: understanding the cost and expected return of a build before committing real engineering time is exactly the judgment a software team needs, whatever it gets called internally.

That judgment looks different depending on the industry running it. A food company's business analysis weighs manufacturing volume and shelf space. A medical device company's weighs regulatory approval timelines.

A software team's weighs engineering hours against a specific metric the build is meant to move, but the underlying discipline, don't commit real resources until the numbers have been checked, is the same one this framework has always documented.

Two stages break down. Testing, in the original model, means a limited real-world release before full commercialization, which is close to how software actually works: a beta, a phased rollout, a canary release.

But commercialization assumes a single, discrete launch event, full production, full marketing, full market reach at once. Software rarely works that way. A digital product ships, then keeps shipping, in a way a 1982 manufacturing line never had to account for.

Forcing a single "commercialization" moment onto a product that's actually meant to iterate indefinitely after launch is where the classic framework does real damage if applied too literally.

Where Teams Force-Fit the Wrong Process

The failure here isn't ignoring the classic framework. It's applying every stage literally to a build that doesn't work the way 1982 manufacturing did.

• What it looks like: a team treats "commercialization" as a single, final launch date, ships everything at once to hit it, and treats anything shipped afterward as a failure to plan rather than the normal, ongoing nature of a digital product.

• Why it happens: the classic framework is well documented, well taught, and genuinely useful for its first five stages, which makes it tempting to assume the last two translate just as cleanly. They don't, because software has no manufacturing ramp-up and no single retail shelf date to hit.

• How to fix it: keep the strategy, idea generation, screening, and business analysis stages largely intact. Replace testing and commercialization with agile product development's iterative release model: a phased rollout that keeps shipping and adjusting, rather than a single commercialization event the whole plan builds toward.

Let's Sum Up!

The classic new product development process earned its 40-year staying power for good reason: the discipline of screening ideas, analyzing the business case, and validating before full investment holds up regardless of what the product actually is.

What doesn't hold up is the assumption that development ends in one commercialization event. Software keeps shipping after it launches, and a process built for a 1982 manufacturing line was never going to account for that on its own.

Classic Informatics offers product engineering services built around how software actually ships, borrowing the parts of the classic frameworks that still hold and replacing the parts that don't. If you're trying to fit an inherited process to a build that doesn't match it, we're happy to look at where the gap is.