Translating business direction into an objectively prioritized backlog

feature requests, hypotheses, and new opportunities pour in from all directions. Few stakeholders can explain to practitioners on the floor how they should change their practice to reflect the business direction or the product vision, to guarantee that the business continues on the right path.

There's a chance you work with OKR's or KPI Frameworks to help translate company direction into action. These methods will help keep a narrow focus on what needs to be built, over the course of a quarter or a year.

But chances are that your company has departments or sources that often request new features, resulting in tedious feature request management.

Features tend to creep into the backlog automatically, also features that do not actually support the current product direction. Either from outside the team or even from your own product discovery team.

If you try to focus on only developing self-discovered features, you might still end up with a backlog of problems and opportunities. Because new ideas arise and new opportunities are discovered.

Or simply ideas that land in your team from a user-facing department like customer service, CX, or sales. Ideas that might give your product a competitive advantage, regardless of company direction.

Either way, you will often find yourself in a situation as a Product owner. where you need to pull in tasks for the next sprint and the icebox is full of great ideas, some are easy, some are valuable, some are important and a lot of them are just urgent somehow.

This is unfortunately the reality in product development in many companies.

But how do you prioritize on a task level, how do you know when to go left and when to go right ?

Maybe you have found your self prioritizing based on some of these models:

• Impact / effort scale: What is valuable and what takes a lot of time ?
• RICE prioritization: When do we have enough confidence to say that something has more reach?
• Eisenhower matrix: What is urgent and what is important

These methods seem very simple and easy to use. But the truth is that it is blackbox on blackbox (not transparent) — effort might be easy to assess in t-shirt sizes if you have access to technical staff. But Impact, Reach, Confidence and Importance ? how do you t-shirt size that quickly to a degree of precision and certainty? Especially if the subject at hand is only a problem statement.

Even though User Experience specialists tend to favor data driven decisions above other factors, that can take time to acquire. The reality is that every person has their own perspectives. As long as we let a single individual choose the optimal course of action, we will allow a subjective viewpoint to guide the company directions.

Before we talk about a possible solution to this let's take a small jump up, and start from above.

1. Lets say your product is: A website that helps consumers find places to buy groceries online. + a partner platform where partners can manage their "store"
2. your product vision is: "Better food choices in your everyday life"
3. And the direction for the year is to: "Make it easier to take a green choice when purchasing groceries online"
4. You might have a KPI on Conversion rate and basket size, set by one stakeholder. And KPI for partner onboarding set by another stakeholder.
5. Your OKR — Objective is: Raise rate of green products in basket. And your key result is: "rate of products in basket with the tag climate friendly is 30%"
6. And one more with: "rate of products converted with tag climate friendly is 20%"

What do you do now, how do you prioritize?

And when you start your next sprint Monday morning to set this course you already have 55 old but good feature requests and opportunities supporting the OKRs to varying degrees. Most of them, not at all.

Some are impactful, some have high confidence, some don't, some are easy, some are for security, some fixes crucial bugs, some are from legal, some are from UX — but most of them are an indirect mix of several parameters.

How do you pull in the next items to your development sprint? Do you start from the top every time? — maybe you had a few meetings last week where individual stakeholders swayed you to start on some urgent tasks this sprint. But is it important ? and what is important?

All this is relying on perspective from you, the Product owner. An individual that might not have been a part of setting company direction in the first place. Maybe you don't really care today and decide to follow the good old fashioned "path of least resistance". Or maybe the latest meetings on what's urgent is suddenly what is important in your mind today. Without you even considering if it's not. Maybe you have been approached by a few other individuals that try to convince you that the new system architecture needs to be looked at. Or else…

Product owners (PO's) are often the ones who are in charge of the backlog prioritization and therefore single handed decide in person what gets integrated into the product now, later and not at all.

PO's have the overall responsibility for steering the product in the business direction. But does that actually happen intentionally?

- it sure doesn't happen unintentionally — but it could:

Backlog prioritization framework using the Pugh Method to drive objective business decisions.

What if there were a method that could sort all features in the icebox (the all opportunity backlog) and/or other backlogs, in a transparent way that everyone agrees on. Where everybody have had a voice.

Based on all the right parameters. A rating system that you, as a company set up based on your direction.

No blackboxes like "impact" and "confidence" are allowed. It should be broken down into categories that are understandable, self-explanatory, and transparent to all contributors. Categories that make sure that "impact" translates into value for your business model.

And this is how this model loops all the way back to the product strategy.

If you are unsure where to start, look at the KPI's or ask in UX what valuable metrics drive impact. If you are high on sustainability, then that could be a score for you. And if that is still a blackbox to some, then it should be broken down into tangible scores related to sustainability. Such as "less load on data centers"

Acting as a contract…

The magic happens when all departments are collaborating on getting all perspectives to the table.

So that everyone agrees that this is the way we prioritize going forward. That last part is a very important aspect. And will save you a lot of meetings about what to prioritize. Or why something was wrongly prioritized.

Parameters

• Traffic — how much traffic is going through "this"
• Time on feature — how much time does each user spend on "this"
• Funnel — how far in the funnel is "this" — user coming in, or users checking out
• Mobile optimization — is "this" optimizing the mobile experience
• User Feedback quantification — how much feedback do you get on "this"
• User tested — is "this" discovered/validated through usertesting (binary or a scale)
• Split tested — is "this" validated in a successful splittest (binary or a scale)
• Used by competitors — is "this" often seen at competitors platform

• SEO — does this improve seo?
• Ease of development (Effort score) — how easy is this to develop? — You would want to value ease of development high (1–10 or more?)
• Legal — how illegal is "this"? — is it a suggestion, or does it apply fines?
• Security — is this patching any security issues in terms of data
• Bug — is this fixing crucial bugs

• Feedback from churned partners
• Reducing data center traffic and calculations
• Empowering users to take a green choice
• You name it…

Every involved department usually has a KPI they would like to bring to the table.

Involve them and create transparency on how this will help prioritize the production going forward.

• To avoid feeling overwhelmed, try to keep the number of criteria you're using under 20. UX-wise (in terms of cognitive load), 5–10 rating scores is a sweet spot, and that's quicker to fill out than the standard 3–4 open-form textboxes (where you ask contributers to explain what the feature does and how its impactful and so on).
• Avoid blackboxes — if something is not self explanatory consider breaking it down.
• It's ok that values often are 0, not all departments KPI's are relevant all the time.
• Two scores should not overlap too much in terms of impact assessment

Scaling

You might say that prioritizing on "traffic" is important, which is why you suggest it will have a point system of (1–5). 1–5 then needs to be compared with the importance of, let's say, "user feedback." If you feel this is way more important for your product, then you can either say traffic is only 1–3 or user feedback is 1–10.

Binary or scale

0–1 is very binary, although some parameters might need to be binary. Consider if it should be 0 or 3,4,5 instead of 0 to 3,4,5 based on importance. Let's play with a binary parameter of high importance: "Feedback is from churned customers." 0 or 4 (this could also be a score based on quantity)

When using the system

"Guesstimating" is ok because the scoring system has so many facets.

It would take too much time to investigate, and it wouldn't move much in the large array. If a value is set to 4 and should be 2. Because of the number of the parameters. The more you have, the less impact mistakes will have.

Boost points missing by adding research…

If you have a "feature" that might end up lower than expected because there is very little user research on it. (low confidence) Then the system also nudges you to take time to "discover and mature" the "feature" and thereby get more points on it and thus make it "more" ready for development by moving it up. And as we all know, research removes risk in development and adds analytical confidence.

Effort

Some people might say that this is too hard to fill out, and it's important to remember that setting up this system takes time. However, once implemented, it will save you as the PO a great deal of time when prioritizing tasks.

"Jumping to solutions"

Another obvious advantage is that you prevent the sender of a request from providing quick solutions. Ultimately, you should strive for greater impact rather than settling for a quick fix. Avoid giving stakeholders the opportunity to elaborate on a simple solution. And strive to limit yourself to a problem statement. Then, you prevent your researchers and ux designers from experiencing "the anchoring effect." And if you were the PO, you would be less likely to build the solution just as it was described in the ticket.

And lastly, not to forget Einstein's famous quote in that regard,

"If I had an hour to solve a problem I'd spend 55 minutes thinking about the problem and five minutes thinking about solutions"

Keep the questions closed to keep an open mind to get the most innovative solutions

we have all been there, decision are being made left and right based on momentum not precision. but you can have both.

Solutions vs problem statement.

So how do you then prioritize if you have a mix of problems statements and hypotheses / opportunities?

Most often, you can take a qualified suggestion / guess as to where and how it could live in the product. If this is wrong then the amount of points it would get all in all would carry the request to the right placement in the backlog.

It's all about the framing of the questions:

"We believe that the solution to this problem can/will"

• "involve sustainable actions"
• "lift mobile experience"
• "be easy to fix"
• "get alot of traffic"

Its about seeing the potential and believing the best until you mature the feature request into a hypothesis

The Prioritization matrix is very much based on the Pugh Matrix or Decision-matrix reused by the PXL framework, but its potential is considerably more than A/B testing, and its origin is invented for to evaluate designs, but it can be use for anything that needs to be evaluated and compared on several parameters all together. Which includes alot of things in our lives. We also use it for travel planning, when we bought a house. anything that normally takes alot of time to decide based on multitude of parameters.