Product Owners and the Art of Saying NO

As a Scrum Product Owner, it is easy to say yes. When we say yes to stakeholders, they’re happy because they know the feature they just requested will be built. The problem, of course, is that when we say yes too often, we build incoherent products.

The popular advice is to practice saying no in the mirror.[1]  Fun? Yes. Practical? No.

There is a better approach, which I call Stakeholder Akido, based on the Japanese martial art “which practitioners could use to defend themselves against attacks, while also protecting the attackers from injury.” [2]. In our case, we want to mitigate the impact on our Product Backlog without harming the stakeholders.

This approach only works if you have a sufficient understanding of the customer and their needs. Usually, this means you’ve talked to customers, gathered data, and turned it into a clear vision, personas, and strategy (e.g. Story Map or Impact Map). Alternatively, if you’re taking the Lean Startup approach, then a Lean Canvas and a list of initial experiments. Without all of this, we risk saying NO to valuable items.

Ways to Say No

The goal with every technique we cover is to get the stakeholder to say their own ‘no’. (This won’t always work.)

Vision

If the request is far enough outside of the scope of the product, then review the vision and/or Lean Canvas with the stakeholder and say something to the effect of “This doesn’t fit our current vision. If we take on this request, we will lose our core focus.” Be prepared for pushback; in some cases, powerful stakeholders will demand an update to the vision. The best defence here is to have involved them in creating the original product vision, so that they can see that changing it isn’t a good idea. Caveat: occasionally, we might learn something new that actually justifies updating the vision.

Personas

Similar to the product vision, test whether the request meets the needs of the documented personas. Personas are a lightweight model that illustrates the needs, behaviours, and experiences of a number of end users. When a feature request arrives, ask if any of our personas use this feature. If yes, would they use it in the way that is being suggested?

Here, our PO might say, “I’ve checked the feature for <PersonaName#1>, … and it doesn’t solve a problem any of them have.”

If the request is appropriate for the personas, but it’s not important for now, use strategic focus to show where it does fit.

Strategy

There are several tools that I recommend Product Owners try to help visualize the product strategy.

• Impact Mapping is a tool that helps teams focus their work on a feature by identifying portfolio items or strategic changes that will have the most significant impact on achieving their goal. Impact Maps are intended to be drawn, and not just written in words.
• Story Mapping is a simple tool to help you visualize your Product Backlog. It indicates which major items the PO is focusing on and which they are not.

Since Impact Mapping is a focusing tool, use it to test whether a requested feature is outside of the current focus. So, in this case, the PO is saying, “Not high enough impact.”

Use a Story Map to show if a feature is or isn’t in focus in the near term. Here, our PO could say, “This area is not in focus now, come back and ask again in 3-4 months.”

If a strategic ‘no’ isn’t working, consider engaging the stakeholder in advance of them making a request.

Prioritization

This tactic works best when we have no surprise requests. Engage the stakeholders as part of the prioritization process. If they’re in the room when the decisions are made regarding prioritization, they’re less likely to try to change the decisions later. Consider using two collaborative games, such as “Buy a Feature” or “Business Value Game”. Both are collaborative activities that use input from multiple stakeholders to help with prioritization. When played well, these games help an individual stakeholder see that their perspective isn’t the only one.

If prioritization fails, demonstrate that an infinitely long queue will become a significant issue.

Product Backlog Size

Once the product backlog becomes too large, a ‘yes’ becomes a ‘no’. Here’s a simple thought experiment that will shock most stakeholders. Ask them to imagine a Product Backlog of 100 items and our team completes an average of 7 per Sprint with no defects, no rework, etc. (This, of course, is impossible). In that case, an item added to the bottom of the queue will take 14.5 Sprints or, assuming 2-week Sprints, over 28 weeks to be worked on. In that time, other priorities will emerge so that it will be pushed down further. Even worse, it does get implemented, but it is no longer relevant. Here our PO should say, “Not yet, let’s recheck the Story Map and discuss how far away it is.”

Portfolio Management

Create a formal space so that the stakeholders aren’t ambushing the PO at random moments with requests. Every 6-8 weeks, the Product Owner invites the stakeholders to review what has been recently completed (focus on large, high-level items). Then review the items currently being worked on (Portfolio Kanban helps engage stakeholders in this respect). Only once we’ve proven there is capacity for new major items does the group discuss which major items are the next priority.

This helps by engaging our stakeholders in the decision-making process. Since they’re in the room when decisions are being made, they’re less likely to make surprise requests. If they do make requests outside of the Portfolio Management meeting, ask them to defer to the next session.

For more depth on executing Portfolio Management, see Scrum Alone Is Not Enough: Portfolio Management.

The Human Side

When dealing with stakeholders, most are not trying to derail your product development. Take the time to listen, understand, and empathize with their needs. When moving away from a traditional approach, many stakeholders are living in a shadow of the past where they had to fight to get their item in the requirements document a year in advance and then, even after that, they had to fight to get it worked on. It takes time for them to understand the new world, where there is a new version of the product every two weeks.

Sometimes, in an attempt to accommodate a stakeholder, the PO will split the difference and give them some of what they want. This results in a product full of half-baked features. If we’re going to work on a feature, commit to it fully or not at all.

We’ve covered seven ways for the Product Owner to say no. However, this isn’t meant to be a complete list. Instead, I wanted to show that saying no comes from engaging the stakeholder and helping them see why their request doesn’t fit the product. Pick at least one new approach to saying no, with empathy to your stakeholders.