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.

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.

Eugene Wei’s Invisible asymptotes is a long, excellent article about the importance of not just thinking about product-market fit, but also product-market unfit:

For so many startups and even larger tech incumbents, the point at which they hit the shoulder in the S-curve is a mystery, and I suspect the failure to see it occurs much earlier. The good thing is that identifying the enemy sooner allows you to address it. We focus so much on product-market fit, but once companies have achieved some semblance of it, most should spend much more time on the problem of product-market unfit.

For me, in strategic planning, the question in building my forecast was to flush out what I call the invisible asymptote: a ceiling that our growth curve would bump its head against if we continued down our current path. It’s an important concept to understand for many people in a company, whether a CEO, a product person, or, as I was back then, a planner in finance.

He goes on to discuss those asymptotes for different companies (for example, shipping fees for Amazon). Another interesting bit:

We speak often of the economics concept of the demand curve, but in product there is another form of demand curve, and that is the contour of the customers’ demands of your product or service. How comforting it would be if it were flat, but as Bezos noted in his annual letter to shareholders, the arc of customer demands is long, but it bends ever upwards. It’s the job of each company, especially its product team, to continue to be in tune with the topology of this “demand curve.”

I see many companies spend time analyzing funnels and seeing who emerges out the bottom. As a company grows, though, and from the start, it’s just as important to look at those who never make it through the funnel, or who jump out of it at the very top. The product market fit gradient likely differs for each of your current and potential customer segments, and understanding how and why is a never-ending job.

Figuring out what your product’s invisible asymptotes are sounds like a really good thought process to me. At the beginning of the article Eugene mentions one way Amazon tried (and succeeded) in answering this question:

For people who did shop with us, we had, for some time, a pop-up survey that would appear right after you’d placed your order, at the end of the shopping cart process. It was a single question, asking why you didn’t purchase more often from Amazon.

Another technique he mentions:

One approach I’ve taken when talking to companies who are trying to achieve initial or new product-market fit is to ask them why every person in the world doesn’t use their product or service. If you ask yourself that, you’ll come up with all sorts of clear answers, and if you keep walking that road you’ll find the borders of your TAM taking on greater and greater definition.

A good way to frame this could be to ask yourself something like this:

If we didn’t change anything about [product name], at what point would we hit a growth ceiling, and what are the factors that would cause that?

If you can have a reasonably confident answer to where the S-curve inflection point will be, you can start planning on avoiding it early. That’s a worthy effort, and definitely something I intend to think through for our products.

While reading this great interview with the band CHVRCHES I came across a passage that struck me as a good description of how product managers should work. They describe the producer on their latest album like this:

And I think that’s why he’s so good at what he does. He’s not a kind of producer that has one thing that he does and he tries to make every artist do that thing. He steps into the room and tries to figure out the people that are in it and figure out the music they’re making, and then how can he add something to that and offer wisdom and guidance and make it better.

We all have methods and techniques we gravitate towards: Jobs-to-be-Done, Agile, customer journeys, sticky notes… It’s totally fine to have favorite methods that we know inside out and that have worked well in the past. But it would be a mistake to force one of our favorites on a team when it’s not the right thing for them.

One of the most difficult things a product manager needs to do is first understand how a team works and what makes them effective, and then figure out which methods and processes can create the right environment for them to thrive. That’s the skill that sets apart the great product managers from the good ones.

Janna Bastow wrote a great post on product management for maturing products. From Growing up Lean: Lean Strategies for Maturing Products, here’s a recommendation for how to avoid becoming a “Feature Factory”:

Break the backlog up into two parts: The Product Backlog and the Development Backlog. […]

Product Backlog: A list of all of the things you could do. You’ll never complete everything on this list, and it’ll always be in a constant state of flux. It’ll include customer requests, suggestions from your team, through to insights from your experiments and prototypes. It should be accessible by your team, to both contribute and follow along on progress – your team should be helping to build and flesh out the ideas in your backlog. This is your space to prototype and spec out ideas, map them to your objectives, and track their progress until ready for production.

This is similar to how we do things at Postmark. Here is our Releases board in JIRA:

You’ll see that we have our short-term planning (the Development Backlog), that currently only covers 2018.2 and 2018.3 (roughly 6 weeks each). And then we have the mysterious Later release… that’s the Product Backlog. It’s that list of all the things we could do. When we do short-term planning we pull from that list, as well as other areas (most notably, our “Idea Zone” in Basecamp, which I should also write about at some point).

I’ve written about maturing products before as well. I’m happy to see that Jenna and I bring up similar points. Here’s a quote from my post Product Management for well-established products, which echoes some of her thoughts:

With an established product, it’s way too easy to get off track (Evernote, anyone…?). So what I argue for is a flexible quarterly roadmap of prioritized themes. You don’t write down dates next to a long list of features. You don’t make hard commitments for releases that might never happen.

Instead, you put together a list of themes you’d like to work on, in order of priority, based on how closely they align with your objectives and key results for the quarter.

Nicholas Thompson and Fred Vogelstein has a gripping feature in Wired called Inside Facebook’s Two Years of Hell. It’s long, but very much worth reading. It takes us through a journey that starts with Facebook’s years of denial:

It appears that Facebook did not, however, carefully think through the implications of becoming the dominant force in the news industry. Everyone in management cared about quality and accuracy, and they had set up rules, for example, to eliminate pornography and protect copyright. But Facebook hired few journalists and spent little time discussing the big questions that bedevil the media industry. What is fair? What is a fact? How do you signal the difference between news, analysis, satire, and opinion? Facebook has long seemed to think it has immunity from those debates because it is just a technology company—one that has built a “platform for all ideas.”

And it ends at the point they are at now: starting to realize that they can’t hide behind the “we’re just a platform” excuse any more.

I’m guessing that not everyone is going to agree with NN Group on this one, but I’m on board with their article about Personas vs. Jobs-to-Be-Done:

With the popularity of the JTBD paradigm, there are calls in some corners to abandon personas, suggesting that JTBD has emerged as a more useful technique. This point of view is based on a fundamental misunderstanding of the purpose of personas as primarily demographic representations of users, missing the key behavioral considerations that are essential to good personas and that provide much needed guidance for interaction design and product strategy.

The thing is that, as I have written in Job stories are great, but personas aren’t dead, we shouldn’t confuse marketing personas with design personas, which are specifically created to guide the development of product features. Design personas are based on needs, goals, and dimensions that have a direct impact on their interaction with the product.

Good design personas are complementary to JTBD, not in conflict with it. As NN Group further explains:

Well-executed personas are based largely on rich behavioral characteristics, attitudinal data, and insights about mental models, and they require qualitative research with real users to uncover the why behind users’ behaviors. These rich personas typically will include information related to specific goals that users must achieve when they use the product; these goals are directly comparable to the information found in the jobs-to-be-done definition.

So instead of choosing between Personas and JTBD, I’d like to have both, please. I’ll use Personas to get a better understanding of the goals and needs of our target market, and I’ll use JTBD to help create the products that will meet those goals and needs.

I think most of us know Ben Horowitz’s classic Good/Bad Product Manager post. At Wildbit we have a whole section of similar Good/Bad posts to help define our take on various roles — but until recently, the Product Manager slot was empty. I started working on our take on the Good/Bad Product Manager debate a while ago, and we finally published it last week.

I realized that the most important lesson I learned about product so far at Wildbit is the importance of a happy and effective team, and how much of a Product Manager’s time should be spent on that:

No amount of workshops, sticky notes, or JTBD theory will help you create consistently awesome products that customers love if you don’t work with a team that is fulfilled and motivated.

That might be a slightly controversial idea, and it might not work for every organization. But it certainly works for us. So here it is, our perspective on what it takes to be a good product manager.