Transitioning to having outcome-driven, empowered product teams is a tricky business. Here are some ideas to help navigate the human problems you’re likely to encounter on the way…
I recently wrote a response to Marty Cagan’s article Product vs. Feature Teams with the aim of explaining why some companies struggle to empower product teams, how many of the problems are related to mindset and what I like to call ‘human problems’.
Many of you wrote to me asking what we can do to help companies navigate this and what my approach would be to solving this tricky problem.
I don’t profess to have all of the answers, but I have experienced some ways of working and approaches that might help companies who are trying to make this transition.
Lead by example
Senior leaders in businesses have an important role to play when it comes to transitioning to empowered product teams.
They are the people that the business looks to for guidance and leadership and so it’s natural that their approach to transitioning to an outcome-driven, empowered product teams set-up is one that sets the tone.
In my experience, good communication around the changes that are happening and the reasons behind them is a good first port of call. Utilising key meetings such as all-hands / similar to let people know what is happening, how they can be involved and what is expected of them.
Setting the tone to ensure that open conversation can happen and allowing the opportunity for people to ask questions, raise concerns and provide continual feedback so that they feel heard is vital.
Providing continual support and backing for these new ways of working is also vital, something which I will discuss in the final section below.
Define roles and responsibilities
I have written about the importance of defining individual team roles and responsibilities in the past and how this transparency can really help teams to work well together as it removes the ambiguity around who does what.
If you imagine a company that is moving to an outcome-driven, empowered product team set up, the need to define roles and responsibilities becomes tenfold.
The transition is not only something that is happening to the product teams, it also impacts the rest of the organisation. Who makes recommendations and decisions when it comes to product? How do the ideas of those outside of the product team factor in this new world?
In the past I have seen frameworks like RACI and Bain’s RAPID put to good use to help people to understand how they fit into the product team eco-system.
If we use the RAPID framework as an example:
- R stands for Recommend — a decision or action
- A stands for Agree — to a decision — views must be reflected in the final recommendation
- P stands for Perform — be accountable for performing a decision once made
- I stands for Input — to a recommendation — views may or may not be reflected in the final recommendation
- D stands for Decide — make the decision
The framework lays out 5 groups of people and what each of them is accountable for. It’s worth noting that this works best when you only have one person as the decider, making the final decision if the recommender and those that need to agree, cannot.
How you organise the people in your company into these groups will very much depend on your culture and how you want to operate, but I have seen it work best when Product Managers are at least in the “R” bucket and making recommendations, and when another senior Product stakeholder is the decider — for example your CPO or CDO.
Bring colleagues along for the ride
In order for a company to successfully transition to an empowered product team set-up I would argue that this is one of the most important things that you can do.
People want to feel involved in what is happening and for there to be transparency around the work being undertaken as well as the outcomes you’re aiming for.
Companies I have worked for in the past have set up OKR teams which include the core multi-disciplinary product team as well as key stakeholders from other parts of the business with a vested interest — e.g. Marketing, Editorial.
Key stakeholders on the OKR teams were made to feel part of the team — they were invited to stand-ups and all key meetings and participated in many of the team’s core activities.
For stakeholders who weren’t part of the core OKR team, we made sure to invite them to our quarterly kick-offs, user testing sessions, ideation sessions, design sprints and just about any other workshop or meeting where we could feasibly involve them.
Leadership provided the cement that held all of this together — every OKR team had a sponsor — this person / people (in my view having just one per team worked best) were responsible for unblocking any big blockers that the team might encounter and offering guidance — essentially ensuring that the team had everything it needed to meet its objective.
The wider effect of having someone from the leadership team sponsoring OKR teams was that the importance of these new teams was elevated in a way that they wouldn’t be if leadership hadn’t been involved.
The result was that previous silos that existed started to break down and colleagues felt involved, valued and heard. The product teams were able to move forward to solve the objectives and impactful work was delivered.
It’s worth noting that while all of these measures were pretty effective, the process was neither easy nor fast and it all requires a lot of patience and perseverance!
If you have questions or would like to know more, please do feel free to leave a comment below. Good luck to all on this journey.