I really love the product strategy direction Marty Cagan proposes in The Alternative to Roadmaps:

Ensure your product organization has a compelling product vision.  Ensure that each product team has a clearly defined, prioritized set of business objectives.  Make sure any commitments that must be made are high-integrity commitments.

This means that instead of prioritizing features (and the timing of those features), the leadership team prioritizes business objectives and problems to solve. There are two components to this:

First, the product vision is about setting OKRs—Objectives and Key Results (again—not features or solutions). From The Art of the OKR:

The objective sets a goal for a set period of time, usually a quarter. The key results tell you if the objective has been met by the end of the time.

Second, high-integrity commitments mean we give teams the time they need to figure out how long something will take. From Managing Commitments in an Agile Team:

So the way we manage commitments is with a little bit of give and take. We ask the executives and our other stakeholders to give us a little time in product discovery to investigate the necessary solution, and validate that solution with customers to ensure it has the necessary value and usability, with engineers to ensure its feasibility, and with our stakeholders to ensure it is viable for our business (they can support this solution).

Once we have come up with a solution that works for our business, we now can make an informed and high-confidence statement about when we could deliver this and what type of business results we can expect. We can also decide if it’s even worth doing.

One day when I grow up, this is how I will run my product team.

As if feature prioritization isn’t hard enough, many companies are starting to introduce another tricky variable into the mix: remote teams. If you’re a product manager who spends a lot of time on video calls with team members in different parts of the world, you’ll be forgiven for feeling like involving the team in prioritization is too much to deal with. But don’t give up on the dream yet. One of the teams on a project I’m working on is very much distributed, and I think we may have found a reasonably painless way to do prioritization together.

Here are the ingredients you’ll need:

• An account on Mural.ly
• A good understanding of the Kano model

Let’s discuss the recipe in detail…

On Mural.ly

Mural.ly is virtual whiteboard software. Before you scream “BLASPHEMY!”, I want to assure you that I still enjoy physical sticky notes as much as the next person. Nothing compares to the feeling of ripping a bad idea off the board and rage-throwing it into the closest trash can1. That said, physical sticky notes have two major drawbacks:

• It’s hard to get remote teams involved in the process.
• Transcribing them is such a chore.2

And that’s where Mural.ly comes in. It lets you create virtual sticky notes on a whiteboard, move them around, change their color, and best of all: the whole team can play along. You can do voting sessions, multiple people can edit at the same time, etc. This tool has really done wonders for our collaboration efforts across offices.

On the Kano model

The Kano model isn’t new, and it’s been fairly widely used in software product development for a while. Developed in the 1980s by Professor Noriaki Kano for the Japanese automotive industry, the model is a helpful method to prioritise product features by plotting them on the following 2-dimensional scale:

• How well a particular user need is being fulfilled by a feature
• What level of satisfaction the feature will give users

The model is generally used to classify features into three groups:

• Excitement generators. Delightful, unexpected features that make a product both useful and usable.
• Performance payoffs. Features that continue to increase satisfaction as improvements are made.
• Basic expectations. Features that users expect as a given — if these aren’t available in a product, you’re in trouble.

Here is a visual representation of the Kano model:

So, as we started our prioritization exercise, I drew the x and y axes on a new mural. We then listed out all the features that we’re thinking about for the next few months—one feature per sticky note. We proceeded to go through each sticky note, and discuss where it fits on the Kano model—how far are we in meeting the need currently, and how satisfied do we believe users will be once we’ve met the need better?

We ended up with something like this:

(Yes, it’s small—unfortunately I can’t show the feature details. Maybe once they’re live…)

This now becomes a great tool for prioritization and release planning. There are couple of rules of thumb I like to stick to when doing sprint/release planning:

• Make sure there is a balance between the 3 different types of features. Don’t overemphasize one type over the other.
• Start with the features with the biggest upside. For Basic expectations, that means features on the far left, where a little work would result in a big increase in satisfaction. For Excitement generators that shifts to features closer to the y-axis, since the real benefits start to kick in exponentially once you go the extra mile on fulfilling the need. For Performance payoff features the story is a little less clear since the relationship is linear, but I would still argue for starting on the far left. The sooner you can get users on the “satisfied” side of the scale, the better.

We’re still learning our way through this, but so far I’m happy with the process. It’s a model that everyone understands and can rally around, and with Mural.ly at our side we get to involve the whole team. I believe marketers call that a win-win.

---

1. Why do rage-throws always miss the basket? Such a let-down. ↩

2. Funny how you never see photos of the lone product designer sitting in a room, tearfully writing down every sticky note in an Evernote document as everyone else leaves the room high-fiving each other. ↩

An interesting counter-argument to the #noestimates movement—and a call for reasonable software development estimates—on the Clever PM blog1. From In Defense of Estimates:

From a business perspective, some level of estimation is absolutely required, so that judgment calls can be made as to priorities of execution and communications within the company and to customers. We need to have some level of understanding of whether something is “bigger than an elephant or smaller than a breadbox” so that we can deploy other parts of the organization appropriately. “It takes as long as it takes” is not useful for tactical or strategic planning within any organization.

---

1. It’s kind of hard for me to link to this. First, there’s no byline, and I’d love to quote the author by name. Also, wow, that stock image… ↩

Scott Sehlhorst wrote a really good defense of good product roadmaps in Features do not a Product Roadmap Make:

If your roadmap says “Will include update quantity control in shopping cart” you’re doing it wrong.  Your roadmap should say “Improved shopping experience on mobile” or “Better shopping experience for spearfisher  persona.” […]

When a roadmap is being used to communicate “what” the product will be, it should be in the language of describing which problems will be addressed, for whom, or in what context.  This is the most important type of theme which would be part of a thematic roadmap.  Other themes could be “improve our positioning relative to competitor X” or “fill in a missing component in our portfolio strategy.”

And this, in the context of agile, is a great point as well:

A backlog – a prioritized list of features – is not a roadmap. It is a reflection of a set of design choices which happen to fulfill in product what the roadmap sets out as a manifestation of strategy.

A roadmap tells you both “why” and “what;” a backlog tells you only “what.”

This reminds me of an article I wrote in 2011 called Product roadmaps are safe. Good times.

Scott Sehlhorst makes some very good points about different levels of roadmap detail in Opposite Views of a Product Roadmap:

Depending on your role in your organization you will be biased towards viewing your roadmap either as a view of what the team will be building into your product, or a view of why the team will be building things into your product.  As a product manager, it is imperative that you can view it both ways.

When it comes to what you’re building, the roadmap gets less precise as you move further out:

I describe rolling-wave planning as being precise about the immediate-term future, having less specificity about the near future, and being nonspecific (but still helpful) about the more distant future. This is because – from the perspective of someone focusing on what they will be doing – there is too much uncertainty about what will happen between now and the future. (BTW, this is where waterfall is wasteful – it assumes incorrectly an ability to predict the future in detail.)

In contrast, when it comes to why you are building what you’re building, it starts off fairly broad and becomes more precise as you go on:

In the “right now” the team is testing hypotheses. Given a customer, and a problem the customer is trying to solve, there is a hypothesis about how best to help. That hypothesis is a design. The design may or may not be a good one. The implementation of the design may be great, adequate, failing, or incomplete. In this time horizon, the activities of the team building the product are concrete – build, test, learn.

The way I would summarize Scott’s post is as follows. When it comes to product planning, be rock solid on what problems you’re solving for which customers, but be open to data-informed change when it comes to short-term implementation details.

Some smart thoughts from Scott Sehlhorst in Classifying Market Problems:

Many teams struggle with backlogs or roadmaps which appear to be a collection of “a bunch of stuff.” Most teams try and address the problems that manifest from having a giant list of stuff by getting better at managing giant lists. This is treating the symptom, not the cause. If you’re trying to juggle hundreds of requirements, the problem isn’t that you have hundreds of requirements, the problem is that you don’t know why you have requirements.

Which reminds me of this cartoon, because that’s what happens when you get better at managing lists instead of getting better at figuring out how to make your product useful:

Of course, it’s also at this point that users tend to take matters into their own hands:

Rich Mironov’s We Don’t Hire Product Owners Here is a treasure trove of advice and clear thinking on the dangers of not taking the Product Owner role seriously in companies that make the switch to Agile development. There are so many good sound bites, but I’ll stick with just one that hits close to home:

Don’t let your customer request list become your roadmap. Kano analysis teaches us that letting current customers prioritize your backlog for you leads to market failure.  Don’t let your product owners confuse “this is what the enhancement request says” with “understanding and solving real customer problems.”