Take a Team Approach to Product Delivery

Have you heard? My new book Continuous Discovery Habits is now available. Get the product trio's guide to a structured and sustainable approach to continuous discovery.

Jim, like many product mangers, spends most of his day with his engineering team.

He clarifies requirements, triages bugs, and seeks out hidden dependencies.

Sally, on the other hand, spends most of her time with customers.

She’s understanding their context, uncovering pain points, and identifying opportunities to delight.

What’s the difference between Jim and Sally?

At some companies, Jim might be a product owner and Sally might be a product manager.

But if Sally and Jim both work at companies that combine these roles, what accounts for their differences?

Why does Sally have time to engage in discovery activities while Jim is stuck in delivery?

Product managers don’t have time for discovery if they are getting bogged down in delivery tasks.

Jim has to overcome the obstacles and challenges that arise during a delivery cycle.

Sally can rely on her team to address them.

Sally plays a role, but her tech lead, her design lead, and her data analyst partner with her to overcome the challenges.

Jim has a team too. But they come to him for all the answers. He generates the solutions. He assigns work. While his ‘teammates’ might give input, he alone decides how they’ll meet their commitment.

As a result Jim spends his days with his engineering team playing hero while Sally spends her days with her customers learning how to make her product better.

Which product manager do you want to be?

Individuals Don’t Ship, Teams Ship

At most companies, it takes a team to ship a product. – Tweet This

Yes, there are stories of the lone genius who builds a product that takes off. But they don’t stay the lone genius for long.

Internet products are complex. Customer behavior shifts. Markets fluctuate. Technologies change.

At some point, it becomes inefficient for an engineer to know the full stack or for the product manager to do the design work.

As products grow in complexity, teams specialize. They hire a product manager, a designer, a back-end engineer, a data analyst, and so forth.

But adding people to the team isn’t enough.

A Collection of People Does Not Make a Team

We like to believe that people are interchangeable. That we can move “resources” around based on changing business needs. That moving an engineer from here to there solves the problem.

But this isn’t true. Becoming a team is hard.

Teams need time to gel. To find their way. To become a team. – Tweet This

Research on team performance (see here and here) suggests that teams need time to figure out how to work together.

Most teams adopt norms based on their past team experiences not taking into account the unique needs of their current team.

This often leads to periods of ineffectiveness, tension, and conflict.

This in turn leads to lost time.

Few product development schedules have room for what  the research refers to as team “forming” and “storming” before they get to periods  of “performing”.

Effective Teams Start with a Team Charter

Fortunately, research (see here) gives us clues for how to reduce this period of ineffectiveness.

Effective teams take the time to define how they want to work together upfront. – Tweet This

They take into account the needs and preferences of each individual member and they optimize for team performance.

They collect their team goals, operating principles, roles and responsibilities, and individual preferences into a living document called a team charter.

This document evolves as the team starts to learn what works for them and what doesn’t.

Creating and updating a team charter isn’t just a team building exercise. It’s a social contract.

Team members commit to both abiding by the charter and updating it when particular norms stop working.

Prepare to Create a Team Charter

Before you ask your team to create a team charter, first ask everyone to think about their own work preferences and goals.

Start by having each person complete the following statements.

• What matters to me most in my professional work is …
• Professionally, I aspire to …
• My strengths that I can offer this team are ….
• As a team, we would be successful if …
• I don’t like being on teams that …
• The best way to get in touch with me is …
• I am typically available …
• You should also know that I …

Once each team member has completed each of the statements, take turns sharing with each other your responses.

Set Team Goals

Keeping in mind what you have just learned about each member’s goals and preferences, set team goals.

You won’t always be able to accommodate every individual goal in your team goals, but get creative.

Strive to set team goals that reflect the needs of the group and not just the needs of the most senior person in the room.  – Tweet This

Don’t just focus on the business context. We all have metrics we need to move. But go deeper.

Define what success looks like for your specific team.

Goals might include delivering on business needs, being more collaborative, reducing meeting time, being inclusive in idea generation, spending time with customers, improving communication with the rest of the business.

Each team is different. Take the time to define what matters most for your team.

Define Team Norms and Operating Principles

Take the time to define how you will work together.

Define who will attend which meetings and set clear expectations around how each member should prepare.

Identify communication channels that work for everyone.

Be clear about who needs to be available when.

Define what tools you will use and for which purposes.

Your team has already adopted norms. Take the time to examine what’s working and what’s not.

Write them down. Adding them to a team charter will help you get specific and ensure that everyone is on the same page.

Clarify Roles and Responsibilities

Many of the challenges that arise during my coaching sessions stem from poorly defined roles and responsibilities.

Dependencies force delays in the schedule because the tech lead thinks the product manager is handling it. The product manager thinks the engineering manager has it covered.

A designer gets upset because a product manger signed off on a release that doesn’t meet the style guidelines.

A data analyst creates a dashboard that defines a metric incorrectly. Nobody took the time to get everyone aligned.

These types of challenges can be reduced by taking the time to define who will do what.

Pay particular attention to who gets to give input vs. who gets to make the final call on key decisions.

Understand and define which areas require input and collaboration from multiple roles.

Make sure people have clear ownership of their own domains and that you are drawing on people’s expertise.

Let your designer make the design decisions. Ask your chief architect to sign off on the new data model. Make sure the voice of the customer is represented throughout.

Don’t Gloss Over This Exercise

If you’ve read this far and you aren’t planning to do this exercise with your team, consider the following:

• Have you ever wished that someone on your team was doing something that they weren’t?
• Is there an activity that you want to be more or less involved with?
• Does your team tend to encounter the same pitfalls over and over again?
• Does your release schedule or sprint commitments tend to slip?
• Do people complain behind each others’ backs?

If you answered yes to any of these questions, your team will benefit from this exercise.

It’s hard to argue with the research. Many team challenges arise because teams don’t do the work required to surface assumptions and expectations about how they want to work together.

Don’t commit your team to the same fate. Get started with your own team charter today.

In the coming weeks, we’ll explore tasks and responsibilities associated with product delivery specifically. As you follow along, work with your team to further define your own roles and responsibilities.

Don’t miss the upcoming posts. Subscribe to the Product Talk mailing list.