What should we build next?
Where product ideas come from and how to prioritize them
It’s a classic problem — resources are limited, development is expensive, and we need to move fast. But move fast toward what? What’s worth spending our scarce time and effort on? Where can we get the most bang for our design and engineering buck? Do we double down on our current strategy or pivot to a new one?
The lifeblood of any tech company is continually finding ways to build things people need.
In today’s “agile” world, we do this iteratively — meaning we are constantly forging a path from Point A, where we are today to Point B, a moving target that shifts based on any number of inputs (market and user feedback, vision and strategy of leadership, and so on). Wasting time and resources building the wrong thing is like taking a wrong turn off of this path. Too many wrong turns can easily lead to a product lacking fit with its intended market and eventually, if left unchecked, to the demise of the company.
So as we move at breakneck speed, down a trail with few discernible markers, toward an ever-changing and often nebulous goal, how do we make the daily decisions of where to plant the next foot and take the next step forward?
The truth is, most product decisions are educated guesses made by smart people who know their product, their business, and most crucially, their users. We call this “intuition”.
Gathering the raw materials
High-level vision and strategy
Product leaders — good ones — don’t just create products on a whim. Strong products are born of leaders with a deep knowledge and empathy for a group of people with a problem, an idea of how to solve it, and the expertise to execute on that idea.
So it shouldn’t be surprising that one of the persistent guiding lights for a product tends to be the vision that these leaders project forward into the next 6 months, 1 year, 5 years, or longer.
Success is what happens when your vision for your product lines up with what the market needs.
From this vision we derive a strategy which defines where we will play and how we will win there. Think of it like this: in a world of endless options and so much surface area for opportunity to manifest, where are we going to focus our efforts and why? These choices set the tone and define success for a product. Often they set the boundaries on what ideas will and will not be pursued.
The essence of strategy is choosing what NOT to do. — Michael Porter, Harvard (emphasis is mine)
For example, Facebook operates in the problem space of connecting people to each other. It’s clear that, from a strategic standpoint, they see video playing a part in solving this problem — hence the strong push into FB Watch of late. But pursuing progress in video has undoubtedly meant that they have had to choose not to pursue this goal in other ways, at least for now.
Formulating a cohesive high-level strategy and the why behind it lays the ground work for everything else thereafter.
Get input from outside the bubble
I have some good news! The answers to all (ok, probably most) of your questions about your product do exist. Here’s the catch, they probably aren’t floating around in your head somewhere.
Some of the best ideas for how to push your product and business forward are outside of the bubble in which you and your team work.
All too quickly product teams can get too close to a problem or (God forbid!) to a specific solution. We formulate a mental model for how we think the world works and have a tendency to ignore disconfirming evidence to the contrary. It was in response to this reality that Lean Startup legend Steve Blank coined the phrase “Get out of the building”.
Getting out of the building, or what I like to call “the bubble”, can be accomplished in many ways — all of which involve direct interaction with your customers. But however you choose to go about collecting data and deriving insights from it, the goal here is to identify problems your users are facing so you and your team can find ways to solve them (more on that later).
Sitting in on customer support calls or emails can give you a great idea of the problems that your users are facing every day when engaging with your product. Just an hour or two a week listening in to calls on the front lines can give you great insight to bring back to the team and inspire ideas to make your customers’ experience better.
Tracking support requests can give you a more quantitative view of the issues your users are facing. All tickets should be tagged with the categories to which they belong which can then broken down into a Pareto analysis to discover the 20% of issues causing 80% of the customer pain.
Chat with your users while they’re using your product. Tools like Intercom can put you right there in the moment while your user is thinking about you.
Ask for feedback from your users. There are many tools for directly asking for feedback from users. One of the simplest and most trusted is the Net Promoter Score (or NPS). It has its flaws and won’t give you much to answer the whys behind the data, but can be a good tool for understanding broad changes in customer sentiment over time.
Make a habit of talking to your users. You don’t have to organize a big research study, but just offer something of value (a $50 or $100 Amazon gift card will usually suffice) to a user to spend some dedicated time talking through some questions about using your product or playing with a new feature you just released or are considering building. Make sure to record the session or find a way for other members of the team to participate in the insights you gather from these conversations. If you make a habit of this and build a pipeline of these interviews, this is a great way to get regular, useful, relatively cheap feedback from people actually using your product.
Two disclaimers: (1) If a user tells you something you don’t agree with, that doesn’t mean they “aren’t your target user”, but it also isn’t enough evidence to shift your strategy completely. This should just be a sign that you need to ask more questions to more users to truly understand if this is just an anomaly. (2) Don’t run crazy with qualitative data. You don’t want to build something only a small vocal minority of your users are asking for. (see this awesome Intercom blog post for more on this and other reasons to say yes to features.)
Your team is a goldmine
No one knows your problem space like your users, but there is no one with more expertise on your product and business than your team. You should always have an ear to the ground or, better yet, set up direct channels through which your team can make their voices heard about problems that need solving or ideas to make your product better.
At any given time there is a list of problems that the business needs to overcome. In fact, most ideas can (and should) be traced back to an implied underlying problem trying to be solved. These problems are the raw material for ideation.
Finding problems to solve should be in the DNA of all product teams.
Create mechanisms for your team to surface problems and ideas. This may come in the form of regular meetings, a dedicated Slack channel, or a mad-lib style document. Regardless of the exact mechanism the goal here is to source fodder for ideation.
Think it through on paper before opening it up to a larger audience. I’ve found it to be helpful to get people to write things down. The act of writing forces deeper thought and sets the stage for a more informed shared vision for the team to work with. Have your team consider the problem, other potential solution(s), and the business justification for their idea.
Keep your finger on the pulse of the business. You can drown in metrics and there are plenty of posts describing how to do so. This isn’t one of them. Decide on some metrics that tell the story of your business. Avoid vanity metrics that feel good but don’t tell the whole story. And make a habit of analyzing changes or deviations from expectations, both positive and negative, to hone in on what’s working and what isn’t. A good place to start is Dave McClure’s Startup Metrics for Pirates. When analyzing your business through the lens of these five metrics: Acquisition, Activation, Retention, Revenue, and Referral (AARRR… get it?), you can assume there will always be problems that need solving — to different degrees in different businesses and at different stages in a product’s lifecycle.
Circle back and double down
Building a product iteratively looks a lot like the scientific method. We derive hypotheses from observations, design experiments, and analyze the results to draw conclusions.
As a product team, at any given time we have several experiments at different stages of this process. After a test has run its course, we must analyze the results and determine the next steps. Sometimes these experiments back up our hypotheses, sometimes they don’t.
Spoiler alert — most product tests aren’t resounding successes or dismal failures, they’re somewhere in between.
And we must make the tough calls on whether we should double down on the solution we are testing or try to solve the problem a different way. Either way, the conclusions drawn from experiments on our product are great fodder for further ideation.
Connecting the dots — That whole diverge/converge thing
Ok, so now you’re armed with a solid vision and strategy, empathy for your users, and some specific problems to solve — derived from talking to users, understanding the challenges the business is facing, and drawing conclusions from testing previous ideas. Now what?
The crux of building good, sustainable products is connecting the dots between problems you can solve for users and methods of creating business value.
Get the team together to ideate. Bringing in team members from across the company is a great way to cross-pollinate and find novel solutions to problems. Pose the challenge to the group — which should be easy if someone has taken the time to write it up ahead of time — and facilitate the discussion that ensues. Be careful not to let the loudest voices in the room dominate. The goal here is to diverge in thinking and come up with many different methods of solving the problem as possible, after which the team can discuss and converge on which ideas they believe have the most merit.
For particularly sticky problems, consider a design sprint, a process that includes understanding the problem, ideating solutions, and actually prototyping them for early feedback. This isn’t a tool to pull out all the time as it takes incredible focus from a large team over several days. But it can be an extremely powerful method of making quick progress on a problem and feeling much more confident in a solution. (http://www.gv.com/sprint/)
The art and science of making product decisions
That’s a lot of inputs to make sense of. So how do you turn that into a cohesive roadmap?
Nail the core
Well, some of this depends on what stage of the lifecycle your business or this specific product is in. Early on your strategy should be focused on the things you can build to test some of the core hypotheses about your business — e.g. Before Uber could optimize users’ wait times, they first needed to find out if people would actually pay to ride around with other people. So if there are still open questions about your core business model, that’s probably where you should start. Once you get those nailed down, you’ll be able to circle back and spend more time on some of the smaller optimizations you’ve been wanting to tackle.
One lens through which to look at prioritization
Spoiler alert PMs: there’s no framework, system, or algorithm that can make these decisions for you. But that’s good news, right? Otherwise you’d be out of a job. However, breaking down each proposed feature based on a set of criteria your team agrees are important will at least serve as a starting point for conversation. Here’s a lens my team and I have found helpful (credit Intercom for this framework and Sean Ellis for previous versions).
Reach. How many users will benefit from this feature? Will every user encounter it during onboarding? Will only your most power-usery power users ever find it?
Impact. If you build this feature, how will it impact your business or your users? Will it increase revenue? Improve the user experience? Increase retention? By how much? A little? A LOT?
Confidence. If you build this feature, how confident are you that it will deliver said impact? Is this a problem you feel confident you and your team could or have solved? Is it just a test and it’s probably 50/50 at best? Is it a complete shot in the dark?
Effort (or Ease). Ok, great, you’re 100% confident you’ll double your business with this feature. I’m skeptical, but good for you! Now how much effort will it take for the team to actually deliver it? Is it so minor we could release it next week with one engineer working part time with her eyes closed and a hand tied behind her back? Is it a massive undertaking the whole team will be working on for the next 6 months?
Once you and your team feel you have good answers to these questions, order your backlog by RICE score as a starting point and have a discussion around why anything should shift from there. There might still be strategic (we need this to go after this market) or efficiency (if we’re working on this thing already we should do this one too) considerations and any number of other things that can and should cause you to consider shuffling these priorities.
After discussing everything you could build, at the end of the day someone will have to make the final decision on what you will build. Often this falls to the Product Manager, but it’s different for every company.
Whoever is making these final product decisions, listen closely — this part’s for you: You. will. not. be. able. to. make. everyone. happy.
Yes, this means at some point you will make a decision that your teammates, your leadership, a really vocal customer, or that one sales guy who has been requesting his client’s pet feature for 3 months will disagree with. That’s ok. The good news is that making these people happy isn’t your job, helping your team build the right thing is your job and losing sight of that can make this whole product development thing go sideways quickly.
That said, you should always make sure to make choices that you can defend to the team. After all, you don’t want to lose their trust or have them feel like you’ve disregarded their input.
Finally, a quick note on backlogs and roadmaps
Great! You’ve got some awesome ideas born out of customer feedback, aligned with your business, and prioritized by the team. These are the beginnings of a successful roadmap. But not so fast. Don’t get too attached. As good as this plan seems now, I tend to follow the Mike Tyson school of thought:
“Everyone has a plan til they get punched in the mouth.”
Inevitably you’ll get started on this plan, ship some awesome stuff, aaaaaaand the market will shift beneath your feet OR users won’t react as you’d expected OR any number of potholes and speed bumps will be thrown in your way forcing you to revisit your perfect plan. But not to worry — now you’re armed with enough know-how to roll with the punches.
Your thoughts and claps are much appreciated. There’s so much that wouldn’t fit here but after sitting on this post for a year because it wasn’t “done” I finally decided it was just time to ship it as-is. 🚢
This story is published in The Startup, Medium’s largest entrepreneurship publication followed by 289,682+ people.
Subscribe to receive our top stories here.
