Tremis Skeete has a good write-up of a recent Marty Cagan talk in his post Product vs. Project Managers: Marty Cagan’s Twelve Best Lessons for Product Team Work. His four traits of a competent product manager is something most of us have probably read about before, but it’s a nice refresher. Especially the first two:

The first is a deep knowledge of the users and customers. This seems like a daunting task, but if a product manager just gets out of the office and talks to users and customers, they can easily acquire this deep knowledge.

The next thing a competent product manager needs to have is a deep knowledge of the data that customers generate. To achieve this, a product manager needs to utilize things like web analytics tools, sales analytics tools, and some form of data warehouse tool that shows how the data changes over time. “Most successful product managers begin their day with dedicated time with those tools so that they know how to answer questions that may come up throughout the day,” Marty says.

The article also provides a good overview of the differences between product discovery and product delivery, and why it’s so important to separate the two activities:

Product and project teams need to understand the difference between discovering a solution and delivering a solution; because by doing so they can work together to formulate strategies that complement each other.

I usually stay away from article titles like these, but I thoroughly enjoyed Chris Cannon’s What a Journalist Can Teach Lean Startups about Customer Interviews. If you talk to customers at all as part of your work, in any context, this is a goldmine of good advice:

Problems are stories — it’s a dull tale that has no conflict to resolve. The customer on the other side of that table is the protagonist in their own adventure. We’ve selected them as a persona that might be interested in casting us as their hero (or even in a supporting role that lets them be the hero of their own story).

So be accommodating: Engage the customer on their terms. Be perceptive: Listen for gaps in the customer’s story that might be worth investigating further. Be a listener: Only talk to make the customer comfortable or to dig for details. And then shut up.

Amen to that.

I really enjoyed Heart-Centered Innovation — a short, from-the-heart essay by Sari Harrison. She talks about how hard it is to see problems from a neutral point of view:

Most people have a center from which they see the problems around them. A sun that everything revolves around. This leaves it up to the person who has the problem to do a lot of filtering among solutions, often with no way of knowing which option is best.

What if we didn’t do that? Instead, looking at all possibilities for generating the outcome we are hoping for?

It’s a good reminder about the value of getting out of our own heads, and into those of our customers to make sure we understand problems and use cases from their point of view.

I always love reading about IDEO’s process. In his post To Transform Your Industry, Look at Someone Else’s Owen Sanderson explains the concept of analogous research: a form of exploration that takes a team outside of its industry to find inspiration in the ways others have tackled similar challenges. He explains how they took some hospital staff to an airport to observe the customer experience:

We started at check-in. The hospital team was issued mock boarding passes and asked to check-in for their upcoming flights. They had the option of using a kiosk, their phone, or speaking to a real, live person.

Almost immediately the team began to discover parallels between the patient experience and the traveler experience. The surgeons on the team quickly noted how many different pathways there were for customers—options for families, those with disabilities, and frequent fliers. “We only have one option for our patients, but patients aren’t all the same,” one surgeon said.

I’ve found this type of research useful for digital products outside the service industry as well. The field of architecture, for example, can teach us so much about things like designing for permanence. This article is a good reminder that as product managers we shouldn’t just look at our competitors for inspiration. We should also study products in industries that might not look anything like ours, but aim to solve similar problems than we do.

The Buzzfeed News article Behind Twitter’s Plan To Get People To Stop Yelling At Each Other is not the kind of thing I usually link to here, but I found it really fascinating from a product management perspective. Author Nicole Nguyen goes deep into the research and development process of the team responsible for “twttr” — an external, public prototype to experiment with new features. The sections that give us insight into the thinking of Sara Haider (Director of Product Management) and Lisa Ding (Senior Product Designer) are particularly interesting:

Haider and her twttr team are hoping to “nudge” people’s behavior in another way. Their hypothesis: Making the design for replies as minimal as possible, in addition to revealing how the conversation’s participants are related to you, may encourage people to read the entire back-and-forth before they react.

“We have this opportunity to learn about how not having likes and retweets could potentially change how people read things,” said senior product designer Lisa Ding. “Does it make you read something that you maybe would have guessed to be popular but actually isn’t that popular? How does that change the way you interact in a conversation? That’s super interesting.”

I also love Lisa’s sketches of the layout of twttr, and wish I could see more of that notebook!

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.

Shaun Juncal has a good overview of the importance of watching your churn numbers carefully in his post Churn: The Most Important Product Metric for SaaS. It’s especially important to figure out why people leave when they do:

But you can also learn something from that lost customer, namely why they left. Were they drawn to a competitor? Did the value your solution offered fade over time? Was a missing key feature causing them to bail out? Answering these questions can inform what should be done to retain your current stable of paying customers and attract new ones.

A simple churn number can’t tell you why someone leaves, so this is data that has to be collected qualitatively. But how? You don’t want to provide a negative user experience to customers on the way out, so putting a giant hurdle in front of them is not a good look. We solve this problem at Postmark by providing an optional text field on the page where you select your downgrade option:

I’m sure we would get more responses if we made this a required field, or turned it into a pop-up. But at what cost to negative perception would we do that? Following someone as they exit a store is creepy. Don’t be creepy.

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.