I always love a good persona case study, and The Story of Spotify Personas is no exception. But more than the story behind it, I am most interested in how teams use their personas (if at all). So I was happy to see the team devote some time to that towards the end of the article:

For instance, teams that want to create features from scratch can now choose their personas, map out the existing opportunities, pick a direction and start ideating from there. Although personas don’t replace user research, they can help us create educated hypotheses and save us time – meaning we don’t need to run foundational research every time we want to explore a new topic within the music listening experience. Our teams can now focus their resources on diving deeper into problems from the level set by the personas.

Equally, when teams are more focused on maintaining features, they can now map out their work and see how different personas would use it. They can create mental model diagrams for different personas and discover how they experience their journeys. And in doing so, they can refine the features to better fit certain ways of listening to music, whilst making sure they don’t alienate others.

I know I’m kind of in the minority here, but I am still a fan of personas—if they are based on actual research, and used to make better product decisions.

Sometimes we can get overly reliant on our frameworks and methodologies to help us make sense of our products and our worlds. Melissa Perri shares some excellent advice about the dangers of this in The Science of Product Management:

These motions, these frameworks, they were made to teach you to think. They were a means to an end, not the end goal itself. They are training wheels. How can they help you understand your work better, so you can DO your work better?

The point of Product Management is not to put things in JIRA in a specific format, use a specific framework for writing out goals, or make sure your developers have full backlogs. The point of Product Management is to create valuable products that customers love.

That’s where the real science of Product Management comes in. The science is about understanding the patterns to building products that people love from a strategy perspective.

I shared some similar thoughts on Twitter in the context of this new-ish push for “product thinking”:

I’m in a spot where I feel we’re trying too hard to make “product thinking” a thing with fancy words and lofty concepts. Like we have some kind of inferiority complex with other disciplines we’re trying to make up for. Talk to customers, understand the market and the business, and experiment until you get it right. That’s pretty much it, right? How you do that looks different in every org, but that’s where the art comes in. You can’t codify product management.

An oldie but a goodie from Michael Copeland: Shipping is a Feature—Some Guiding Principles for People That Build Things:

For these five bits of advice, I chose to focus on what I think is the most challenging aspect of being a PM, which is achieving clarity and maintaining a point of view for a product when all forces work against this very thing. What customers value most in a product is that “it just work” or “does what it is supposed to do,” and yet at every step in a product, the dynamics of design work to make this the most difficult to achieve.

The whole list is good, but the one that resonates the most with me is “Can’t agree to disagree.” What to do when you simply have to make a decision that not everyone agrees on:

So if you’re on the “winning” side of such a dialog then you have to bring people along every day for a while. You can’t remind people who was right, or that it is your decision and so on. If you’re on the “losing” side you need to support the team. You can’t remind people when little things go wrong (which they will) that you were right. Once a choice is made, the next step is all about the greater good. Nothing is harder for technologists than this because as technologists we believe there is a “right” answer and folks that don’t agree are simply “wrong”. Context is everything and remember you have to ship–as a team.

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.