Let’s Talk About Imperfect Teams
In the books and articles about product management there is often reference to the perfect team set up. But in reality there is never enough people or money, but if you are leading any medium to large size org you still need to create teams as good as they get, in short you need to configure and progress with imperfect teams
No compromise: The Perfect Team?
- Product to undertand the customer and the problem
- Delivery to track progress, run agile ceremonies and facilitate across teams
- UX & Design to support customer discovery and provide
- Business Analysts out requirements, edge cases, read integration documents, detail unhappy paths etc. proc
- QA to test the work before it goes to production
- Team lead to be the voice of the team in early stage discovery and provide engineering leadership
- Engineers to solve the problem in code and ensure security, scalability and guidelines are followed
While the above is probably the optimal set up to enable each role to focus on its strengths it is also lot people and rarely is an organisation able to to support this from day one or justify the expense for the long term. Actually, open question, has anyone really worked in this model?
Compromise 1: Two Teams But Only One Product Manager
Context: You building a big release or a new product, there is lots to code and lots of attention but one customer problem to solve
Pros: engineering capacity is not the constraint
Cons: The product role is super stretched, possibly fielding details and support for the teams most of the time, and so not paying attention to the outcome, possibly dropping the stakeholder comms piece. Similar challenges with delivery and UX
Mitigations: Leverage the whole team. in this model more than any other we need input from engineering to support on the detail, we need the data to support on impact and we need support from product ops to ensure the product work is following common patterns
Compromise 2: One Engineering Team And Multiple Product Managers
Context: Engineering hiring is slow so product hiring is running ahead or you have some strong product talent you just don’t want to loose.
Pros: Product have a lot more time for deep discovery work, tracking impact and communication
Cons: The team is confused who to listen to and the product function is frustrated because they are fighting over engineering capacity
Mitigations: Have a lead product manager to ensure the overall priorities are represented by one person. Use the additional product management to support deep discovery — think twin track agile. Ensure there is some framework to ensure discovered product work can be fed to the team — perhaps alternate sprints or sub goals around small fixes
Compromise 3: Multiple Big Problems, Limited Experience On The Product Roles
Context: Engineering hiring is good and there is lots of work, but you are struggling to hire the product seniority you need or are replying on existing employees transitioning in to product from other teams
Pros: Potentially a great fast way to gain experience for new PMs
Cons: Experiences engineers are frustrated by poor product management, impact of the work is poorly understood, rookie errors are made
Mitigations: If you can leverage the most senior product manager you have to lead the juniors, cover the gaps watch the big picture. Also leverage product ops to ensure the junior PMs are supported by clear processes, templates, good routines
What Are Senior Level Leadership Doing To Help?
With the best efforts made to set the teams up as best as possible its now on senior leadership to coach any of the remaining gaps, defend through the tough times and provide platforms to showcase the work and provide transparency
It is also on senior leadership to watch out, look around the corners, check for unexpected consequences. The platforms for transparency Create closed door small forum meetings to check in on the “so what”, watch closely for alignment to the target outcome, challenge assumptions
It is also on senior leadership to watch for bad outcomes from good intentions. These are particularly hard to manage! Some examples of bad outcomes from good intentions look like this
- Process Treacle: This originates from the good intention to bring order to things, make good practice repeatable, manage risk. But quickly you can cross the line from just enough process to process treacle that slows everything down with no benefit.
Mitigation: Senior leaders need to be comfortable with risk and trusting people and teams more than trusting process. - The Reverse Onion: This comes from every role doing their best most professional job. Everyone is seeking to add value: product, UX, engineering. And through these good intentions comes massive over complexity — Each layer of value makes you cry more.
Mitigation: Challenge complexity at every opportunity and relentlessly time box. If all these contributions mean we don’t know our next step for another 2 months, then ask what is the one thing we can each do to get more confident by next week
