I’m staying out of the “hot takes on that John Maeda interview” genre, but I do want to link to Heather Phillips’s Stop dwelling on being design-led: Focus on the user. She brings up some great points that product managers need to keep in mind as well:

We shouldn’t think about being design-first, or development-first. Instead, we should be thinking about how we can bring our paths closer together. Every business function — including design — should be thinking about the user, first and foremost. And building solutions with the best user experience in mind. This work should not be silo’d in product, marketing, or design.

We’re in this together.

Amen to that.

I am intrigued by the idea of product-specific wikis, as outlined in North Star Product Management. The idea is to have a living document that explains how each product component works, why it exists, why certain decisions were made, and what the future looks like:

The purpose of North Star Docs is not (at least, not necessarily) to minimize changes — changing the North Star Docs is just fine, and is of course actually encouraged, if we can find a better way to do something.

The purpose is, instead, to help map complexity for systems-level, rather than localized, problem solving. They are comprehensive and detailed specs like a Waterfall, yes, but they serve a very different purpose.

This can then be paired with project-specific specs as and when needed. But separating those from the main “this is the overall vision of the product/component” document provides a clear decision-making framework and builds organizational memory.

This interview with Jonathan Golden, Airbnb’s very first product manager and now Director of Product, is sprawling and worth reading in full. It’s a fascinating look at the company’s philosophy on product and teams.

I was particularly interested in the description of three types of PMs: Pioneers (focused on taking risks and building new things), Settlers (focused on growth and scaling), and Town Planners (focused on infrastructure and platform management). What’s important is the point that companies need all three types, no matter their size:

Even in an established company, all three types of product managers are critical. “The product team needs each of these PMs to be nimble and responsive. Otherwise the business won’t endure for the long term,” says Golden. “We allocate product resources across three main categories: core initiatives that focus on the existing product, new initiatives that explore possible areas of growth for the business, and platform initiatives that focus on building fundamental technological infrastructure.” Pioneers and settlers don’t become obsolete just because you’re at scale.

This is the type of framework that brings up lots of (good!) questions for all of us to answer. Which of the three types of product managers are you? Is it possible to be combination of them? Which might you or your company be lacking in?

Phil Johnson has some good advice for product managers in The Goldilocks of Process:

Blindly following process is a project-killer—not just in terms of efficiency. The real poison is the mentality: in these cases process became a crutch to lean on, with these individuals no longer thinking critically about their tasks. In many ways, the process became the job, where process really should be what enables the job. This rings doubly true in the software development world.

On any team, you want your process like you want your porridge: just right. If you have too little, the team may not know what the priorities are, or who is responsible for the next step. Too much, and your team will end up doing more process than actual work. The right strategy should be flexible enough to fill in the cracks of the team’s blind spots while enhancing their strengths. It’s up to the PM to find that sweet spot.

This also reminds me of Michael Lopp’s essay The Process Myth, and these words that will forever be etched in my brain:

Engineers don’t hate process. They hate process that can’t defend itself.

I talked about adding friction to products last week, and Kurt Yalcin’s article Against Engagement makes for a great companion piece. He touches on many topics, but I especially appreciate his views on that topic:

Slowing experiences down with intention and adding deliberate requests for user action at critical moments in a user flow makes for better experiences in the long run. Bring a level of consciousness to your designs and address the pressures you may have to reduce friction at all costs. If adding an additional click means giving users more freedom, go with the extra clicks. This level of awareness in your design enables users to make conscious choices about when, where and how to engage with your products, rather than acting on autopilot.

Emily Tate’s article on the best ways to prioritize bugs comes at the problem with a Scrum lens, but many of the points are more broadly applicable to product management. I particularly like her assertion that there’s nothing “special” about bugs, and as such they should be prioritized just like any other idea/feature:

As product managers, we should always manage our backlog so that the next most important thing is at the top of the list. Many times, the bug you would work on is less important than other things on your backlog. By working on the lower priority bug, you are deferring the more important work that can help you reach your strategic goals.

The flip side of this is also true: sometimes the next most important thing may be five or six bugs that really need to be fixed before adding yet another feature on top of a fragile platform. If you live in a world of separate queues or say you’ll always devote 20% of the team’s time to bugs, you actually lose the opportunity to say “this week, we are squashing these bugs that have been plaguing us before we do another thing.” In reality, you will likely have a mix of bugs and features in your backlog, but the most important thing is that you prioritize strategically and intentionally, not letting a false constraint determine what the ratio of your backlog looks like.

We all know the old enterprise software joke that “no one ever got fired for buying a Microsoft product”. But one of the important points in Auren Hoffman’s post on how Zoom is beating much larger competitors like Google Hangouts and Slack is that larger companies are not that unpleasantly predictable any more:

One of the biggest trends that is driving Zoom’s success is that companies are forgoing the full stack and buying the best-of-breed. The number of vendors the average company is buying from has increased almost 10x in the last 12 years. Companies are happy to buy from many different places. They are even happy to buy from new start-ups. […]

In fact, it has never been easier to sell to large companies. Large companies are open for business. They want to be sold to. They are sick of having a third-rate solution. They want to use the best product. If you can show them your product is superior, they are excited to buy.

This is an exciting development for product managers, especially if you’re building something in the B2B space at a smaller company. With a really good product it’s becoming so much easier to sell to larger companies without the need for the bureaucratic checklists that used to be an impossible barrier to break through (“Are you ISO 9001 certified?”).

That said, in most cases it’s important not to start there. As Box CEO Aaron Levie points out in this article about Slack’s move into the enterprise:

[Slack] have had a methodical process of continuing to drive strategy up market. They started with individuals and small teams, and then departments and bigger teams, and now broader enterprises. It’s been a very thoughtful strategy.

There are many reasons to start your product growth with smaller teams. One is that it will help you make incremental improvements very quickly. But it’s also really dangerous to end up in a situation where most of your revenue comes from a few large customers. So start small, get better, move into larger markets, and then just keep going…