Saying “No” is the most important job of the product owner. It’s really the reason d’etre for this role. But there are lots of different ways and reasons to say “No”. This is my stab at categorizing three important “No”’s a product owner can deliver.

---

I still like the definition of a product owner as “if you’re responsible for building a product in a company using scrum, then you’re a product owner.” Or to say it with the words of Melissa Perri Product Owner is the role you play on the SCRUM team. Product Manager is the job!

Henrik Kniberg has a great way of explaining the works of a product owner in simple terms. He highlights the reason that the product owner must exist lies in the fundamental conflict between:

1. We want to stay agile, have really short cycles between input & output.
2. We have way more requests for a development team than they can handle.

The SCRUM way of resolving this conflict is to put a “product owner” in front of this queue, and let him say “No” all the time, then prioritizing the items in the queue to enable really fast cycle times.

Here are my favorite three “No”’s. Ask yourself “wherein our backlog/queue would I place this item if I were to implement it”. For me this results in one of three places:

1. Right at the top, because it’s a small (already smaller cut) item with some value.
2. At the bottom of the backlog, because it’s a rough & large topic with a potentially large value.
3. “Beneath” the backlog, because it simply isn’t due yet, but is really necessary.

In all three cases, you can of course say “Yes” to the item. But since product owners end up saying “No” way more often, let’s focus on the “No”.

So what does this “queue” look like?

The Queue & Projects

This is the queue. In SCRUM it’s called the product backlog (PB), but in essence, it’s an ordered list of items that will be implemented. It has one interesting feature: Things on the top are cut really small, certain, and well refined. The team knows exactly what to do with them. The items farther back are rough, large, not well defined. An example of a “top of backlog” item is “add the ability to view past orders for customers within a year, possibly with filters”. A similar item on the very back of a backlog could simply read “order history”.

The product owner roughly estimates two things:

1. The size of every entry (cost)
2. The value of every entry

And then puts it into an order in the backlog.

Usually, PBEs or product backlog entries are grouped into “feature areas” or “projects”. Projects are a larger collection of user stories to gain some large end-user value. This is because context switching in IT is really expensive, so grouping things is smart. The value curve on a project usually looks like this:

A risk-reducing phase in the beginning with prototypes etc. It’s where the feature area could also die in case a risk is too large, or a hypothesis fails.

A “building value” phase with lots of fun for stakeholders who get lots out of this one.

And finally a “find the cutoff” phase where we need to find the point where the marginal value is too small to continue in this feature area.

Side note: this is why disturbing at the beginning of a new project is a really bad idea, while a phase between switching projects with a bunch of “plugging a few holes” tickets is just fine.

Large items on the bottom can turn into complete projects depending on how much is needed and how large the possible gain is.

Now we got everything ready to discuss the “No”s.

The Off-Topic No

The Off-Topic No is an important one to understand as it also produces the “dependency tension”.

“Hey, can you please quickly add X for Y to product Z?”. That’s usually a small item on top of the backlog. Compared to the other items you have in your backlog, the individual value may actually be the same.

But there’s a catch, this new request is in a totally different feature area. The reasonable response is to say no, because if you say yes, you:

1. produce a delay in the large value to come on the project (which means you lose “days of delay times value/day”)
2. and produce pretty large context switching costs.

A possible phrasing would be “This is in a very different field of work than what we currently do. It would delay this important large topic & produce context switching costs which usually diminish the value altogether, so no this item cannot be placed on the backlog in order to keep our time to market short and get this cool large thing into the end-user hands as quickly as possible.”.

The second decision is whether to turn it into a large thing or to discard it altogether. For instance, you should ask “Are customers asking just for this one feature? Or maybe for a whole feature group?” If that’s the case, you just gained a large, rough item for the bottom of your backlog.

But you cannot have a large queue of large items either. In fact, you can only have very few!

The Priority No

Discussing focus & priorities means organizing projects you work on, which usually happens at the bottom of the backlog with those large blocks. Those discussions might involve dependencies on other teams, the larger company vision, and the larger product vision. Saying no to a project here is actually pretty easy because those large blocks are pretty easy to trade-off.

A possible phrasing of No would sound like “I’m sorry, but the company vision is to enable X, so I got Y and Z as possible topics for Q3 & Q4 of this year and they will span all the time. I cannot take on this large project.”

Or, “project Y and Z enable the following value to this customer group which is this large. That project, although interesting, enables not as much value.”

You may use “impact mapping” and some simple benchmarks to make such trade-offs.

Usually, this is then followed by “Oh ok, so can we do it in Q1 afterward”? Where the proper agile response is “No, that would increase our time-to-market by 50%!. We got to evaluate that when we’re at that point and there’s space in the queue.”

The Event Horizon No

The last “No” find’s it’s placed at the very bottom of your queue. Actually below it! Remember the queue influences your time-to-market. Whatever you place in there lengthens your time to market. So why not add stuff “below” the queue? I’ve written a whole post about this, but the essence is:

By adding items “below the queue”, by creating a “backlog to the backlog” you add things where you personally are more uncertain than certain that this will actually be done ever. The far more likely thing to happen is that once it’s time to implement this thing, everything has changed and it’s obsolete, or you’re producing something or pretty low value.

Try not to do this:

So if a request comes in which is below your current queue, simply say “I cannot add this to my backlog, it’s not on our current horizon and should be discussed, when the time is there.” If this is followed by “But it’s necessary! It has to happen.” Try to follow with an “If it’s that important, it will surely come up again when we discuss the topics for that time and can then be weighed against the things that are also relevant then.”

That’s a lot of nos! Is there a reason to say yes even if it looks like a no?

The Dependency Tension

Things would be straight forward if your team would work in isolation. Then you could use these three nos all the time. But sometimes there is a dependency between teams.

Product owners have to be really careful when seeing dependencies, they need to understand that it’s necessary to actually “squeeze in” things to the better of the company but that they also bear the cost of it. It’s a trade-off they have to make and be aware of.

This is of course, why from a product management perspective it’s essential to decouple teams, to remove dependencies, to cut actual products, and make sure they run independently and don’t share lots of components, etc. Because if you don’t do so, you’ll end up with this:

So, if the request comes in with “we need you to implement X now because we’re blocked by it with implementing Y” you should:

1. Estimate the value of Y (which isn’t yours!).
2. Estimate the size of X.
3. Discuss possible alternatives.
4. Discuss the switching costs (which I simply like to estimate to be between 50–100% of the size of the thing. 50% for large, 100% for small items).

Make your decision, and then try to figure out if there’s a dependency between teams that need to be removed to increase the productivity of both teams! You could for instance push use some “consulting” model to deal with knowledge dependencies where in essence you might loan out one of your developers to another team. You could pus for an internal open-source model as Spotify does. In that case, a dependent team could simply fix X for themselves and go on with Y.

That’s it! Keep on saying “No”.