When I was Head of Product at eBay, one of my primary responsibilities was to lead and build eBay’s new catalog system. 

If you think about it, eBay’s product catalog should basically include any product that was ever created since many items there are vintage and can be sold for a long time after they are no longer available in other places. 

That’s just one of the challenges we had.

We spent months defining how the new catalog system should work. I’ll just say that it was a totally different concept than the existing system’s one. We created a beautiful vision and design that laid the foundation for anything that would be needed in the future until the existing system could be fully replaced. We aligned everyone on the new approach and went over dozens of use cases in depth until the other side was convinced that we could support them.

Now that we got everyone’s buy-in, it was time to make it a reality. But where do you start?

The idea was a system that would continuously scan eBay’s inventory and update the catalog according to the products found on site. It was a massive effort. 

We allocated four teams across different continents and time zones to build it, and we knew we took upon ourselves a major challenge. We wanted to succeed.

To do this, we decided to define an extremely thin version as the first one. We took one use case and agreed to support only that but do so end-to-end across all teams. The promise that we made was that by the first version, any listing that sells a product that meets certain criteria would be tagged with the right product from the new catalog. This would then allow other groups at eBay to start using this information to create new buyer and seller experiences.

With that focus in mind, we started rolling. We were super strict on delivery. We only supported the scale that was essential for the first version. When additional functionality was on the table, we deliberately left it out.

In the end, within just four months, a whole new system was up and running, regularly scanning all of eBay’s inventory to update the catalog and tag the inventory accordingly.

This success was only possible because we defined a clear outcome for the first version. Otherwise, we would have ended up building tons and tons of infrastructure that would be used somewhere along the way. Each team would have had its own roadmap and priorities, and any real results would have taken years to materialize.

Working with outcomes was the key to our success.

I’m sure you know that outcome-based roadmap planning is a good idea. The concept has been around for a while now. However, truly implementing that concept is not so trivial, and many companies simply give it up and stick to their old habits of planning by stacking features against a timeline. 

So, why is outcome-based planning so hard to get right, and how can you make it work in your organization? Let’s dive right in.

Why It’s Hard

Everyone loves talking about features. It’s so easy. They are often tangible and clear, with very concrete decisions that you need to make.

Thinking about outcomes, though, is much trickier. That’s true in general, and planning for outcomes makes it even more difficult.

Outcomes, even when well-defined, are more abstract by nature. Have you ever seen customer satisfaction or felt market readiness? Even if you are used to dashboards, not every outcome is measurable, and you must not confuse the outcome with your progress monitoring.

That’s even before we started debating the right outcomes (which is helpful in and of itself—see below).

And even when you have agreement on outcomes, how do you translate that to what you want to build? Any feature is only a bet since no one guarantees that it will get you the results you are looking for. Making bets is never easy, especially when you have what seems to be a much simpler and stabler alternative that focuses on delivery.

Unfortunately, planning from what you can do rather than from what you want to achieve is not likely to get you the results you are looking for – either because you didn’t plan for them or because you don’t know what they are.

Understanding What You Want to Achieve

The first benefit of outcome-based planning is not even related to planning. You will get value from it even if you don’t use it beyond a certain point. 

It’s very simple, actually. 

Planning for outcomes forces you to apply top-down thinking and start by clarifying your goals. 

Planning is not just a prioritization effort. It’s not about taking whatever you already have on your plate and the ideas you have and spreading them nicely over the year. It’s an opportunity to raise your head and ask the right questions:

• Where do we want to be a year from now, and why? 
• What does it take to get there?
• What will we have to overcome to succeed?

The answers to these questions go beyond features and allow you to focus on what it really takes rather than on what you can do. Even if you choose to make compromises or take risks later on due to constraints, knowing what they are will go a long way toward managing them.

Moreover, the answer to these questions can (and probably would) go beyond the product team since success is a team effort. You often need sales, marketing, business development, and customer success to partner with you if you want to achieve the outcome and not just the product delivery.

Explaining Your Prioritization

Another benefit of this top-down approach is that it creates a strong connection between what you do and the goals you set. 

Since you need to discuss it, you should have a good answer as to why you chose the specific goals over others.

You should then be able to explain logically how the actions that you are planning to take will get you there and why they are the right actions.

When eventually translated to features, the logical link should continue and tell an end-to-end story, explaining clearly how each feature contributes to the bigger picture.

This is important not only for yourself (to know that you are making the right calls) but also for your ability to impact and lead others. When you want people to follow you, it is much easier for them to do so when they fully understand what you are trying to do and why. 

I see many product leaders who like communicating the bottom line and ask others to trust them that it’s the right one. But that’s not the best way to do that. Communicating the strategic context and the assumptions or thought process that led you to the conclusions you are sharing not only builds trust but also impacts their ability to do a better job on their own part, making sure it’s aligned with the bigger picture you are trying to create. For them to be able to do so, though, this bigger picture must be clear and present in your communication at all times.

Delivering Results

It sounds almost trivial, but it’s not.

If you plan for outcomes rather than effort or output (namely, deliver a certain feature), you increase the chance of actually achieving this outcome.

But it doesn’t happen in and of itself. It requires ruthless focus throughout delivery. Note that focus doesn’t necessarily mean sticking to your original plan. If you are committed to the outcome, you might realize along the way that your plan is no longer the right one and needs to change.Once you plan for outcomes, you create a new language for everyone working with you. You have a north star (not a metric, an objective) that you can always use as an anchor and a compass for everything you do. When you lose your way, just raise your head, look for the star, and refine your path accordingly.