Today we're going to talk about adopting a product roadmap framework. This is for teams who are trying to create product roadmaps. If you've ever tried to create one, it can be extremely difficult. There are different ways to prioritize roadmaps. There are different ways to prioritize what features you should focus on. There are different prioritization frameworks.

Who Could Use a Product Roadmap Framework?

Let's talk a little about product teams who could use a product roadmap framework. Maybe they have created a roadmap already, they have a document that everybody's working on, but the product leaders -- the various product managers and the internal stakeholders -- have habitually disagreed on what the prioritization should be. You create the document and then you go into a meeting and you bring your whole internal team there (even the newly onboarded employees). You start to discuss, "Oh, this is what we should do, right?" And you find out that there is rampant disagreement and you end up debating like crazy. Often this can happen because you don't have a clear view of the goals of your product and the goals of your roadmap. When you don't have that -- if things are unclear and you're not all speaking the same language -- a framework can be really helpful.

A Product Vision Based on Customer Needs

It's a step-by-step process to adopt Jobs-to-be-Done as your product framework. But ultimately, it is going to massively increase your product development efficiency because it's also going to mitigate risk. This comes from having a product vision. What should your product vision be based on? Well, of course, it should be based on what your customer wants and what they need: your customer needs to get their job done. They're hiring your product to get the job done. Your product vision has to be based on what your customer is trying to do, not what your products are trying to do. That's the first step.

The next step is to agree on what that job is. You've got to get everybody in your team to agree on what that job is. Every job has a whole series of steps and each step has a whole series of needs. Jobs are very, very complicated which is why it's incredibly important to have that be the first step. Determining what you're going to develop means prioritizing where the struggles are in those needs. And that's the next step: identifying those struggles, where the jobs are underserved, and where your competitors are weak.

It's easier for your team to pick a product strategy. This means agreeing on 2 questions: "Where should we focus?" and "What platform are we going to use to get the job done?" It's much easier to agree on your product roadmap prioritization because what you should prioritize is what your customer struggles with. We always shorthand this and joke that product teams actually shouldn't prioritize their roadmaps. Your customers should prioritize your roadmap. The things your customers are struggling with are what you should focus on.

Problem-Based Roadmaps

For decades, there have been product managers talking about problem-based roadmaps. It seems like once every five years or so, we see certain blog posts really take off because of this. And it's always a product manager positing that there should be a problem-based roadmap, that instead of having a list of features, you should just have a list of problems and the stakeholders should get excited about the problems you as a team will solve. Once you determine what those problems are, then the team can go away and investigate the technologies that could be best put to use to solve that problem. They can investigate the cost of implementing them and they can create the priority order of features that they're going to launch that will solve that problem. But the rubber meets the road in how you define a "problem."

Whose problem should you solve? First of all, should you be solving your problems as businesses? Or should you be solving the customer's problem? Secondly, what level of abstraction makes sense for problem solving? Is it a problem like a customer can't find a particular button on your page? Or, do you want to solve the problems that they have independent of your product -- the problems that they have whether you launch into the market or not? Jobs-to-be-Done can help you focus on that. But how?

How Does JTBD Help?

The first step, of course, as we mentioned, is figuring out what the job is. Then, you figure out all the steps to the needs. That's going to give you a much better definition of a customer problem. A customer problem is a goal your customers need to achieve independent of any products or solutions. That's the key. There are plenty of examples of this throughout history: no one wants Apple or Google Maps, they want to get to a destination on time; no one wants a quarter-inch drill, they want a quarter-inch hole; no one wants a swaddle blanket, they want to get a baby to sleep through the night; no one wants a stent, they want to restore artery blood flow, etc, etc.

You need to identify the problems that work at the level of abstraction that you have a risk-mitigated way of solving. What do we mean by risk mitigated? It means you can launch a solution at a cost and a time that allows you to hit your growth goals. So let's say you need to hit a certain growth number, by a certain date, in order to generate the revenue you need to survive as a company. If you have a product idea that will launch three months after that, your company will probably go out of business before you launch it.

When we talk about mitigating risk, it's the risk that you have the wrong idea. It's the risk that the idea will cost too much or take too long to build such that you can't launch it in time to have the right impact on your business. If you have an idea to get a baby to sleep through the night and that's it, and you think you can just make that faster, more accurate, and you can bring that to market at the time your company needs, then go for it...as long as you know it's going to do that better than competitors. But most teams don't have that kind of runway. They can't solve problems that are quite that big and only wait until they solve it to launch.

We recommend you break the problem down into smaller components so you can solve more discrete things. This is where the Jobs-to-be-Done framework can come in handy; it helps you figure out what those more discrete risk-mitigating problems are. For example, to get a baby to sleep through the night, you might need to figure out how much you need to feed the baby before bed. That's a much smaller problem than the whole problem of getting a baby to sleep through the night. It's what we would call a "customer need." If that customer need is unsatisfied, then that's an opportunity for you to get people to switch to using your product if you can demonstrate that you can help them figure out that problem faster and more accurately than the competitors' solutions.

Not only do you need to figure out how big your features are, but you have to figure out how big the problems are that you're going after, and that's a tremendous help in determining what to prioritize in your short, medium and long term.