Astronomers sometimes refer to Earth as being situated in the Goldilocks zone, meaning we are lucky enough to be orbiting our sun within a very small, just-right range for life to flourish. Move us a little farther away from the sun, and our planet would be too cold to support liquid water, meaning no life. A little closer to the sun and we’d be Venus… where the average daily forecast is a sunny 870 degrees.
As a product manager, building a cross-functional product team is often an attempt to find a Goldilocks zone as well. Include too many people, or the wrong people, and you risk slowing the development process, or worse, building the wrong things. Include too few people and leave out some necessary team members, and you’re likely to face a different set of equally serious problems.
What’s the Goldilocks zone for a cross-functional product team? Although every situation is different, there are some clear best practices you and your company can adopt to give your products the best chances for success. Here are a couple of ideas.
1. Include a product owner, scrum master, development team — and, yes, QA.
This is one potential Goldilocks team for many organizations, particularly agile shops, because it includes everyone absolutely necessary to shepherd a product through development, and it doesn’t include anyone who’s unnecessary.
That last point is worth underscoring. As a product manager, you might find that people from different parts of your company want to be a part of your product team, and they often have the best of intentions.
A sales VP might believe she can be useful throughout the process, offering guidance on what her team is learning out in the field from prospects and customers. A marketing executive might have a similar idea about how his experience can contribute during development.
You might even agree with these execs from other departments. After all, aren’t you building a cross-functional team here? What better way to ensure as much knowledge and as many relevant points of view as possible are represented on your team throughout the development process?
But the truth is, you should be gathering up all of these learnings prior to your product development. Indeed, this data from across your organization should inform your product roadmap process, but once you and your team have begun a sprint, that team should be as lean as possible, and focused entirely on the development priorities you’ve set.
Your product development sprints, in other words, should have no place for a new request from a sales rep or marketing executive on your product team.
The people on your cross-functional product team should be only those absolutely essential to completing each development sprint. That will include…
- The product owner (you), who is responsible for organizing and overseeing each sprint, and is always available to the team to answer questions and provide help when needed.
- The scrum master, who is responsible for understanding the big development picture of each sprint, and for delegating tasks appropriately to ensure the right developers are working on each task and that the team is always fully deployed and not idle.
- The developers.
- QA resources, who ensure new code is continuously tested as the product is developed. This can take the form of developers writing and running their own tests, or a separate QA team that is responsible for testing code before it is reviewed during sprint review.
This group represents a lean, agile cross-functional product team, where everyone has an essential and very clear role, and the team is entirely free of nonessential personnel.
Tweet This:
“A cross-functional product team should be a lean, agile group, where everyone has a very clear role.”
2. Form product squads — even leaner teams consisting of a product owner and a group of developers.
You might also find that the product squad model creates the Goldilocks team for your company. Popularized by Spotify a few years ago, the squad model works very similarly to the cross-functional product team I described above. But there are some major differences.
First, each product squad is given responsibility for a specific area of a product — rather than the product’s development as a whole. This allows a squad to become a team of true experts in a specific area of product development — responsive design, for example, or databases.
The second way product squads are unique is that they are able to push their work directly out to customers. Whereas in most organizations a product team will need to run their new release of the product by a series of stakeholders before making it live, squads can simply push their new release out to the public when they’re satisfied that it’s ready.
We think the product squad concept is so intriguing that we wrote an entire article about it.
However, the squad model is not without drawbacks. First, if your company doesn’t have enough product managers or development resources, this model might simply not be feasible. After all, you will want to assign a product owner (ideally a PM), a scrum master and several developers to every squad to make them as effective as possible.
One of the possible pitfalls of the product squad model is that QA can easily become a low priority. If the squad is going to push its code out to the public without running it by anyone else in the organization, we would argue that they also need to have that code rigorously tested beforehand to give it the best shot at being bug-free. If you are considering giving the product squad model a try, we’d suggest you add a QA person or a dedicated portion of developer resources to each squad.
And if that modified version of the product squad still doesn’t feel like the Goldilocks cross-functional product team you’re looking for, read how Chris Leckie, Product Design Director for the fantasy-sports company FanDuel, found another effective way to customize the squad concept for his company. He told us about his team’s fascinating approach to cross-functional design and development in an interview he gave to ProductPlan as part of our Product Lessons Learned series.
What do you think a Goldilocks product team would look like? Please share your ideas in the comments section.
