“I don’t get to set the direction. Leadership tells us the big projects they’ve decided to do, it’s up to us to elaborate and execute.”
This is a common situation for a lot of product managers. They’ve been told that some big initiative is happening, and it’s up to them to “make it work.” Without all the details needed to unambiguously define what “it” is.
Here’s an example – A company is growing by acquisition, and is now faced with the integration / consolidation of two different products. Merging into a single customer base, looking for cost efficiencies from a combined team, increasing profits because of the reduction in price-competition in the market.
The problem statement for that initiative is likely undefined or unshared with the product teams, but we could imagine something like:
The Problem of… Our widget-product is not growing as we lack the scale to fund the product improvements we need to gain share
Affects Whom… Prospective customers for whom our current product falls short of their needs
The Impact of Which is… Uncaptured servable obtainable market share (SOM) of ~20%
The Benefits of a Solution are… A gross-margin increase of 50% through allocation of fixed costs across a larger customer base
This may be muddled, as the benefits are around profitability, but the problem is around lack of competitiveness. These are intertwined concepts, and if this were an article about better shaping of the central problem statement, we could dive into it. This, instead, is an article about how to better operate within the context of someone else’s decisions.
Inside the Mandate
The leadership team has decided to acquire a widget-product competitor, buying the additional market share, bundled with the additional costs associated with maintaining the acquired product and servicing the existing customers. Most product managers I work with are operating in organizations where they are not participating in decisioning like the above, and instead are operating within the context and consequences of those decisions. This article is a focus on the “now what?” parts of making the intended benefit of the acquisition real.
In rough terms, the company expects cost-efficiencies to drive an increase in profitability, and that the increase in revenue (once the paired increase in costs is eliminated or reduced) will fund investments to improve the product(s) to improve competitiveness and gain additional share.
The solution selected to address the original problem was “acquire competitor Zeta.” Within that context, there are problems which exist which the team must address to make it work. The challenge for the team now becomes identifying those problems within the operating context. To do this, the team must align on the definition of success for the acquisition.
You cannot define the solution of a problem without first defining the problem.
Even in a situation like this, where the team lacks the agency to define the outer problem, there’s still a need for a coherence check to understand how ambitious to be in identifying problems and solution approaches within the outer mandate. To define what needs to be repaired, improved, or created, the product manager needs to know what the definition of success could be.
A common pattern is to start with an imagined comprehensive solution, and then break down that solution into independent projects. Those projects can then be allocated to discrete teams, slotted into incremental delivery schedules, and project managed through delivery. The challenge is, instead, to identify the comprehensive problem (we need to consolidate the experience to realize any efficiencies), and then break it down into a series of independently addressable problems. This is problem decomposition not solution decomposition, helping to avoid design fixation* resulting from prematurely defining a bunch of projects and then focusing efforts on delivering those projects.
*Design fixation is when all of the team’s decisions moving forward fixate on the solution design in front of them. The team becomes unable to shift focus back to the underlying problem to be solved, unable to consider alternative design approaches.
Immediately jumping to an imagined implementation supporting the entire experience, then elaborating details and assigning to teams is the wrong approach. The consequence of jumping to solutioning at this point is you may not make a difference, focusing on areas of the solution which are devoid of problems or stopping short of completely addressing needs. The result is an overpriced and underwhelming deliverable. I hesitate to call it a solution, because it might not even solve anything. By failing to deliver on the value proposition for investment and acquisition, the entire thing can become a boondoggle.
I’d lay the blame on the organization collectively rushing to build some “thing” instead of planning to solve the problems preventing the benefit. There is often a pathological desire to appear busy which disrupts attempts to make a difference.
Finding Problems Inside Projects
The “acquire Zeta and sell their widgets” context has been set. Within that context, there are plenty of problems which might be worth addressing. Because you’ve established the context, you can now identify problems within that context. Given that the customer support experience is going to be supporting customers of both Alpha and Zeta widgets, what are the identifiable problems you might solve. Even within this mandate to consolidate the process, there is agency. It is bounded, but it is present.
Hypothesize that there are issues with trying to leverage the existing processes to support Zeta widget customers in addition to Alpha widget customers. The first question becomes how to identify those issues.
An obvious place to start in this example is to look at the value stream of how the company makes money in the widget business, to see where the gaps might be associated with selling Zeta widgets. The danger of this approach is that it reflects an inside-out view. Given how your process works today, what scenarios can you imagine, and what problems can you anticipate. The danger of this approach is that the scope of work is bounded by what you can anticipate and imagine. What’s missing is the outside-in view. Understanding how your customers experience your company, product offering, and services.
By using a customer journey map as a framing tool, you are constantly reminding yourself and everyone else that the secret to creating value for customers lies within the customer’s experience. I am consistently working with organizations who have not had experience developing customer journey maps. Often, their decisions – about which problems to solve, about selecting solution approaches, and even about confirming their effectiveness happens without discussion of customer needs.
To introduce the concept, I start with an easy to imagine, high level description of a customer’s experience in interacting with a company. This process is likely not a perfect fit for the scenario I’m helping a team to address. It is, however, very approachable and easy for them to appreciate and edit. For this article, I’ll use it unmodified.
This is a model of a customer’s comprehensive experience. Breaking it into stages might feel artificial to a customer, but it is still helpful for problem identification and evaluation. The first stage in this journey is a customer becoming aware of an unmet need – a desire crystalizes, a problem surfaces, etc. Once that awareness is present, the customer shifts into shopping and buying a solution. Cognitively, these are different – think of it as choosing among multiple products, then purchasing one of those products. Product usage, maintenance, and repair are all different elements of the experience of owning a product. At the end of life of a product, you may replace it and you may dispose of the original.
Aware > Shop > Buy > Use > Maintain > Repair > Replace > Dispose
- Aware – become aware (of your needs, of the product)
- Shop – make purchase decisions (compare, review, evaluate)
- Buy – transacting (paying, warranty, add-ons, account creation)
- Use – out of box experience (OOBE), first use, ongoing use
- Maintain – required to enable continued use (incl. preventative maintenance)
- Repair – fixing something which has broken to restore ability to use
- Replace – replacing broken, lost, obsolete with newer or better alternative
- Dispose – getting rid of the previous one (repurpose, recycle, destroy, discard)
Within each of these stages, you can look for problems which need to be addressed – because what the company built to support this experience with Alpha widgets may fall short of expectations when it is leveraged to support Zeta widget customers.
Let’s look at the ‘Shopping’ stage in this experience. When someone is shopping for a widget, part of what they are trying to do is decide which widget to buy. Previously, the prospective customer would have been comparing the Alpha widget, the Zeta widget, and perhaps another competitor, the Beta widget. The Alpha company shares information which positions the Alpha widget as being better than both the Zeta and Beta.
Since the acquisition, the company would be excited if the customer purchased either the Alpha or the Zeta widget, as long as they don’t purchase the Beta. Is there a problem which needs to be addressed? Does positioning the Alpha widget against the Zeta widget help sales or hinder them?
The Alpha and Zeta widgets are competing for the same customer, and having two alternatives available makes it hard to choose – potentially driving more business to Beta. The problem here may be to eliminate the choosing (between Alpha and Zeta) to stop accidentally nudging prospective customers to Beta.
There are multiple ways to approach solving this (I know you’ve mentally started solutioning), from killing one of the products to better managing customer flow so only one widget option is presented to any given customer. Another approach is to invest in both Alpha and Zeta products, in a way which differentiates them from each other, making each appealing to a distinct group. This is a great time to remember that you cannot competently design a solution without a definition of “solved” for the problem. Stop unspooling the solutioning thread for a moment and frame the problem.
The Problem of… Forcing customers to choose between Alpha and Zeta causes more people to choose neither and pick the Beta competitor
Affects Whom… Prospective customers shopping for widgets
The Impact of Which is… At least 10%* of the people who should have chosen either Alpha or Zeta end up choosing Beta instead
The Benefits of a Solution are… An increase in profits of $100K annually (10% increase in revenue of $1M at 10% net margin)
*Note – 10% is not meant to be a made-up number, it is simulating for this article the result of quantified assessment. I’m including a number to reinforce the need for quantification when developing problem statements for real, even though this example is not focusing on quantification.
This would enable an initiative to be developed to solve this problem within the solution. Treating the decision to purchase Zeta as an externality does not force you into order-taker mode, it merely clarifies the level of agency you have. As a product manager, you’re still responsible (even if not accountable) for creating the value which comes from solving the problem.
You are constrained to operate within a context. This doesn’t force you to be a cog in the feature factory machine. Identify and solve the problems which exist within the context of the overarching directive.
With this example from the shopping phase, the layers of context are interesting. This is an opportunity to increase profits by changing a characteristic of the anticipated experience. It is a problem because it is undermining the financial premise of the outer context. When Zeta was acquired, there was an untested and unexplored assumption that the combined sales of Alpha and Zeta would not be negatively affected by selling both through a combined experience. After the acquisition, it was discovered that there is a dynamic which undermines the original investment premise. This is an unanticipated problem which exists because of the acquisition.
Defining the problem statement like this within the broader solution helps to provide real clarity on the size of the problem, which helps in both selecting the problem and sequencing the solution of it.
Consider another example, this time inside the ‘Repair’ stage. There is consistently a lot of interesting infrastructure associated with supporting customers after they’ve purchased a product. From stocking replacement parts for physical products to partnering with and certifying service providers who perform maintenance to staffing a call center to provide support. When the company acquired Zeta, they may have decided part of the cost savings would come from consolidating two call centers into one. This problem is anticipated and must be addressed. Problem statements are also helpful in this situation.
Part of the premise for consolidating was that the Alpha and Zeta widgets are similar enough that the same call center agents can support customers who purchased either. Further, leadership assumed there are more support agents than needed. With a little bit of investigation, it becomes apparent that the Alpha widget experts don’t know enough about the Zeta widgets to help customers with issues and vice versa. As part of the acquisition, all customer support calls have been merged into the same hotline. Previously, Zeta had their own call center, and Zeta customers would call that number. Now, all Alpha and Zeta customers call the same phone number.
The question to ask is what are the problems preventing this call-center consolidation from working as expected? This example could be considered an anticipated problem, which people knew needed to be solved all along. From an exec’s perspective, this is just part of the scope – ‘figure it out.’
How might you describe the problem? Here are two valid considerations – immediate cost penalties and delayed revenue penalties. Immediate costs are the ones associated with triaging the incoming calls to route them to the appropriate agents – this takes extra time, may require additional fees for the call-center infrastructure, and may have a small cost associated with configuring the system and training agents to route calls to the right agents. Losses in revenue result from a degraded support experience depressing future sales which would have come from repeat purchases or word of mouth recommendations.
The Problem of… Incoming calls for Alpha and Zeta product support need to go to different agents but all come in on the same line
Affects Whom… Call center agents who handle product support calls for Alpha and Zeta
The Impact of Which is… An additional 20 seconds per call of handle-time reduces effective call center capacity by 10%, increasing cost-per-call by 10% (which works out to a 1% increase in net profit, as allocated support costs are roughly 10% of COGS)
The Benefits of a Solution are… An additional $10K in annual profit (increasing annual profit from $90k to $100K at $1M revenue and 10% net margin)
The Problem of… It is hard for customers to get effective support for Alpha and Zeta products because they cannot easily reach knowledgeable agents
Affects Whom… All customers with Alpha or Zeta products in need of repair
The Impact of Which is… The company gets a reputation for poor product support, degrading word-of-mouth ($200K) sales by 10% and repeat-purchase sales ($150K) by 10% as customer loyalty declines
The Benefits of a Solution are… Protecting forecasted revenue through sales both via recommendation (+$20K) and repeat purchases (+$15K) – yielding annual net profit of $3,500 (10% of $35K)
Your instinct may be to lump these together into a single project, responsible for delivering both outcomes. That instinct can make sense if the same solution approach can be imagined to solve both problems. I’ve seen situations where the same implementation leads to the resolution of multiple problems, but it made sense to treat them as separate efforts because the testing needs are different. Using the example above, solutions which reduce the increase in handle time might avoid degrading the support experience, or they might not.
In this example, there is a pretty clear alignment, where a solution can simultaneously reduce handle-time (cost) and improve the support experience. It may be that what you have to implement to solve both is more complicated than what you would implement to completely solve either. You could choose to focus on the first (reducing call center costs), while anticipating (hoping) it also reduces the size of the second problem by being “good enough” for a large slice of those people who be dissatisfied with the experience.
Iterative and incremental development is not “what do we build next?” it is “what problem do we tackle next?”
Once the solution to the larger problem (costs) is in place, you can evaluate if the secondary problem (lost future revenue) is still actually a problem. It may be that the solution to the first problem reduces but does not eliminate the second problem. It may be reduced so much that it is no longer the next most important thing to work on. This is an example of how problem statements help you to shape your product roadmap by helping you to refine your product roadmap as you go. Before you did any work, you saw two problems, both worth addressing. Your clever approach to solving one of the problems reduced the size of the other problem so much that it was no longer worth addressing. You update the roadmap to reflect a choices about what is most important at that time in the future.
You operate as a product manager with a degree of agency established by your org design and process definition. By introducing problem statements within the context of a mandated solution, you are playing the hand you’ve been dealt and doing good product work. As a product manager you can, through the articulation of problem statements:
- Provide clarity of purpose for your team to LI, highlighting the rationale for building something.
- Provide a crisp definition of success, shifting the operational from “did we finish?” to “did it work?”
- Support economic prioritization decisions when determining how best to allocate capacity and sequencing decisions when determining when to allocate them.
- Avoid jumping to solutions which may fail to address the problems, allowing teams to contribute to collaboration around achieving successful outcomes.
Conclusion
You don’t have to have own a product strategy to get value from writing problem statements. Defining success in terms of outcomes and aligning teams towards achieving success is what product managers do, and can do even inside feature factories. Identify the problems which need to be addressed within the context of mandates. Those mandates could be very high level (company strategy), high level (market segment defined), or mid level (high level solution approach selected). Write good problem statements within the context of what you’re being asked to achieve.
