A systematic and objective way to choose the ideas to test and build using evidence and other factors.
Why Good Product Ideas Don’t Survive Good product ideas, ones that create significant value for the business and the users, are rare and precious things. Look at your product and you’ll immediately recognize them. These are the features that are used the most, that drive conversions, that keep your customers onboard. Think Google Search Suggestions, […]
Prioritization is the process of choosing which ideas/bets to invest in and which to postpone or park. It entails two cognitively-hard tasks: 1) evaluating the merit of each idea, and 2) comparing multiple ideas and choosing an order of precedence. If that’s not difficult enough, prioritization decisions are often a flash point of debate and
In part 1 of this article series I discussed the principles high-performing companies use to accelerate and improve the quality of their decisions. In this article I want to give you specific techniques to do the same, including the ACID model, not judging decisions by their results, and publicly killing HiPPOs. This is a long
I regularly ask product people how they choose what to develop. Today, an increasingly popular answer is “we focus on the most important user problems”, or its more modern cousin “we prioritize opportunities”. Underlying these answers is a classic model that asserts that product development has to start with mapping out and prioritizing customer problems,
Observing tech companies you may notice a broad, disturbing phenomenon: everyone’s hard at work “selling” their product ideas — stakeholders and engineers are selling to product managers, product managers are selling to management, and management is selling to everyone (just listen attentively in the next all-hands meeting). As a product manager I too had to
When talking to product managers, company leaders, and customer-facing folk, a common belief surfaces: if enough customers (b2c), or an important customer (b2b) ask for something, then we should build it. This axiom is reflected in prioritization discussions as well as in many product management tools that rank ideas by “customer votes”. Customer feedback, whether it
Idea prioritization exercises are often hard and unsatisfying. The discussions run long and the decisions feel suboptimal. Using numeric methods like ICE or RICE adds more process, but not necessarily more clarity, as the numbers feel “made up”. I’ve written in the past about how to make better use of ICE, but I have to
Q: My manager keeps instructing me to build certain features that were decided on by management without my input. I’m not happy not to be consulted, and I disagree with many of these ideas, but my manager always presents them as a “must” and is not willing to challenge the decisions. What can I do?
UPDATE: An expanded version of this article is available as a free eBook: ICE Prioritization Done Right ICE (Impact, Confidence, Ease) is a popular idea prioritization method that has lately been getting some bad press. Some people openly warn against it as the worst thing you can do to your product. In this article I’ll explain
Here’s a sentence that always fills me with dread: “We plan to adopt this new approach, just as soon as we launch these must-have features.” The must-have feature list (AKA catch-up features) has become my nemesis—it’s forever standing in the way of progress. Usually it’s a laundry list of things copied from leading competitors, from