Need someone to lead product or development at your software company? I lead product and engineering teams and I'm looking for my next opportunity. Check out my resume and get in touch.

Domain expertise in Product Management

November 16, 2020

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.

Strategy Means Saying No

October 27, 2020

It’s not the notes you play, it’s the notes you don’t play. - Miles Davis

An oft-overlooked aspect of strategy is to define what you are not doing. There are lots of adjacent problems you can attack. Strategy means defining which ones you will ignore.

There are three types of opportunities you’ll come across. Those you’ve decided to tackle, those you’ve decided to ignore, and those you didn’t know existed. By defining which ones you’ll ignore alongside those you’ll tackle, you bring clarity to how you think about a problem.

I once worked with an executive that called himself an "and leader." When confronted with his organization asking if they should focus on this or that, he would proudly say yes to both.

This is a failure of leadership.

Anyone can say yes to everything. They don’t need a leader to do that for them. Thinking strategically means deciding what you’ll do. The list of things you’ll do is only meaningful if there’s a limit to the list.

Leaders communicate strategy by explaining what the organization is going to do, but often forget to communicate what they’ve chosen not to do. It is more effective to include negative choices when communicating strategy. It’s easier for people to understand the choices you made when you put them in the context of the choices of what to leave out. They’re two sides of the same coin. Communicate them as such.

By having a clear strategy that covers both what you’ll do and what you won’t do you’ll improve your organization’s ability to make decisions themselves and to execute.

An effective strategy acts as guide rails. If people know what to say no to, it’s clear whether you’ll pursue or evaluate a new opportunity that appears.

Understanding vision, strategy, and execution

October 24, 2020

What’s the relationship between a product vision, strategy, and execution? Vision is what you’re trying to do. Strategy is broad strokes on how you’ll get there. Execution is the tasks you complete to complete the strategy.

Read more »

How to advance your Product Market Fit KPI

October 21, 2020

Finding the gaps in your product that will unlock the next round of growth.

Once you’re tracking your product-market fit KPI and you understand why your biggest fans love you product, the next step to advancing your product is identify product improvements that will turn more people into fans.

Your best-fit customers are the ones that absolutely love your product and all like it for the same reasons. You asked your customers how disappointed they’d be if your product went away. The ones that would be extremely disappointed are your top customers. Then you asked what they like best about your product. The most similar answers are your top product attributes.

The people who identify the top product attributes as their favorite thing about the product are your ideal customers. Getting more of those requires that you expand the number of attributes that people love while expanding the group of customers that love them.

To expand these and advance your product-market fit, ask one more question. "How could we improve this product?"

Then ignore most of the answers.

It’s tempting to look at what the biggest fans are asking for and build those features. If you do this you’ll end up building things that the early adopters want instead of what the broader market wants. You’ll be improving the product for those that already are customers instead of making the product more attractive to people who aren’t already customers. You’ll expand the number of top attributes, but not the number of customers that love them.

Likewise, you should ignore the improvement ideas from people who say they wouldn’t be at all disappointed to lose your product. These people are far enough away from your target market that building for them will take your product off on a tangent.

The opportunity for product improvement lies in those end users that would only be somewhat disappointed if they couldn’t use your product. They like the product but could live without it. These users are telling you, "I really want to love your product, but..." If you want to make your product better, work to convert these users into your best fans.

You need to be careful, though. Changing the product to better cater to these users could move your product in a direction that’s less attractive to your existing customers. To increase your product-market fit, you need to make these people happier. But without moving the product away from the things that make your biggest fans happy.

The secret to doing this is to realize that not all your "almost fans" are the right market. The right market is the subset of these users are most like your ideal customer.

Look at the clusters of attributes your biggest fans loved most. Then find the almost-happy users that identified these same attributes as the best thing about your product. This is the cohort of users that like your product for the right reasons. Now, look at what they think would improve the product. Fix these things and you’ll move these customers into the raving fan category.

Take this cohort’s answers to "what could we improve" and cluster them. Find common requests. These requests are the gaps in your product that will unlock the next round of growth.

You asked, "How could we improve this product?" You ignored most of the answers. The only answers you’re listening to are from users who like but not love your product, like the same things as your top fans do, and are asking for the same things that others like them want. These users want to love your product and want to love it for the right reasons. They just need a little nudge.

Developer Relations as Developer Success

October 19, 2020

Most companies see Developer Relations as a marketing role. The job is to build awareness, recruit developers, and get product feedback.

Instead, the most important part of Developer Relations is to treat them like you do your Customer Success teams.

The primary role of your DevRel team is to enable customer outcomes. They are there to make the customer successful.

Creating developer tools, tutorials, and documentation are "one-to-many" enablers for customer outcomes. They are not targeted at a specific customer or specific outcome. These tools help developers discover self-success with your product.

One on one deep consulting with customers is another DevRel tool for customer success. By helping your customer understand what outcomes they are after and the best way to use your product to reach those, you’re enabling your customer to succeed.

Look at how you do customer success elsewhere in the company. What do you focus on? Onboarding? Adoption? Building competencies with your product? Do those same things as part of your developer relations.

Outreach, marketing, and developer evangelism are a part of Developer Relations. But the companies that are most successful with developers aren’t spending most of their time at events and doing content marketing. They’re spending most of their time making sure their developer customers are successful.

Developer Experience Principle 6: Easy to Maintain

October 17, 2020

Easy To Maintain To have a successful developer experience, developer products must be Easy to Maintain. Developer products have lots of things in the periphery. Documentation, SDKs, sample applications, and management tools. If you can’t easily maintain these, they’ll drift away from the APIs. The reality a developer is working with will be different from the reality you’re trying to create.

Read more »

Recently Written

Domain expertise in Product Management (Nov 16)
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.
Strategy Means Saying No (Oct 27)
An oft-overlooked aspect of strategy is to define what you are not doing. There are lots of adjacent problems you can attack. Strategy means defining which ones you will ignore.
Understanding vision, strategy, and execution (Oct 24)
Vision is what you're trying to do. Strategy is broad strokes on how you'll get there. Execution is the tasks you complete to complete the strategy.
How to advance your Product Market Fit KPI (Oct 21)
Finding the gaps in your product that will unlock the next round of growth.
Developer Relations as Developer Success (Oct 19)
Outreach, marketing, and developer evangelism are a part of Developer Relations. But the companies that are most successful with developers spend most of their time on something else.
Developer Experience Principle 6: Easy to Maintain (Oct 17)
Keeping your product Easy to Maintain will improve the lives of your team and your customers. It will help keep your docs up to date. Your SDKs and APIs will be released in sync. Your tooling and overall experience will shine.
Developer Experience Principle 5: Easy to Trust (Oct 9)
A developer building part of their business on your product needs to believe that you're going to do the right thing for them and their customers.
Developer Experience Principle 4: Easy to Get Help (Oct 8)
The faster you can unblock a stuck developer, the better their experience will be.

Older...

What I'm Reading

Contact

Adam Kalsey

+1 916 600 2497

Resume

Public Key

© 1999-2020 Adam Kalsey.