This interview with Ryan Hoover from Product Hunt on how to develop products people love is really interesting. For example, here he makes a really good point about the importance of systems thinking in product management:

Most products can be broken down into a math equation, where multiple variables need to be true for it to work. Many newer product managers don’t break this equation down as much as they should. Then, they don’t test some of their hypotheses soon enough. If you have x, y, and z, and you’ve figured out the x and the y but you failed to resolve z, then it won’t work.

Sometimes people focus on the easier things. They resolve two hypotheses that are easier to figure out, and then defer the last one. A lot of people don’t think about user acquisition. They think, “We’re going to build an awesome product, we’ll get press, and we’ll launch it on Product Hunt and that’s it.” They should probably reverse it — think about distribution and marketing first, and then figure out how to build that into the product itself.

I also love their approach to experimentation, which can basically be summed up as “do it as cheaply as humanly possible.” Great interview.

I’m a big fan of the product forces aspect of the Jobs-to-be-Done framework to help teams think through the challenges they need to overcome to get customers to adopt their product. In Product adoption: how to get customers to embrace your product the Intercom team discusses the product forces, as well as some strategies for overcoming those forces. For example, on decreasing attachment to the status quo:

What can you do to draw your prospects’ attention to your benefits over their feelings of belonging? It may be as simple as promising a feature they’re desperately missing (like online privacy) or mentioning the support options you have in place (so they don’t have to ask a friend for help).

Google UX Designer David Hogue shares his thoughts on How to Reverse Over-Complication in Product Design and How to Avoid It Altogether. It’s a very good read for product managers. Here he describes how do build a process to avoid over-complication:

Critically evaluate every new and existing feature for the value it provides weighed against the costs of including in a product or service. Does a feature introduce friction or ambiguity? Does adding something more make flows, paths, and choices harder to understand? What are the potential positive AND negative outcomes of adding something, and is it worth it?

Constant vigilance against entropy, scope creep, and the accumulation of friction is necessary. Pausing for review after major releases, conducting retrospectives after updates or changes, critical analysis of product performance before and after a change, and ongoing quantitative and qualitative research can all provide information about and indicators of increasing and unintended complication.

Ian Bicking makes some very good points in his post “Users want control” is a shoulder shrug:

Control is what you need when you want something and it won’t happen on its own. But (usually) it’s not control you want, it’s just a means. So when we say users want control over X — their privacy, their security, their data, their history — we are first acknowledging that current systems act against users, but we aren’t proposing any real solution. We’re avoiding even talking about the problems.

I like the framing of the broad concept of “user control” in this very Jobs-to-be-Done way. It’s almost like a safe word to watch out for. Whenever we catch our colleagues (or ourselves!) arguing for giving users more control over something, we should immediately stop ourselves and try to uncover what deeper need the discussion about control might be obfuscating.

Lenny Rachitsky starts off his article on A three-step framework for solving problems with a really good insight:

Though many factors contribute to a project’s failure, nothing is more certain to cause a project to fail than a misunderstanding of the problem you are solving.

He spends the rest of the article focusing on how to develop and rally around a good problem statement, which is an essential skill to have for any product manager. I really like this framework and am keen to try it on my next project, alongside a version of Marty Cagan’s Product Opportunity Assessment that we’ve adapted for our specific needs.

I’m a big fan of product discovery, and this extensive guide from Tim Herbig is a great resource:

The goal of this guide is to show you the extensive range a Product Discovery can have and how to set up and execute your own Product Discovery process. Which exact phases, tools, frameworks, and participants are needed depends on many individual aspects like the maturity of your product, which stakeholder environment you’re operating in, which resources you have at hand, etc.

I also like his definition a lot:

Product discovery is about ensuring that the right product gets built for the right audience. It’s the foundation for a successful implementation and launch phase later on and should give you the confidence to represent your product vision towards your team and stakeholders.

This is a guide I will return to again and again for inspiration.

Yana Welinder looks at different areas where PMs need to make sure we don’t let process get in the way of good product sense in her post Product Over Process. On the importance of making sure specs aren’t “set in stone”:

Focusing on product over process during the execution stage means constantly evaluating whether the product does what it’s intended to do. This requires PMs to see the product through the users’ eyes and, more importantly, to figure out ways to do user testing even when it’s hard. It also means that the build process needs to be iterative. If you discover that the product doesn’t have the impact you’d expected, you should change it before it reaches the users — even if that means delaying launch.

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.

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.

Product Management podcasts are a bit hit and miss, but this week there were two discussions that I found really interesting and useful.

First, on the Product Science Podcast, an interview with Teresa Torres on continuous product discovery:

Teresa Torres is a product discovery coach and the author of the Product Talk Blog. She spends most of her time coaching cross-functional product teams on how to adopt continuous discovery practices. On this episode of the Product Science Podcast, we get into how you can refine your product discovery practices.

And on the Product Experience Podcast, Tim Herbig discusses how to be an effective product leader when you don’t have “official” power:

Tim Herbig has made many mistakes (who hasn’t?). Fortunately for us, Tim not only owns up to his mistakes, he’s written a book to help the rest of us avoid making the same ones. We’ve all had issues with how to work best – not only within our individual teams, but with the rest of the organisation as well. In our conversation, he shares some simple and practical methods to diagnose when you have a problem and how to solve it.

Tim references Teresa’s work in his conversation, so the two episodes are really complementary as well, which is a nice bonus. Tim’s agile peer canvas to foster empathy within a team is also really interesting and worth looking into.