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