Have you heard? My new book Continuous Discovery Habits is now available. Get the product trio's guide to a structured and sustainable approach to continuous discovery. What should you build next?
This is one of the most important decisions you’ll make as a product manager.
If you work in an Agile environment, you’ll make it sprint after sprint. Much of your success will depend on these decisions.
Don’t Do What Most People Do
If you Google “how to prioritize features” you’ll get countless blog posts about creating a spreadsheet or matrix that scores each feature on the following dimensions:
- Customer Demand
- Time to Build
- Stakeholder Needs
Add a weight to each dimension and tally a total score. Sort by total score and build the features that have the highest score.
I never prioritize this way.
Assume Your Competitors Are Wrong
Customer demand is typically scored by counting incoming customer requests or worse by defining must-haves and nice-to-haves based on competitors’ feature sets.
This is why we call it “requirements gathering.”
I hate that phrase and I think it’s the worst way to build a product.
If you want to build a great product, why would you copy your competitors? Why would you let your customers define what you build?
You assume that if your competitors build a feature it must mean people want it. This is a faulty assumption. Your competitors aren’t doing customer research. They don’t know what the customer wants any more than you do. They are having the exact same arguments about what to build next as you are.
If you remember only one thing, remember this:
Your competitors are no better than you at understanding your customer. – Tweet This
First of all, if you defined a clear vision and picked a unique position in the market, your competitors’ customers are not your customers.
Second of all, if you define your customer segment and get to know them inside and out, you are the best judge of what they need. Not your competitors.
Don’t waste time building the same crappy features all your competitors have.
But what about customer requests? Those must matter.
They do. They matter a lot. But not in the way that you think.
Customers will always tell you what features they want. But these features are rarely what you should build.
Customers are limited by what they know. They are limited by what is feasible today. If you build what they request, you’ll build yesterday’s product.
It is your job to understand the intent and the need behind the feature request and translate it into tomorrow’s solution. – Tweet This
Customer demand should inform what you build, but it should not dictate what you build next.
Time-to-Build Doesn’t Matter
If you use time-to-build to prioritize what to build next, you’ll end up with a product full of easy solutions. What will keep a competitor from coming in and stealing your lunch?
I understand you are working on short timelines. You have 3 months before you’ll run out money. You have to meet aggressive growth goals. Three customers are at risk. I’ve heard it all.
That’s fine.
Time to build matters. But it doesn’t matter when prioritizing. – Tweet This
Decide what’s the most important thing to build next (more on that below) and then figure out how to build it in the time that you do have.
Don’t let your timelines dictate what you build next. That’s the fastest way to a mediocre product.
Stakeholders Shouldn’t Be Involved
I’m not going to make friends with this section. But I’m not here to help you make friends (Dale Carnegie can do that). I’m hear to help you build great products.
Stakeholders (as in your CEO, executives who are not on your product or UX team, sales) should not be involved in feature prioritization. Period.
Keep them out of the weeds. Yes, their input matters. Yes, you need to take into account business needs. But if you are sitting in a meeting ranking a list of features, you are building a product by consensus.
Products built by consensus suck. Please don’t build products that suck.
Instead, get stakeholder buy-in on the goal you are pursuing. Get stakeholder input on how different features will impact that goal. But don’t let other stakeholders dictate what to build next.
It’s your job to manage all the conflicts. To figure out how to meet all the competing demand. You should be prioritizing what to build next.
Prioritize Based on Expected Impact
We set goals for a reason. They help us focus. They give us the freedom to relentlessly chase after a target. They separate the planning from doing.
But they only do this if you use them to guide what you do next.
You’ve already taken into account what your customers need and what is most important to your business. That is reflected in your goal. You don’t have to do this again when you prioritize.
You only need to prioritize on one dimension – expected impact on your goal.
That’s it.
You already estimated expected impact back when you were evaluating ideas. You already tested those estimates for your top ideas. Prioritizing is easy. Evaluate the results of your top tests and build the most promising ones.
But what if I run out of money in 3 weeks and my top idea will take 6 weeks to build? We’ll look at that in the next post. Don’t miss it. Subscribe to the Product Talk mailing list.
