The Product doesn’t have to be perfect, understanding its boundaries does.
Everyone should understand what the product does and, importantly, what it doesn’t do – from Product, through Sales, to Delivery, and then CS, no exemptions. But the impact of misunderstanding falls on the delivery teams and the client, and as a result on CS.
In a product-led SaaS company, your product must be fit for purpose but it will not cover everything that your clients want. I am intentionally writing ‘will not’, and not ‘may not’, I don’t know a situation where there are no gaps.
The reality is fairly clear, though not always simple – a SaaS solution may lead in some aspects, but will play catch-up in others. Define new ways of working, while responding to changing market conditions. Deliver new functionality, and then work to adjust it based on users’ feedback (and don’t get me started on MVPs that we never get back to…). And there will always be a backlog that the budget is just too short to cover.
This isn’t a problem, the problem is how some organisations accept and handle these gaps.
It gets complicated when sales are committing to clients to deliver open-ended capabilities such as 3rd party integrations – which 3rd parties, and what formats and connectivity protocols are really supported? Which of these will allow your platform to read and write, which limit you to read-only, and which ones will force you to extract in batches… boring stuff for sales, big headaches for the implementation teams.
- Worth checking if there is a well-documented availability/compatibility matrix, a 3rd parties connectors catalogue, and API documentation.
Missing functionality is also tricky – was it promised, or perceived by the client as promised because it’s a must-have for a product in this space? Is it required because the client works in a legitimate different way, or maybe the client’s use case is not supported out-of-the-box? Can the delivery teams bridge this gap / should they bridge it?
- Product documentation should cover some of this. Functionality that supports operations is usually neglected, it shouldn’t be. And a review and prioritisation process with the product and the implementations teams is necessary.
Knowledge of the product is yet another critical aspect – it allows the implementation teams to deliver a valuable solution with a non-perfect product. The teams on the ground can use their solution knowledge together with their business domain knowledge to help the client make decisions that are better for the long-term. Documentation will help, but more importantly, the knowledge of what is documented where, and the ability to refer to it quickly is as important in a rapidly changing environment.
- Ongoing training and mentoring for team members will do the trick. An organisational structure that brings product team members closer to delivery will help the client-facing teams, but will also add a lot of value to the product.
The Product is the way to make money in a SaaS company, but we need to get better at saying: here is the value, and this is as far as it goes.
~ It doesn’t make coffee ~