Chris Jones describes his favorite product manager interview question, but in the spirit of “know thyself” I think this is an exercise everyone should go through for themselves:

The question comes late in the interview, but early in the overall hiring process. The setup goes like this: “Now that I know you a bit, I’d like to give you a list of 4 broad work attributes. You’re a product manager, so I already expect that you’re strong in each. But I highly doubt that you consider yourself equally competent in all of them. So I’m going to ask you to stack rank them in order of strongest to weakest”. This setup should be disarming. The candidate must understand that there is no correct answer to the question, hopefully setting up an honest conversation.

The four attributes are Execution, Creativity, Strategy, and Growth. Chris does a good job of breaking down what each attribute means and why it’s important.

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.

I really like the this Mountainsides approach to software projects from the Postlight team:

It’s sort of like a Gantt chart that was left on the stove too long, leaving all those neat and tidy bars melting into one another.

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.

Clive Thompson digs into software that aims to add friction to our lives in his Wired essay We Need Software to Help Us Slow Down, Not Speed Up:

It’s certainly possible to slow our software, and thereby ourselves. But it’ll happen only when we become too unsettled by the speed of our journey.

His post reminds me of some other ideas I’ve read about this in the past. Chris Palmieri in A Practice of Ethics:

But some friction is borne of respect, when we present information about the choices available to users and help them make better decisions. An emailed invoice could remind a customer they were paying for a service they no longer use. A checkbox could assure a user of their current content privacy settings before posting a sensitive photo. Recognition of a past purchase can save a customer the hassle of having to return a book they already have, or confirm that they are re-buying exactly the same shampoo.

And here is Andrew Grimes in Meta-Moments: Thoughtfulness by Design:

Meta-moments can provide us with space to interpret, understand, and add meaning to our experiences. A little friction in our flow is all we need. A roadblock must be overcome. A speed bump must be negotiated. A diversion must be navigated. Each of these cases involves our attention in a thoughtful way. Our level of engagement deepens. We have an experience we can remember.

Not all friction is bad…

I’ve been really intrigued by Ryan Singer’s thinking around Products as Functions:

Products are easier to reason about when you think of them as functions. They transform an input situation into an output situation.

This lets you describe what the product does as a transformation of the user’s circumstance instead of a bundle of features.

I’ve been using this thinking on a new project we’re working on at Postmark. I like this approach because it gives us a framework to communicate why something is a good idea to work on, and it focuses on the benefit for customers. If our answer to the question “How much better is this new outcome?” is “Not better enough”, then we need to define a better Output situation, which would lead to a better Process.