How Product Development Frameworks Work Together To Enable Actions

A product strategy can be seen as a function that takes in business outcomes, possible product changes, activities people do and produce an effective action.

JTBD helps discover activities people do that need improvement.

Company Vision Helps identify business outcomes.

The North Star Framework helps produce metrics that align with business outcomes and activities customers do that need improvement.

Continuous Discovery helps discover opportunities and solutions.

Opportunity-Solution tree helps make product changes that align with opportunities which best solve company and customer problems simultaneously

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. 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.

From Escaping the build trap – Melissa Perri

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 consider business results and customer values with equal competence.

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.

Escaping the build trap – Melissa Perri

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.

The end

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.

The Build Trap, Great Product Managers, Strategic Gaps and Product Kata

Last month, I finished reading Escaping the build trap as part of an attempt to discover the pillars of product management. Although I did not discover anything of sort, I think it was a great read since the book provides useful frameworks and mental models that I can apply in my daily work. In this blog post, I want to elaborate on some ideas in the book that I found to be interesting.

Table of content

Introduction

Last month, I finished reading Escaping the build trap as part of an attempt to discover the pillars of product management. Although I did not discover anything of sort, I think it was a great read since the book provides useful frameworks and mental models that I can apply in my daily work. In this blog post, I want to elaborate on some ideas in the book that I found to be interesting.

A theme running throughout the book is about a particular fictitious company called Marquetly and how it escaped the build trap. Before that, we need to set some context by seeing how Marquetly fell into the build trap in the first place.

How Marquetly fell into the build trap

Melissa tells a story about a fictitious company called Marquetly – an education company that provides online training for marketers. Experts in digital marketing, Marquetly professionals create classes through their online platforms that any individual can take for a monthly subscription.

Marquetly was growing rapidly with yearly revenue growth at 30%. They hired a lot of people and assigned them to all sorts of projects. Then they learned that they needed product managers to work with developers after adopting Scrum. They moved marketing people to product management because they knew the audience for the school best.

The product and the sales team were pointing fingers at one another. All of them cited a lack of product management skills as the problem. Melissa got to work with the product managers, assessed their skills, provided them with new frameworks to try. Even though they saw glimpses of early success in how they thought and approached the problem, these moments were short-lived because the company structure incentivized around shipping features rather than values. They were handicapped by poor planning and poor strategy.

Revenue was declining, so the leadership pushed for even more features to be shipped, with the premise that without demonstrating the ability to ship, they would not be able to raise another round of funding.

The product managers reverted to their old ways. They stopped doing user research because it took time away from writing user stories. They began to focus on getting as many features as possible out the door. When the next release came, they had about 10 new features to deliver to their customers.

The calls began pouring in. The site was breaking because the features were not well tested. The teachers were frustrated that the new features got in the way of them trying to create courses and respond to student comments. Many teachers decided to take their courses down, which stressed the account managers to bring them back.

In the end, no one was using the new features that were rushed through the door. The revenue growth was declining, and company was feeling the heat. The company had too many strategic initiatives spread over very few people. The incentive structure is tied to shipping software, not solving problems. People think they have to ship or they won’t get paid. This is what Melissa called the build trap.

The build trap is when organizations become stuck on measuring their success by outputs rather than outcomes. It’s when they focus more on shipping and developing features rather than the actual values those things produce.

Becoming a product-led organization is the way to escape the build trap which, according to Melissa, involves four key components:

  • Creating a product manager role with the right responsibilities and structure.
  • Enabling those product managers with a strategy that promotes good decision making.
  • Understanding the process of determining what product to build, through experimentation and optimization.
  • Supporting everyone with the right organizational policies, culture and rewards to allow product management to thrive.

Great product managers tend to be pulled back to the problem space until it’s properly explored and validated

The book presented two bad archetypes of product managers : The Mini-CEO and The Waiter. Both are bad because they are too concerned with what to build, one way or another.

People often say that product managers are like CEOs their products. However, CEOs have a lot of authority over many things: they can fire people, they can change up teams, they can change directions. This myth birthed a very arrogant product manager archetype who doesn’t listen to anyone, and only tells people what to build. He usually does not do enough user research, and therefore relies on more opinions than evidence. To sum it up, The Mini-CEO is too concerned with building what they want to build.

In contrast, The Waiter is someone who swings to the other extreme. They go to their stakeholders, customers and turn their requests into a list of items to be done. There’s no goal, no vision, no decision-making involved. More often than not, the most important person gets their features prioritized. They implement the specific solutions that customers demand, instead of solving their actual problems. Waiters tend to focus on the when, rather than the why. As a result, they easily fall in the trap of managing projects rather than products. The Waiter is too concerned with building what others want to build.

So what’s a great product manager looks like? Let’s follow Melissa’s story of a great product manager in action. Melissa brought in Meghan, a product manager whom she knew, to talk to the team at Maquetly. Meghan worked on a software for consumer mortgages at a large retail bank. She told the team about how she thinks of her role and what does she do on a daily basis.

“I always start with our mortgage division’s vision in mind,” explained Meghan. “That’s our business. The vision is to make it easier and more convenient for mortgage applicants to apply (or for mortgage holders to access), their information from anywhere.”

Here we can see that she starts with what, specifically what does her business promise through offering this software or product. Answering this question leads her to focus on why that promise was made, or more particularly, why the mortgage application process was not easy and convenient.

After spending a lot of time talking and listening to them, she uncovered a lot of user problems that needed to be solved. For example, users have to go to the local bank branch multiple times a month to meet with a loan officer. They have to do a lot of paperwork in the office, which means when they forget necessary documents they have to come back the next day. And even then, they have to wait to see if they’re qualified for the amount they needed.

But how did she decide which problem to solve? Again, she goes back to asking what is the biggest problem that needs to be solved. At the time, 60% of first-time applicants who started the mortgage process did not finish with the bank and instead switched to other competitors. Improving that number was what aligned with the vision of her department.

To do that, the first thing Meghan wanted to understand was why these first-time applications were dropping out. Many people said they were frustrated with the process and willing to make it better. She conducted user research sessions with the team periodically and soon they found a pattern. Because document verification could not be done online, users had to go to the office. Many of them dropped out because they could not find an open appointment to verify their documents. Meghan sent out a survey and found that the problem was prevalent – only 25% who had this problem actually completed their applications with her bank.

She called the team together to generate ideas for what to build. They came up with many solutions and decided to run some experiments to see which one was the best. One experiment is essentially a Wizard of Oz Prototype. They had the applications email in the documents and the bank designated a person to review and approve them. Over time, these applicants completed their applications 90% more often than those who had to come to the office. They then scaled that solution and eventually reaching on the goal of zero verifications.

All the events are kept true to the book, but the framing and emphasis above are mine. In this framing, great product Managers do oscillate between the problem space (the why) and the solution space (the what), but they tend to be pulled back into the problem space until it’s been explored and validated. Only until then the focus is shifted towards ideating, validating and scaling the solution. It’s not a revolutionary idea, but seeing how it’s played out in a narrative is certainly helpful.

A good strategy should help organizations avoid the strategic gaps

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.

The most important part about the above definition is that it positions strategy as a decision-making framework that enables decisions, instead of a plan to be executed. In other words, a strategy specifies certain essential structures that govern how people should make decisions, but not the decisions themselves. In contrast, a plan is a set of decisions that will be carried out to achieve certain goals or objectives.

Why is this distinction important? Or conversely, what are the consequences of treating strategy as a plan. While studying strategy, Stephen Bungay discovered that when companies approach strategy as a plan, they often fail to achieve what they expected. This failure comes from the actions taken to fill in these gaps:

  • The Knowledge Gap.
  • The Alignment gap.
  • The Effects Gap.

The knowledge gap is the difference between what management would like to know and what the company actually knows. Management desires certain business outcomes but they lack the information necessary to create a plan that would achieve these business outcomes. This creates an impulse for management to demand more details to feel more certain. However, such certainty is often not possible until after experiments with high degree of uncertainty have been carried out. When the team is unable to provide such details, the knowledge gap manifests.

So what happens when management ignores the knowledge gap and proceeds to make plans? The alignment gap appears.

The alignment gap is the difference between what people do and what management wants them to do. Management may come up with their own plans because they believe that executing certain decisions will achieve the desired outcomes. The problem with this is that, as mentioned, they often lack the user understanding and insights required for such plans to be realistic and coherent. If the team has sufficient authority, then they would push back and execute other more informed and thought-out plans. Management is puzzled as to why things do not go as according to their plan, which is when the alignment gap manifests.

What happens, then, if the team doesn’t push back and instead carries out the plans that management provide? The effect gap appears.

The effects gap is the difference between what we expect our plans to achieve and what really happens. When plans based on flawed knowledge (inevitably) fail, management doesn’t understand why they fail and thus commands the team to provide more details & information. As you can see, we have arrived at the knowledge gap once again.

These strategic gaps tend perpetuate themselves and ultimately create friction that slows down progress and eventually grinds the company to a halt. Therefore, the advantage of defining strategy as a decision-making framework is in avoiding these gaps and enable organizations to be more effective.

Use Product Kata to get closer to our goals

Product Kata is my favorite framework from the book, and that’s mostly because Melissa did a great job walking the reader through the how the team at Marquetly actually applied Product Kata in their product development process.

To create strategy, you must understand where you want to go, then identify the obstacles standing in your way and finally experiment to tackle them until you reach the vision. This continuous improvement framework is called the Improvement Kata. The Product Kata is an adapted version that aligns with product terminologies.

There are four stages to the product kata:

  1. Understanding the direction.
  2. Problem exploration.
  3. Solution exploration.
  4. Solution optimization.

The first step of the Product Kata is to understand the direction, which is about the company vision and the business goals that the company needs to reach in order to progress towards that vision. They are important but are not too relevant to the ideas I want to elaborate. The next two steps: problem exploration and solution exploration, are particularly interesting.

Melissa showed how the team at Marquetly to explore their problems. They had set the goal to increase the rate of published course to 50% and the number of second courses created by teachers to 30%. After evaluating where they are with respect to these goals (25% and 10%), they determined the biggest obstacle to reaching this goal is the lack of understanding about the problems that teachers face when creating courses.

The next step they took was doing user research. After interviewing 20 teachers, they have discovered numerous problems that users were trying to solve:

  • They want to easily transfer their courses from another school.
  • They want to import all their content for creating a new course.
  • They want an audio-option only to save time creating videos and appeal to podcast lovers.
  • They want recommendations on pricing when creating a course.
  • They want to know what their potential students want to learn so that they can create relevant content.

They map the problems to the current user journey, and decided that the biggest problem was to get the teachers’ content into the system. They wrote down their hypothesis:

We believe that, by helping teachers get their lesson content into the system painlessly and quickly, we can increase the rate of published courses to 50% and increase the number of second courses created to 30%.

After discovering their most significant problem – getting existing content to the system, they refer back to the Product Kata to see what’s next.

After learning about that teachers have trouble getting the content into the system, their current state with respect to their goals had not changed. But their biggest obstacle did. They needed to know whether they are picky about the format, or they would follow a template.

After reaching out to 20 teachers and offered to get their content into the system, they discovered that the content came in all shapes and forms, Dropbox, Google Docs, Youtube link. The most surprising thing was that the videos came in unedited, only with instructions on how they are to be edited.

It turned out that the teacher were good at developing curriculums, but not necessarily good at making videos. They began to suspect that getting the content into the system might not be the problem, but creating online content was. They went out to talk with the teachers and confirmed that the they were indeed frustrated that they had to learn how to edit and create engaging videos.

After discovering that teachers have troubles editing and creating content which prevent them from publishing more courses, the Marquetly team tried to pitch their video-editing services to the teachers. They set the success metric to be at least 10 of the courses they worked on to be published within a month.

After two weeks, the team further discovered that most teachers had no idea what good videos look like for an online class. They ended advising the teachers to make their videos entertaining. Based on this information, they determined the solution components that mattered to the teachers:

  • Recipe or how-to guide for successful video creation.
  • The ability to piece together talking-head video, slides, images, audio and Youtube videos.
  • The ability to show text on top of the video.
  • Introduction slide to the video.

While the team was thinking through how these factors might turn into a scalable offering, they started to see courses go live. Within one week after the videos were edited and uploaded to the site, half the teachers had published their courses. By the end of three weeks, 12 teachers had published, so they succeeded in reaching their metrics for this experiment. The rest of the story is about how they scaled and eventually reached and surpassed their business goals.

The Product Kata for Marquetly looked like this:

I think Product Kata aligns well with the notion that in lean startup, anything that doesn’t produce knowledge is not essential. It does so by:

  1. Explicitly recognizing that the outcome of an experiment is knowledge.
  2. Tying the knowledge obtained from the previous experiment to the action in the next one.

Conclusion

Overall, while the book was not revolutionary, it has a lot of great ideas and frameworks that are neatly organized and presented. I enjoyed Melissa’s style of writing in this book a lot. Although Marquetly is not an actual company, the way she moves back and forth between presenting an idea and how it manifests at Marquetly was helpful to capture my attention and provide a narrative structure that connects the ideas together.

Spectrum of delight:A product strategy framework

According to Gibson Biddle – former Netflix’s product lead, product strategy answers the question “How will your product delight customers, in hard to copy, margin-enhancing ways”.

In this blog post I examine why that definition is interesting, and how it can be applied when formulating your product strategy

What is product strategy?

If I have to settle on the most important aspect of product management, I would say it’s product strategy. But what is strategy, and more importantly, what is product strategy?

If we look at Wikipedia, then a strategy is defined as “a general plan to achieve one or more long-term or overall goals under conditions of uncertainty”. That’s reasonable but vague and ultimately unhelpful. To be honest, for a while that’s where I was stuck at. When I searched for definitions of product strategy, they also seemed generic and unhelpful. For example, here’s a definition of product strategy:

A product strategy is a high-level plan describing what a business hopes to accomplish with its product and how it plans to do so. This strategy should answer key questions such as who the product will serve (personas), how it will benefit those personas, and what are the company’s goals for the product throughout its lifecycle. – Product Plan.

According to this definition, we should figure out who’s the target personas, what’s the benefits being offered, and what’s the goals of the company. I can’t help but feel that it’s not very instructive. I also suspect that the context in which these thinking become important is what makes them important, but it was unfortunately lost in communication.

But then I stumbled upon the series How to define your product strategy by Gibson Biddle – a former product leader at Netflix. I immediately found his way of thinking interesting and helpful. His series is very insightful and is highly recommended. However, some of the interesting things I noticed and thought about were not explicitly mentioned.

The next section talks about Gibson’s way of thinking about product strategy. The rest of this blog post presents my own take on product strategy, which is inspired by Gibson’s, together with my experience and thinking.

A product strategy seeks to delight users in margin-enhancing and hard-to-copy ways

According to Gibson:

A product strategy seeks to delight users in margin-enhancing and hard-to-copy ways.

Margin-enhancing and hard-to-copy

In order to understand why a product strategy must be margin-enhancing and hard-to-copy, we first examine the definition of company strategy from the book 7 powers.

A company strategy is a route to continuing power in significant markets.

Power is defined in the same book.

Intel simultaneously succeeded in microprocessors but failed in computer memories despite sharing the same managerial, technical, financial prowess. Whatever differences must lie outside all such common grounds. We can only assume that microprocessors possessed some sort of rare characteristics which materially improved cash flow, while at the same time inhibiting competition. These rare characteristics are referred to as power. Power is the set of conditions creating the potential for persistent differential returns.

The term “persistent differential returns” is particularly interesting, because it implies that power must be associated with benefits and barrier:

  • Benefit. The conditions created by power must augment cash flow. It can manifest as any combination of increased prices, reduced costs, and/or fewer investment needs. In other words, it must be margin-enhancing.
  • Barrier. The benefit must persist. There must be aspects of the Power conditions that prevent existing and potential competitors from engaging in value-destroying arbitrage. In other words, it must be hard-to-copy.

The point of a company strategy is to continue a configuration that creates persistent differential returns, which means that it must be margin-enhancing and hard-to-copy. A product strategy must also meet the company strategy, so it must also be margin-enhancing and hard-to-copy.

Delight users

But that’s only half of the story, the other half is what stood out when I first parse Gibson’s definition. A product strategy must, above all, delight users. It doesn’t matter if a company is gaining profit and staying ahead of the competition, if the product doesn’t delight users then you’re not really playing the product game. I think this is a sentiment we can all reasonably agree with.

Customer delight is usually discussed in the context of customer service (forsome examples). I believe that putting the concept of delight at the heart of product strategy opens up many possibilities. Offering delightful customer support is obviously important, but it’s also equally important, if not more, than the product itself delights.

The spectrum of delight

One interesting thing I noticed is the implication of defining product strategy in terms of delighting users. Follow the line of reasoning, I think it’s natural to see that there’s a spectrum of delight across which product aspects or features are scattered.

On one end of the spectrum, we have the things that are the opposite of what’s delightful: buggy features, bad onboarding experience, bad customer support, and more. On the other end of the spectrum, we have the power configurations, things that delight users in margin-enhancing and difficult-to-copy ways. In between these two ends are the things that are okay, and things that are delightful (but not yet part of a power configuration):

UnacceptableOkayDelightfulPower
Aspects & features that are broken, do not work as promised, or are below the industry’s standardAspects & features that are useful, acceptable that get the job done wellAspects & features that get the job done very well, better than the competitorsDelightful aspects & features that are elevated even further so that they can’t be replicated by competitors and they increase the company’s profit

The last division is likely the most unfamiliar. Let’s take a look at Netflix. One of their delightful “features” that’s also margin-enhancing and difficult-to-copy is Netflix’s originals.

  • It is delightful because their originals, for example, House of Cards, achieved excellent ratings and widespread audiences.
  • It is margin-enhancing because it attracted millions of new paid subscribers.
  • It is difficult to copy because, with more paid subscriptions, the marginal cost of building high-quality originals also becomes lower than its competitors. more Netflix subscribers mean the company can charge less while producing more quality content.

The other divisions on the spectrum should be more familiar. Unacceptable aspects or features make users churn, decrease retention, create bad reputations and decrease acquisition. The Okay aspects or features are things that are getting the job done, but there’s more to be desired. Delightful aspects or features are usually things that make people adopt the product if there are multiple similar products in the market.

I include the term “aspects” because there are things that are not features but they delight your users nonetheless. For example, if your users often remark that you have a lively community, and they receive answers minutes after asking a question, then that community is a delightful aspect. If your product competes against open-sourced projects, a delightful aspect is the pace of development and the professional commitment to improve and maintain the product. Without acknowledging them, we lose part of the bigger picture.

I use the term “features” because it’s more familiar, but your product probably has a lot of features with varying degrees of details, and your product strategy should remain high-level. I’d recommend applying the Job-to-be-done framework to identify the jobs that users hire your product to get done. The jobs and the aspects will become the units of your product strategy.

Once you’ve identified the jobs/aspects of your product and categorized into the divisions on the spectrum, then the strategy is to elevate the items in each division as far as you can towards the state of delightful, margin-enhancing and difficult-to-copy.

  • For Unacceptable items, your product strategy must first improve them so that they’re at least Okay. In the following quarters, they may be taken into the Delightful division, and even in the Power division.
  • For Okay items, the product strategy must make them become Delightful. In the following quarters, they may be even elevated into the Power division.
  • For Delightful items, they can be used optimize your marketing strategy to deliver the most valuable message. Your product strategy should aim to take them into the Power division eventually.
  • For Power items, the strategy must seek to maintain them.

Some aspects/jobs can be margin-enhancing in a non-obvious way. For example, if community is an item a delightful aspect, then improving it will reduce the burden on your customer support team, which increase resources to support key clients, which provides them with higher satisfaction and potentially attracts more license subscriptions (if you’re a SaaS company).

The most important part is identifying the jobs/aspects of your product and the divisions they belong to. The next section describes the JTBD framework and how it plays a role in product strategy.

The role of the JTBD in product strategy

The job-to-be-done theory is a theory about why consumers consume. It posits that people adopt a product or an innovation in order to get a job done. For example, when people buy drills, they want to hang a family picture on the wall. If you invent a product that helps people hang family pictures without having to dig a hole, then it will be adopted over drills, because it gets the job done better (with less collateral damage).

The following statement captures the essence of JTBD:

In the factory we make cosmetics; in the drugstore we sell hope.

I won’t go into too many details about the JTBD here, because there are available online resources that do an excellent job at that. However, it is useful to look at the two schools of thought on JTBD. Broadly speaking, JTBD can be categorized into two camps:

  • The Switch school of thought of Bob Moesta. Through qualitative interviews, it seeks out to reverse-engineer the underlying motivation for changing one solution to another. The researcher can then deduce “why” people hire a solution a product to get the job done and use the Four Forces of Progress to increase demand for a given product or service. It is also called JTBD-as-demand-generation.
  • Outcome-Driven Innovation by Tony Ulwick. Through qualitative interviews, ODI seeks to uncover desired outcomes that people want. Then these desire outcomes are prioritized quantitatively. ODI aims to create products that address unmet needs. It is called also called JTBD-as-innovation-generation.

Both these schools of thought are useful for product strategy because they allow us to uncover the jobs/aspects that belong to different divisions on the spectrum of delight.

Use the Switch Interview to uncover Delightful jobs/aspects

The purpose of the Switch Interview is to reverse-engineer why people adopt your product. The output of Switch Interviews can be used to increase the demand for your product by crafting messages that resonate with your potential users. But more importantly, it helps you identify the delightful aspects or jobs of your product.

You’re ultimately looking for the moment people start struggling with the previous solution because getting this job done is likely what’s delightful about your product. After all, they adopted your product, likely after considering the alternatives, so it’s reasonable to think that your product is getting the job done significantly better than others. For this task, my favorite way is to use the Four Forces of Progress framework to analyze the observations.

The four forces of progress can be used to analyze the factors that influence your users when they’re considering adopting your product:

  • The problems with their existing solutions make them look for alternatives.
  • The attraction of your new product, the promises you make that your competitors can’t.
  • The Uncertainty surrounding adopting your product.
  • The Habits that keep consumers from adopting your product.

The observations coded on the Problem and Attraction are likely the candidates that delight your users. Use observations coded on the Uncertainty and Habits to improve your product.

Use the JTBD Interview to uncover Okay jobs/aspects

JTBD is a theory, therefore it doesn’t specify concrete steps to uncover the jobs, or provides any guidance to do so. Fortunately, Tony Ulwick – who invented Outcome-Driven Innovation, has managed to put JTBD theory into practice. Outcome-Driven Innovation (ODI) is a process that enables companies to conceptualize and invent new solutions that help customers get a job done better and/or more cheaply. According to Strategyn, It has a 86% success rate, because it begins with a deep understanding of the job-to-be-done and employs unique quantitative research methods, which the JTBD Interview is a part of.

The JTBD interview focuses on uncovering the jobs, the need statements, the context surrounding the jobs through qualitative research. For product strategy, it can be used to uncover the jobs that are in the Okay division on the spectrum. Because the premise of most user interviews is to improve the product, users are naturally biased towards things that can be better. Therefore, you’d most likely uncover what your product is doing okay, but that they can be improved in some ways.

You can use some guidelines as follows:

  • Get the background on the job performer and the job
    • Tell me about yourself and what you do for a living?
    • What was the last time you had to do the job?
  • Focus on the main job and related jobs
    • What problems were you trying to resolve or prevent?
    • What else were you trying to get done?
  • Understand the process of executing the job
    • How do you get started?
    • What is the previous step, what is the next step?
    • How do you continue after that?
    • How do you know you are doing the job right?
    • How do you wrap things up?
  • Find needs
    • How do you consider the job done?
    • What workaround are you using?
    • What do you avoid doing? Why?
    • What could be easier why?
    • What is the most annoying or frustrating part?
  • Find out the circumstances
    • In which situation do you act differently?
    • What conditions influence your decision?

As you interview more users, you will be able to build a more comprehensive Job Map.

If you don’t take initiatives to counter natural biases, the Job Map will likely contain only the jobs that your product is getting done in an okay way, and the associated needs will point to the direction of improvement.

If you take initiatives to counter natural biases during user interviews, the Job Map will be a comprehensive description of all the jobs your users hire your product to get done, along with the associated needs. You will get extra clarity. Since you are aware of all the needs, you can ask users to rank them in terms of importance and satisfaction and discover underserved needs quantitatively.

Either way, it helps discover the jobs/aspects that belong to the Okay division on the spectrum of delight.

Use Churn Survey/Interview to uncover Unacceptable jobs/aspects

Unfortunately, I don’t have a lot of insights to add to this section. Churn is a beast that’s difficult to slay. However, it is an important part of your product strategy, because the jobs/aspects that make people churn need to be uncovered in order to make for a comprehensive product strategy. One of the popular methods you can go for is churn surveys. If you are lucky to get them on a call, apply the Switch Interview to analyze what jobs/aspects of your product are chasing people away.

My approach to product strategy

Put them together, my approach to product strategy is as followed:

  • Conduct the JTBD user research.
    • Conducting Switch Interviews.
      • Identify the delightful jobs/aspects.
    • Conducting JTBD Interviews.
      • Identify the Okay jobs/aspects.
    • Conducting Churn Interviews/Surveys.
      • Identify the Unacceptable jobs/aspects.
  • For each division, except for the last one, the strategy is to elevate all items to the next level.
  • Each aspect or job forms a swim lane in your product strategy.
  • For each strategy swim lane, define a metric and the tactics that will move the metric along.

Here are examples from Gibson’s Netflix case study:

References