Product Development Isn’t a Straight Line, and Ignoring the Loops Costs You

Product development is often drawn as a straight line of stages, but validation and testing routinely send work backwards. Those loops are cheapest when they come early, and a stable product with proven demand rarely triggers them.

Subject
Why product development stages loop back
Published
19 AUG 2026
Reading time
4 min

In short

Why it loops
Validation and testing produce information no earlier stage can. Looping back on what they find is the process working, not a broken plan.
The cost
One study of venture-backed shutdowns ranks a product the market didn’t want second only to running out of money as a cause of failure.
What to do
The earlier a loop fires, the cheaper it is: a killed idea costs little; a shipped product sent back costs a public rebuild.
In this post · 3 sections
  1. —In short
  2. 01Feasibility decides how the software is built
  3. 02Testing decides how expensive a mistake gets
  4. 03Name the stage you’re stuck at
The same argument in 2:54. Our graphics, AI narration.

Product development is often mapped as seven boxes in a row, each feeding the next: idea, screening, validation, feasibility, design, testing and launch. Real teams don’t work that way. Validation and testing routinely send work backwards, and a team that ignores what they find pays for it later.

CB Insights looked at 431 venture-backed companies that have shut down since 2023. Of the 385 with a known cause, 43% failed partly because the market didn’t want the product, second only to running out of money. CB Insights itself notes that running out of money is almost always the final cause, not the root one. The validation stage exists to catch the wrong product cheaply, before anyone builds it.

CB Insights, “The top 9 reasons startups fail,” updated March 2026 — 431 venture-backed shutdowns since 2023, 385 with an identifiable cause. cbinsights.com/research/startup-failure-reasons-top

Seven product development stages in sequence, with two feedback arcs showing validation sending work back to the idea stage and testing sending work back to designSTAGESNOT A STRAIGHT LINETHE LOOPS ARE THE POINTDWG Nº 107 STAGES, 2 LOOPSIDEASCREENVALIDATEFEASIBLEDESIGNTESTLAUNCHno product-market fitusability failureFeedback loops backCheap to redo earlyDesign is the pivot
Both feedback loops exist because real information arrives late: you can't know whether the market wants this until you validate, and you can't know whether the design works until real users test it.

Feasibility decides how the software is built

Most versions of this diagram include a feasibility stage, and they rarely say what gets decided there. In practice it’s usually one question about how the software is structured: build one system, or split the work across several smaller ones that talk to each other. The answer turns on how many teams need to release without waiting for each other, and how often they plan to release. It also turns on whether every part of the product must see the same data at the same moment.

For engineersThe choice between one system and several smaller ones comes down to three checkable questions.

The two options are a monolith and microservices. The three questions: how many teams need to deploy independently without blocking each other, called team topology; how often the team expects to release, called deployment cadence; and whether the data each service touches must stay perfectly in sync across a transaction, or can catch up a moment later. Google Cloud’s own introduction to the two patterns contrasts them in general terms, though it doesn’t name these three questions itself.

Google Cloud, “What Is Microservices Architecture?” cloud.google.com/learn/what-is-microservices-architecture

Testing decides how expensive a mistake gets

The advice to test early and often is right, but says little on its own. Three habits decide whether it happens. No code change ships until it passes its own checks, and most of those checks run fast. A change one team makes that would break another team’s work is caught before it reaches a customer.

For engineersThree checks make ‘test early’ something a team does.

Continuous integration (CI) blocks a merge until its tests pass, instead of reporting failures without stopping anything. A test pyramid — many fast unit tests, a thinner layer of slower integration and end-to-end tests on top — catches most mistakes cheaply, instead of the slow, flaky, upside-down shape teams back into under deadline pressure. And contract tests check that a change to one team’s application programming interface (API) breaks a build rather than a customer’s request weeks later.

Name the stage you’re stuck at

Products stall at different stages for different reasons. A team that has validated demand but can’t make the feasibility call is missing experience in structuring software. A team with a tested design is missing only the people to build and ship it. The decision in front of you is which stage your product is stuck at, because that decides what it needs next.

Updated 26 Sep 2026: corrected a claim crediting Google Cloud’s framework with three architecture criteria it doesn’t name, cited Google Cloud’s introduction to the two patterns instead, and removed the post’s own pitch and call to action.

AGNIZAR
Production AI · System architecture · Fractional CTO

Agnizar builds custom software and AI that fits the systems you already run, then hands it over or keeps it running. Every job starts small: one bounded piece of work, one named result, one clear decision. Tell us what you’re building; a senior engineer replies within a business day, not a salesperson.

Tell us what you’re building