How to Create Confident and Trusting Product Teams

Why making great product teams is so hard, and what leading companies are doing differently to create high-performance teams that trust each other.

Our Design Transformation team at InVision works with household brands to help them achieve their product creation ambitions. That gives us almost unprecedented access to the Fortune 500’s product teams and the leaders that guide them.

What we know without a doubt is that these organizations — like Amazon, Starbucks, and IBM — have embraced design as a critical component of corporate strategy. What’s less obvious is the relationship between those design strategies and building high-performance product teams. How these companies design conversations and create safe places to share opinions is as important as how they design their products.

Strong Foundations

Before we delve into those connections, let’s talk about the foundation that these teams are built on. Thanks to the work done by Leah Buley and her team, we know that the more a company invests in design, the more positive business outcomes it experiences. This includes those outcomes related to product, position, and profit. In the New Design Frontier research of 2,200 companies, her team found that nearly three-quarters of companies have improved customer satisfaction and usability through design.

What’s critically important for leaders and team to know, is that the most mature of these companies value something much more important than great UI and UX. A strong foundation isn’t just about design, it’s about the mindset that mature designers use when approaching challenges.

The New Design Frontier research echoed what we heard while writing the book on product leadership. As we gathered insights from nearly 100 of the world’s leading product managers, we were struck by the consistency in how these successful leaders work. How they structure the product teams and the daily conversations make a significant impact on performance.

Building trusting, cross-functional teams; developing a shared product vision and stellar product management; and creating products that truly meet your customer’s needs are all critical components of design maturity and maintaining a sustainable competitive advantage. So how do you do that?

Here are my recommendations for building trust and confidence in your teams:

1. Never call the product leader the CEO of their product ever again

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 that 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 contribute to the work.

True leadership recognizes that the whole is greater than the sum of the parts. Being dictatorial and enforcing your own ideas is never going to be as productive or successful as bringing the whole team, from design and engineering to sales and marketing, together to collaborate.

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, which allows the whole team to design the solutions together.

Every job in a tech company is an inherently creative role. Our biases might have us believe that designers are the creatives. This is a dangerous perception. Some of the most creative product solutions I have worked on have come from back-end engineers that aren’t involved in the traditional design of a product.

Whoever has the best understanding of the problem space, and an inherent grasp of the opportunity will generate the most interesting and elegant solutions to customer needs.

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.

2. Transition to smaller, autonomous, cross-functional teams

New organizational models are emerging. From extremes like Holacracy to the scaled, agile approach of Spotify, these new approaches realign the accountability structure around smaller, semi-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 has built fully autonomous product teams with clear KPIs, but otherwise, they have total freedom to set their roadmap, decide their organization, and build the team and resources they need to execute their plan. Because teams include people from all functional areas of the organization, any team can be involved in changing any part of the product. 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.

David Platt (left) leading a customer preference test for Pluralsight learner experience.

At Pluralsight, teams have complete autonomy, are cross-functional and mostly co-located. The company does not stand up a team unless the cross-functional team composition is possible. Each team discovers, builds and delivers on their own, progressing all the way through to a production environment. The teams control their experience and the experience of their customers in its entirety.

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.

Spotify developed one of the better-known models around this autonomous approach: squads. These independent teams 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, small, autonomous, cross-functional teams that hone in on the customer are an increasingly important factor in creating trust and confidence. 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. By allowing the customer to break the tie, this further reinforces that leadership is trusting the team and not micro-managing their decisions.

3. Design diversity into teams

Diversity in a team is essential to great product design. 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, which is then reflected in products and 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, 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 and eliminating individuals’ confirmation bias, it also ensures your team will be able to overcome any product challenges that arise.

James Keller, senior director of UX at Firefox, said, “Building great things requires a 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 need less structure and more chaos. Product creation needs the chaos of people soup. Once the early phases are done, more structure is needed.”

4. Structure teams to reflect the product vision

Cross-functional doesn’t just mean only product, design, and engineering people are sitting at the same table. Although that’s a good start, the best teams go further and practice a connected workflow. In these teams, they contain everything needed to execute their area of the product, from legal to marketing. If your vision is to create a future where the customer feels less friction then start by reducing friction in your own teams. Less friction leads to more confidence.

The currencies team at Transferwise, which launches new currency exchange paths, comprises of lawyers and bankers, in addition to product manager, designer, and developers. By eliminating the unnecessary friction and processes for queueing and prioritization, this truly cross-functional team is able to efficiently manage the local bank accounts and regulatory requirements required to launch new currencies.

5. Teams want a vision, not another guaranteed-output machine

Abstracting all product team decision making to a methodology or process makes the assumption that the process is smarter than the people who use it. Believing that a process can be a substitute for thoughtful intellect signals that you don’t have confidence in your team. Trust is conveyed when the team is given a well-considered vision and the permission to experiment their way towards that vision.

A practice of discovery and experimentation is another way of saying, “We trust you to find the right answer.” Currently, best practices for teamwork at mature product companies like Pluralsight encapsulate both deliberate product discovery and engineering delivery. Here’s how high-performance teams take high-level product vision and boil it down to tasks, and then track those outputs against outcomes:

1. Product Vision: When discovery is applied the correct way, an entire product experience team can track 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.
2. Unifying PM, UX, design, and engineering: The delivery phase brings user experience and product management to the engineering table. This way, user experience, and product management have the opportunity to witness how engineers size stories, how the single-piece workflow of practice breaks down into deliverables and the time it takes to deliver those stories. More trust is created when you know what your teammates are thinking about priorities.

The best collaboration is when you create frameworks that ignite conversation. In the image above, each team member jotted down their simple narrative and are taking turns to learn how each individual (development, design, product management, and user experience) sees the story coming together for the customer. Talking these scenarios out builds trust because now each team member can relate how ideas are connected to the vision.

In the photo above, on the far left, three separate artifacts describe the customers the team is 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. The message here is not that you need a methodology like Kanban, but that a framework for conversation exists. Good decisions don’t get made in a vacuum, and by extension, confidence in decisions isn’t created in a vacuum.

Pluralsight’s guiding framework is called Directed Discovery and 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.

Each of these categories promotes conversation and interaction between functional members of a team. The voice of the customer guides that conversation but still allows for experimentation, prototyping, and iteration. Confidence comes from learning in an environment that values knowledge and thinks of mistakes as assets. Trust is a game of driving toward the highest opportunity with the knowledge that your team has your back.

6. Embrace eternal optimism

The best teams I’ve worked with are eternally optimistic, full of energy and have an unquenchable appetite to find answers. They deconstruct problems, build the best idea for the customer, and have an unbridled passion that might need 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.

Enthusiasm to solve a problem for a customer is the ultimate way to squash biases. Solving the problem for the user becomes more important than personal preferences or motivations. 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. Strong, cross-functional teams driven by autonomy and optimism, can be implicitly trusted with any vision, strategy or idea because they share an aligned goal: delivering something truly meaningful to the user.

Parting thoughts

If confidence and trust are the ultimate internal outcome for product teams, and I truly believe they are, and you want to create those outcomes with your team, then ask yourself these questions:

• What’s the framework that you’ve created that provides an experimental mindset?
• What language do you use to convey and maintain that mindset?
• What’s the behavior you’re looking to create and how will others know what it looks like?
• How do you measure confidence, and are those measures meaningful to the outcomes for the customer?

For more insights on how to build awesome products and teams, check out InVisionapp.com