The Hidden Costs of Building the Wrong Things
A product person’s job, at the end of the day, is to build the right product. Now, there’s a lot that goes into that (as can be evidenced by the plethora of books, articles, training materials, and more on the matter) but I’m here to talk about something else. The flipside.
What happens when you’re building the wrong things?
Because this happens more often than we probably know or care to admit.
Why do we build the wrong things?
Sometimes it’s because we’ve misunderstood what the business needs, or what the customers were asking for. A lot of the time, it’s a case of scope creep—all those little rabbit holes we convince ourselves that we need to build out into fully-fledged feature areas when something simple would have sufficed.
And sometimes because we end up influenced—or downright forced—by the wrong stakeholders who just don’t get what’s at stake.
What is at stake?
You might be filling your product with features that never get used.
It’s way too easy to say “Sure, we can add that while we’re in there”, and not realize the extra cognitive overload this gives your users in your app or that the new functionality will be used only by a tiny fraction of your user base in the long run.
It’s causing stressful crunch periods to get everything out.
All these extra pieces add up and end up creating more effort to finish off than ever estimated, so it slows down the last 20% of the project work to a crawl. There’s more to integrate, test, and document than you went in expecting. This has an effect on your team’s mental health, too, if every release is heavier and harder than anticipated.
A sea of missed milestones and eroded trust.
By not defending your product pipeline’s ‘Yes’, you create knock-on effects across the business, making it harder and harder to deliver on anything with certainty. Others lose their faith in the product management process, and you then find it harder to get buy-in for your next big initiative for fear it becomes another time suck.
The opportunity cost of building the right thing!
If you’re heading down the path of building a bunch of features that aren’t going to have a huge impact, they are jostling for space in your product development pipeline with any experiments or initiatives that might actually make a difference. Your team only has so many resources and so much time, and for every lackluster piece of work completed, that’s the time that could have been spent solving real, juicier problems.
How to stop building the wrong things
All of these unwanted paths of building the wrong thing can be summarized with two things. Fix these two things, and you’ll never waste large amounts of precious time building the wrong thing again:
Problem: Incorrect assumptions about what’s actually needed in the first place.
Solution: Better discovery and research practices, earlier in the process.
We could go on about this topic for a long time as it’s so fundamental to good product management practices, but that’s not what this article’s about. Here are some of the best resources you’ll find on discovery:
What is Continuous Product Discovery and are you Doing it right?
“Continuous Discovery Habits’ by Teresa Torres
Problem: An inability to stop and iterate if on the wrong path.
Solution: Agile processes with short delivery cycles that create opportunities to iterate regularly.
Agile is nothing new either, but too often people follow the motions of agile but don’t take advantage of the best advantage it unlocks: the ability to take a breather between sprints or cycles to check that previous work has actually made an impact. If you’re skipping this step, you just have a series of small, inefficient waterfalls, and aren’t lean at all. The most impactful part of lean is enabled by agile in that it allows you to build, then measure and learn. Don’t skimp on the measuring and learning, or else you’re probably going to end up just building the wrong things.
Sunk-cost fallacy: your worst enemy
A special mention for one reason why product people around the world find themselves building the wrong thing. Sunk-cost fallacy.
You’re probably aware of sunk-cost fallacy. You’ve also probably fallen prey to it more than a few times in your product management career.
Psychologically, we attach such value to work that’s already been done or is in progress, and it regularly blinds us to the harsh truth that sometimes the final product—where this thing is headed—isn’t actually worth the journey after all. You’re better off just leaving the half-finished work actually half-finished, and focusing your efforts on whatever truly is turning out to be valuable in your more refreshed research and discovery work.
Doing so is nothing to be ashamed of. In fact, it’s only when you step away, that you get a blast of fresh air and realize that you were burying yourself in these sunk costs—and that getting away is the real hero move! It takes guts to be that reactive and to iterate based on new information that’s otherwise tough to swallow.
One of the best ways to determine if you’re falling foul of sunk-cost fallacy? Pretend you’re an outsider, contracted to come in and look at your business and product with fresh eyes.
Imagine you’ve got no ties to the work that’s been done, and no investment in the effort so far. Your job is just to point out what you think is the best route forward.
Would you, hand on heart, still recommend the path you’re on as the path forward? Or would you place more value on more up-to-date research which is leaning another way?
If that research doesn’t exist, but you’ve got a niggly feeling that some outsider would question the effort you’ve been putting in without sense-checking along the way, then NOW is a good time to run some extra discovery exercises to check you’re on the right path.
You might not like the answer, but good research and discovery techniques will rarely lead you astray, unlike your own internal biases.
Conclusion:
What do you think? Have you ever built the wrong thing into your product, only to find out too late that it was all for naught? Let us know what happened and how you dealt with it. We’d love to hear about your experiences so we can help other product people avoid these pitfalls.
