Need someone to lead product management at your software company? I build high-craft software and the teams that build it. I'm looking for my next opportunity. Check out my resume and get in touch.

This is the blog of Adam Kalsey. Unusual depth and complexity. Rich, full body with a hint of nutty earthiness.

Product Management

Domain expertise in Product Management

Freshness Warning
This blog post is over 4 years old. It's possible that the information you read below isn't current and the links no longer work.

Many software product management job advertisements request or require expertise in the problem domain the company competes in. With rare exceptions, a good product manager does not need to be an expert in the problem. Often, it’s detrimental for a product manager to be a domain expert.

Products are about solving problems for customers. When a product manager is a domain expert, it is hard for them to avoid injecting their own views and desires into the product. They act as if they were the customer and solve problems they imagine a customer might have instead of ones that the customer actually has.

What’s important is that a product manager possesses good technique. That they are able to execute a repeatable product discovery process. That they can analyze customer needs to identify problems that the customer needs solving. That they can use data to determine if the product is solving those problems for their customers. These are the skills and knowledge a product manager needs.

Hiring product managers based on their expertise with a specific market or customer type can lead to a product that’s led by the product manager’s understanding and biases instead of what the customer actually wants.

For this reason, we spend time coaching product managers to approach problems with a beginner’s mind. To discover what your customer needs you must throw out your notions of what problems exist or how to solve them.

It’s strange to ask someone to think with a beginner’s mind but also require them to come with expertise.

This isn’t to say a product manager should remain completely ignorant of the domain. A good product manager can learn what they need to know about the problem space in a few months. By interacting with your customers the product manager will continue to grow that knowledge over time.

This applies to customer types and markets as well. Managing consumer products isn’t a mystical thing that an enterprise software product manager can’t figure out. The tactics used to get product feedback can be different across customer segments. The go-to-market mechanisms will vary. But that’s also true of different market categories or geographies or buyer types or product stages. If a product manager can be effective with pricing strategies for a mid-market SaaS accounting product, they can design effective pricing for mobile games or enterprise healthcare or consumer finance tools.

Someone does not need to be a mother to build software products for moms. They need to know how to talk to moms and elicit problems from them.

What are the rare exceptions? If the problem domain has deep tribal knowledge that’s not expressed anywhere or requires extensive training to understand, a product manager won’t be able to learn enough fast enough to know if they understand the customer needs well. The quality of a product manager’s decisions will suffer. If there aren’t sufficient checks on those decisions, problems will arise. A product manager for firmware in implanted medical devices likely needs more than superficial medical knowledge. A product that manages compliance for a highly-regulated environment would benefit from someone that knows the laws well.

Another exception is the creation of a new product category. If you are solving problems that customers don’t know they have it’s hard to talk to customers about those problems. This is a much more rare state than most entrepreneurs and product people think it is. You probably aren’t Steve Jobs. Steve Jobs probably wasn’t Steve Jobs.

This all applies to software products only, since that’s what I know. Building performance racing carburetors for vintage motorcycles or designing complex financial investment vehicles might need domain expertise. Or might not. I have no idea.

When you’re hiring software product managers, hire for product management skills. Looking for domain experts will reduce the pool of people you can hire and might just be worse for your product.

Recently Written

Think Systems, not Symptoms
Dec 15: Piecemeal process creation frustrates teams and slows work. Stop patching problems and start solving systems. Adopting a systems thinking approach helps you design processes that are efficient, aligned with goals, and truly add value.
Your Policies Aren’t Your Culture
Dec 13: Policies guide behavior, but culture is the lived norms and values of your team. Policies reflect culture -- they don’t define it. Netflix’s parental leave shift didn’t change its culture of freedom and responsibility. It clarified how to live it.
Lighten Your Process Burden
Dec 7: Everyone hates oppressive processes, but somehow we keep managing to create them.
Product Add-Ons Are An Expansion Myth
Dec 1: Add-ons can enhance your product’s appeal but won’t drive significant market growth. To expand your customer base, focus on developing standalone products.
Protecting your Product Soul when the Same Product meets New People.
Nov 23: Expand into new markets while preserving your product’s core value. Discover how to adapt and grow without losing your product’s soul.
Building the Next Big Thing: A Framework for Your Second Product
Nov 19: You need a first product sooner than you think. Here's a framework for helping you identify a winner.
A Framework for Scaling product teams
Oct 9: The people, processes, and systems that make up a product organization change radically as you go through the stages of a company. This framework will guide that scaling.
My Networked Webcam Setup
Sep 25: A writeup of my network-powered conference call camera setup.

Older...

What I'm Reading