Developing Strong Product Teams

Note: This article is a collaboration between myself and my long-time friend and colleague Jeff Patton.  We often work together to help product teams.

We have both long argued that the best way to evaluate product teams is by their results; the outcome they generate, not their output.

That said, many teams are still learning the techniques and methods of strong teams, and in this article we wanted to highlight what to look for in a strong product team and how to help the team develop.

Team Staffing:

• Is there a strong product manager/owner?
• For teams working on user-facing software, is there at least one strong UX/interaction designer?
• Has at least one senior engineer been identified that is available to participate in discovery work at the level of at least an hour a day?
• Are at least the three people above co-located?
• Does the team have an effective working chemistry – do they talk to each other constantly, and do they respect and work well with each other?

Team Context:

• Does the team have clearly defined business KPI’s that they are driving towards and measured against?
• Does the team have a clear vision for what they are trying to create?
• Does the team have direct and ready access to users and customers?
• Does the product manager understand who the key stakeholders in the company are, and what their concerns are?

Dual-Track – Discovery:

• Is the team trying out at least several significant ideas (not just minor tweaks and optimizations) every week?
• On average, how many ideas are validated each week in discovery?
• Is the team skilled at using MVP testing techniques to validate quickly?
• On average, what percentage of the ideas each week are killed in discovery?
• Is the team validating ideas each week with actual users (before they get too attached to the ideas?)
• Is the team validating ideas each week with business stakeholders (before actually building)?
• Is the team competent at quickly creating low and high-fidelity user prototypes?
• Does the team understand the difference between live-data prototypes and building production software?
• How often is the team using live-data prototypes?
• Does the team have an A/B testing infrastructure in place?
• Is there some amount of real work put on the product backlog every week?
• Is there a good shared understanding of the work on the product backlog?  Across the whole team?
• Do all of the other developers and testers on the team feel able to contribute product ideas in discovery and share in the learnings?
• Does the team feel a sense of urgency for their discovery work?
• At the end each week does the discovery team do a mini-retrospective asking if they could have validated any of these ideas faster or cheaper?

Dual-Track – Delivery:

• Is the team releasing something, even if it’s internal only, even if only bug fixes, no less than once every two weeks?
• Has the release been tested and put through the release process (“done done”)?
• Are impediments identified and especially resolved quickly (typically within 48 hours)?
• Is the team good at predicting delivery with reasonable confidence and accuracy?
• How long does it take the team to run a full regression suite and determine if they can “release with confidence”?
• Does the team have a test automation strategy in place?
• Does everything that’s released have some level of analytics in place?
• Does the team assess potential customer impact prior to release, and do they work with product marketing or others to communicate key changes?
• Is the team immediately reviewing the newly released software to evaluate how they impacted the scorecard KPIs?
• At the end of the sprint, does the team do a retrospective looking at how the sprint went and what they could have done better?

There are many more techniques and especially cultural elements that can help a good team become a great team, but these questions above can help you see where your team is, and what they need to focus on to improve.