As Product Managers, it is arguable that we have one of the most critical roles in building a shared understanding of the problem so that our team can build world-class products. But, we know it’s a lot easier said than done. Scaling product management thinking within your team enables you, as a product manager, to focus on the complex, hairy questions, like the long-term vision of the product as your team becomes empowered to make good, product decisions on their own.
This talk addresses the benefits of getting your team to think like a product manager (for both you and your team!) and practical exercises on how to build that product muscle within your team.
— Adam Bottega (@adzbottega) October 31, 2019
Jenny joined a team that had about 20 people and 5 projects, but she was quickly becoming a bottleneck and focusing on short-term tactics and not long-term strategy.
The team did not get why they were building things. They didn’t have context that leaders had, and that was what they really wanted from Jenny. She wanted to syndicate what was in her head.
Bring people on the journey. Empower to make decisions on their own; get them engaged with the problem just as you are; then they can take up a lot of that short-term load – freeing you up for long term thinking.
Review feedback as a team –
- they have a weekly feedback meeting that’s treated as being as important as retro and planning. They split the feedback and respond to customers (they do use some consistent/canned answers). Created tickets in the backlog as required.
- Set things up so your whole team gets notified when feedback comes in. JIRA issue collector does this, there are slackbots.
- When this works, magic happens – engineers saying “we need to prioritise this bug, we get feedback every day”.
Have feature leads –
- this is usually an engineer; and the role complementes team lead, PM and designer. They are responsible for delivery of a specific feature. They drive the technical direction and follow through on execution.
- this is a role that can rotate between people on the team, everyone should have a chance to do this
- it’s a great growing opportunity for engineers; and gives PMs a way to work closely with an engineer
Prioritise as a team –
- Have a prioritisation framework
- set high level goals, eg. OKRs
- formally split team time between Keep The Lights On vs. OKRs.
- prioritise collaboratively – get the whole team to understand why you’re doing things in the first place
- try not to answer “which one is important” → ask engineers what they think, use it as a chance to coach them on prioritisation
- eventually you’ll see people say “no we’re not doing that, it’s not part of our goals”
Other tips –
- Demo your work – what have you learned about customers, what metrics have you looked at? Don’t just demo engineering stuff.
- Get peoples ideas – include people in vision setting workshops, kickoffs, etc
- Try to stay out of the backlog – PMs need to set higher level goals and not be bogged in details
The result of all this is the team is empowered to make decisions, they are all experts on the problem. The PM’s role is to create shared understanding and enable this empowerment. You get high velocity, high engagement/excitement, long term focus and better solutions.
Great product teams are made up of ordinary people who are empowered and inspired. – Marty Cagan