Innovation Charters in Motion

Resolving The Struggle Across Agile, Jobs-to-be-Done, and Product Line Strategy

by Paul O’Connor

Agile, Jobs-to-be-Done, and Product Line Strategy are in a significant struggle. Each tool drives superb product development results, but old-school gurus didn’t design them to work with one another. Instead, they push in different directions. The key to solving the challenge and reaping extraordinary gains is to employ a powerful toolset called Innovation Charters.

Many product development professionals declare an evangelical dedication to at least one of the topics, yet few managers see the struggle. Surprisingly, they’re simply not well-versed in the full set of topics. They know the titles, but dismiss the methods they don’t follow. And that’s a mistake.

The Methods and Their Following

I’m calling out two topics that have strong followings, and another topic that’s gaining support. The first is Agile, and the second is Jobs-to-be-Done. Agile has an almost religious like following among project managers and developers, particularly those deeply involve in software coding. Jobs-to-be-Done has a strong and growing following among marketers and those seeking a strong link between customer needs and the product offering.

The third is product line strategies. More specifically, it’s product line systems and their strategies. This new-school approach stresses synergistic gains across sets of multiple products. It’s much different than traditional product strategy that focuses on developing and managing one product at a time.

The issue is that these approaches are independent, and they push in different directions. In their current state, these three methods can work against one another and hinder a company’s performance.

New School

I’ll also show how adding Innovation Charters and Responsive Roadmapping to the mix corrects the problem and drives extraordinary gains. These are new-school methods, both are rooted in old-school fundamentals.

Let’s explore the topics.

#1 Agile Methods

In today’s development groups, nearly everyone has an Agile approach underway.

Agile was created to help companies develop software. In our digital world’s early days, teams quickly learned that old-school waterfall approaches were unsuitable for software development. The friction between process and project was far too great. It turned out that practices like Stage-Gate, hurt software development more than they helped.

Agile now extends beyond software to tangible products and services. It’s core principle is to avoid rigid practices and work in sprints and scrums. This flexible approach stresses adjusting deliverables based on fast customer feedback and nuanced user stories. And to do this, teams must build backlogs of work and product features. Agilists then work to “groom” their backlog and decide what they should deliver for each sprint and project iteration.

#2 Jobs-to-be-Done

Jobs-to-be-Done is much different. It’s a practical approach to understanding customer needs. Jobs-to-be-Done is based on the notion that people don’t buy products. Instead, people hire products to do a job. To the Jobs-to-be-Done evangelical, the outcome of these jobs matters the most. Jobs-to-be-Done enables developers to discover what customers want and need, even before the customer can voice these needs in terms of product attributes.

Jobs-to-be-Done also improves a company’s ability to segment markets by analyzing and clustering job outcomes. This approach makes Jobs-to-be-Done segments specific to product development. Such segmentation differs from what companies lay out for sales and distribution. The big deal is that Jobs-to-be-Done-defined market segments set up notable targets for front-end discovery and concept development work.

#3 Product Line Strategy

Product line strategists may use Jobs-to-be-Done to create and position new offerings and then use Agile to develop them. But the strategy objectives go further. A good strategy seeks to leverage assets and gain synergy across many products. Plus, it strives to align with other non-product functions in the organization. This scope is broader than that for Agile and Jobs-to-be-Done. It’s the multi-product concerns that separates product line strategy from traditional single product strategy.

Product Line Strategy aims to boost the line’s full impact, now and into the future. To carry out the strategy, product line teams must build a roadmap for the entire product line. The roadmap’s purpose is to guide work and aid decision-making to keep the strategy on track. The product line team’s job is to make sure the plan is coherent, coordinated, and impactful.

The Conflict

These practices weren’t designed to coexist. They can act like three forces pushing in three different directions. Unfortunately, their independence creates a burden for product development and product management, not a benefit.

Rather than working independently, the approaches should complement and boost one another.

But how can companies unify these three disparate forces?  The answer is to set up and use a long-established tool called the Innovation Charter. It’s a vehicle to build focus and guide direction before work begins.

But before explaining the charter and its use, let’s look at the conflicts across the approaches. Our challenge is that the gurus who created the practices did so without insights about the others.

Just Develop The Product

Many Agile experts may say, “I don’t need Jobs-to-be-Done research. The job I want done needs people to focus on coding software, building systems, and crafting products.” They say, “why should we invest time and money into something not needed?  The outcome of our work can’t be market research. We need to produce a product that customers will buy, and we do that by direct and frequent communication with customers. We build the customer’s voice into Agile and don’t want to spend time or money on independent research. Jobs-to-be-Done doesn’t do my job!”

The Agilist also shuns fixed strategies. Their rightful concern is to get a product out the door that people will buy. Agilist say strategy comes from on-high and means little once a project begins. To them, their work supersedes the strategy. And they double down on this view when they perceive a strategy to be inflexible.

Just Develop The Product

Many Agile experts may say, “I don’t need Jobs-to-be-Done research. The job I want done needs people to focus on coding software, building systems, and crafting products.” They say, “why should we invest time and money into something not needed?  The outcome of our work can’t be market research. We need to produce a product that customers will buy, and we do that by direct and frequent communication with customers. We build the customer’s voice into Agile and don’t want to spend time or money on independent research. Jobs-to-be-Done doesn’t do my job!”

The Agilist also shuns fixed strategies. Their rightful concern is to get a product out the door that people will buy. Agilist say strategy comes from on-high and means little once a project begins. To them, their work supersedes the strategy. And they double down on this view when they perceive a strategy to be inflexible.

Developing Impactful Products

Jobs-to-be-Done experts have a different perspective. They’ll say, “Agile’s fast feedback from customers gives a view of customer needs that’s too narrow and short-lived. They say the fast feedback approach doesn’t help good product innovation, it reinforces small, incremental moves. This narrow focus wastes time and effort by pursuing less desirable developments.

Jobs-to-be-Done evangelists also point out how Agile provides no help in segmenting markets and understanding where new offerings should focus.

Sure, Agile will get a product out the door, and someone will probably buy it, but that product won’t have the impact that Jobs-to-be-Done delivers. Plus, the Agile approach often drops new products into markets while exposing the product to easy competitive moves. This negates the product’s gains. ”

Jobs-to-be-Done gurus are quick to point out that understanding job outcomes is vital to a strategy. Without Jobs-to-be-Done, strategies are weak. To these gurus, Jobs-to-be-Done is the strategy. It’s not just a part within the strategy.

Product Lines, not Products

Strategists focus on an entire product line’s performance, not on just developing one product. Their goal is to get the most out of the line. The strategist says that being Agile or using Jobs-to-be-Done only matters if they do a better job than otherwise. The main goal is to realize a notable impact from the strategy. Should an organization not embrace Agile or Jobs-to-be-Done approaches, the strategist will push on without them.

So, how important is it to resolve the independent views, and can the three methods yield better results together than separately?  These questions are fundamental to product development and management. But recognize that if you ask an expert focused narrowly on one topic, you may hear them discount potential gains from the others. The same is true for your colleagues who may zealously support one of the topics.

Uniting the Approaches

Gaining more by having the three methods work together is a job that falls to practitioners and independent consultants.

Getting products out the door faster (by using Agile) and matching customer needs better (by using Jobs-to-be-Done) aren’t the company’s only mission. Business leaders must work across many topics to drive value for their shareholders in the near- and long term.

Leadership will always want their organization to develop only the “Best Products. ” And building a shared focus on “Best” is a challenge.

The Agile promise is to get products out the door and then use future generations to make them better. The Jobs-to-be-Done promise is to set up targets for product feature sets or job outcomes. And a strategy’s promise falls short without these execution capabilities. Each needs the others to enable a company to deliver what is truly “Best. ” That’s why a singular, evangelical approach toward only one method may create enthusiasm, but with time, the situation can become tricky, if not disastrous.

What’s “Best”

The notion of “best products” is vital to a business. Unfortunately, it also falls flat with old-school single-product thinking. Today, companies must build a continuous stream of products. The focus isn’t to develop and launch just one product at a time.

In today’s competitive markets, there is no such thing as a single, Best product.

The job is to build a flow of products that work in unison. It’s to boost the overall impact, and this demands Strategy, Agile, and Jobs-to-be-Done to work together. It’s a product line approach, not a focus on developing one product at a time. If you wish to bolster the product line, the three methods must complement each other.

It’s here that Innovation Charters become so powerful. They aid with integrating the approaches.

Innovation Charters

Innovation charters are documents that act as targets for new products and services. They’re created before defining a concept, and they focus a company’s front-end efforts like design thinking and creative explorations. The idea is to target innovations and development before forming concepts and starting projects.

As deliberate targets, Innovation Charters enable a focus that drives strategy instead of encouraging a random walk through an infinite field of opportunities.

There’s a rich history both in the academic world and among practitioners in driving gains from innovation charters. We know how to create and use them to drive greater value into innovations and product development.

Good and Bad Bureaucracy

An Agile team may declare static charters to be unhelpful. The Agile mindset is to root out such documents as bureaucratic. But bureaucracy is not always a burden. With an open mindset, you’ll see some bureaucracy that set standards and create focus can be extraordinarily valuable.

Charters that target Jobs-to-be-Done outcomes are essential to strategy. They guide projects toward features that best match customer needs. They also help coordinate more significant impact from the entire line.

An Agile team undermines a strategy when they drop charters. It forces product line teams to embrace firefighting to keep their lines competitive. Dropping charters across many projects can then drive chaos into a product line. The only good news about the chaos is that if you only care about one project, you can point to the other teams as the root of your problems.

Dynamic Innovation Charters and Responsive Roadmaps

The solution isn’t to toss all innovation charters. Instead, it’s moving them from static use into dynamic documents within a continuous management flow. The flow is a practice called Responsive Roadmapping.

The Responsive Roadmapping flow ties the Agile approach to strategic moves and resource management.

And it does this while keeping a focus on project objectives and Jobs-to-be-Done outcomes.

The approach works by turning static innovation charters into dynamic tools. The dynamic charter helps Agile teams to rank-order and groom their sprint backlogs based on strategy. They aid teams to resolve Agile backlogs, drive Jobs-to-be-Done outcomes, and manage Strategy moves. Plus, they guide product line teams to adjust strategy moves based on Agile backlogs and needed Jobs-to-be-Done outcomes.

Embedding Jobs-to-be-Done

Charters and Responsive Roadmapping also overcome Jobs-to-be-Done’s most significant challenge, embedding Jobs-to-be-Done into continued use. Today, most Jobs-to-be-Done application is one-off — to uncover a set of desired outcomes for a single development project. It’s often a product owner’s decision to use it or not. But Jobs-to-be-Done outcomes are a cornerstone of each innovation charter. With a flow of innovation charters, there’s also a constant flow of Jobs-to-be-Done outcomes.

Consider how the Agile approach purposely creates a backlog of work. This is development work focused on new features of the product, and the work is either being delayed or removed from the product’s current generation. But these features, if they made it into the original scope of the product, should also be linked to a Jobs-to-be-Done outcome. When there is no such link, it’s likely the foundational Jobs-to-be-Done research isn’t being carried out, at least not correctly or not on the product in question.

It’s also important to see how the Jobs-to-be-Done outcomes, captured within innovation charters, should be focal points of deliberate product line strategy moves.

In turn, the innovation charters, each with jobs to be done outcomes, should be displayed and tracked on the product line’s roadmap.

Backlog Decisions

The Agile Backlog decision creates two critical questions. First, will the Agile team make backlog decisions with a clear understanding of related Jobs to be Done outcomes? Second, will the backlog decision maintain a coherent strategy and a viable roadmap? If there’s no approach to unify Agile, Jobs-to-be-Done, and Strategy, the Agile team likely makes decisions by itself. That’s good for the project but probably not what’s best for the company.

The recourse is to embed Jobs to be Done outcomes into innovation charters before development projects start. The product line roadmap should then capture and track the innovation charters both in front-end projects and throughout development. The solution must also enable teams to adjust the charters as the project moves forward. Any change to a charter then shows up on the roadmap, and management must address it as part of product line Strategy oversight.

Strategy and The Big Picture

Backlogs and outcomes aren’t the only influence on a product line and its Strategy. Product Line teams must also reconcile many other changes. Some changes may have a minor impact on the Strategy and the product line flow, while others may have an enormous effect. For example, competitive products might pop up, supply chain bottlenecks may occur, or economic disruptions may happen. Product line teams must scrutinize such influences across all product line decisions, including backlog decisions, as part of the Strategy they laid out.

These influences mean the Product line’s Strategy and its roadmap must be in constant play. They must be responsive to the forces and adapt or pivot accordingly. The goal is to make sure that internal influences work to the advantage of the product line with minimal conflict.

Notice how innovation charters enable Agile, Jobs-to-be-Done, and Strategy to work in unison, not against one another. They aid teams with reconciling Agile backlogs, focusing on Jobs-to-be-Done outcomes, and carrying out an intelligent strategy. Plus, they guide product line teams to adjust strategy moves. Most importantly, they create guidance with a full accounting of Agile backlogs and Jobs-to-be-Done outcomes.

Maximizing the Flow

Responsive Roadmapping, set up as the reactive centerpiece of Strategy Oversight, purposely strives to continually improve a product line’s flow.

The goal isn’t faster-and-faster time-to-market when a company focuses on single product development.  Instead, the goal is to improve a product line’s velocity. The velocity is the speed toward improved cash flow, customer satisfaction, and competitive position for the entire product line.

Figure 1 displays how Responsive Roadmapping with Dynamic Charters boosts the impact of Agile work and JTBD influences. It shows how the approach focuses on a full product line, not just one product at a time.

If you wish to induce a faster product line velocity, not just a single development’s time to market, you’ll need smart thinking and great execution of the three core methods.  JTBD, Agile, and Product Line Strategy have much to offer a company. Yet, each topic won’t produce success repeatedly without the other two. Excellent product development must go further.


Figure 1. Responsive Roadmapping with Dynamic Innovation Charters both unifies and amplifies the gains of Jobs-to-be-Done needs assessment, Agile project management, and Product Line Strategies.

Learn More and Take Action

There’s much to learn about Innovation Charters and Responsive Roadmapping. Plus, there’s much to learn about unifying JTBD, Agile, and Product Line Strategy.

It’s best if you learn fundamentals from experts in each topic. But make sure the experts see where you’re going. Getting to a unified approach should be every manager’s and expert’s job.

Please encourage others in your organization, not just those in marketing or technology, to learn the importance of product lines strategy, Jobs-to be-Done, and Agile. But do this with an eye toward moving your business forward.

More Resources

Here are three short online courses to help you and your colleagues learn the topic and take action to improve your company’s product development and management performance.

Print Friendly, PDF & Email