Most people and teams conflate prioritizing and sequencing of work. Prioritization is the process of deciding what is important to do, and sequencing is deciding what order to do it in. Shaping a product strategy involves both. First you decide which problems are important to solve. Then you decide which problems are important to solve first. Your product won’t spring into existence fully formed and ready to compete like Athena emerging fully armored from the head of Zeus.
Going to Market
You will develop a go-to-market (GTM) approach which includes multiple releases of your product. Each release needs to be a distinct, coherent, valuable offering. There needs to be someone who wants to buy the first release. Shaping your product requires you to add the dimension of considering multiple interim versions of the product, each more ambitious than the previous one. Like the Amazon mobile app, initially focused on the spear fisher, and gradually growing to be more valuable to more people in more situations.
Too many teams try and use reskinned project-management tools which are helpful when sequencing instead of being helpful when shaping. As a result, I think the “what can I do first?” and “when can I do the next thing?” questions displace the more important questions of “what value will the first version create and for whom?” To tease apart the difference between shaping releases vs. sequencing work, it helps to contrast two different ways to think about timing. I’ll demonstrate with a facilitation exercise I ran for a leadership team where we shaped a product – in this case, a bespoke transformation services engagement. I find this to follow the same patterns as developing a product roadmap to operationalize a product strategy.
Shaping an Engagement
Several years ago when beginning a multi-year services engagement with a large corporation, I helped the leadership team through the process of both selecting and sequencing the problems they would want to address as part of their transformation. The first step, problem discovery, was to elicit the collection of problems which were of concern for the leadership team. Recognizing that the benefits which come from solving problems varied, they identified which problems were more valuable and which were less valuable to address. I believe the leaders expected me to use the Eisenhower matrix as a prioritization tool to map importance and urgency of all of the problems to build a prioritized list. In the context of organizational change, I find there is something more important to consider than explicit urgency – appetite.
This group of leaders was operating within part of an even larger organization, and the problems they identified were not solely within their control to fix. Every potential improvement required some form of change beyond their scope of direct responsibility. Sometimes solving an identified problem would require significant or disruptive changes in other parts of the organization. In all cases, solving a problem at least required leaders or teams to collaborate and operate differently across those organizational boundaries as a result of doing things differently within their own areas. In a large organization, political clout is needed and political capital is sometimes spent to drive change outside a leader’s area of responsibility. Leaders may not feel like it is the right time to make waves, or may not feel like they are personally interested in leaning into another leader’s space at a point in time. So instead of combining importance and urgency, I combined value with “appetite.”
Transformation efforts will not succeed without leaders stewarding the changes. You cannot grass-roots your way to a meaningful change at scale. From a shaping point of view, what we were looking for was the highest value problems to solve which leaders had an appetite for solving. Some high value problems were pointedly unappetizing for them at the beginning of transformation; it was helpful for everyone to understand this. What we discovered was which of the highest-value problems this leadership team was willing to push to solve. Committing their energy, their political capital, and possibly their promotions and bonuses to the change. Now with a 2×2 matrix, we identified the most valuable and most appetizing problems to address. Effectively defining the scope of the desired transformation. We were ready for the next step.
The next step was to determine a “when” for solving the problems. Instead of building a timeline-roadmap for the transformation, I had them build my version of what Janna Bastow would call a “time horizon roadmap.” Janna has been promoting the time horizon approach for years, which puts things into a coarse-grained timeframe. Two approaches she has shared are to label investments as “now, next, or later” or to use the categories “current, near term, future.”
I have a variation I find I enjoy more. “Now | next | not yet | never.” While the alliteration is fun, the real value comes in having explicit conversations about problems which will not get solved. Every problem which made it onto the list had someone who experienced it, if not championed its resolution. In a collaborative setting, it is helpful to acknowledge and remember when the decision has been made to not solve a problem. It helps facilitate “disagree and commit” behavior in a healthy way. If strategy really is about saying no, then this gives you a great place to store the ideas which don’t get pursued.
As the leaders took the high-appetite, high-value problems and mapped them into time horizons, it allowed healthy conversations about feasibility – capacity of the team to deliver and capacity of the organization to absorb simultaneous change. The leaders were also able to unearth some sequencing dependencies, where solving one problem would yield limited value if another problem were not already solved first.
The collection of problems which landed in the “now” bucket represented a coherent and valuable offering – a first release. Adding the scope of “next” problems unlocked more value, representing the next discretely valuable offering – a second release. As time progressed, the “next” problems would become the “now” problems, and the murky future unfolded to enable potentially changing the shape of the offering. Some things would not yield as much value as expected and the team would go back to the drawing board to try again. Other problems surfaced which weren’t originally considered, driving discussion to reshape the transformation.
Pruning the Product Tree
In Innovation Games, Luke Hohmann introduced an elicitation exercise called Prune the Product Tree, where you get customer groups to identify the features they want to add to (or remove from) a product. In that exercise, customers are encouraged to demonstrate their desired time horizons – with explicit guidance to identify nearer term and longer term timeframes for the features. In Software Profit Streams Luke and Jason Tanner use the metaphor with a subtle shift – describing the growth of a product in terms of the benefits it creates for customers. They refer to this as a “growth centric” roadmap, differentiated from a time centric one.
I like the metaphor of a growth-centric view of shaping (pruning) your product as a way to consider a time-horizon view. Products, like transformation projects and trees, grow organically, and not always at a predictable pace or in exactly the expected ways. Agreeing on “these things first” is the principle goal of this exercise.
While people are talking coarsely about timing, the real signal in this exercise is relative importance – which problems are the more important ones to address? When I used it in the example above, I was combining discovery of the key organizational issues with alignment and collaboration to shape the bespoke services offering.
When running this exercise about a product, with different customer groups, you get localized signals about what matters to each group, allowing you to think in aggregate terms about your market. For the people you’re working with, time horizons act as a proxy for an undefined combination of importance and urgency. Not only are you not your customer, but not all of your potential customers are the same.
You will find not only that different groups of customers care about different problems, but that they care about the same problems differently. A problem which is “now” for one customer group can be “next” or “not yet” for another. Problems can also be never for a particular customer group, even though I didn’t show that in the visual below.
These signals help you decide which customers to help first, which problems to solve first. It also helps you to evaluate some assumptions about problems – you may feel a problem is shared by multiple customer groups, only to discover that only one group values solving it.
As a result, you can shape how your product will grow. For which customers will you try to provide value first? Which of their problems will you try to help them solve first? And maybe most importantly, operationally, which problems are you choosing to not solve. You are now able to focus on the immediate.
The “next” problems are likely to evolve, your understanding of them certainly will. The “not yet” problems are more of a signal of directionality for the moment. You have to develop a product plan which is feasible, taking into account both your capabilities and capacity to deliver.
Regardless of what tools or techniques you use, the important thing is that you are shaping your product in terms of the value you intend to create for customers in a way you believe will lead to value for your company. When you move from hand-wavy philosophy about value and desirability into operationalizing, you need some form of artifact which manifests this purpose, which you can use to align the organization and clarify for the teams actually building solutions. You need to combine knowing how to write a problem statement with knowing how to use the problem statements to set direction – to both shape and sequence the development and release of your product.
Feasibility Rears Its Head
Shaping your product starts with choosing to solve problems which are valuable to customers, making the solution desirable to them; but must also be done in a way which creates value for your company, justifying the investment. Product investments which are not simultaneously valuable and desirable are bad ideas. However, this alone does not assure the idea is good; some ideas can be objectively good, but not good for your company to pursue. They may be infeasible for you to execute.
Feasibility concerns are concrete and immediately visible. They get the lion’s share of attention within the organizations I’ve helped. The initial go / no-go decision includes an ROI analysis, with a typically unstructured estimate of potential value and a well structured estimate of costs, capacity, and schedule. Through execution, managers focus on output-delivery schedules and measures of feasibility; almost universally bypassing measurement of desirability or value.
The first pass of roadmapping yields an ambition, the desired shape of your product. The customers generate desirability signals for you. Then you develop an approach to meeting those needs which you believe will also drive business value assuming the approach is realistic. This is the right time to push on that assumption of feasibility. Your teams have limited capacity and capabilities. You have developed a solution approach for each problem you choose to solve. Those approaches represent a way to achieve the [[Clarity of Purpose|purpose]] embodied in the problems you are signing up to solve.
The reality of execution is that it takes time to create solutions. When your capabilities are limited, it can take you more time than it might otherwise take – a feasibility double-whammy. It may be that some solution approaches are effectively impossible to execute in the time horizons you desire when treating the organization’s capacity and capability as fixed variables.
When you shape your product approach – and in this visual depicting a choice to only solve 3 problems “now” – you create a signal for conversation with your leaders or execs. Your choice to address 3 problems and not 5 in the first release was likely heavily influenced by the constraints preventing you from solving all 5 in the first release. Can you increase capacity and capability to be able to do more now? Should you make those investments?
This is where you benefit from conversation centered on the value you expect to generate from solving the problems you intend to solve. You are limited in how much value you can create by the capacity available to allocate to the solution approach you envision. When your conversations are focused on outputs or features, and not outcomes or benefits, you are hamstringed in your ability to make a good decision. You can endlessly discuss “can we deliver more now?” and “how can we deliver more now?” You are unequipped to ask the real question, “should we deliver more now?”
Should you keep the missing resources allocated to a different pursuit? Are they even available? Can you create or acquire them? The answer will be yes – if you’re willing to spare no expense. But should you? Only if the benefit of doing it outweighs the cost. Only if the benefit of doing it exceeds the opportunity cost of whatever you’re delaying to acquire the additional resources. You cannot answer those questions without an estimate of the value you expect.
Conclusion
The right frame for decisions is to ask “should we solve this problem now instead of solving a different problem now?” The reason we are constrained in our ability to solve problems as rapidly as we desire is because of our limited capacity to implement the solutions. It is easy to abandon the discussions about problems and center conversations around the solutions. But you lose the ability to make the tradeoffs. The problems are primary and solutions secondary. Not the other way around.
