Does Your Team Trust You?

Does your team trust you?

That question is important to product managers (PdMs). Since a PdM’s job is to help consistently improve the decision-making of a team, trust is critical. If the team around you doesn’t trust you, they surely aren’t drawing on your expertise when they make decisions. 

As important as shipping the next release can feel, over time, it won’t matter if you aren’t gaining the trust of the team around you. As a PdM, you’ll need ways to find ways to do that.

So, how does one build trust?

More From Adam ThomasWhat Do Product Managers Produce?

 

Building Trust

Think about your personal life. What are some ways that someone can gain your trust? Here are a few I can think of:

You should be able to see how those three things manifest themselves in your work as a PdM on a weekly basis, and I’m sure we could add many others to the list. We use our roadmap to make promises and communicate changes and our metrics to show progress. All of those things, when everything is going well, build trust.

Unfortunately, in the real world, everything doesn’t go well all the time. In product, it’s safe to say that a lot of our work inescapably entails some level of failure. So, how we communicate changes to the teams that rely on our outcomes may be even more important to us than keeping promises and showing progress. 

That said, because of the trickiness of delivering bad news, the ability to deftly communicate changes that must happen when things go bad is one of the hardest skills to develop. Let’s be honest: Without any prep, you’re essentially going to be reacting to a room full of upset people. That is not a fun situation. 

So, what does preparation look like here? Bringing data into the picture is one way to help. If you can offer a clear explanation for why something is failing, you’ve won half the battle. All you have to do next is outline a clear response to make folks feel better.

Well, that’s where survival metrics come in since they package both explanation and response together before any initiative even begins. We’ll see this in action by taking a trip to BobCo, where Jill, the product leader, is talking to Sheryl, one of the project managers, about an initiative that’s on its last legs. We’ll talk about how Sheryl prepared using survival metrics and how her she retained her team’s trust even though her project failed.

 

Survival Metrics for Trust

Truly empowered product teams are few and far between, which means that most have no idea what to do (or no power to act) when their organization’s initiatives go off the rails. Survival metrics are a framework that allow product managers and teams to improve their decision fitness. This improvement means they know when to stop an initiative altogether, when to pivot their strategy, and when to invest more resources into its success. The framework also makes real the three pillars of organizational survival — being fast, data-informed and politically safe — giving teams the tools they need to remain agile and effective in the face of change. 

By using survival metrics in your product development, you can see the next action ahead of time: You are either going to stop, pivot or invest. These are simple terms that everyone can understand, and that simplicity means you can always easily make your next step happen. 

Sheryl undertook her latest initiative, a new onboarding feature, by setting up survival metrics. After asking questions of the stakeholders, she translated them into metrics, prioritized the most impactful ones, and communicated them back to the relevant stakeholders.

As she made them, she noted how having instructions about whether to stop, pivot or invest up front made stakeholders comfortable. For her, the system was a reminder of the Getting Things Done approach, particularly the “Next Action” principle. Having the next action top of mind makes executing that action much easier. 

The metric that was most important to the project was listed first and contained a nod to company values in it: 

STOP — If the outcome of the initiative has to become specialized to become effective, then shut it down. We build for all of our customers or not at all.  

She recently found out that the initiative had to become specialized. Even worse, although it would work with some of their favorite customers, it wouldn’t provide value to any others. 

The data are the data, however, and what are values if you don’t live them? It was time to shut the initiative down. Sheryl had a coffee meeting with Jill, and their discussion was less about what to do and more focused on summoning the confidence to do what needed to be done. 

Jill heard the story and smiled. 

“I’m glad you came to talk to me. Let’s go back over the data, concoct a story, and turn this crisis into an opportunity to show the company that we truly believe in our values. Before we present this news to everyone, let’s use survival metrics and some data from when you gathered your metrics to tell a story.”

Sheryl nodded.

 

Playing Back Important Data

According to Ron Kohavi, a former executive at Airbnb and Microsoft, “60 to 90 percent of ideas do not improve the metrics they were intended to improve.”

Failure is not an if, but a when. 

When failure happens, the first thing you need to do is acknowledge it. Far too often, teams take the easy way out and sweep things under the rug by shipping anyway and moving on to the next thing. That approach increases the system complexity. As a result, whatever you ship will be that much more expensive to maintain or remove. 

Survival metrics give you the tools to acknowledge failure by having the next action ready for you when it happens. Invest means let’s put gasoline on the fire, pivot means let’s adjust, and stop means, well, stop. 

To get the metrics that will inform the team, you’ll need to ask these questions:

• What markers do we need to see to commit more resources to this initiative? Example answer: “If we get X metric, it’s worth adding more resources because it’s important to our company’s identity/position/adoption, etc.”
   
• What are some non-negotiables for the team/company? Example answer: “We have to get this feature out or else we’ll be sacked.”
   
• How much are we willing to let this initiative cost us? Example answer: “We can afford to put this out if we can do it with three engineers, one designer and one PdM in six months.”

But survival metrics aren’t just about the metrics themselves. The work to get the metrics is a sensing mechanism, one designed to help development teams understand what makes the organization tick. When things go wrong, the data from these questions provide perfect information to frame a story you can tell to maintain trust. 

Sheryl remembered the conversation she had with Jill and what Jill told her to do. She first sent a message to the team and relevant stakeholders. 

Hello everyone, 

We’ve hit our STOP metric:

STOP — If the outcome of the initiative has to become specialized to become effective, then shut it down. We build for all of our customers or not at all.  

We will be stopping the project immediately. The team will spend the rest of the sprint putting together a postmortem, which will be held during our sprint review. There, we’ll have a presentation and Q&A session to help determine our next steps.

Jill had pointed out that there was no reason to wait to break this news. The other point that Jill made is that the work wasn’t just on Sheryl: The postmortem was the whole team’s responsibility. This way, the things that the product development team had learned wouldn’t be siloed into individual disciplines. 

“Trust is as much about learning together as it is about building together,” Jill had said before the meeting was over. 

During the rest of the sprint, the team’s digital spaces turned from product development into a workshop. Sometimes, it felt like a jury room as the team poured over the research, talked through their thinking, and worked out how they could’ve gotten to the stop decision sooner. 

Sheryl wanted to frame the lesson around speed to solution. Failure was going to continue to happen, so they needed to learn how it happened and how they could figure things out faster next time.

 

Telling the Story

With the data put together after the postmortem, we can now put the information we’ve learned with the team into a story. Stories have a hold on humans and help us understand things. Think about this: What do you remember, your favorite childhood story, or your favorite childhood food? I would bet that you can recall one much faster than the other. 

Turn what you’ve learned into a story that plainly states the following:

1. Ideal state — Where do we want to be? 
2. Obstacle — What stopped us?
3. Lesson — What gets us closer to the ideal state?

This practice is a useful way to take the information that you’ve collected and make it digestible not just to the people in the room, but the folks that may want to learn later. 

To add extra firepower, you want to make sure you do the following as well:

1. Draw on social proof. Use company artifacts, anecdotes from stakeholders, and well-trusted sources of information to strengthen the confidence others have in you.
2. Stick to one thread and repeat it. Multiple stories lead to a scattered Q&A. What is the important lesson? Once you’ve identified the main takeaway with your teams, repeat it over and over. 
3. Show iteration. What’s the next action after this one? How will we make this process better?

When doing this, you’ll end up with a very clear point of view and give the stakeholders the opportunity to ask relevant questions.

Sheryl prepared following this method. After distilling the information down, she highlighted the key lesson, which was that they didn’t diversify their discovery pool enough, into all three sections of her presentation. 

Before the presentation started, she gave the stakeholders 10 minutes to read through a one-page summary that she provided, giving a short introduction to why the team chose this metric and a timeline of the initiative. Then she jumped right in.

BobCo is really focused on making things for everyone. The CEO was burned by specialization at his last company and now talks about it often. Sheryl led the presentation with examples of him talking about the evils of specialization and then added some supporting materials from the head of business development and the director of customer success. Then she repeated the importance of diversification and how taking what was available, instead of building the right participant pools led to this being done late.  

She couldn’t rely on the people she knew just because it was easy to contact them. Finding the right people to talk to takes time and patience. Getting a better collection of participants earlier in the project would have saved them a ton of time and expense.

She closed on how the team will be pushing to ABR (“always be recruiting”) to keep research in front of them and where the information from the presentation will be available. The team didn’t want to be in this same position again, and they also wanted to experiment with randomization to ensure they eliminated thier own bias in selection.

The Q&A session was soon about how the company could do better research, and instead of focusing on failure, the focus was on how the team could get better.

Soon, Jill received an email from the director of customer support who was excited about Sheryl and what her team would do next.

More in ProductThis Weird Push Notification Keeps Me Up at Night

 

Heighten Trust

You need to make it easy for folks to trust you. Even in failure, using survival metrics helps us do the following:

• Making promises and keeping them (setting up survival metrics)
• Communicating changes (communicating failure as soon as it happens)
• Showing progress (Going through a post mortem and sharing the results) 

Things go wrong. After all, you’re a product manager. But having the benefit of the doubt and clearly communicating any changes not only helps build trust, but also allows the company to evolve. As the steward of decision making in the organization, it’s up to you to keep and maintain that trust to help the company avoid stagnation.