Product Mastery Now for Product Managers, Leaders, and Innovators

Product Mastery Now for Product Managers, Leaders, and Innovators


424: Lean product management - with Dan Olsen

February 19, 2023
How to achieve product-market fit – for product managers

Product Manager Interview - Dan OlsenThis episode is sponsored by PDMA, the Product Development and Management Association. PDMA is a global community of professional members whose skills, expertise and experience power the most recognized and respected innovative companies in the world. PDMA is also the longest-running professional association for product managers, leaders, and innovators, having started in 1976. I have enjoyed being a member of PDMA for more than a decade, finding their resources and network very valuable. Learn more about them at PDMA.org.


PDMA invited me to their conference, which was in Orlando, Florida, to interview some of their speakers. This speaker emceed the conference and presented on Lean Product Management: How to Achieve Product-Market Fit. Our guest will teach us a simple but effective process for creating successful products.


Dan Olsen is a returning guest to the podcast. He is a well-known product management trainer, consultant, and speaker. He is also the author of the bestselling product management book, The Lean Product Playbook. Through his talks and interactive training workshops, Dan helps companies build great products and strong product teams.


Summary of some concepts discussed for product managers
[3:38] What are the steps of the Lean Product Process?

The Product-Market Fit Pyramid is the key framework, and it has five layers that build on each other. Start at the bottom and work your way up:


Market:


1. Target customer


2. Underserved needs


Product:


3. Value proposition


4. Feature set


5. User experience (UX)


Write down your hypotheses in each layer then test the product with customers to see where you’re at with product-market fit. Iterate those assumptions and hypotheses until you get to the level of product-market fit you want or decide to pivot.



[8:38] How do we identify our target customer?

It’s important to start in the problem space. Get really clear on who has the problem, because those details will change how you solve it. Segment the market by:


  • Demographics (or firmographics for B2B). Usually demographics show correlation, not causality, but they’re a good starting point.
  • Attitudes: What do customers believe? What’s important to them? For example, how much do different segments care about the environment?
  • Behaviors: What are customers doing? For example, power users vs. lightweight users.
  • Needs: What are the different needs of different segments? This is the closest to causality.

Use all four ways of segmenting. To find out if your segments are clear enough, interview ten customers. If five of them love your prototype and five don’t, that’s a hint you haven’t segmented your market enough. What is the salient attribute you missed? Adding that attribute adds predictive power to your model.


The Lean Product Process helps teams get aligned. If we’re not aligned on the customer, of course we’re going to have disagreements about features and prioritization. Create a simple persona to get everybody on the same page.


[13:45] How do we discover underserved needs?

Find out why the problem is important to your customer. How is it going to create value for them? Don’t go rushing into the solution space without being clear on who your customer is and what problem you’re going to solve for them. People don’t want a quarter-inch drill; they want a quarter-inch hole.


A product manager’s main job is to define who our customer is and what their needs are. Map out a problem space definition. Brainstorm all the benefits you could address and organize them. Look for an unmet or underserved need. I use an importance vs. satisfaction framework to define how well-served or underserved each need is. How important is this need to the target market segment? And how satisfied are they with the current solution? If they have an important need and have not yet found a satisfactory solution, that’s where the opportunities are.


[18:18] How do we define our value proposition?

Out of all the benefits we brainstormed, what are we going to actually promise to customers? And what’s our plan for how to do it in a way that’s better than the competition? How are we going to deliver higher levels of satisfaction? I apply the Kano model, which is a categorization scheme for problems using three relevant categories:


  1. Performance benefits or features: You can plot this on a graph. The x-axis is how fully the products meets the need (from 0% to 100%), and the y-axis is how much customer satisfaction or dissatisfaction results. Usually you can quantify performance. For example, if we’re in the microprocessor chip business and everybody else’s chips are 2 GHz and ours is 3 GHz, we’re outperforming by 1 GHz.
  2. Must-haves: If your product fully meets the must-have needs, it doesn’t make customers happy. If you don’t have a must-have, customers won’t buy your product. For example, HIPAA is a must-have in health tech. It doesn’t make people excited, but you must have it.
  3. Delighters: The opposite of a must-have. If you don’t have a delighter, it doesn’t cause a problem because people aren’t expecting it. For example, yesterday at the conference, Hershey brought a huge table of chocolate. I was not expecting to get some yummy Reese’s peanut butter cups when I came to the PDMA conference, so I was delighted to have those.

We create a value prop grid where we list the performance benefits, must-haves, and delighters in rows and each of our competitors in columns. We do competitive analysis to see which areas each competitor is best at. Then we analyze our product. How are we going to be better? Which row are we going to dominate?


The next step is our feature set and MVP, so we need to be really clear on how we’re going to create more value. We make sure our MVP addresses those differentiating needs.


Once we’ve figured out how we’re going to be better or different, we need to figure out how to position and message our product. A great example is the iPod’s messaging—”a thousand songs in your pocket.”


[25:38] Tell us about the minimum viable product.

Now that we’ve got a solid grounding in the problem space, we need to brainstorm feature ideas for each value prop benefit. Break down your features into smaller feature chunks. Then do ROI analysis and create a roadmap. Create a MVP roadmap by listing the same benefits from the value prop grid—performance benefits, must-haves, and delighters. Then deploy the feature chunks by version in each category. For version 1, which chunks do we need to have in there? Usually you need the must-haves in version 1 and whatever special sauce your value prop is. You can build out your value prop over time.


This simple one-page roadmap visualization, anchored in your value prop, helps everybody understand what’s in scope and out of scope. The whole point of the MVP is to prevent over-scoping the product before you’ve confirmed whether you’re going in the right direction, but ironically one of the top mistakes teams make is over-scoping the MVP. By having that visualization, you can have those tough debates—do we really need this feature in version 1 or can it wait for version 1.1?


When I do this exercise, people get so fired up. They have pet features and are pounding the table saying, “We gotta have it!” I remind them, “Who’s the target customer?” The team members are not the target customer. In the absence of having a clear target customer, they advocate for their needs and their preferences.


When we’re talking about any feature idea, of course it’s a good idea. It’s going to create some value. The question is, which ones are going to create the most value for customers? We have limited resources and need to talk about the trade-offs.


People act like if they don’t get the feature in now, they never will. We can have a minimum viable feature. What absolutely needs to be in scope for a feature for this sprint? People act like if they don’t get their feature into this milestone, it’s never going to get built. There are places where that happens, but assuming it’s not happening, they’re delaying the whole project for one feature. You could launch on November 1st and then fast-follow with the extra feature on December 1st. Do you really want to delay the whole project a month for one feature? People don’t think about it that way. It gets emotional for people. A lot of it is not data-driven. It’s just following their gut and throwing spaghetti against the wall.


[34:16] Tell us more about the prototype.

In the previous step, the goal is to identify what functionality needs to be in the MVP and what can wait. At this point, you have no UX yet. The UX is in the solution space, and if you have a good design resource, they can help you explore the solution space and the UX. This can help you think of additional features or refine your features or problems. UX lets you show the product to a customer and get feedback, because no matter how good you are, nobody nails it the first time. Quickly get to the prototype so you can get it into customers’ hands. That’s when the real learning starts.


[36:52] What tips do you have for testing?

I’m a big fan of interactive prototypes. You can start off with hand sketches then use tools like Balsamiq, InVision, and Figma. Make a low-fidelity, interactive prototype of your MVP that you can show people and get feedback. Pattern-match the feedback. If you talk to ten people and eight of them can’t figure out how to get through the new user flow, you need to change something. Small sample sizes are okay. Some people are concerned about statistical significance, but if eight out of ten people can’t figure it out, you don’t need to test it with another 200 people.


Get better results by how you ask your questions. Don’t ask leading questions like, “That was easy to use, wasn’t it?” or closed-ended questions like, “Did you like that feature?” Ask open-ended questions like, “What did you think about that feature?” People tend to be nice and don’t want to point out problems, so tell them they’re helping you by finding the problems.


Action Guide: Put the information Dan shared into action now. Click here to download the Action Guide.



Useful links:

Thanks!

Thank you for taking the journey to product mastery and learning with me from the successes and failures of product innovators, managers, and developers. If you enjoyed the discussion, help out a fellow product manager by sharing it using the social media buttons you see below.