Product Creation is a Team Sport: Part 1
How to Build and Lead a Successful Product Team.
This article is a collection of excerpts from the book Product Leadership: How Top Product Leaders Launch Great Products and Build Successful Teams, to be published by O’Reilly Books in May 2017.
Let’s Start By Never Calling The Product Leader the CEO of Their Product Ever Again
It’s been said before but it needs to be said again, the product leader is not the CEO of the product. Many in the product space have suggested that a product leader is the ‘CEO’ of their product, but this fundamentally misunderstands the role. Worse than that, it sets an expectation which can only lead to disappointment and possibly failure.
A better analogy would be the product leader as the captain of a sports team, a conductor of an orchestra, or a university professor guiding their class. Like the professor, conductor or team captain, the product leader is an individual who only succeeds by bringing the whole team along with them as they work toward a common goal. The product leader is ultimately graded by the overall team performance, not how their individual behavior or choices contributes to the work.
In almost every organization product managers have no direct authority over engineers, designers, marketers or any other members of the product team.
True leadership recognizes that the whole is greater than the sum of the parts. Being dictatorial and enforcing your own product ideas is never going to be as productive or successful as bringing the whole team, from design and engineering to sales and marketing, together.
The product leader’s job is to curate the right team, provide an environment for success, align the user problems with the product vision and then facilitate conversations to help connect the dots that allow the whole team to design the solutions together.
It’s so valuable to involve the whole team, with their diverse mindsets and experience when designing solutions, that it would be foolish not to. Every job in a tech company is an inherently creative role, whether it’s obvious (designers) or not (engineers). Some of the best product solutions we have worked on have come from engineers who have such a good understanding of the problem space (thanks to a great product leader) and an inherent grasp of the opportunity afforded by the technology stack, that finding quick, elegant solutions to customer needs becomes second nature.
The bottom line is that everyone in the company owns the product, and its success or failure lies in the hands of each person who touches it.
It bears repeating that a product leader’s job is to create the best team possible, to lead them to tackle the product challenges together, get the best out of everyone when building the product and provide a gentle hand to keep it heading in the right direction.
How To Craft A Successful Product Team
“Product is people. Every single person in your organization influences the customer experience in some way, so the experience your customers have is a direct outcome of the people you hire and the decisions they make,” says Nilan Peiris at Transferwise.
“There’s a myth in the corporate world that people do what you tell them to do, but in reality they only do what they want to do, so you have to build a culture that influences those decisions in the right direction.”
Peiris is alluding to is that the ideal team output isn’t a reaction to orders from above but rather a thoughtful set of decisions aligned with the direction the organization is headed. To create or mold the best possible team you will need to give them the power to be autonomous while still ensuring they are aligned with the overall mission of the organization.
A Move To Smaller, Independent, Cross-functional Teams
A new organizational model is emerging, from extremes like Holacracy to the scaled, agile approach of Spotify, these new approaches realign the accountability structure around smaller, independent, cross-functional teams. This offers them full autonomy to discover what their customers need and execute the delivery of that product in whatever way they see fit.
TransferWise have built fully autonomous product teams with clear KPIs but otherwise total freedom to set their roadmap, decide their organization, and build the team and resources they need to execute their plan. Any team can change any part of the product so for example, Marketing doesn’t have to wait for Product to build what they need, they have full access to build pages , change user flows, or do anything else necessary in pursuit of their goals.
At Pluralsight, their teams have complete autonomy, are cross-functional and co-located. The company does not stand up a team unless this team composition is possible. Each team discovers, builds and delivers on their own. All the way through to a production environment. These teams control their experience and the experience of their customers in its entirety.
Spotify developed one of the better known models around this autonomous approach. They start with squads. These are independent teams that sit together and have all the skills and tools needed to design, develop, test, and release their part of the product to production. Each squad self-organizes and decides their own way of working. Some use Scrum sprints, some use Kanban and others use a mix of these approaches.
However it’s described, this idea of small, autonomous, cross-functional teams that can get close to the customer is an increasingly important factor in great product leadership.
Autonomy motivates teams better than the old carrot and stick model, and as a team structure, it scales better and moves faster than any top-down model. In today’s info-centric world your team has more information, experience, and knowledge about the customer problem and the specific product area they’re working on than the individual product leader ever will — so why try to drive their priorities when they have more information?
“Traditional management is great if you want compliance, but if you want engagement, which is what we want in the workforce today as people are doing more complicated and sophisticated work, autonomy and self-direction just works better” shares Dan Pink.
The organizational models above will, and should, continue to evolve in order to better support teams over time. “Knowing that this is not how we may operate a year from now, the scaffolding of supporting teams should remain but we may re-configure it depending on what we are working on, making leadership changes and team moves as required.” Says Pluralsight’s Nate Walkingshaw. “The decision to do so comes from our teams, who have their finger on the pulse of our customers and understand what needs to be done to execute on a solution.”
In an ideal situation, the product team isn’t making decisions based on a burn-down chart or efficiency flow metrics, rather, the team is making decisions based on customer outcomes.
Designing Diversity Into Teams
Diversity in a team should be the imperative. From the beginning of an organization’s journey, diversity will serve the overall best interests of the entire team and the product itself. The tech world suffers from a lack of diversity and this is often reflected in our products and the challenges they face in the market; from every major social network’s inability to manage online harassment, to an overabundance of startups aiming to solve white, upper or middle class problems.
A good product team needs skills from design, tech and business, a mix of genders, creeds and backgrounds, a collection of industry experience and product management experience — from the visionary to the detail oriented, from the data hungry to the user-research fanatics.
This level of diversity is not just the best chance you have of representing your audience, but also ensures the best experience is brought to any product challenge the team will face, and is the best defense against any one individual’s confirmation bias.
James Keller, who leads strategy at Uncorked Studios in Portland has a great name for diversity in product creation Keller, who held senior roles at Walmart.com before joining the Uncorked team says, “Building great things requires diversity of age, skills and experience.”
“We call that people soup. Organizations need structure and hierarchy to get validated ideas built into products, but the initial ideation and concept development needs less structure and more chaos. Product creation needs the chaos of people soup. Once the early phases are done more structure is needed.”
There is a wealth of research that underlies the value of diverse teams and shows that being around people who are different from us makes us more creative, more diligent and harder-working and has also been proven to make companies more innovative and successful.
Mina Radhakrishnan shares how she approached diversity in building the product team at Uber “For me, it was really important to make sure that we had diversity in our group, because I think it’s really important to have women, people of color, and minorities in leadership roles in order to encourage diverse thinking.”
Radhakrishnan describes one of her first hires and the second product manager at Uber, “She was an ex-McKinsey consultant, and is probably one of the best PMs I have ever had the privilege of working with. She had a completely nontraditional background.” Although this hire had a traditional education from Stanford, the work that she had done and the way that she thought about things presented very differently. “In just looking at her resume you would not have thought she was a product person, but she was a complete natural.”
Cross-Functional Doesn’t Just Mean Design and Dev
When we say cross-functional it’s important to note that this doesn’t just mean product, design, and engineering (although that’s a good start). The best teams go further, and contain everything needed to execute their area of the product, from legal to marketing.
For example at Transferwise, the Currencies team, who launch new currency exchange paths, contains lawyers and bankers in addition to the product manager, designer, and developers, so that they can manage the local bank accounts and regulatory requirements required to launch new currencies. Imagine how much more efficient this is than having to coordinate with a separate legal or banking department within the company in order to get this more basic part of their work done?
Each additional internal interface between teams or departments creates unnecessary friction, and necessitates processes for queueing and prioritization.
Eternally Optimistic Is More Than Unicorns and Rainbows
The teams we are describing are also eternally optimistic, full of energy and with an unquenchable appetite to understand. They deconstruct problems, build the best idea for the customer and have an unbridled passion that needs to be reigned in at times. They start with a growth mindset. This might sound a little like unicorns and rainbows, but the reality is that great teams deliver from a positive attitude.
The best part is that much of the personal bias is reduced because the user breaks the tie.
It’s unlikely that all bias will be removed but gone are individual contributors fighting over who has the better idea. Focusing on customer value is product purity at its core. These teams can be implicitly trusted with any vision, strategy or idea because they know how sacred it is to respect and deliver something truly meaningful to the user. Their individual roles crossover and intersect naturally.
How it Works In The Real World
Companies like Pluralsight have been operating with cross-functional, co-located, autonomous teams for some time now. It works, but how does it look on the ground.
Currently, best practices for team work at Pluralsight encapsulate both product discovery and engineering delivery. Below is a description of how the teams take high level product vision and boil it down to tasks and then track those outputs against outcomes.
The two biggest differences between traditional product methodology and this approach are:
- Product Vision: When discovery is applied the correct way, an entire product experience team can see the origin story all the way to the first big idea stage. This involves the team creating the vision, strategy and idea implementation. These teams actually shape it, not their managers.
- Unifying PM, UX and Engineering: The delivery phase brings user experience and product management to the engineering table. The Pluralsight product teams have seen a lot of success using different parts of the most common methodologies. In their case it’s a combination of Lean (slanted toward Kanban), Agile, and Scrum. This way, user experience and product management have the opportunity to witness how engineers size stories, how the single piece workflow of a practice like Kanban breaks down into deliverables and the time it takes to deliver those story’s steps and details.
The real goal of this is for companies to make the journey from inflexible products, process and platforms and grow into a constant state of iteration.
In the image above, each team member jotted down their simple narrative and are taking turns to learn how each individual (development, product management and user experience) sees the story coming together for the customer. Themes are collected and a simple narrative is created.
In the photo above, on the far left, three separate artifacts describe the customers we are creating outcomes for. Narratives have been grouped into simple themes, then steps and details below. They are then sized and cards created for the team’s Kanban boards.
Directed Discovery includes both stages of continuous discovery and continuous delivery. First column VOC stands for the voice of the customer. Column two CPT stands for customer preference testing which is prototype observation. OE are cards dedicated to operational excellence. More about this process and elements here and in the upcoming Product Leadership book.
Why Is This a Better Approach
Team empowerment comes from the team seeing this entire process and developing an understanding of its nuances. Nuances are by nature the small, easily overlooked ways of working together to create better outcomes. The team learns one another’s strengths and weaknesses. The team learns empathy for their team members. It also provides them with the opportunity to break apart and solve problems as a group, so that everyone is part of the solution and they all see the soft skills and the hard skills working together.
Teams that can relate to one another will also move more quickly and deliver at a blistering pace without even realizing it. To them, it is just a way of working.
Better still, this approach “scrum theater”, which gives the illusion of productivity, without the material impact. Scrum theater is when teams find themselves getting caught up in presenting evidence of activity instead of delivering real value. This situation emerges when there’s a lot of activity but no clear metric for measuring anything of value is being created.
Velocity isn’t a label for ticking boxes on a spreadsheet, it’s what happens when there is authenticity and understanding in a team. In other words, velocity is not a measure of activity, it’s an outcome of good work. The team’s pace expresses their love for the craft of developing an amazing experience.
Read Part 2…How to develop team talent and mentor a product team.
Enjoy what you’ve read? Good, because there’s an entire book full of this stuff. I’ve been working with two masters of product Martin Eriksson and Nate Walkingshaw on writing a book that all product professionals can benefit from. Partly out of curiosity and on the back of our own experience, we’ve interviewed almost one hundred product leaders. Their insights and experiences will open up the conversation and take the lid off the mystery of great product leadership.
You can follow us at @rmbanfield, @bfgmartin, and @nwalkingshaw.
The Product Leadership book will be published by O’Reilly and on shelves in May 2017. You can pre-order the book on Amazon.
