The overwhelming emphasis I see in product organizations is on sequencing the execution of the product strategy over the upcoming quarters. Optimizing the product operations work to deliver a subpar product. There is little to no effort applied to shaping the product strategy. Problem statements should be used to shape the choices about what needs to be done, before trying to decide which bits to do when.
The Jobs of the Problem Statement
This article is part of a series on the three critical flaws in most product development processes a problem statement exists to address.
- To deepen shallow product thinking to identify meaningful outcomes.
- To empower product leaders to shape the product strategy through choosing what to do and choosing what not to do.
- To reduce the confusion, delays, and waste teams face as a result of not knowing why something is being asked for and not knowing what good enough looks like.
Let’s focus on the second challenge – deciding what to do
Deciding What to Do
The prompting question, “what should we do first?” is a critical question, but it should not be the first question. Over-indexing on this question can result in the delivery of an incoherent mess for your customers. When the organization is using an agile operating model, the product is delivered in incoherent increments of mess.
Each problem statement describes a specific problem which could be solved, for whom, and a vision of the future in which the problem has been solved. This is too low-level of an analysis to shape a product strategy. In the startup world, there’s a question thrown at founders – “Is it a feature, a product, or a company?” A problem statement is not a product, it is only a part of a product. A product is a collection of solutions to a collection of problems. You use a collection of problem statements to focus the decisions about which problems will be addressed by the product and which will not.
Product strategy development and decisions about what to do are made in terms of choosing to solve some problems and not others. Problem statements are useful to help with collective reasoning about a set of problems.
Alignment or Execution Focus?
The portfolio team is responsible for assuring the execution of an effective product strategy to advance and support the organization’s strategy. In smaller and less-structured organizations, I’ve seen this as the responsibility of a director of product or product manager.
Scaled Agile expresses “A SAFe portfolio aligns strategy to execution,” and LeadingAgile states “The Portfolio Team ensures work is strategically aligned to Investment Themes, Strategic Objectives, or whatever the organization uses to express their strategy goals.”
In practice, the training, coaching, and management emphasis which follows, unfortunately, focuses on the execution activities, and not the alignment activities.
Many teams use weighted shortest job first (WSJF) as a technique to facilitate sequencing discussions. Don Reinertsen developed the cost-of-delay (CoD or CD3) model for accelerating the delivery of economic benefit to the organization. Analytic Hierarchy Process (AHP) is the multivariate version, allowing an organization to optimize when accounting for other aspects, such as regulatory compliance, customer satisfaction, brand equity.
As more companies are starting to see the light of being outcome-oriented instead of output-oriented, these frameworks look great as tools to sequence things in terms of outcomes for the firm. The flaw arises when sequencing decisions invalidate the assumptions which make each element valuable.
Once the product strategy exists, you can then build a product roadmap, which I call building a problem roadmap; laying out the sequence in which you plan to tackle the problems you’ve chosen to tackle. This assumes your product strategy has sprung into existence like Athena emerging from Zeus’ head. It does not, unfortunately.
As an adjunct professor in a masters program I teach a methodology for developing a competitive product strategy. The shaping of your strategy to meet the needs of your customers within the realities of your market is more important than your efforts to sequence the execution of the plan.
The capacity of your organization to shape and sequence a product strategy is a limited resource and energy put into sequencing comes at the cost of doing less shaping. Energy spent focusing on the sequencing decisions comes at the expense of making a better product, because that energy is no longer available to effectively shape your product strategy.
This is often presented as a binary choice, creating a false dilemma. In practice, you’re actually making choices on the margins. Do you invest time to make the product marginally better with marginal delays, or do you deliver a marginally less-valuable product marginally faster?
Shaping a Product Strategy
To dramatically compress the thinking around developing a product strategy, consider a handful of choices which coherently describe what you’re trying to do.
- Which customers do you choose to help?
- Which set of problems do they want your help to solve?
- Who is competing with you to solve those problems?
- How good do you need to be at solving each of the problems, not only to satisfy customers (the obvious part), but to be the better choice than your competitor?
The potential benefit to your company is not the value which drives these choices. Sequencing techniques do not help you with “choosing” activities.
Answering the listed questions is shaping your product strategy. Some prospective customers must be ignored. For the customers you pick, you must choose to not solve some of their problems with your product. Your sales forecast is built one sale at a time – imagine how good your product must be to be the better choice from the point of view of the customers you picked, for the set of problems they expect you to solve.
Being the “better” choice is something we can never omnisciently achieve, but we have developed a lot of approaches and practices to make us less likely to be wrong. From developing personas in a customer-centric market model to satisficing and defining good enough (or good enough for now). We don’t want to throw that away by solving for a flawed (more on that in a second) estimation of value.
You shape your strategy based on your point of view – a set of feasible-to-solve problems is of sufficient interest to enough customers to build a meaningful business case and deliver value to the organization.
What’s important is that you think of your product strategy as sufficiently solving a meaningful collection of problems. All of WSJF, CoD, AHP calculate a sequence based upon characteristics of each problem discretely, not holistically and contextually. To quote a former colleague – “the calculation is not meant to end the conversation, but to start it.” Unfortunately, the act of performing the calculation anchors the team on the wrong aspect of the analysis: efficiency of value extraction. Undermining the team’s ability to assess the effectiveness of product offering.
Customers choose products based on their aggregate performance along multiple dimensions – are the products “good enough” at solving a set of problems? You need to shape your product strategy to be collectively good enough at solving the right set of customer problems, to be the product your target customer chooses.
When you discretely analyze all of the problems you might solve, for all of the customers you might pursue, these mechanistic analyses will calculate the most efficient solution-deployment sequence, ignoring the coherence of your offering from the point of view of your customers. Followed blindly, you would build a roadmap which has you delivering something which is unlikely to be the better choice for anyone.
Instead of emphasizing sequencing to accelerate potential value extraction, you need to focus on shaping your product roadmap to develop the most effective product for your target customers. The presumption of profits to the company is built upon the expectation of sales to the customer. The ‘calculators’ allocate presumed benefits discretely, but the assumptions of value are made collectively.
When you build a product which is good enough for one customer at solving one problem, and good enough for a different customer at solving a different problem, you create a product which is not good enough for either customer at collectively solving the set of problems they need to solve. The result is an incoherent product. This is what clockwork prioritization techniques can yield when the most discretely valuable solutions are not part of the same sets. The approaches sort the inputs, they don’t shape coherent outputs.
Problem Statements Enable Shaping
We need something to act as a token, for each problem we might choose to solve, to allow us to reason about collections of problems without going into all of the details of each problem and each solution. We don’t need all of that information to choose which problems to solve now, which to defer, and which to discard.
When considering amongst all of the problems we might solve, we don’t want to boot up all of the details. It is too hard, and we risk using the wrong information to make our decisions. The problem statement is just enough salient detail to meaningfully recall information and reason about it.
- Each problem statement articulates a problem to be solved.
- Each problem statement identifies who has the problem and benefits from solving it.
Those two elements together allow you to shape a strategy – “only these problems for these people” – without getting distracted by the details.
One thought on “Problem Statements Shape Better Products”