Product Development Life Cycle: Why Building Wrong Beats Competitors
Managing risk sounds smart. It occasionally leads to stupid behavior.
By Tristan Kromer · Product Development Life Cycle
In a lean business model, we need to manage our risks. We sound very intelligent when we do this, but it occasionally leads to incredibly stupid behavior. For example, we might insist on stealth mode development so that the risk of a competitor stealing our super special sauce is mitigated. But here’s how the folks at LUXr represents the Time Spent Building Stuff vs. the Risk of Building the Wrong Stuff:
Building the Wrong Stuff
Of course, if we build the wrong thing we get the joy of going back to the start. And since the only point at which we realize we built the wrong thing is at the end of our super long product development life cycle and PR blitzkrieg launch, we’re kind of screwed at that point. Contrast that with working in…
Quick Answer: The biggest risk in the product development life cycle isn’t competitors stealing your idea — it’s building the wrong thing entirely. Risk doesn’t grow linearly; it compounds hyperbolically as we layer on wrong features, UX confusion, feature creep, and dwindling funds. Working in small iterations limits how far off course we can get, so we only ever need to revert a little code and marketing before correcting direction. As product managers, we should fear long waterfall cycles far more than stolen ideas.
Small Iterations
We can still build the wrong thing, but in this case, we only need to revert a little bit of code and/or marketing before we can proceed in the right direction. So our project never accumulates too much business risk.
Hyperbolic Risk
You may object that even if you work in one year long waterfall development cycle, you’ll only make some small errors and in that case, you can just go back a little bit and fix that one small problem. Then there wouldn’t be that much risk, right? Just like the small iterations. you’d just need to tweak your product. Without getting into the deep technical reasons why this is going to be completely impossible if you’ve made a fundamental architectural error, let’s just look at it from an experimental point of view. How do you know which part of your product is screwing up the user experience? Do your users want more buttons and widgets? Do they want less? Does widget A plus button B make a bad user experience but both together are confusing? Put another way,
But even worse, The risk in our long development cycle looks suspiciously like this:
The actual risk may approach infinity as we compound the risk of building the wrong thing, the risk of being unable to debug the user experience, the risk of running out of funds, and the risk of feature creep.
Frequently Asked Questions
What is the biggest risk in a long product development life cycle?
The biggest risk is building the wrong thing entirely and only discovering it at the end of a long development cycle and launch. As the article explains, risk compounds over time — combining the risk of building wrong, being unable to debug the user experience, running out of funds, and feature creep. The actual risk can approach infinity in long waterfall cycles.
How do small iterations reduce the risk of building the wrong stuff?
Small iterations limit how far off course we can get. If we build the wrong thing in a short iteration, we only need to revert a small amount of code and marketing before correcting direction. Our project never accumulates too much business risk because we’re continuously validating and adjusting rather than betting everything on a single big launch.
Why can’t you just fix small errors at the end of a waterfall development cycle?
Even if you think you’ve only made small errors, the problem is diagnosing which part of your product is hurting the user experience. Do users want more buttons? Fewer widgets? Does combining feature A with feature B create confusion? When everything ships at once, it’s nearly impossible to isolate what’s wrong — especially if there’s a fundamental architectural error underneath.
Why is stealth mode risky for product development?
Stealth mode might feel smart because we’re mitigating the risk of competitors stealing our ideas. But it also prevents us from getting early user feedback, which dramatically increases the risk of building something nobody wants. As product managers, we need to weigh competitive secrecy against the far greater danger of investing months or years into the wrong product.
Does risk grow linearly or exponentially over a product development life cycle?
Risk grows hyperbolically — not linearly. As we spend more time building without validation, risks compound: building the wrong thing, inability to debug user experience issues, running out of funds, and feature creep all stack on top of each other. This means the longer we go without feedback, the more dangerous each additional day of development becomes.
Comments
Loading comments…
Leave a comment