Expressing a Problem Statement in Product Development
The circus we do as Product Managers — start from a fuzzy problem statement and work on continuously refining it — is something! During the process, several problems fizzle away as non-starters. However, if we are diligent, some others will move along to become new features and products in their own right.
“If I had an hour to solve a problem, I'd spend 55 minutes thinking about the problem and five minutes thinking about solutions.”
- Albert Einstein
Mandate Levels
I attended a lab hosted by Amplitude, where John Cutler talked about mandate levels, decision boundaries, and measurement. He presented a spectrum of problems to solve, ranging from building precisely this to more strategic thinking.
A. Build exactly this [to a predetermined specification]
B. Build something that does [specific behavior, input-output, interaction]
C. Build something that lets a segment of customers complete [some task, activity, goal]
D. Solve this [more open-ended customer problem]
E. Explore the challenges of, and improve the experience for, [segment of users/customers]
F. Increase/decrease [metric] known to influence a specific business outcome
G. Explore various potential leverage points and run experiments to influence [specific business outcome]
H. Directly generate [short-term business outcome]
I. Generate [long-term business outcome]
Source: John Cutler
My Commentary
It’s a great mental model to think in terms of what kind of problem I am dealing with. We may not think in this exact language but product managers, designers, and developers work on one or more levels at any given time.
One level is not better than the other; they are just different from tactical to strategic. Tactical (delivering within cost, scope, and schedule) is equally important as strategic (envisioning the next big thing).
There are feedback loops, ideally, between each of these levels. Even more prescriptive build-exactly-this (A) generates valuable feedback if you are doing it in an agile way, helping influence the more strategic initiatives.
There is an overlap of responsibilities across the levels. John talked about how some organizations have developers, designers, and product managers taking collective responsibility much further into the exploration levels (G). Some other firms have firm boundaries between the responsibilities. I've asked John, in his experience, did he see the benefits of one model over the other (more overlapped responsibilities vs. less). There is no one size fits all. Clearly defined roles can help with the expectations, while I believe teams taking collective responsibilities may be more successful. It's my anecdotal experience; I am hoping to see some studies on the topic.
Regardless of the level, the commonality for success is to have a clear understanding of Jobs-to-be-Done (JTBD). For example, levels F through I strives to define/refine JTBD, while the earlier levels are implementing solutions related to those described JTBDs.
Setting OKRs is proportionally tricky as the levels go up. For some levels, the difficulty is to formulate a clearly described Objective itself (O of OKR), and with some others, it is the Key Results (KRs). Measuring strategic items is much more difficult, and hence a time-bounded constraint has to be applied: “what can you accomplish in the next six-to-twelve months with measurable results?”