Philipp Krehl has a very thorough, practical article up on Mind the Product called Product Discovery or Product Delivery: How do you Decide? His main thesis is that figuring out when it’s safe to move to the build/delivery phase of a project is all about your level of certainty about the problem you’re solving. He proposes a simple rubric to calculate your comfort level with different product risks:

If you and your team have marked every answer a 3 or below, it confirms that you have a high degree of certainty about your path, and you can start building. You will probably still discover new information but you can just adapt to it — this is why we work with Agile methodologies like scrum or Kanban.

Answers marked with 4 or above indicate areas where you should invest and do product discovery to reduce your uncertainty. At this stage, it’s better to figure out the right thing to do rather than commit to an outcome.

Once you have identified areas which require more understanding you can use an effective technique called Assumption Mapping.

He also provides a good overview of the value and practical aspects of Assumption Mapping, a method I am keen to try out.

Shaun Juncal makes a compelling argument in Product Accessibility Shouldn’t Be an Afterthought:

But addressing accessibility early and often—if not making it an ongoing pillar of product quality—is a best practice every product team should embrace. Accessibility enables the maximum number of potential users to engage with products, increasing the total addressable market and avoiding frustrated customers from getting tripped up on accessibility shortcomings. […]

When a product doesn’t fully incorporate accessibility, the company is essentially telling a cohort of potential users that “this product isn’t for you.”

He shares some good advice on how to make accessibility efforts a natural part of the product development process.

Jase Clamp asks, What’s in the DNA of Product People? I especially like his depiction of the complementary forces of empathy and optimism.

This process of synthesis we call empathy. We all know that is what is needed to begin the job of product. But if it stopped there, we’d just be counselors, sitting with people, understanding their pain, and journeying with them.

We harness an opposing force that provides balance — it’s our ability, while reaching into the present to understand problems, to also reach into the future and feel what could be. As product people we often don’t know the exact shape a solution will take, but we have to believe that there is one and we’ll keep striving until we find it — which is an essential sense of optimism.

And on the topic of empathy… I shared this in the weekly newsletter, but I feel like I’m seeing a lot more articles on the importance of empathy in product management and design. One way I know this is that the blowback articles have started popping up as well (“6 Reasons Why Empathy Is A Bunch Of Crap!”). I recently came across this video from Brené Brown on the differences between sympathy and empathy. Even though on the surface it has nothing to do with technology work, it gave me a lot to think about in terms of how we interact with colleagues and customers. Check it out, it’s only 3 minutes long.

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.

Casey Winters takes the product/market fit model further in his post Feature/Product Fit:

Every product team tries to make their core product better over time. But sadly, at most companies, the process for this is launching new features and hoping or assuming they are useful to your existing customers. Companies don’t have a great rubric for understanding if that feature is actually valuable for the existing product. This process should be similar to finding product/market fit, but there are some differences. I call this process feature/product fit, and I’ll explain how to find it.

This is a great way to approach ongoing, consistent improvements to our products. Casey’s practical checklists and advice are worth reading and bookmarking.

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!