Kwan’s Product Process for continuous Product-Market Fit
Kwan’s Product Process for continuous Product-Market Fit
Imagine your team on a bus. You tell them to drive to the top of the highest mountain in the land. And they set out to get there. Except in this special bus, the driver doesn’t do all the work. The entire team has to come together to navigate and arrive at the destination together.
The bus represents your product management process
Imagine your team on a bus. You tell them to drive to the top of the highest mountain in the land. And they set out to get there. Except in this special bus, the driver doesn’t do all the work. The entire team has to come together to navigate and arrive at the destination together.
The bus represents your product management process
The Tour Bus
Perhaps your process is like a tour bus.
Tall, luxury row seats mean each team member can only see out their own window. Cushy, reclining seats mean your team is not motivated to change seats to get a different vantage point. Curtains on the windows mean some team members can opt-out of helping with navigation entirely. On such a bus, you often see a driver driving solo, long into the night.
The City Bus
Perhaps your process is like a city bus.
Standing room in the front make it easy for your team to talk to each other. With large windows, your team can easily see out the sides, helping with navigation. With lots of hand-holds, your team can walk around on the moving bus. With such mobility, it’s not unreasonable for your team to take turns at the wheel.
Just as the design of the bus influences how the team interacts and executes, so does your product management process. With a great product management process, you can have sales, marketing, design, product, and engineering working together to reach the highest mountain in the land. Without it, they might just leave it all up to the driver.
What is a bad product management process?
The difference between a winning and losing product is the product process behind it. Are you listening to the right audience? Are you digesting the insights well? Are you building the right stuff?
A bad product process is ad-hoc. Decision pathways are unclear. Members do not buy-in to the path forward. The majority of what gets built needs to get thrown out. Or worse. Nothing ever gets thrown out and your engineering team is maintaining a bohemeth of a product.
What is a great product management process?
A great product process keeps the team running smoothly. Research is intentional. Listening to customers occur continuously. There's open collaboration, testing, and feedback. A great product process keeps your product in continuous product-market fit.
Kwan’s Process for Continuous Product-market Fit.
There are 6 steps to achieving continuous product-market fit:
1: Listen
2: Digest
3: Prioritize
4: Build
5: Ship
6: Validate
These steps work together, it’s not a linear process but a circular one. For example, your team may complete step 3: Prioritize, and move into 4: Build. But as your team builds they realize that the project will take a lot longer than previously estimated. A great product management process would enable the team to quickly go back to 3: Prioritize, and make a call about whether to move forward with the new estimation or build something else.
43Step 6: Validate loops back to 1: Listen again. They’re intimately connected and keep your product in continuous product-market fit. The links between parts are just as important.
Let’s talk about how to set up each part of your product management process to drive product-market fit.
1: Listen to your customers
Listening to your customers allows you to gather a diverse and weighted set of inputs. The worst thing you can do is start building without knowing where you're going. That’s why these inputs need to be chosen intentionally because it will guide the bus.
The steps are simple:
Choose your target audience
Line up a way to listen to that audience
Collect the data
The nuances of each step may be difficult.
a. Choose your target audience
Choosing a target audience is relatively simple for a mature product, but may be the hardest step for a new product. Nonetheless, it’s necessary to narrow it down. If you need an example, here are Product Maestro’s two target audiences for the storytelling class: “Mid-career Product Managers ready to step up and influence through storytelling,” and “Seed-stage startup founders in tech, who need storytelling to fundraise, recruit their team and set product vision.”
Be careful about the ‘squeaky wheel gets the grease’ effect. Some of your most vocal customers may not represent the majority.
b. Set up a way to listen to your audience
Lining up a way to listen is relatively easy to accomplish. But it gets complicated quickly. There is a litany of products to help you with this task. You might choose to listen through customer interviews, customer surveys, or looking at product usage analytics. In fact, you need to choose multiple ways. This way you are listening to what your customers say and also what they do. Here are a handful of different tool examples that set up different listening pathways for you:
UserVoice - feature voting
Happy or Not - point of sale feedback
Intercom - customer support
GetFeedback - NPS tracking
Pendo, Mixpanel - product analytics
UserTesting - Set up interviews with potential customers
C. Collect the data
Now do the work and collect the data. Here are some of the tools you’ll use for collecting the data:
Jotform - survey creation
Figma, Invision - mockup creation and feedback, user journey mapping
Spreadsheet, Confluence, Notion - to organize the input and take interview notes
These are the specialists who can help you with data gathering:
UX Researcher
Product Manager
Sales account managers
Business development
Marketing
2: Digest your data and sort signal from noise
This is the messy middle, where data turns into opinions.
You want to avoid this. How?
By setting up a system for how to digest the data ahead of time.
This is a tricky part. Because you don’t want to lead the data by making assumptions before you look at the data. You want to walk in with a structure for digesting the data before opinions take over.
Stay objective.
That’s the goal of the product process in this step.
When I was at Atlassian, we sorted NPS responses by the issues the customers were commenting on. First, they set up a table of categories they care about like the one below. Then each mention merits a point.
This is a great structure. Even if you don’t know the categories yet, you have a category column. That’s good grounds for debating the relevant categories and digging into the data while staying objective.
During this step, you start drawing patterns. Ideally, you walk away with an idea of the top 10 areas to address. We will then further dig into these areas in the next step.
Some of the tools you might use:
Dragonboat, Productboard, Aha - to organize the input and feature requests
Gooddata, Pendo - to find patterns in the data
Story Mapping, Service Blueprint - to visualize the user journey
This is what you hire a Product Manager for, right?
Companies that don’t have a PM often prioritize with these techniques:
CEO’s Gut reactions
The loudest voice in the room
The highest single feature ROI - x will pay us y to build z. Let’s do it.
Sometimes companies with PMs also do this. Since you’re reading this post, I’m guessing that the above techniques don't serve you anymore.
So how do product managers prioritize? There are a million ways to do it. None of them are perfect. But all of them fall into this pattern:
Set the product vision
Choose themes toward that vision
List and score product features by ROI
a. Set the product vision
Features are personal to people. Every single feature reflects someone’s hard work and opinion. Joey, the UX designer, spent weeks tweaking the onboarding flow. Only 20% of the improvements got shipped last time, so he wants to see the rest built. Sue, the engineer, heard about bad load times, and she’s super passionate about migrating databases to fix it.
If the team doesn’t agree on the big picture, then they certainly won’t agree on a single feature.
That’s why your product manager’s storytelling ability is such an important asset. No product vision results in dissent in the team. Or worse, incoherent parts of products getting built.
b. Choose themes toward that vision
Themes are groups of features that align with a company goal, product vision, or overall strategy. This way you work on features that are most important right now.
Decision paralysis can happen even if you’re all agreed on a shared vision. A vision is too big to build in one quarter, one sprint. That’s why we choose themes. Those are smaller chunks of the vision.
In the previous step 2: Digest, you identified 10 areas to address. We can use that now. In this step, filter the themes that fit your product vision, then prioritize those themes.
For example:
The vision can be “make customers feel awesome.”
The theme can be “reduce onboarding time,” because in the ‘Listen’ step customers say that the onboarding process leaves them feeling confused.
For the team, your chosen themes specify the portion of your vision to spend your focus.
c. List and score product features by ROI
At this point, you have a product vision, 3 to 5 themes, and 5 to 15 features under each theme. Maybe that’s enough for you to do prioritization. If you have tens of thousands of feature requests in your backlog, you might want to get a bit more systematic and scientific. How?
You can implement a scoring system.
There are many ROI calculators to choose from. All of them balance effort with payoff. Here are some options:
Kano Model - what brings customer delight?
RICE - what brings the best payoff?
MosCow - what’s actually do-able?
Value versus Complexity Quadrant
Weighted Scoring - custom table
Buy a Feature
Opportunity Scoring
Prioritize with scoring is a great system but there are a few things to watch out for:
The effort scores tend to stay valid over time, but payoff scores tend to get stale quickly. If 80% of the users are asking for button A on screen 1, then screen 1 gets deprecated, the feature is no longer high payoff.
High-risk bets are not apples to apples with low-risk bets. There’s a tendency to attempt to score everything on the same scale. But you have high-risk bets with uncertain payoffs, like AirBnB adding Experiences. And you have low-risk bets with predictable payoffs, like AirBnB adding a $100 credit promotion for new guests. optimizing the onboarding flow for new customers. If we followed the scoring system exactly, all high-priority bets tend to be low-risk bets. A balance of the two is necessary if you want your product to stay relevant in your industry. And that may mean deviating from the scoring system for high-risk projects.
4: Build
Now it’s time to build. Build culture depends on the release cadence of the teams. Most software teams have 1-6 week release sprints. Modern, collaborative tools have replaced lengthy product specifications. Most teams make use of tools like these to communicate user stories and feature intent:
Jira - for writing user stories tracking development status
Figma - for design mockups
Github - for code repository
Launchdarkly - for feature flagging
Shorter release cycles are better for efficiency from a product-testing standpoint. So the more you can chunk down a feature and release over time, the faster you can get feedback to see if that feature is on the correct side of product-market fit.
But some features may lose value if it’s cut down too small, or a project simply takes a long time technically, such as migrating a database. So those tradeoffs must be taken. By having your team work closely together, you can continue to refine the release cadence that is most suitable for your product.
The important thing to remember is that there is no perfect length for sprints. There is a perfect fit though, and it highly depends on the type of product you have, the attributes of your tech stack and code, and the comfort level of your customers in accepting product changes. That’s why great teams set up check-in habits such as retrospectives to continuously update each other. Just as you are seeking continuous product-market fit, your team is seeking continuous process-team fit as well.
Your team here consists of:
Engineers
Designers
Product Manager
Scrum master
5: Ship the feature
To build a great product process that achieves a continuous product market, you’d want to make sure that everything you ship is hooked up to analytics. Tools like Pendo and Mixpanel lets you track user actions on your new feature. Feature flagging tools like Launchdarkly let you release the feature to a selection of customers.
Common Tools:
Github - code repository
Launchdarkly - feature flagging
Circle CI - automated testing and deployment
OpsGenie - on-call and alerts management
A great product process is set up to have control over who sees your new feature. This is important to ensure you can do a limited release to a subset of customers. Why? So that you can test out a feature at lower risk, see the adoption, before releasing it more broadly. Killing features is necessary but erodes customer trust, so you don’t want to do it too often. If you release to 1000 people instead of 100,000 people first, then if you need to pull back it will be less painful.
At this stage your team is primarily:
Engineering
Product Manager
Marketing
Not all feature launches require marketing. You can set up an understanding of tier 1, 2, 3 launches, each of which requires a different level of marketing involvement. For example, a minor patch would be a tier 3 release, a new product line would be a tier 1 release.
6: Validate with user feedback
This is the most important and most overlooked step of the product process. There is a tendency to ship and forget. There are 3 reasons for this:
It takes time to see the results, and we forget.
The results are never black and white.
The results may lead to difficult decisions.
But to overlook this step is to shoot yourself in the foot. All the work done prior to this definitely gets you closer to product-market fit, but this is one lever that helps your team:
Learn from mistakes.
Kill zombie features
It’s obvious why learning from mistakes is helpful. How customers use a feature may not be how you envisioned it. To see usage patterns helps improve the feature. But more importantly, it shows you new custom pain to be addressed that may become entirely new product lines for you.
Killing zombie features is important because it simplifies your product, creating less cognitive overhead for your users, but also lowers maintenance overhead for engineering and support.
These tools have been mentioned throughout because they need to be set up early so that you can have the data to look at later. Your analytic tools are:
Pendo, Mixpanel - product analytics
Launchdarkly - feature flagging
Intercom - customer support
GetFeedback - NPS tracking
Setting up product management process for success
Your product process is only as strong as the weakest link. So it’s important to pay attention to where the weakest links are, and elevate the standards of all links together to hone your product process.
These are common tools used by great product companies:
Slack - for chat and fast communication
Confluence - for meeting notes, longer documentation, and logging decisions
Great communication habits unpin the success of your product process and are worth paying attention to.
Now that Kwan's product management process has given you all the steps, you have all you need to drive continuous product-market fit. I wish you and your team much success at reaching the highest mountain in the land.
Are you a product leader implementing a new product process? Storytelling and influence skills are vital to creating organizational change. If you're ready to take control of your career, check out my Storytelling for Product Leaders course.
As a mother and an entrepreneur, my mind fills with worry. This is a story about a structured story technique I use to manage worry.
It didn’t used to worry like this.
I remember that in my 20s I was much more carefree.
Healthcare is on the precipice of transformative change. While Artificial Intelligence (AI) has been making headway for some time now, a particularly promising subfield - Generative AI, also known as Large Language Models (LLMs), such as OpenAI's GPT-3 or its latest GPT-4, is beginning to leave a profound mark with deep implications for Healthcare. Product Management teams operating in healthcare can leverage these technologies to advance the industry.Healthcare product management is a subset of product management. And as such, there are general principles that guide useful application of Generative AI. Here we will review those first. Then hone in on healthcare more specifically.
Made with Bullet