Strategic Prioritization

We often hear the words strategic prioritization when it comes to answering the question - "what should we focus on now vs next?". Think back to the last time you participated in a prioritization exercise, specifically to what was being prioritized.

• Was it a project?
• Maybe a feature?
• Perhaps an idea?

These are all examples of output-based prioritization and this style of prioritization focuses on the things to be done, not the value to be added. This does not mean that the output will not produce value, just that the value is not at the heart of the prioritization.

There is a disconnect and John Cutler does a great job in giving it a name - a proxy.

"Sometimes proxies are unavoidable. It might be all we have at the moment. And sometimes proxies are desirable! Say that when X happens, we're pretty sure Y will happen at some point in the future. In that case, we don't need to wait for Y to happen. Make X happen! If we see a decrease in X, pay attention!"

When prioritizing, we tend to emphasize work that either sounds more important, or work that we personally think will create higher value. This style of prioritization is one or more steps removed from the overall goal it hopes to achieve. Proxies can speed the process up, and that is because they can imply connections & assumptions without having to be explicit about them.

Proxies can help us move faster so they must be a good thing. They're a good thing right?...

When prioritizing proxies fall short

Let's explore this with a short story. Imagine you are working at TheNextHotStartUp Inc.

1 month ago - in a strategy meeting far far away...

Leader/Stakeholder: Our 2nd largest customer needs feature set X and it will change their life forever! Let's push that to the top of the roadmap.

PM: How does this change their life again?

Leader/Stakeholder: Right now, they have to rely on this unreliable vendor for everything. If we just build feature set X into our product it changes the game! What do we think? How hard will this be?

Tech Lead: We'll need to iron out some logistics but I think that's feasible.

Leader/Stakeholder: Great! Let's start looking into it and circle back in a few days.

2 weeks ago - standup

Tech Lead: I'm working on feature set X and I've been looking through some documentation for this new integration that will help solve for it. ****I think we need to put together some mocks that will let users add some configuration options on the settings page.

Designer (Did not attend prior meeting): I'm going to need to learn more about which users would be setting this configuration and more about this new integration in general. I want to get the UX right on this.

...the conversation continues.

Now - strategy meeting

Leader/Stakeholder: Building feature set Y should result in some big wins for us so let's do that now and prioritize it over X on our roadmap. Why is X up that high anyway and how far along are we?

PM: I'll follow up with the team and look at tickets to verify progress, but this is the feature that our 2nd largest customer has been asking for.

Leader/Stakeholder: Ah that's right the "vendor thing". Well, feature set Y has a larger upside so let's move it right up there.

End scene

There is quite a bit ****to unpack in this story, however, one thing should stand out - there are a lot of assumptions / proxies at play;

• Feature set X "will change Customer 2's life forever".
• Feature set X will solve for the unreliable aspects of the current vendor.
• The current vendor cannot easily resolve the issue on their end.
• The proposed integration will work for Customer 2 and is compatible with existing systems / processes.
• Feature set Y will produce more value than feature set X.
• Feature set Y in general.

In product development, the problem with solely prioritizing outputs are the numerous assumptions / proxies that are tied to them. They can sometimes be so far removed from the value they hope to produce, that it becomes foggy as to why they are prioritized the way they are. To bring clarity to the process we need to know what assumptions are being made.

Business assumptions (assumptions around how the output will drive business value)

• Do we know what goal(s) (OKR / KPIs, etc) this output is hoping to address or move forward?
• Do we know what high level business problem it hopes to solve?

Product assumptions (assumptions around product innovation). $^2$

• Do we believe customers want this? What discovery has gone into arriving here? (desirability)
• Do we believe we can build this? (feasibility)
• Do we know if we should build this? (viability)

If you can answer these questions then great! However.. before we pat ourselves on the back, take a quick moment and re-read that list of assumptions and focus on the word "we".

Does your entire team share that same understanding? If you ask any team member how a solution was derived, would the response be similar? In our short story, the designer was not in attendance when some assumptions were discussed.

From the designer's perspective, this is what they see.

From those who attended the meeting a month ago, they may see it like this.

And if not explicitly identified can easily turn into this over time as we saw in the story with the PM in the second strategy.

This lost context around output is what leads to lost time and missed opportunities (we'll come back to missed opportunities shortly). In our story, the leader/stakeholder uncovered a pain point that exposes an opportunity, which, if solved, could result in potential positive change. This missing piece is an opportunity that carries an assumption, so let's label it.

Opportunity proxies?

Here's a fun question for you. Is an opportunity a proxy?

I'd say yes and take it further, it's a proxy to:

• a key result or outcome you want to drive, which is a proxy to...
• an objective you want to achieve, which is a proxy to...
• some high level problem to solve (One that is probably in some mission statement or slide deck somewhere).

Uh oh.. we've got a lot of hidden assumptions. Now they may not be hidden to everyone involved, but they are in someone's head, or multiple someones, or distributed across multiple documents, messages, and conversations. The leader/stakeholder in our story may know that they want to grow existing accounts by 50% which would allow for more favorable terms to raise a round, which in-turn enables team growth required to execute on the larger vision.

Does the team really need this level of clarity?

This is a quick diagram that I believe can help answer that question.

Before you go and call a quick meeting to reiterate strategy, doubling down on feeding the consensus bias monster, how do we ensure our team will reach true alignment and shared understanding of the big picture?

Visually map and expose your proxies

Visualization tools are fantastic. They can allow us to almost instantly communicate or better comprehend complex concepts. I hope the fun circles above help demonstrate this concept.

Teresa Torres, author of the book - Continuous Discovery Habits $^3$ and the concept of Opportunity Solutions Trees $^3$, explores the power of visualization and exposing opportunities to drive better results and real customer value.

Which leads me to another point before we get back to "Strategic Prioritization".

Creating space for the discovery of opportunities

Having more context can create space for others on the team with diverse experience to weigh in. Perspective can help uncover more (potentially better) opportunities to drive an outcome or key result, but only if that outcome or key result is known.

If you pick up Teresa's book $^3$ (which I highly recommend) - you will learn how to effectively empower teams to discover higher quality opportunities. You will learn how to build habits of working through the opportunity space to uncover unrealized value for your customers and your team.

Without the anchor point of a key result or outcome, this becomes nearly impossible and creates a dependency on someone who has that context to get a lot more involved in the process.

Actual "Strategic" Prioritization

By exposing proxies we can strategically move up chain and prioritize at higher levels. You now have the capabilities to prioritize opportunities, key results, objectives, and even problems themselves. By prioritizing further left, you are prioritizing the value you want to generate, not the work you are committing to.

You may already use some value based prioritization methods today. A popular one is the value/effort matrix.

Note: Before you read on - I do believe this is a valuable exercise and can certainly help your team decide on what should be built next.

So where's the but?

But... There are hidden assumptions everywhere and the focus is once again on the output. In this exercise, we map a list of features into a matrix and create an artifact that approximates their value and complexity relative to one another. This works great if those assumptions are well understood. In other words, we have high confidence and a deep understanding of the value and complexity of the features we are mapping. The challenge here is getting everyone on the same page with enough understanding the current assumptions. If everyone does not have a high level of understanding;

• Meetings
• Presentations
• Reports
• Emails / Slack messages
• Siloed / hasty decisions
• Excessive debating

Even if at the end of the day we decide to list our outputs for prioritization, if proxies & assumptions are exposed, it will make this process easier to navigate and will result in more value driven results.

Building Stakeholder Buy-in

Now you may be thinking...

"This is great and all but it's pretty much pie in the sky. My boss/stakeholder/etc.. is not going to assign an outcome and let us take it from there."

This may be true but I want to challenge it a bit and ask my favorite question. Why? Well let's take a moment and consider this scenario.

You finally get tasked with an outcome - reduce customer churn by 5% for product XYZ. Your boss tells you that you can do whatever you want, just be sure to report back on progress. Wow.. this will be fun, and challenging, and you cannot wait to get started. A few days pass and you're making some progress towards understanding what you believe to be key contributors to customer churn. Unfortunately something has come up and you need to take two weeks off for personal time. You decided to temporarily give the task to a smart and trusted colleague and leave for two weeks.

Two weeks later...

You return and find your colleagues hard at work building a new feature. Excited, you begin to look through the work outlined in you handy dandy product management tool AwesomeProductManagement360Live. Your heart sinks, the solution feels foreign and far from what you had envisioned just a few weeks back.

What happened? Well there's a lot that could have happened, but I'm going to take a guess at the root cause.

We don't often clearly communicate the discovery process in a way that is easily consumed. All the intermediate hops that took the team from an assigned outcome to what you see as a "Confusing new feature" are opaque at best and more likely invisible and lost in the void of conversations you were not fortunate enough to be a part of. What do you have to do now?

You: How did you get to "Confusing new feature"?

Colleague: Oh.. um well we had some conversations with customers and engineers and pulled some data and this was the best solution.

You: I have like.. probably a million questions...

The conversation continues...

This is the feeling anyone not intimately familiar with the journey will have. Building buy-in could be infinitely easier if proxies are exposed and in the open.

Conclusion

• Be cautious when prioritizing outputs (features).
• Enable true strategic prioritization by exposing proxies.
• Leaders: Think about what it would take to make teams more autonomous.
• Teams: Think about how you can expose proxies to generate buy-in.

References

1. TBM 33/52: Challenge Proxies. https://cutlefish.substack.com/p/tbm-3352-challenge-proxies
2. How to Prototype a New Business. https://www.ideou.com/blogs/inspiration/how-to-prototype-a-new-business
3. Continuous Discovery Habits - Teresa Torres. https://www.amazon.com/Continuous-Discovery-Habits-Discover-Products/dp/1736633309
4. Opportunity Solution Trees - Teresa Torres. ProductTalk.org/opportunity-solution-tree