Common Anti-Patterns

As you work with your stakeholders, keep these common anti-patterns in mind.

Telling instead of showing. Even though we all know that showing is better than telling, all too often, we fall into the trap of telling instead of showing. We are proud of our work. We are excited about our conclusions. We love our ideas, so, of course, our stakeholders will love our ideas, too. We rush into telling our stakeholders everything we’ve learned instead of showing our stakeholders so that they can draw their own conclusions.

There’s a cognitive bias that is coming into play when we do this. It’s called the curse of knowledge.⁵⁵ Once we know something (like we do in this situation, we have a wealth of discovery work that supports our point of view), it’s hard for us to remember what it was like not to have that knowledge. In fact, our conclusions—our roadmaps, our backlogs, our release plans—start to become obvious. We forget that not only are they not obvious to our stakeholders but also that they very likely have their own conclusions that seem obvious to them. The key to avoiding this “curse of knowledge” is to slow down. Start at the beginning. Walk your stakeholder through what you learned and what decisions you made. Give them space to follow your logic, and, most importantly, give them time to reach the same conclusion.

Overwhelming stakeholders with all the messy details. Even though we want to slow down and show our work, we don’t want to overwhelm our stakeholders with every last detail of what we’ve learned. If you are interviewing customers and running several assumption tests every week, everything you are learning will quickly overwhelm a busy stakeholder.

Instead, you need to act as a smart filter. Tailor the detail and context to the stakeholder you are talking to. What does this stakeholder, in particular, need to know? Your boss might enjoy the discovery journey and want week-over-week updates of how things are going. Your marketing manager probably doesn’t want that much detail. Instead, monthly updates with just the highlights might be adequate. Your CEO probably needs even less detail.

However, when someone wants less detail, it doesn’t mean you aren’t showing your work. Even with a busy CEO, you still want to start with the outcome you are driving, highlight the top two or three opportunities, give a quick explanation of why you chose the one you did, highlight your top solutions, and share the results of one or two assumption tests that support your final decision. For example, Lisa’s team might share the following narrative: “Our goal is to reduce the number of lost sales from not having a journey builder (outcome). We interviewed customers and learned that existing journey builders are too complex; marketers don’t know how to get started (opportunity one), and, when they do, their journeys are hard to maintain (opportunity two), and they often create redundant journeys (opportunity three). We decided to focus on reducing the complexity by helping marketers to zoom out from the messages they are sending to focus on the goals they are trying to achieve. We explored a few different ways to do this, but the most promising one is our lifecycle-maps idea. In testing, we found that marketers had no problem getting started and that they loved the high-level view on their work.”

Of course, Lisa’s team discovered dozens of opportunities, and their solutions addressed many of them. But their CEO doesn’t need all of this detail. He needs to know that Lisa’s team is finding a solution that customers love that drives the outcome he cares about.

Arguing with stakeholders about why their ideas won’t work. As you do more and more assumption tests, assumptions become building blocks. You start to learn which building blocks will work and which won’t. When you hear a new idea, you are going to be able to quickly assess it based on those building blocks. However, when working with stakeholders, we need to remember that they aren’t starting from the same set of building blocks. The fastest way to discourage your stakeholders is to shoot down their ideas. Remember, nobody likes the know-it-all.

Instead of jumping straight to why an idea won’t work, use your discovery framework to help the stakeholder see where their idea does fit. For example, is the stakeholder focused on a different outcome from you? If yes, then don’t shoot down their idea. Even if you don’t like the idea (remember, our preferences don’t matter), you can remind your stakeholder that, while their idea might be a good fit for their outcome, it doesn’t support your outcome right now. You can follow this same strategy if their solution addresses a different opportunity. You can always say something like, “That idea has promise. We’ll consider it when we address that opportunity.” You can even capture it on your tree or in your idea backlog (not your development backlog) so that you remember to return to it later.

If your stakeholder is suggesting a solution for your target opportunity, consider it. Should it be in your consideration set? If you can see that it is based on a faulty assumption, don’t just call that out. Help your stakeholder reach that conclusion on their own. You can do this by story mapping their idea together. Generate assumptions together. When your stakeholder sees what assumptions their idea is based upon, you can now share what you’ve learned about those assumptions in your past assumption tests. This helps your stakeholder reach their own conclusions about their own ideas.

Trying to win the ideological battle instead of focusing on the decision at hand. No matter how strong your discovery process is, there will still be times when your stakeholders swoop in and ask you to do things their way. If they are more senior to you in the corporate hierarchy, that’s their prerogative. What you can control is how you respond. I strongly recommend that you don’t turn the conversation into an ideological battle. In fact, if you ever catch yourself saying, “This is the way it’s supposed to be done,” take a deep breath, and walk away from the conversation. You aren’t going to win the ideological war in one conversation.

Instead, you need to take stock of the decision that needs to be made and focus on the best outcome given what you have to work with. Save the ideological war for later (or never). You aren’t going to convince your stakeholder that their worldview is wrong. In fact, this is tied to the “Show, don’t tell” advice above. When you are asked to deviate from your discovery process, telling your stakeholders that they are doing it wrong isn’t going to get you anywhere. Focus on the opportunities with which you can show the benefit of working this way. Choose your battles. Don’t fight the ones you can’t win.