Best Practices

Prioritize This! A Framework for What to Build Next

Too often in my career, I’ve seen arbitrary opinions dictate which features should be built, without any clear arguments as to why. But as a product leader, you should be the voice of the market. It’s your job to explain to an entire company why they should build, market, and sell new things, and why those matter to your business.

I’ve seen product managers struggle to back up the importance of a feature or product idea with real numbers. Questions abound when you’re telling people they should do more work:

  • how many users are actually waiting on this?
  • will this help our company?
  • does this support our product strategy?
  • why should we do this now?

The process of synthesizing customer feedback and feature requests rushing in through Slack channels, Excel sheets, emails, and JIRA tickets can be daunting. Not to mention the vision and input of the different stakeholders from within the company and from the market as a whole. That is why we at OTA Insight came up with a framework for answering what is a fundamental question in every product manager’s life: what should we build next?

Introducing: the SUE framework

When I joined OTA Insight, it quickly became clear that we needed a more effective way to demonstrate the importance of a feature idea. That’s how we ended up with the 3-pronged prioritization framework we call SUE, which stands for:

  1. Strategic value
  2. Number of users impacted
  3. Effort involved

Strategic value

Your product vision should be correlated to your business’ strategic drivers. Defining them will help you surface those features that best align with as many strategic focal points.

To launch this process, start by asking: What are the key drivers that make our product successful and support rapid growth?

To make sure we keep building things that matter, the CEO, CTO, VP of Engineering & myself sat down to define our strategic drivers so that we can prioritize accordingly. I would recommend involving other senior management in the conversation as well.

These will, of course, be different for every company, but in our case– we’re a leading provider of data intelligence for the hotel industry– we settled on the following strategic drivers:

  • Ease of use: We have the most user-friendly product in the market. To stay ahead of our competitors, we need to keep investing in good UX in everything we build.
  • Innovation: We need to make sure we are always one step ahead of our competition by building new products that solve new problems.
  • Data coverage: To provide hoteliers with the best insights we need to keep adding relevant data sources.
  • Performance and reliability: There is nothing worse than looking at the wrong data. Having stable systems and providing accurate data is part of our DNA.

After defining these, you should ask: do we think adding this feature help us get more x, more y, or more z? If it doesn’t hit any of those, maybe you should question why you want to build it (more features≠better).

Effort involved

Every week, our PM, CTO, and VP of Engineering sit down to discuss high-level user needs and how we can address them. Ballpark effort estimates are assigned to each feature we think is worth further investigation. The effort scores are updated and used in every stage for prioritization.

Users impacted

You should be able to track how many times each feature has been requested, by whom, and how important it is to those users. Ideally, you’re able to:

  • Keep count of the unique users or customers who asked for a feature
  • Segment users (maybe that enterprise security feature is not needed by your SMB customers)
  • Rank how important the feature is for the user or customer. Is it a nice to have, a need to have, a must-have or critical?

SUE = Strategy, Users, Effort

Once you’ve employed SUE, you can tell what the impact of a given feature will be on your business, how many users will benefit from it, and how much effort it will take. This way you can find quick wins and prioritize bigger projects based on real value.

Instead of just saying yes or no to a feature request, or letting the loudest opinion in the room prevail, try applying SUE prioritization to feature ideas. If you’ve employed it and found the feature lacking, you can then objectively explain that one (or more) of these is true:

  • It’s not part of our strategy or the ultimate vision;
  • Not a lot of users will be impacted or the wrong user segment will be impacted;
  • The problem is too complex to be solved now.

Focus is everything when you’re executing a product vision. Using a prioritization framework will help you build the right things, but perhaps more importantly, will allow you to explain why.