Feature Frenzy and its close cousin Shiny Object Syndrome (S.O.S) are startup killers. They confuse product direction, muddle the sales pipeline, and frustrate developers and eventually our users – and then, as a result, all of us.
And yet, we want aspirational and aggressive product roadmaps so that we can excite the market with our product vision, demonstrate responsiveness to early customer feedback, and possibly share our vision and direction to seek investment to grow the company. Sharing a big vision, being creative, and coming up with exciting and dynamic solutions are why we became entrepreneurs after all!
So, the challenge is real.
Recently, I pulled together a workshop on how to avoid Feature Frenzy but maintain an aspirational product roadmap, and here are 10 tips to consider:
Keep your aspirations focused on your business first, not your software.
Software should enable your business. New features (i.e. more software) should have clear and direct business value. See if you can test the business value first without building more software. It’s amazing what you can figure out with some conversations, some data, and maybe a spreadsheet. If that won’t cut it, just make sure you are building the smallest amount of software possible to test the business value.
Be clear about the purpose of your roadmap.
There are lots of roads and lots of maps that serve lots of purposes. So, you just need to be clear at all times which one you are talking about and who it is for. The roadmap for your tech team and the roadmap for your investors or your customers are not the same in detail or message – even though they should align in direction.
Never forget: Products are for customers, so your roadmap should take them somewhere. Entrepreneurs like new things and get excited by the next thing. But, the milestones on a product roadmap should be focused on delivering some tangible value or specific outcome to your user.
Beware solutions looking for problems.
Entrepreneurs are problem solvers, so we come up with solutions. New features can be dazzling for us and for our customers, but a pile of new features that seem like a solution to us doesn’t necessarily solve a customer problem as they understand it.
A startup product roadmap should focus on finding answers to critical market hypotheses. Our early product development priorities and sequencing should lead to validating or invalidating the hypotheses that are core to early adoption. If it includes anything else, it’s probably noise for you, your team, and the client and will obfuscate the testing of the value proposition. It’s easy to come up with features customers love, but a lot harder to build a product they will actually use.
Beware solutions to problems that are nice-to-solve but don’t need to be solved.
Ideas and feedback from the market on what’s nice-to-solve often comes clearer and faster than the underlying what-needs-to-be-solved. We have to dig deeper into our customer problems than they are able to and come up with solutions they don’t have the time, inclination, or experience to create for themselves.
Be aware that users who say email is their problem will often design email as their solution. I have lived this one many times trying to improve communication in schools and in hospitals. Don’t ask customers for solutions. You have to dig into their problems, listen for understanding, and solve from there.
Beware the shiny object.
When you see it, check your reflection in it before you grab it. Figure out why you think you need it.
Just say no.
We have to communicate that we are listening and care about our customer feedback even when we don’t take it. But feedback like: “If your product just did X, we’d be ready to buy” or “If you just added this button, we’d start onboarding all of our users” is almost never true. If we chase those things, we will almost certainly kill our product.
Be honest about what you can deliver and when – and then deliver it.
Overselling puts our product roadmap in chronic debt and is a sure path to disappointed customers, frustrated product managers, and uncreative developers. Selling something small but valuable and delivering it is a win. Selling something huge and then only delivering that same small-but-valuable element becomes a loss.
As a bonus, I highly recommend watching this video: 20 Years of Product Management in 25 Minutes by Dave Wascha
