Empowered Product Teams is another gem of a post from Marty Cagan. This part stood out to me:

In most companies, technology teams exist “to serve the business.” That is very often the literal phrase you will hear. But even if they aren’t explicit about it, the different parts of the business end up driving what is actually built by the technology teams.

However, in contrast, in strong product organizations, teams exist for a very different purpose. They exist “to serve the customers, in ways that meet the needs of the business.”

The distinction is subtle, but important. If you only serve “the business”, you’re going to make decisions without asking whether something is user-hostile or not (see, for example, scroll-jacking, or Twitter’s tendency to “forget” that you prefer a timeline that shows latest tweets). Bringing customer needs into any conversation about business needs is the way to build something that’s profitable and sustainable.

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.

You might think that A rocker’s guide to management sounds like one of those “What X can teach us about Y” articles. And it is, I guess, on the surface. But it’s just so well done. As an intro:

The history of rock groups can be viewed as a vast experimental laboratory for studying the core problems of any business: how to make a group of talented people add up to more than the sum of its parts. And, once you’ve done that, how to keep the band together.

The article is less about management, and more about the different ways that teams can be structured, as well as the good things and pitfalls of each approach.

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.