Product Management frameworks are exciting to learn and frustrating to implement. As a product manager myself and a framework teacher, I totally understand the appeal. Being a product manager is a messy job. You’re constantly trying to explain to your peers what you do. You didn’t go to school for it. And every day you have to motivate really smart people who don’t report to you to align with your vision and decisions. In the least, frameworks provide a comforting structure. At best, they align and focus your team, leading to operational rhythm and achieving your goals much faster than you anticipated.

As a Jobs-to-be-Done trainer and consultant, I’m obviously a huge fan of frameworks. In the past few years of helping dozens of large and small companies with Jobs-to-be-Done, I’ve repeatedly seen the enthusiasm of learning something new followed by the struggle to implement the lessons. Those who overcome the struggle reap the rewards.

The phenomenon is not unique to Jobs-to-be-Done. Here’s a pattern you have likely experienced with any framework:

• Hype: Your team reads some articles or even a book about a framework and gets amped about using it to fix broken processes, operations, decision-making, etc. and hit the targets you’ve been missing.
• Thrill of Education: You bring in expert trainers to teach the framework to your team. The session is one or more days, and your team happily attends. They believe this new framework has great promise, the training will be a nice change of pace, and you ordered great food. At the end of the workshop, momentum is at its peak. The trainers were inspiring, and the team is excited yet a little intimidated about putting the framework into practice.
• Cannon Shot: The day after training you and your colleagues are shot out of a cannon. You spend the morning unburying yourself from the emails you didn’t answer while you were in all-day sessions. You look on everyone’s calendars to find time for the “Framework Implementation Meeting.” The next available slot is in two weeks. (While you were in the session the rest of the company slammed you with meeting requests). While you wait for the follow-up meeting, your team falls back into its operational patterns. That’s ok, you think, they need to finish their current projects, and there’s a bunch of research to do before we can really use this framework. The follow-up meeting can wait.
• Land of the Forgotten: This is where your dreams of fixing your broken processes fade. Your follow-up meeting got rescheduled. Finance told you to wait for next quarter to get budget for the research. Half of your resources are working on tech debt. Growth has slowed so much there are whispers of re-org--definitely not a good time to start something new. Your team, your work, your company, and your career remain on the descending path they were on before you learned about the framework.

Don’t let this happen to you. I’ve learned from experience so you don’t have to. Here are three tips to implementing frameworks. Break the pattern and use frameworks to improve your team and achieve your goals.

1. Don’t Add, Change

Frameworks can be extremely powerful, but they cannot add hours to a day. Not only is it unrealistic to ask a maxed-out employee to add something to their plate without taking something off, it’s demoralizing. We’ve all been on the wrong end of that equation, and as a product manager, you’ve already learned this lesson from your engineering team.

Engineers can only handle a finite number of story points in a sprint. If you want to prioritize a new item, you have to de-prioritize something else.

The same is true for Product Managers. You are not superhuman.

To help your team adopt a new framework and the work that goes with it, change their responsibilities.

Change their metrics of success. Change the way they write specs and user stories. Change the meeting schedule. Change the deployment schedule. Change your criteria for decision-making. Change the process for decision-making. Change one of these things, all of these things, or a new thing not listed here, but change something.

Presumably, the reason you got excited about the framework in the first place is that something wasn’t going right on your team and you thought the framework could fix it. Articulate that something. Isolate it. Before you introduce the new framework, offer it to your team as the candidate for change and tell the team, “I expect the framework to replace this thing we do today.” If you do it right, adding the framework decreases the work.

2. Use The Framework Right Now; Waiting Is a Slow Death

The training session ends, everyone is excited, and they think, “I’m really looking forward to spinning up a new project that will be right for this, but I have to finish my current project first.”

Two weeks later...fire alarm! Your team interrupts their current project to put out the fire. It takes another two weeks to clear the smoke. Now, they’re back on the project. At lunch one day, someone remembers, “Weren’t we going to adopt that framework?” “What would be a good project for that?” “We should talk about that when I’m back from vacation.” You get back from vacation to 500 emails. The framework is forgotten.

Waiting to implement a new framework will kill it.

Meanwhile, you continue with your old processes, decision-making, and operations that you thought were so broken that you needed a new framework. And every day you do that, you are spending money on development that isn’t achieving your company goals because they were chosen under the old, broken decision-making rubric. Your budget dwindles and you tighten your belts, “We can’t implement something new now; we’re in crisis!”

Here are two ways to avoid this death spiral:

• Come up with a project (or multiple projects) that will use the framework before you train your team in it.
• Don’t wait for a special project. Insert the framework into whatever your team is doing today even if you can only make incremental improvements, which brings us to tip number three.

3. Perfect is The Enemy of The Better

Often when you learn a framework, you learn it from an expert who has spent years using, advancing, and teaching it. The framework is full of new terms with very precise definitions. There are specific research, analysis, and decision-making techniques. There are wrong ways of doing things with seemingly disastrous consequences. Leading practitioners have long-standing arguments about the right way to do things. The experience can be intimidating, like you’re walking on a minefield. One wrong step and BOOM.

It can make you feel like using the framework requires perfection and a tremendous amount of work. You can’t use human-centered design without observing your customer in their natural setting. You can’t be Lean without lighting your road maps on fire, allocating all of your engineering resources to instrumenting every pixel of your application to measure user behavior, and hiring a coach for every team. You can’t use Jobs-to-be-Done without doing dozens of user interviews, running lengthy surveys, and executing a detailed analysis of every competitive feature against every customer need.

All of the above activities are valuable and help you mitigate the risk of investing in the wrong product ideas but none of them are necessary to get started with a framework.
You can use a framework before executing all of the research, training everyone in your organization, and building out the infrastructure to support it. Remember, the framework was appealing in the first place because something about your current work habits was broken and you were not realizing your aspirations. Even if you start with a small piece of the framework, even just the way of thinking, it will be better than what you were doing before. Start with that while you invest in full implementation.

For example, if you’re implementing Jobs-to-be-Done, before you do all the research, create a hypothesis about the job your customer is hiring your product to do. Make sure it doesn’t include a solution. Then pick a feature your team is *currently* working on (don’t wait for a new one, see above). Ask, “How would this help our customers get the job done? Which struggle with the job does it help our customers overcome? Does it satisfy that need faster and more accurately than their current solution?” Then refine the feature based on these answers to try and satisfy the need better than the competitive solutions.

Because you didn’t do your customer interviews yet, maybe your job will not be at the perfect level of abstraction or you’ll articulate it in a way that’s not exactly in the customer’s language. Maybe the need you identified is not the *most* unmet need because you haven’t done your survey yet. Perhaps you’ll miss an element of the existing solution that makes your speed assessment a bit off. But at least you’ll have a justification for developing the feature that is clearly connected to a customer problem, builds your team’s customer empathy, aligns your team with the customer’s goal and a clear goal for your feature, and potentially leads you to refine your feature and increase your likelihood of success with it. Those are a lot of benefits even though you are still far from implementing the framework perfectly.

In parallel, you can do all the work related to getting the full value of your framework, but don’t wait for that. In the meantime, your team can perform much better than they do today.