A four-layer model of product focus
By: Raj Nagappan
Tags: Vision, Product Management, Startup, UX, Strategy

One thing you’ll notice about strategy is that it doesn’t focus on target revenues as a prime directive. Instead it focuses on tangible things that we can actually do; the revenue numbers follow as a consequence of our actions. And it also contains a “who”: just who is the customer that this strategy is designed for? Effective strategies focus on one group of people, for example individuals with high disposable income, retailers, technology early adopters, and so on. It’s important to identify who experiences the pain most acutely, and target our strategy so that those people can succeed.

A good strategy defines a critical challenge… it builds a bridge between that challenge and action… the objectives of a good strategy should stand a good chance of being accomplished, given existing resources and competence.

— “Good Strategy Bad Strategy” p54 We got desperate and we did some dumb things… I looked back and realized all those things distracted us. They didn’t help, and they marginally hurt. The reason we won is because we improved our everyday service of shipping and delivering… Executing on the core missing is the way to win.

— Reed Hastings on Netflix

Layer 3: Outcomes

Our next layer down is Outcomes. “Outcomes over Output” is very fashionable at the moment, so let’s see what that means. Traditionally, teams just focused on output, or building features. It was assumed that customers would naturally see the benefit of these features and buy (and use) the product. Only this didn’t always happen. What often happened was that the myriad of features did not actually meet the needs and expectations of customers, but overwhelmed them instead, and thus remained unused.

So instead the focus has turned to outcomes. An outcome is a goal or objective that a customer is trying to achieve — it’s a job that they are trying to do. If I sell cameras, my customer’s outcome is to take great pictures. If I sell guitars, my customer’s outcome is to make great music. Outcomes are easy to understand if you put yourself in your customers shoes: “what am I trying to achieve today?” As you can imagine, for this outcome layer we return to the customer’s point of view.

An Example

Continuing our example of Netflix Streaming, what are some outcomes that a customer might have:

To make a spontaneous choice to watch a movie, and see it on my TV.

To find something to occupy my children when they are bored, without having to drop everything to go to the rental store, or plan ahead with a mail-order DVD in advance.

To not be stuck with a movie that I don’t like; to change my mind and watch something different instead.

You’ll notice while we’ve described all these benefits that the customer receives, we have not yet described how any of them actually work! We will discuss that in the final layer. But the main message of this layer is to focus on goals that are most important to the customer, and prioritize those.

Strategy and Outcomes Should Relate

You might be wondering how outcomes tie in with the strategy that we devised in the previous layer. When we left the strategy, there was a set of coherent actions that we were going to work in order to realize the vision — projects or initiatives that we were going to actually do. Each of these actions should tie in with one more outcomes. If we have identified important outcomes that cannot be addressed within the scope of a strategic action, then we have missed an opportunity. If we have an action that contains no useful outcomes, then we are working on the wrong strategy!

The Strategy and Outcome layers intersect with each other, and it may take several iterations to get a good fit. We may identify outcomes that we cannot act upon, e.g. they be part of a challenge that we simply cannot solve. Or we may identify a strategy that no one actually cares about (remember Juicero?) It may take several attempts to get this all working and meshing correctly — hence my comment earlier that good strategy is hard.

Layer 4: Experiments

Our final layer is Experiments. This is where we do the actual work — the specifications, designs, code, deployments, tests, evaluations and so on.

However, we cannot treat each piece of work as a “given”, that is we cannot assume at its commencement that it will actually create the value that we identified in those layers above. Generation of value is our guide — we must constantly assess, iterate and improve the actual work so that it delivers on the promise of value that we made. And many times we will turn out to be wrong. Gibson Biddle said that only about half of Netflix’s ideas turned out to be useful. So this final layer is treated as a series of experiments rather than a plan set in stone. This will allow us to try different things to pivot and adjust as needed in order to navigate towards our goal.

The Improvement Kata

Usually when we think about the Improvement Kata, we imagine it operating at this layer: the actual work layer. So let’s see that in action.

Understanding the direction. This is the outcome from the previous layer that we are trying fulfill. Identifying the current condition. This is our starting point, which might be a User Story, or we might have done several prior experiments whose data we can leverage. Establishing the next target condition. This is the next milestone or deliverable that we can reach in our pursuit of the outcome — it’s the experiment that we are about to run. This might be an MVP, our next product increment, or a mockup that we can road-test. Plan-Do-Check-Act increments of improvement. This is the iterative and incremental work we complete to inch us closer to first understanding and then solving the problem.

Why Experiments Rather Than Features?

As mentioned above, when we commence our work we don’t really know whether or not it will actually solve our customers’ problem. We’re taking a chance. Hence we treat it as a falsifiable experiment; we do the work, evaluate it, and then decide how to proceed. We may well find at the experiment’s conclusion that our attempt didn’t actually solve the problem at all, or that it was a roaring success, or indeed anywhere in between.

Marty Cagan writes that about half of our ideas don’t end up working out, and the ones that do take several attempts to get right. So it behooves us to not get too attached or committed to individual experiments; to treat each one as expendable in the pursuit of the higher-level outcome. It’s especially important to make these expectations clear, both to ourselves and to important stakeholders such as management, sales, or anyone with influence. This also means that we will have to deal with rework.

Rework and Expectations

On any meaningful project, rework is inevitable. We cannot know everything upfront to get it right the first time round, on every piece of work we do. When you think about creative work this makes sense: writing, music, film and TV — all these pursuits evolve from rough drafts through several rounds of refinement. Software is a creative work too. In many countries software is regarded as a literary work (e.g. in copyright law), so we should expect the same rules about refinement and improvement apply to it also.

The language that we use is important; it sets expectations. For example when a team “accepts” work into a Sprint, there is often an expectation that they have committed to it (you can read my view on this particular example here). What we want to do is make it clear that (a) no individual piece of work is guaranteed to succeed, (b) the work is in service of satisfying an outcome, and (c) multiple attempts or iterations are to be expected. What we want to do is shift the focus back to the Outcome being the primary deliverable that we assess progress and success against, so labeling this bottom-most layer as Experiments is a great way to do that. It makes them sound more “expendable”, which they are.

Putting it All Together

Let’s tie together our four layers to form a complete model:

Vision: this articulates the overall promise or benefit to the customer. It is written from the customer’s point of view. Strategy: this articulates how we will realize the vision — it describes our execution as a coherent whole. It is written from the business’ point of view. Outcomes: this articulates the specific goals that our customers are trying achieve. Each outcome should be relizable from within the set of actions defined in the strategy above. It is written from the customer’s point of view. Experiments: this articulates individual attempts that will try to satisfy each outcome. Experiments are where we do the actual work, and should be treated as expendable and iterable. It is written from the business’ point of view.

You can think of the set of actions in the Strategy layer as being projects or overarching initiatives. The Experiments contain the individual features or services that we want to try to build. Connecting the two is the Outcomes, which gives a two-way justification for both each feature (the experiment), and for the project overall (the strategy action).

Our Example

Let’s see our historical Netflix Streaming example all tied together (and just a reminder that these are my interpretations, not necessary what the company actually used at the time that they first built streaming). You can see how the layers tie together: the strategy realizes the vision, the outcomes determine the strategy, and the experiments realize the outcomes.

Vision (customer-centric)

I can watch whatever I want, whenever I want. I’m never bored, and because it’s a fixed price I never have to worry about the cost.

Strategy (business-centric)

Diagnosis (challenge): Our customers love the convenience of mail-order DVDs but they need to plan ahead to receive the movie that they want to see, and it limits the amount that they can watch. The Internet is developing in speed and capability every year, but it is not yet fast enough to deliver video on demand to everyone, everywhere, simultaneously. If we could find a way to deliver content instantly via the Internet, then our customers could watch whatever the they want, whenever they want.

(challenge): Our customers love the convenience of mail-order DVDs but they need to plan ahead to receive the movie that they want to see, and it limits the amount that they can watch. The Internet is developing in speed and capability every year, but it is not yet fast enough to deliver video on demand to everyone, everywhere, simultaneously. If we could find a way to deliver content instantly via the Internet, then our customers could watch whatever the they want, whenever they want. Guiding Policy (broad approach): we will seek to develop capabilities to distribute video on demand in real-time to some customers, and assume that the Internet speed will catch up over time. We will also make it easier for those customers to simply and easily receive the video stream, connect to it, and watch the content on their TV or computer.

(broad approach): we will seek to develop capabilities to distribute video on demand in real-time to some customers, and assume that the Internet speed will catch up over time. We will also make it easier for those customers to simply and easily receive the video stream, connect to it, and watch the content on their TV or computer. Set of actions (projects or initiatives): we will figure out how to store and serve multiple videos simultaneously to different customers who live in high-speed Internet locations. We will devise a device or decoder that allows each customer to receive and view their video stream. We will study what video resolutions and levels of service the Internet can support, for whom, and which technical tricks get us maximum bang-for-buck.

Outcomes (customer-centric)

To make a spontaneous choice to watch a movie, and see it on my TV.

To find something to occupy my children when they are bored, without having to drop everything to go to the rental store, or plan ahead with a mail-order DVD in advance.

To not be stuck with a movie that I don’t like; to change my mind and watch something different instead.

Experiments (business-centric)

The actual work, i.e. features and systems that we will build, measure, and learn from in order to try to satisfy the Outcomes, for example:

Choosing a movie. Playing that movie instantly. Stopping the movie, and choosing something else (i.e. returning to step 1). Reassurance and peace of mind that I won’t end up paying too much.

Disseminate Widely!

It’s not enough to simply define the four layers above; we need to share those layers across our whole organization so that everyone knows the common goals and they work together rather than in different directions. This is the spot where many organizations fall over — their plan is not communicated and consistent, so the left hand does not know what the right hand is doing!

I asked all the product managers in the organization why they were working on certain things. None of them could answer me. No goals, no direction. They are just reactively building requests. Then I asked the leadership team what was the most important thing we could do as a company? They all gave me different answers. It’s pretty clear we’re not aligned on our strategy.

—“Escaping the Build Trap” by Melissa Perri (p71, abridged)

Inevitably, we will need to adjust our plan as our business progresses. This is to be expected. Each time we adapt and improve, we also need to widely publish the updates.

Create company and organizational goals that lead to customer outcomes. Make the corporate goals and strategy clear to all, make them visible and refer to them continuously.

— Heidi Araya

What About…?

There are a few things we didn’t cover, but are worth considering.

Positioning. Product positioning is a large topic in itself. Often it’s left to the marketing department to figure out, but as you can see above the Vision and Strategy layers speak directly to positioning. I recommend reading “Obviously Awesome” by April Dunford; in it you will find many elements that speak directly to the Strategy elements above. In fact, I recommend following her product positioning steps as part of your strategy discussions.

Product Goals and Sprint Goals. The 2020 Scrum Guide describes these two goals. A Product Goal is the same as your product vision. A Sprint Goal is still the same thing — a progress goal for each Sprint — but from our Outcomes and Experiments layers we can see how to make the Sprint Goal far more customer-centric and less like “implement all these features by the end of the Sprint”.

Metrics. We haven’t talked about how to measure the impact or success of your project within the four layers above. I’ve previously written about avoiding Agile Success Theatre in favor of metrics that actually measure business outcomes. Everything that we’ve talked about above is from the perspective of making a tangible difference to your business, rather than focusing on how much code you wrote last week. If you can measure the success of your initiatives above (e.g. customer engagement, customer sentiment) rather than focusing on velocity and story points then you will be well ahead.

Hypotheses. It has become fashionable to phrase features or outcomes a hypothesis statement. For example “we believe that if we provide solution X then it will increase our customer retention by Y%; we will know this by seeing metric Z change by W amount.” Since we are already dealing with Experiments, it becomes natural to phrase each one as a hypothesis to be proven or disproven. It’s a good practice to get your mind in the headspace of identifying risk and verifying your initial hunch.

Conclusion

A common problem with many ways of defining product vision is that it bears little correlation to the work we are actually doing — the features that we actually deliver. So this means we are not actually creating the value that we think we are. Or maybe we treat the vision with skepticism, as in management espouse one ethos but tell us to build something quite different.

So we looked at a four layer model for product focus. The four layers are:

Vision. What do you want to be known as? This is a simple, coherent promise that you fulfill to your customer. Strategy. How will you execute to get there? This must delineate your current position, challenges or hurdles along the path to your vision, and how you will overcome them. Outcomes. What goals do your customers want to achieve? This identifies in detail how your product vision satisfies the needs of your customers and provides them with day-to-day value. Experiments. How will you fulfill your customers’ goals? This describes the actual work you will do to realize customer outcomes.

By identifying and refining these four layers, we can focus our work so that everything we work on contributes in a meaningful way to our overall product vision. We should be able to see the connections all the way up and down the tree: an experiment should contribute to validating an outcome, an outcome should fulfill some part of our strategy, our strategy should realize our vision, and our vision should be a common purpose that our customers and our staff can all rally around.

You can see that the overall structure contains a considerable amount of detail, especially the Strategy layer. And you can see that it takes considerable work and iteration to get all these layers meshed and supporting each other well. We should not expect that this is a trivial exercise — it can take months or years of continuous improvement before we get it all right. But if you take the time to connect the dots all the way from your vision right down to your day-to-day deliverables, then you may unlock something remarkable: alignment.