I have written about product strategy and tried to apply product development frameworks to my day job as a product manager: JTBD, Opportunity-Solution Tree, The North Star Framework, Four Level of Strategy Deployment, Continuous Discovery, to name a few.
They said that the road to expert product development is paved with novices trying to apply frameworks. Well, actually no one said that but me, but you get the point. I’m no expert, and I think there’s nothing wrong with learning and applying what other people tried. And I think these efforts have been fruitful.
So the other day I was reflecting about things that’s been going with me recently in work and life. As part of that reflection, I contemplated on the relationships between the product frameworks that I’ve learned. After a few hours of flexing out my thinking, I finally arrived at something that makes sense.
In reality, product management is a mess, so this isn’t the “right” way to look at things. Plus, there are too many product frameworks out there, so I’m aware that this is a very minimal investigation that only concerns the ones that I’m actually familiar with.
A somewhat holistic attempt to view product development frameworks
The following is a simplified diagram that shows how I think about the relationships between certain product frameworks (open it in another top to view it more clearly). The rest of this blog post attempts to explain and expand on this diagram. There are plenty of good resources on the details of each of these frameworks, so I will primarily focus on the relationships instead of how to apply the frameworks specifically.
The inputs and outputs of product strategy
Stephen Bungay defines strategy in his book The art of action as:
Strategy is a deployable decision-making framework, enabling action to achieve desired outcomes, constrained by current capabilities, coherently aligned to the existing context.Stephen Bungay – The art of action
It would be easier if we visualize it.
Some of these terms are somewhat unfamiliar, and I think we can translate them to product terms as follows:
- Desired outcomes are business outcomes. Products are vehicles that enable value exchange between customers and businesses. We can’t define what customers value, but we have the luxury to determine what our business values.
- Capabilities are product changes that we can make, this is the solution space constrained by the team’s resource and competency.
- Context is the activities that people do. In Christopher Alexander: A Primer. Ryan Singer mentioned the idea of Context-Form Fit being the essential thing in design. Forms are the parts of the world that we have decided to create or change. The context is the activities that people are trying to do, the things going on. We can go along with or against the grain of this context. The fitness between context and form judges the success of a design. Even though this idea surfaces in buildings’ design and architecture, I find it helpful in both software and product development.
After translating then into familiar terms, we get something like this:
A product strategy can be seen as a function that takes in business outcomes, possible product changes, activities people do and produce effective actions.
This serves as an initial framing that we can hang the product frameworks around. I’ve found that the product frameworks I know either help identify the critical inputs to product strategy, and/or combine them in ways that ultimately let us know what to do next.
Company Vision helps identify business outcomes
First, we need to derive business outcomes from the company vision.
A company vision explains where the company is going based on its purpose. But which route a company chooses depends on its maturity and development stage. That’s where business outcomes come in. They communicate the company’s current focus that helps realize the vision, which usually takes years.
Strategic intents may focus on four business goals: increase revenue, protect revenue, reduce costs and avoid costs.
For example, Netflix had a clear strategic intent: “Lead the streaming market.” All of its decisions – enabling internet-connected devices to focus on creating more content- helped achieve this goal. It pushed them in the right direction. Once Netflix realized the strategic intent, it changed its course to maintain its position by creating original content.
Next, we combine business outcomes with the outputs from applying the JTBD framework using the North Star Framework.
JTBD helps discover activities people do that need improvement
Then, we need to explore the context in which our customers operate.
Ryan Singer mentioned the tendency to focus on designing forms. Most design requirements are expressed in terms of form. The form is what we want to create or change: like adding a button to the UI to change a setting. The button is meaningful insofar as it enables people to do certain activities better. In other words, what essential is the Context-Form Fit.
The same tendency can also be seen in product development. Sometimes we build and deliver features without adequately thinking about their context. The Job-to-be-done framework counters this tendency by shifting the focus of product development to center around people’s activities, or the jobs they’re trying to get done.
When applying JTBD, we produce an artifact called Job Map. It describes all the jobs people do, and the underserved needs that make them difficult to perform.
I’ll keep them separate to highlight the input to product strategy, but we can combine them together and say that the output of the JTBD is the activities people do that need improvement.
The point of applying the JTBD framework is not so much about the Job Map and the Underserved Needs, it is about helping you and your team gain empathy from your user problems.
I have never walked away from a user interview where I did not learn anything new about the ways that my product is used. That’s the point of user research.And that’s what required to produce the Job Map and the Underserved Needs.
Next, we combine business outcomes with activities people do that need improvement using the North Star Framework.
The North Star Framework helps produce metrics that align with business outcomes and activities customers do that need improvement
It is vital to have a metric because it enables optimization, but it is even more critical that the chosen metric incorporates both business and customer values.
Otherwise, as Ryan Singer said, we risk falling into the trap of focusing on building forms (solutions) that fail to achieve Form-Context Fit. If it’s not meaningful to the customers, then no value exchange is possible, which also renders the product – a vehicle for value exchange, meaningless.
But, and this tend to be counterintuitive for those who have a high empathy, it is equally important that our business survives, strives and grows to continue to deliver values to customers.
The point of defining The North Star Metric is not so much about the metric itself than it is about helping you and your team think about business outcomes and customer outcomes with equal consideration.
The North Star metric is a leading indicator that defines the relationship between customer problems being solved and sustainable, long-term business results.
The inputs of the North Star Framework are customer problems and business outcomes. The outputs of the North Star Framework are North Star Metric itself and a set of Input Metrics that influence the North Star Metric.
Activities people do that need improvement are customer problems. By solving customer problems, we create value for them. In exchange, customers pay us with their time, attention, and money, which help our business to grow.
The heart of the North Star Framework is the North Star Metric, a single critical rate, count, or ratio that represents your product strategy.Amplitude – North Star Playbook
At this point, the map is almost complete.
Continuous Discovery helps discover opportunities and solutions
As mentioned, the outputs of the North Star Framework are the North Star Metric itself and a set of Input Metrics that influence the North Star Metric. To improve these metrics, we conduct Continuous Discovery to identify opportunities and solutions.
JTBD can be applied again in this phase if we only focus on identifying the big jobs and big underserved needs in the previous stage. In this phase, we can dive into a particular job and identify the specific underserved needs.
The point of Continuous Discovery is about staying in touch with your users. But applying Continuous Discovery in isolation isn’t enough, we must do that while keeping an eye on the metrics that really maximize both business and customer values. That is why the North Star Framework, or the set of principles behind it, is needed.
Applying the Continuous Discovery process, we identify the opportunities as high-level bets (3-6 months) broken down into low-level bets (1-3 months). These opportunities are also called Product Initiatives in Four Level of Strategy Deployment, which product teams can address.
Opportunity-Solution tree helps make product changes that align with opportunities which best solve company and customer problems simultaneously
Once we have opportunities aligned with business outcomes and customer problems from Continuous Discovery, generating and mapping solutions to opportunities remains. In Continuous Discovery Habits, Teresa Torres talked about Opportunity-Solution Tree, which does precisely this.
An Opportunity-Solution tree assumes the desired outcome, and this can be improving a North Star Input Metric.
From sizing the Opportunities based on their impact on customers, improving our positions on the market, and aligning with our company values, we can pick an opportunity and then generate solutions to address it.
Opportunity sizing is an intuitive game, but the Opportunity-Solution tree gives us some visual indications. The depth and breadth of the opportunity space reflect the team’s current understanding of their target customer. If our opportunity space is too shallow, it can guide us to do more customer interviews. An opportunity space that’s too wide reminds us to narrow our focus. If we’re not considering enough solutions for our target opportunity, we can hold an ideation session. If we don’t have enough assumption tests in flight, we can ramp up our testing.
There are a lot of actions we can take from looking at the Opportunity-Solution tree. That brings us to the completion of our map.
Product development frameworks should come in pack
Echoing the sentiment on Form-Context Fit yet again, product development frameworks need to fit in the context of what we’re doing.
You can’t run Continuous Discovery without knowing what metrics you should optimize for.
You can’t define North Star Metrics without knowing the activities that your customers really engage in and what your business is about.
You can’t map out an Opportunity-Solution tree without knowing the opportunities that align with business value and customer value.
Applying the JTBD framework alone risks solving customer problems without also solving business problems.
What do you think? Feel free to leave your thoughts and comments. I’d love to hear your opinions on this blog post or any of the ideas mentioned here.