Prioritize Opportunities, Not Solutions is a really good post by Teresa Torres about using the Opportunity Solution Tree methodology to make sure we place lots of product bets early on in a lifecycle, and only implement the ideas that matter. I also like her distinction between one-way door decisions (“once you’ve walked through the door, you can’t turn around and come back through”) and two-way door decisions:

Your opportunity assessment and prioritization decisions are two-way door decisions. Once you choose a target opportunity, you’ll test whether or not you made the right decisions by prototyping and experimenting with solutions that address those opportunities. If you learn through experimentation that you didn’t choose the best opportunity, you can always walk back up the tree and choose another opportunity.

Itamar Gilad shares a healthy critique of the Impact/Effort prioritization matrix that is so ingrained in every product manager’s brain:

As straightforward as this all seems, there are major problems with Impact/Effort prioritization that cause us to pick the wrong winners. Most importantly Impact/Effort analysis requires us to make somewhat reliable predictions on future events — the effort we will require to complete a task and the value that will be delivered to users and/or to the company once completed. As it turns out both are jobs we’re exceptionally bad at.

He doesn’t say we need to stop using it though, just that we need to move the borders of the matrix around a little bit. It’s also worth noting that there is no “one size fits all” prioritization method. I’ve written about different prioritization techniques, and am a proponent of choosing and adapting the ones that work best within the culture of an organization.

“Cause & Effect and Product Risk” is a good good post by Scott Sehlhorst on the importance of moving to an outcome-based approach when evaluating and planning product features. He also discussed how to use Impact Mapping to do it:

When we collaborate to develop a shared understanding that explicitly connects “building X” with “realizing benefit Y” we address the first problem. Impact maps are great for this, because in the process of creating the connections, we intentionally challenge those connections and explore others; creating a better plan, shifting to a bigger goal. All while providing deep context throughout the teams, increasing likelihood of successful delivery and effective stakeholder management.

The Netflix Data War is a very interesting post about the internal discussions that happen between Netflix’s content team and their data team. In short, data isn’t everything:

[…] in almost any decision-making situation involving data, there is some non-zero percentage of the process that involves “gut”. The reason is because not all information about a process can be incorporated into a data analysis, and it’s important for data analysts to realize that.

That’s an important point to reflect on. It doesn’t matter how complete a data model is. There are some variables that simply cannot be included, because it’s impossible to know what should be included in any particular model.

Apart from that, it’s also just a fascinating look at the internal workings of Netflix.

Here’s a pragmatic approach to roadmaps that I can get behind. Escape From the Feature Roadmap to Outcome-driven Development:

You’re exploring new lands. You know where you want to get to — that’s your outcome — but there’s no established route to get there. So you’ll probably set out, and if you’re measuring yourself correctly and you’ve got good feedback loops in place, you’ll be able to course correct and quickly iterate towards your outcome. But you could only draw the complete roadmap with hindsight.

So it’s time to take a new approach: forget the features and focus on the outcomes.

Roadmaps that include a bunch of features are doomed to fail. Instead, say “here’s the problem we want to solve in this iteration.” That allows you to be flexible on scope, and ship solutions to customers quickly.

Scott Colfer writes about product roadmaps in this article, but it includes what I think is a pretty valuable overview of the core role of a product manager:

Product management makes promises to solve problems over commitments to specific solutions. We take the human tendency to specify the means of doing something, rather than the result that is wanted, and redirect it by specifying what is to be achieved, rather than how to achieve it. Product managers are usefully agnostic about solutions — we help teams to prioritize the most valuable problems to solve and then help them to prioritize the solution that requires the least work for the most value — and we’re happy when we learn something that helps us to refine and simplify our solution.

Mind the Product has a good write-up of C. Todd Lombardo’s talk called Roadmaps are Dead! Long Live Roadmaps! I’m also in the “prioritize themes, not features” camp:

Every theme on your roadmap should have a problem, an objective, and even some potential ideas you have to solve those problems. In practice, this changes how your roadmap looks. Rather than being a list of features, it might start from an objective of reducing support costs, and then show themes that might help reach that objective such as improving invoicing options or expanding payment types. By removing the details of what features will be built to fulfill these themes, it gives the team the freedom to figure out how best to solve the problems presented.

This is similar to some thoughts I had in a 2011 post called Product roadmaps are safe.