If you read my last post on outcome-based product management and thought how do I get there, you aren’t alone.
I received dozens of emails, tweets, and comments from product leaders just like you asking this very question.
In an ideal world, every product manager would start at the beginning and work their way through the process.
But this isn’t likely to happen at most organizations.
Let’s take a look at the top reasons why not.
1. Fast Development Cycles Don’t Allow Time to Evaluate Ideas
With development cycles getting quicker, it’s harder for product managers to keep up.
They spend their days scrambling to keep the backlog full.
They become backlog groomers rather than problem solvers.
This is an expensive mistake.
First, it’s a pointless scramble.
Engineers will always find something to work on.
There’s technical debt to reduce, infrastructure to upgrade, and code to refactor.
Second, product managers can and should engage engineers in the entire outcome-based product management process.
Engineers can bring a unique perspective on how to map the challenge.
They can generate ideas drawing on their technical expertise.
They can help to identify assumptions, design experiments, and evaluate data sets.
Third, a product manager should be spending the majority of her time working this process, not project managing the engineering work.
It’s better to invest in the three ideas that will work, than to quickly build ten where only three have an impact.
Take the time to evaluate each idea and iteratively invest as the data coming back warrants. – Tweet This
Overcoming this barrier:
If you are a product leader, stop all product development for a week.
Is that terrifying? Start with one day.
Tell your engineers to work on platform projects.
Tell your product managers to spend the time evaluating the top ideas in the backlog.
They should identify the underlying assumptions, collect evidence, run experiments as needed, and evaluate the evidence before deciding whether to invest further or to jump.
You’ll be surprised by what you learn by this.
Your engineers will find things to work on.
Your technical platform will get a little better. You’ll earn goodwill with your engineering team.
Your product and UX teams will learn that some of the items in the backlog aren’t worth building.
You’ll earn that week (or day) back in no time by not building the wrong things.
If you are a product manager, start small.
Spend an hour testing an assumption.
Ask yourself, what would I expect to see if this assumption were true?
Write down your answer and then go look for evidence that supports or refutes it.
I know your schedule is full. Do it over lunch one day a week. Grow your investment as you schedule warrants.
Be systematic. Make next week better than this week.
Do that week over week and before you know it you’ll be evaluating everything before it goes in your backlog.
Don’t wait for permission. Just start doing it. It’s your job.
2. Product Managers Are Assigned Ideas to Pursue
In many companies, product managers are still order takers.
Features get doled out by management and product teams deliver on them.
More often than not, the feature list was generated by a leadership team with little exposure to customers or a shallow understanding of customer needs.
Many individual product managers don’t have the luxury of picking and choosing what they get to work on.
Overcoming this barrier:
If you are a product leader, push back on your leadership team.
Start building the case for why your team should be responsible for evaluating ideas.
Use your visual from mapping the challenge to communicate why your points of intervention are your current priority.
Help your leadership team see how their ideas attack a different point in the system or don’t impact the system at all.
Be consistent. Don’t prioritize your own pet ideas.
Treat all ideas the same regardless of where they originate.
Run them through the process and invest in the ones that make sense. Abandon the ones that don’t.
The more you do this, the sooner your company will start to adopt this process as the definition of product management.
It will take time. Change is hard. But you are better off starting today rather than tomorrow.
If you are a product manager, first do what your boss tells you to do.
If you are assigned ideas, you need to work on those ideas.
At the same time, invest in your skills related to evaluating ideas.
Get better at experiment design and data collection.
Do it over lunch. Come in 30 minutes earlier. Stay 30 minutes later.
Small investments over long periods of time pay off in spades.
Get good at evaluating each idea. Predict which ideas will work and which won’t. Track outcomes.
Once you are in a good position to make your case, share your process and results with your boss.
Remember change is hard and often slow.
Look for small wins and be persistent.
3. Product managers don’t have access to the data that they need.
This is a common barrier that is often real, but is also overblown.
You will never have perfect data.
You will always want to know more than you know.
But that shouldn’t prevent you from working the process.
Your map of the challenge will always be evolving.
So will the data that you attach to it.
Overcoming this barrier:
For product leaders, map the challenge.
How can you get your team access to better data?
What data do they have access to? What do they need most? How can you visually represent this challenge?
Identify your highest impact points of intervention.
Source ideas. Can you install Google Analytics? Do you have logs that can be mined? Can your team sit in on sales calls, conduct customer interviews?
Select the top ideas. Evaluate. Iterate.
See what I did there?
Your team works on your product. You work on the environment in which your team works. – Tweet This
This is your challenge to solve. Map it out. Work the process.
For product managers, collect some data right now.
Call a customer.
Go outside and observe the world.
Analyze your traffic logs, your feedback channel, your sales win / loss results.
Use whatever you can get your hands on.
Focus on the data you do have, not on what you don’t have. – Tweet This
Do the best you can. Make a decision. Iterate.
4. The product team lacks one or more of the necessary skills.
Product management is changing rapidly.
It means that we have to be investing in our skills to keep up.
This process requires many skills that you might not have: systems thinking, visual communication, suspending your need for closure, being curious enough to understand the root-cause, estimating the impact of an idea, identifying and testing assumptions, collecting valid and reliable data, drawing appropriate conclusions.
You don’t need to be an expert in each of these areas. You do need to develop competence in all of them.
That’s what the job calls for.
For product leaders, invest in your team.
Send them to conferences and workshops. Encourage them to attend classes. Give them a book budget. Share interesting articles and podcasts. Invest in a coach.
Prioritize it. Schedule it.
Ask your team on a regular basis what they are doing to invest in their skills.
Follow up with them.
For product managers, pick a skill, learn as much as you can, practice it. Iterate.
There are countless books, talks, podcasts, blogs, classes, conferences, workshops, and so much more.
Seek out what you need. Be proactive.
Practice. Practice. Practice.
A Final Word
I know this isn’t easy.
Our field is changing quickly.
It’s hard to keep up while doing our jobs.
But if we don’t, our jobs will leave us behind.
I’ll keep writing in-depth articles on each step of the outcome-based product management process.
I’m also planning to offer courses that will give you practice space to hone your skills.
If you invest a little bit everyday, before you know it, you’ll be transforming your organization, one product manager at a time.
Want to come along for the ride? Subscribe to the Product Talk mailing list.