We interviewed the plant manager and he said that they didn’t have any problems with scale, but we know that they do!
That’s what a team working on anti-scaling technology reported back early in the Lean LaunchPad process. This statement illustrates several of the common issues that we run into doing LLP.
The first issue is that the customer development process is different in business-to-business settings than it is when we’re targeting end users.
My response to the team was: “There’s not a plant manager in the world that has scaling problems, but there are plenty of production engineers that do.”
It’s harder to identify customer needs (and pain) inside of a business, because there are lots of different agendas in play. People often aim high in an organisation’s hierarchy for their customer development interviews, but this isn’t always smart. We have to get to the people that have the direct experience with the problem that we’re trying to solve.
If we’re selling into an industrial plant, there are many people with an interest: plant operators, production engineers, process managers, finance people, upper management. All of them have different, sometimes competing, needs. We need to understand the needs of all of these people.
For customer development, we need to start with the people most directly interested in the problems we’re trying to solve.
The second issue is that our initial hypothesised customer segments are almost always too broad. This team started out with a target market of ‘mineral processing plants.’ Too broad.
One crucial sign that we need to sharpen your target segment is when we talk to people that seem similar, but their responses are completely different. This is very common at the start of customer development, and it’s one of the reasons that our confusion level increases when we start the process.
When this happens, we must pay attention, because it means that we’ve just found a way to segment the market. Conflicting feedback means that the people we’re talking to are different in some important way, and we have to figure out what that is.
When you identify people with common problems, then you are zeroing in your target segment.
The third issue is that people that are actively trying to solve their problem are our early adopters.
What’s the hardest part about [problem context] ?
Can you tell me about the last time that happened?
Why was that hard?
What, if anything, have you done to solve that problem?
What don’t you love about the solutions you’ve tried?
Questions like this are great both for learning about the problems that we’re trying to address, but also for finding early adopters.
For our scale prevention team, the plant manager is not an early adopter – there’s no pain there at all.
The team eventually ran into two bunches of people with more promise. The first were production engineers that had scale problems, and had built redundant processing lines to deal with it. This is an expensive way to deal with the problem, but it reduces the immediate pain level. Also not early adopters.
The second bunch was in a different type of processing plant, where scale problems meant they had to shut down the production line. These guys have an immediate, expensive problem, and they’re actively trying to solve the problem. They’re our early adopters.
So after about 50 customer development interviews, the team was able to say:
Our first customers will be plants processing Mineral X, where the incoming water quality is poor [which leads to specific regions in Australia], and where they have to stop production to descale.
Because this group has an urgent, expensive problem, they are much more willing to try new things. And the new things don’t have to be perfect – they’ll be more willing to experiment with a prototype rather than a fully-developed product.
The guys with the redundant processing lines are still prospects, but they look like this:
Later customers will be plants being built to process Mineral Y.
That’s also a pretty specific group. In order to be comfortable saving money by not building redundant lines, they will have to be very confident in the new anti-scaling process. So they can only be approached once there is a solid track record in place.
Customer development is trickier when we’re trying to learn about businesses. It’s also trickier when we can’t just build anything that people want, which is the case for people doing scientific research. But the risk is also higher in both of these situations, which means that we need to do customer development to make sure we’re creating real value by solving real problems.
Note: Over the past year, I’ve been running (with help, of course!) a bunch of Lean LaunchPad programs with the Commonwealth Science and Industrial Research Organisation (CSIRO) aimed at increasing the impact of all the great research that they’re doing. This is part of a series reflecting on what we’ve learned through the course of six programs involving 40 research projects and more than 250 people. The other posts are:
- Part one: The How and Why of Customer Development
- Part two: Is Our Business Model Ready to Launch?
- Part three: How Big is Your Market and Where Will You Start?
- Part four: What Assumptions Underlie Your Business?
- Part five: A Minimum Viable Product is an Object for Learning
- Part six: Move Sooner and Faster Than You Think You Can
- Part seven: How to Find Your First Customers
- Part eight: How to Make Good Lean Startup Hypotheses