Why the Last 10% of Product Development Takes So Long

Why the Last Ten Percent of Product Development Takes So Long

The last ten percent of product development often takes so long because it is not one final piece of work. It is the stage where the clean idea collides with different users, repeated use, manufacturing variation, customer expectations, and the cost of being wrong.

A prototype answers a narrow question. Can this mechanism work? Can this shape carry the load? Can this software complete the path? That answer can arrive quickly and feel like ninety percent of the job.

The remaining work asks a larger question: can other people depend on it?

Josh Sprague described this gap through Orange Mud, the endurance-gear company he started in 2012. His first improvised bottle pack used pieces from a gun holster, a ratchet strap, an old waist pack, and a hotel sewing kit. It worked on its first run. That proved that placing a bottle high on the back had merit. It did not resolve materials, appearance, fit, production, long-duration comfort, or the different ways a product sits on different bodies.

That is why progress appears to slow.

A working prototype changes the question

The first prototype creates a powerful emotional signal. Something that did not exist now works. The mechanism has crossed from imagination into the physical world.

That moment is real, but it can distort the estimate of what remains. The builder has evidence about one object, one user, one environment, and one period of use. A customer expects the product to survive many more combinations.

Josh said a normal design could take roughly ten months even though getting to what felt like ninety percent was relatively easy. One pack seemed fine for shorter outings but developed a pressure point around the three-hour mark. He stopped the design for about four months, then returned to it with a different approach. Another waist-belt concept moved in and out of development for about a decade.

Those examples do not establish a universal product-development schedule. They show why the first successful demonstration is a poor proxy for dependable use.

flowchart LR
    A["Working mechanism"] --> B["Different bodies and environments"]
    A --> C["Materials and manufacturing"]
    A --> D["Repeated use and wear"]
    A --> E["Instructions and customer expectations"]
    B --> F["Dependable product"]
    C --> F
    D --> F
    E --> F

Venture Step editorial diagram based on the product-development pattern Josh described in E119.

One prototype becomes a system

Early in development, the team can work with one object and one intended use. Later, it has to manage a system of relationships.

The material has to perform and be manufacturable. The product has to fit the design and survive actual handling. Instructions have to make sense to someone who did not build it. The supplier's definition of acceptable quality has to match the brand's. The customer has to receive what the sales page promised.

Each relationship creates edge cases. Resolving one can disturb another. A stronger material may add weight. A fit change may help one body and hurt another. A new supplier may improve cost and introduce variation.

The final stage is slow because the work has become coupled.

Hidden failures need time to appear

Short tests favor visible success. Long use produces accumulated evidence.

For endurance gear, rubbing and pressure can emerge only after hours. Josh used about three hours as a meaningful threshold for some packs because that was where problems began to surface in his own work. He also tested on people with different builds because a product that sat correctly on him could behave differently on a tall, lanky runner or on a woman's body.

Three hours is not a general testing standard. The useful principle is to find the duration and conditions where the product's hidden costs begin to accumulate. A kitchen tool may reveal strain after repeated cycles. Software may reveal permission drift or stale data after recurring runs. Machinery may not expose its maintenance burden until long after the first demonstration.

The prototype stage rewards invention. The dependable-product stage rewards patience, observation, and a willingness to revisit decisions that already felt settled.

The U.S. Consumer Product Safety Commission's manufacturing guidance makes the broader responsibility clear. A manufacturer should consider foreseeable use and misuse, applicable standards, supply-chain controls, documentation, feedback, and outside perspectives. Informal founder testing can reveal important failures, but it does not replace product-specific safety, testing, certification, or legal work.

Manufacturing turns design intent into variation

Seven Clay emerged from another version of the same mismatch. Josh described receiving finished work from outside embroidery suppliers that technically completed the order but did not meet the standard he wanted to send to customers. A remaining thread, placement issue, or weak finish can look small from one station in the process. It becomes the whole product when the customer opens the package.

That is the hard part of the last ten percent. Every upstream compromise becomes one downstream experience. The customer does not separate design, sourcing, finishing, packaging, and support. They decide whether the brand kept its promise.

The work now includes specifications that another person can follow, acceptable tolerances, supplier feedback, inspection, rework decisions, and a record of why a change was made. These tasks rarely appear in the first sketch. They determine whether the hundredth unit behaves like the one the founder approved.

Refinement needs a stop rule

The difficulty of the last stage does not justify infinite polishing.

Some founders keep changing the product because another change is always possible. That is not the same as resolving a meaningful failure. Refinement earns its time when it changes safety, core use, durability, clarity, manufacturability, or trust.

A useful stop rule asks what failure remains, how often it occurs, what it costs the user, and what evidence would show that the next change improved it. A recorded pressure point after three hours is a testable problem. A vague feeling that the product could still be better is not yet a development requirement.

This distinction protects both sides of the decision. It prevents a team from shipping a known failure simply because the schedule is uncomfortable. It also prevents endless revision from borrowing the language of quality without identifying a customer consequence.

The last ten percent is finished when the important unknowns have been reduced enough to make a responsible promise, the known limitations are visible, and the feedback system is ready to catch what the team still missed.

That may take longer than building the first prototype. It should. The prototype proved the idea could work. The product has to prove that someone else can trust it.

If you are preparing that proof, [[How to Test a Product Where It Will Actually Fail]] turns the principle into a real-use protocol. Readers interested in how process discipline shapes the work should also see Episode 115 on process goals and Episode 117 on building a product around the real operating problem.

Sources

This analysis draws on Josh Sprague's product-development account in [[E119 Full Transcript]], Orange Mud's company history, Seven Clay's account of its production work, and CPSC manufacturing best practices. The testing durations and development timelines are Josh's episode-specific examples, not universal benchmarks.

AI assisted with organization, source comparison, and editorial review. Dalton Anderson's transcript and the linked public sources control the factual claims.