Escaping the B2B SaaS rat race
How to stop running behind clients and start focusing on the product
In the B2B SaaS world, this is usually how startups are born:
- You start with an MVP.
- Company X finds your product interesting, but they need more features to adapt it to their business. They’re willing to finance the development of those features, and you accept.
- The features are now part of your product, and you can use them to pitch to prospective clients. Other big clients will finance more features, and the cycle repeats.
The above pattern is pretty normal, and it’s acceptable as long as it keeps the startup from going bankrupt. However, once the startup reaches a certain level of maturity, this pattern can lead to feature-bloated products.
Clients will keep disrupting whatever roadmap you have for your product. That’s why you need to get rid of old habits and learn to say no.
Don’t wait for clients to ask
If you’re a B2B startup, chances are your product addresses a very niche set of problems. There just isn’t enough data to make informed decisions, and that’s why you need to rely more on qualitative research.
Design thinking is really about empathizing first. Unless you talk to clients (or whoever is going to use your product) and understand their problem space, you’ll always be one step behind. Instead of waiting for clients to come to you with a new feature request, you can go to them and ask them first. You can set up an interview with a contact person at the client company and dissect their business problems to really understand their point of view.
Stop building features for one client
This one’s usually the first step to be adopted. It’s important to take the client’s needs into consideration, but unless your company’s future depends on that client, always make sure that the problem you’re solving is common to more than one company.
Think about this: if clients stick with you, it’s either because you address all of their requests, or because your product is reliable and high quality. What would you rather the reason to be? (hint: because your product is reliable and high quality)
Cheap clients are the ones that are going to ask the world for free. Clients that recognize quality are willing to pay for it, and they understand that it’s not just about putting their logo everywhere.
Split client success and product
In some companies, Product Managers are in contact with clients. The person that takes decisions on the product should not be regularly in touch with clients. Reasons being:
- There just isn’t enough time in a week to handle both clients and the product.
- The person that is in touch with clients will feel the pressure to comply with their requests. That pressure should not influence product decisions. In short, it’s easier to say no if you‘re not the one actually saying it to the client.
Don’t spread yourself too thin
The temptation when getting feature requests is to commit to all of them: if clients are willing to pay for the development, that will make your product more complete and you will be able to leverage those features when pitching the next client.
However, you should refrain from taking on too many requests — and one could argue you shouldn’t take on any request whatsoever. The reason is you can’t possibly deliver a high-quality product if you do it. Clients shouldn’t be the ones to dictate your product map.
You should establish the direction you want to take with your product strategically, and that depends not only on what your customers want but also on your threats and opportunities.
Find a balance
There are many reasons why you might not be able to follow the above points. Maybe you’re not in the financial position to say no to clients. Or maybe your client base is so niched that you must hear what those few clients have to say.
However, I think there comes a point for startups in every industry where this approach starts to have a lower and lower return on investment. A product that does one job well will have a longer life than a product with hundreds of half-baked features.
Don’t take client’s requests as problems to fix per se, but rather as symptoms of a problem. Your job is to find out what the real problem is and how you can solve it in a way that fits with your product strategy.
