Decide what to build
(and plan when to build it)

So far we’ve taken a closer look at the process for deciding what features might be most valuable to build, based on what your users need. Now we’ll look a little more at the other core responsibilities of the product manager: ensuring features are usable and feasible.

Once you’ve organized the user needs you’re interested in solving and generated some feature ideas, you’ll want to begin deciding what to build. This phase is known as feature prioritization. If you consider the task of prioritizing hundreds, or even thousands of features against one another so as to decide which to go and build next, it seems pretty daunting. That’s why prioritization is best done over time, and not during a single session.

What do PMs consider when prioritizing what to build?

Here are some tips for setting yourself up for success when prioritizing what to build next:

Define your target user: Most products serve many different types of users with subtly varying needs and goals. Decide in advance who your target user segment is – the group of users who are most important to the success of your product. You can’t please ‘em all! When push comes to shove, it will be better if you can make prioritization decisions because they’re what’s best for your target user, even if doing so means forgoing the needs of others.

Focus on specific objectives: On top of how well features meet the needs of different types of users, there are strategic reasons to build certain features as well. Perhaps a new onboarding flow isn’t hotly requested, but it’s a great opportunity for driving acquisition of your product. Or maybe you decide to spend engineering effort on a growth hack to help existing users invite others from their networks to start a trial of your product. Decide in advance what criteria you’ll use for evaluating feature idea. What’s most strategically important to your product, and to your company, right now? Retaining existing users? Acquiring new ones? Improving user experience? Improving platform reliability? Your objectives may vary quarter to quarter, but you’ll want to focus on one or two goals at a time so your team is focused on achieving specific measurable objectives rather than floating around aimlessly unsure of the strategic purpose of the features they’re delivering.

Prioritize in phases: In an initial phase you might sort your feature ideas based on what users have requested most frequently this quarter. That might help you realize how many ideas relate to helping users get up to speed in your tool more quickly, and that in turn might inspire an initiative to improve onboarding this quarter. That in turn will help you narrow your sights on other features that support this aim.

Validate your assumptions: Even when certain feature ideas get prioritized as candidates – serious features you’re considering building – it would be unwise to send them right to designers and engineers to begin working on them. Carrying out high fidelity designs and writing production code involve time-intensive work from highly skilled members of your team. It’s always best to take the features you’re considering working on and run them by customers first – particularly those who requested them in the first place. Do they still need these features? Do you understand their need correctly? Do they envision the same final solution you do? If there’s a discrepancy, is it a sign of misunderstanding the underlying need? Try to answer all of these questions before beginning work on a certain solution.

Champion the users’ needs: Ultimately, the product manager and the user experience designer (or “interaction designer”) share the responsibility of deeply understanding users needs, as well as ensuring any proposed solutions will be usable given the user’s background knowledge, skills, and experience. Often this involves user testing specific solution ideas to ensure users easily understand how they work. This can often be done on prototypes before a single line of code is written. The product manager should be involved in this process whenever possible, as it’s often your responsibility to share user context with other colleagues on engineering and marketing.

Know when to ground your prioritization process in reality: It’s counter-productive to seek feature complexity estimates from a representative of the engineering team before you deeply understand the problem you’re solving, but once you’ve whittled them down to a select few to go and research further (a process often called Product Discovery), you’ll be ready to generate specific solution ideas. that means technical members of your team will be able to evaluate each in terms of how challenging they’ll be to develop. This isn’t always black and white. There are often contingencies attached. (e.g. Engineer: “If we have to support Internet Explorer when developing this new feature it will take 2 months. If we don’t, it will take 2 hours.”) The key is to make the tradeoffs clear so you’ll know when to cut corners, when to forge ahead building a complex feature, and when to skip it in favor of a simpler feature with even higher value.

Become familiar with popular prioritization frameworks: There are many different ways of framing what criteria matters most and using it to evaluate which features to go build. For example, RICE dictates a specific formula for judging feature priority based on projected reach, impact, effort, and confidence. Another school of thought favors the Kano model, which divides features into those that satisfy basic needs (and could be a dealbreaker if your product didn’t offer them) versus those that actively delight users.

Clearly communicate context and constraints with designers and developers: As product managers prepare to send features into development, it’s important to ensure designers and developers understand what they’re building and why. This means that for each feature, the product manager must communicate the following details:

  • Strategic objective
  • Core user need to be addressed (and user segment being targeted)
  • KPI (What metric will move and by how much if this feature succeeds?)
  • User scenarios to be enabled by the functionality
  • Constraints, requirements, and other success criteria

Traditionally this information has been presented in the form of a feature specification (or “spec”). It’s worth adding that in recent years there has been some backlash to this approach. Too many product managers treated specs as the be-all end-all of communication with their team, even though they lacked critical context that helped designers and developers understand the real user needs they were addressing – the real why behind the features they were working on. There was also just something inhumane about the process of “tossing specs over the wall” from product to engineering – detailing requirements in tens (even hundreds) of pages without bringing engineers in front of users to see the relevant needs with their own eyes. Of course, it’s not possible for engineers to interview every user, but there is a happy medium where specs are clearly detailed but embellished with more user context, and all teammates spend more time interacting with end users.

How do PMs plan when to build and launch functionality?

Release in phases to minimize risk

Sometimes features can be built on their own and provide a lot of value to users. This could be the case with a specific piece of functionality that comes highly-requested. Other times, complementary features must be developed and released together if you are to advance your product in a more substantial way. For example, you might develop an entirely new interface, composed of many features, to meet the needs of an administrator user role who needs to be able to better manage users in their organization if they are to succeed with your product. An entirely new admin console is required to help them manage their products at a basic level.

In this latter case, we’ve moved beyond one-off feature prioritization to evaluate an entire initiative. This is tricky territory because it requires the team to risk putting in substantial effort on developing many features before they’re tested on users. Always try to minimize this risk by developing and launching the smallest possible group of features – even if that’s a small subset of the greater initiative. That way, you’ll begin collecting feedback from users as early as possible and can change course if you learn something surprising (e.g. admins don’t actually need an audit log, they could get by without it if there was better versioning). You can always complete an initiative by releasing subsequent phases of functionality at a later time. This approach of releasing the smallest amount of functionality as early as possible so as to maximize learning and minimize risk is known as the minimum viable product. It is central to the lean methodology and applies to most every aspect of prioritization and planning.