In 2011, designer Tim McCoy, who had spent years bringing lean UX and Balanced Team principles to entrepreneurs, educators, and businesses, extended the concept of the Balanced Team pattern by contributing the notion of Product Stewardship (Tim went on to join Pivotal in 2012, and is currently a Senior Director of Design). His early thinking on this involved creating a role on a balanced team that shared product ownership with the PM. Over time, this evolved into a simpler concept: shared product ownership on a Balanced Team. This means that no single person owns the product. Instead, everyone on the team is responsible for stewarding the product to a successful outcome.
We’ve all seen the Balanced Team diagram:
Innovation Consultant and founder of Precoil, David Bland, contributed the Desirable/Feasible/Viable framework on top of the Balanced Team diagram, making it what we all know now. Product Stewardship places the product in the middle of this Venn diagram like an egg in a nest. PM, Design, and Engineering are equal roles tasked with nurturing and helping the product to flourish.
This Venn diagram is the simplest pattern to set up a successful product team. It’s just a pattern though, and patterns need to be extended pragmatically. There are heavier models which explicitly bring in others to complement the skills on the team, and get that team to a place where they can successfully build a product without external blockers or dependencies.
One such extended model in the world of Agile software development is called whole-team, which seems to have had a parallel evolution to the Balanced Team idea (Balanced Team came from UX Practitioners who were looking to find a better way for designers to work with Agile developers). Lisa Crispin and Janet Gregory (in Agile Testing: A Practical Guide for Testers and Agile Teams) describe Whole-Team this way:
“The focus of agile development is producing high-quality software in a time frame that maximizes its value to the business. This is the job of the whole team, not just testers or designated quality assurance professionals. Everyone on an agile team gets “test-infected.” Tests, from the unit level on up, drive the coding, help the team learn how the application should work, and let us know when we’re 'done' with a task or story.”
In The Leader’s Guide, Eric Ries talks about the team as an “Island of Freedom.”
Ries’ take extends the Balanced Team to include gatekeeper functions like HR and Finance in order to reduce external blockers.
Have the right people, involved to the right degree, to do the work you need to do.
Team Stewardship
Pivotal’s practice encourages us to look at teams in much the same ways these two concepts encourage us to look at products — I refer to this practice as Team Stewardship. Just as the team shares the responsibility of stewarding a product to a healthy outcome, the team shares the responsibility of creating and maintaining a healthy team. No single role owns or drives the team. The roles are equal participants in making the team what it needs to be in order to be successful.
If you’re the one on the team with the (practice) maturity to understand this, then you need to help grow that maturity across the rest of the team. It’s your job to bring the team up to the level they need to be, NOT to make decisions for them. As I like to say:
The PM is NOT your CEO. The PM is not your admin. Make the decisions that are appropriate for your role and book your own damn meetings.
We don’t look at Gantt Charts. We have a backlog. It’s a single track, prioritized list, with a WIP limit (dictated by the number of available pairs). It’s not the PM’s job to bang on the team to make them go faster. It’s the PM’s job to prioritize appropriately to meet business and user goals given the actual velocity and the WIP limit.
When clients ask us about Project Managers, I tell them we don’t need them. They say, “Well isn’t the Product Manager a Project Manager too?” The answer is a simple “No.”
The team and the process manage the project. Engineers reach out and make the connections they need, in order to learn the things they need to move the project forward from a technical perspective. Designers and PMs meet with customers and other stakeholders to understand what the desirable outcomes are. Each role on the team takes responsibility for making its full contribution.
Sometimes teams lose their way, and they need a stronger hand to guide them. This often defaults to the PM, but there’s no good reason why it should. Any team member can step in to take a stronger role. The goal of that helping-hand is to align the team around their goals and joint self-management. Health and maintenance of the team is the responsibility of every team member.
As with the product, everyone has a hand in stewarding the team towards a healthy outcome.
