I love sending release emails. After all, there isn’t a single product manager who doesn’t look forward to writing and hitting send on these emails. These emails celebrate the result of months of effort, negotiation, and teamwork – and you want the entire company to know that your product is finally out.
Soon the adoption data starts coming in – one week out: zero adoption. We tell ourselves that it’s just a slow start – the feature is good, customers will soon adopt it. One month out: a handful of clicks. A quarter out and it doesn’t look good. We then dive into root causing mode, trying to find answers to why adoption is low. At the end of it, a hard truth hits us – we didn’t build our feature to solve the problem of our foothold customer, many time we realize that we aren’t even sure who our foothold customer is. n n As Product Managers, we often fall into the ‘Ship and Pray’ fallacy. We assume that because a stakeholder asked for it, or because a competitor has it, our customers must want it. But the hardest truth in product management is this: customers don’t want features, instead they want someone to solve their problems.
Who is a foothold customer?
A foothold customer is a specific, real-world persona —or a small cohort of them—whose pain is so acute that they are willing to partner with you on an unfinished, unpolished solution. They aren’t looking for a perfect product; they are looking for a lifeline.
Why is it hard to identify a foothold customer?
As product managers, we spend a lot of time talking to customers. We ask questions to understand workflows, identify problems and discuss potential solutions. Over time, we build great relationships with a set of customers, and we default to these customers every time we have a question or an idea. However, in many cases, these familiar customers may not be our foothold customers. While they may experience some part of the problem we are trying to solve, they will never be the primary users of our solution.
One of my biggest product failures happened because I did not identify the foothold customer. We were building a feature that we thought was game changing. The expected savings from this product were calculated to be in the millions for the healthcare industry. Everyone was excited – we spent months prototyping and validating with customers, and built a solution that they loved. However, there was one big problem – the personas we spoke to were never going to be the key users of our solution. In case any of you are wondering what happened to that project, it didn’t even make it to release. After spending over a year on development, we realized that our solution did not have legs and the project was shelved.
Another reason why identifying foothold customers is becoming harder is because of our overreliance on AI agents to provide answers. Talking to customers is time-consuming – we need to ask the right questions, synthesize insights and ensure our insights are statistically significant. As a result, PMs are beginning to increasingly rely on AI generated insights, rather than gathering feedback from actual customer conversations. A good product manager knows that while AI can give a wealth of information is a few minutes, AI cannot replace feedback and learnings derived from talking to flesh and blood customers.
Why is finding the foothold customer important?
Foothold customers define the constraints and scope of the solution we are building:
- They define the MVP: They help us understand the problems that truly need to be solved and the features that will solve them
- They provide the vocabulary: They tell us how they describe the problem, which allows us to communicate using a shared language
- They are our North Star: They help us decide what features truly matter to solve the problem. In a project where I have competing priorities and need to decide on MVP, I ask myself: ‘Which of these features will help my foothold customer succeed today?’
Affirmation versus Validation
Affirmation is when a customer says, ‘Yeah, Susan, that sounds like a great idea! We’d totally use that.’ They’re being nice and giving you a false positive because it costs them nothing to say ‘yes’. It’s not just our customers who do this; we also do the same thing in our daily lives. I’ve lost count of the number of surveys I’ve answered in which I’ve said yes to things I would never actually buy or use.
Validation is when that customer gives you something of value before the product is even built. In B2B, that value is usually time, data, or access.
Time: They agree to meet with you every Tuesday for 30 minutes to look at wireframes.
Data: They give you access to their messy, real-world datasets so you can test your logic.
Access: They let you sit behind their employees and watch them work. Access is a great indicator of how easy adoption will be. If a customer has too many legal processes and hoops to just go and visit them, then you can bet that adoption will be challenging.
I once worked on a project where we spent 6 months trying to work through the legal requirements to deploy and test a prototype we had built along with the customer. In the end, we abandoned the project because we realized that if legal would not allow us to test a prototype under controlled conditions, a full implementation of the solution would be an uphill battle.
If a customer won’t give you 30 minutes of their time to talk about the problem, they will never give you 30 minutes of their time to use the solution. Securing this buy-in early is your insurance policy against building a product that struggles to gain adoption.
User versus Buyer – who is more important?
Throughout my career, I’ve learned that the end user is often different from the buyer. In B2B environments especially, the person writing the check is rarely the person clicking the buttons.
But here’s the issue – if you only validate your solution with the buyer, you’ll have poor adoption because the users may not find your solution useful. I’m sure we can all think of examples of applications we use at our workplaces that we do not like and grumble every time we are forced to use it.
After all, you must validate with the people who will actually live in your software. So does that mean you only focus on the user and forget about the buyer? Of course not! Your solution needs to solve problems for the user, but it must also have a compelling value proposition for the buyer. If the buyer does not care about the solution, they won’t pay for it.
Final Thought
When you focus on the human being at the other end of the screen, the features take care of themselves. I want to challenge you: tomorrow morning, look at the top three items on your roadmap. Ask yourself: who is the specific customer that is waiting for this, and have I seen them struggle with the problem this is supposed to solve? If the answer is no, it’s time to step away from the keyboard and find your foothold.