This post was originally published on Medium.
It is re-published here with minor edits.
One feature away from heaven
When building B2B products, you will see two types of SaaS customers: those who pay and those who “pray”.
Paying customers buy your product as is. They do ask for extra features, of course, but their requests usually make a solid business case. Praying customers, on the other hand, fail to adopt your product fully no matter how hard they try. To make it worse, they often have no better option, or can’t afford a custom solution, so they start praying to get a few extra features instead of switching services. Features, which will make their lives a little less painful. Or so they think.
Features which praying SaaS customers ask have no reason to exist in your product. And although you would never implement them, it’s worth taking a closer look at the stuff they hope to get. (More about this later.)
Fundamentally, though, both you and the praying customer end up in a business relationship that is too good to leave, and too bad to stay in.
Praying SaaS customers are tough to handle, and they can be toxic to your business. But not in the way you may think. Yes, they feed your Sales team red herrings about one feature that will definitely make everything perfect. (Hint: It never will.) And yes, they force your Support to entertain painfully long email threads about — that’s right! — one feature they really-really miss.
If your Product Team doesn’t handle requests from praying customers correctly, it will put your startup at risk of becoming nothing but a feature factory. Although your Engineering Team might have the capacity to be a feature factory and keep the crank turning, the reality is that VCs don’t invest in shoddy operations like that. They invest in businesses, and you ain’t got one.
But where do praying SaaS customers come from?
It’s all about value
SaaS companies usually focus on a single market central to their product, and then divide that market into segments. Here is how Geoffrey Moore defines the absence of a market: “If two people buy the same product for the same reason but have no way they could reference each other, they are not part of the same market.”
That formula is so beautiful, so deceptively simple, even the smartest people get it wrong. Let’s look at it again, now with highlights: “If two people buy the same product for the same reason but have no way they could reference each other, they are not part of the same market.”
Moore’s definition is as brilliant as it is confusing because we instinctively focus on how connected agents in the market are, and not on what they do or what it means for them to actually operate in the market.
The truth is, connectivity nowadays is no longer the key feature of any digitals goods market. Distribution of SaaS products doesn’t follow the rules of a conventional supply chain, which makes connectivity irrelevant. In the reality of the 21st century Internet, markets and their segments are defined by how customers apply your product to create value in their businesses and for their own customers.
This means, two SaaS customers belong to the same market if and only if they use your product to serve their customers in a similar way.
This, by the way, is a central point of a so-called Service-Dominant Logic. A paper that started that economic and marketing paradigm has already been cited over 9k times, so it’s worth checking. Go read up on that. Thank me later.
Just can’t get enough [of sweet new features]
Not all feature requests are bad, and not all customers who ask for improvements mean trouble. In fact, most will simply ask for stuff which you’ll ship sooner or later anyway. Typically, product managers analyze and group such missing features to find which business processes within the customers’ organizations they fit, then add them to a product roadmap after prioritization.
Once in a while, though, you’ll see a feature request that doesn’t fit into any known business practice among customers in any of your market segments. At first glance, such request won’t make sense, which is why many would reject it with little to no research. In fact, conventional product practice encourages that: say “No”, ignore the noise, focus on your niche.
But in this case, following a well-established practice might mean digging your own grave. Don’t do that! It’s best to treat such outlier request as a regular one, and do your research. This is because an outlier request often means one of two things:
< 1 > You accidentally captured a customer from a different market
If you often capture customers from the wrong market, this means you’ve got a product marketing or sales problem. You may want to drill into that to understand why your messaging and positioning attract businesses who aren’t fit for your product.
Whatever the reason for their presence in your customer base, praying customers offer a unique opportunity to learn more about the markets you didn’t even know existed or have never considered viable.
< 2 > Your old SaaS customers are creating value in new ways
Markets evolve, and so do businesses operating in them. Your customer might be an early adopter of a new business practice, and this drives them to demand additional functionality from your product. More customers like this will appear eventually, and if you don’t act fast, your competition sure as hell will.
The most tricky thing here is to capture the trend and figure out whether any of your other customers are changing their practices in a similar way. Tools like Receptive.io can help with this. (All in all, though, this is a massive topic that needs its own series of posts.)
Let them go, but learn from them first
Whether or not you’re dealing with the paying customer whose business is changing, or with a praying customer who shouldn’t be using your product, refusing their feature requests means seeing them go sooner or later. Satisfying them prematurely means turning your product into a bloatware, or even becoming a feature factory.
If as a founder or product manager you are building a business and not just shipping features, you may need to let them go. But before you do that, remember to map outlier feature requests and understand why they happen. Chances are, you’ll learn a ton about the industries and markets you serve, and about your own business. Even if you lose a customer, this research is likely to expose realities you didn’t know existed and even create new business opportunities in the future.