One thing I find very fascinating is that for a lot of startups there seems to be an almost inverse relationship between the energy put into acquiring and onboarding customers versus the energy put into keeping them as happy customers for the long term.
Of course most startups do customer satisfaction surveys, NPS scores etc, but how often do you actually reach out to some of your customers to engage in a real conversation about how it’s going, how they use your product and what challenges they are experiencing?
The challenge tends to become more complex the more you’re driven by SaaS-metrics like MRR and ARR. Yes, it is vital that you understand these, but what difference will it make, if in essence you have very little understanding of what is going on behind the scenes, in the heads and minds of your customers?
One of many reasons that Amazon has become so extremely successful over the years is that they have always been extremely customer obsessed. They have always been looking towards understanding the customer, the journey and experience better and better in order to develop their many offerings.
And they have been remarkably successful to say the least.
You will most probably not be the next Amazon, but that doesn’t mean you shouldn’t steal a page our of their playbook and become totally customer obsessed.
Lesson one in that course is to start treating an existing customer and the relationship you have and want to expand with that one over time with the same amount of energy, you put into acquiring new customers.
For quite a while I have been deeply fascinated with no-code platform Bubble. It’s immensely powerful in itself, and it allows no-coders like me the opportunity to dabble a bit into it and try to get an understanding for how code structure actually works.
But it also presents another huge advantage: An improved ability to understand and communicate with coders.
Here’s how I am trying to do it:
The Bubble editor contains a number of separate workstreams. Two of these are Data and Workflow.
Start with Data. Here you can define the properties that should go into your database, ie the different datapoints you would like to capture, store and manipulate as either part of a function of your service or the user itself.
You can essentially map out your business model here. Think about what you need to capture, and what you need to be able to do with it. And make sure that your database is structured based on it using telling labels etc.
When you have your database table in order, you move onto Workflow.
Here you can pick out individual labels from the database and basically do a IF THIS THEN THAT analysis on them and just map them out one by one. You can do this through fx a mindmap where you specify that when you’re looking at this function or feature, and a specific thing happens, the result should be something like this. And then repeat the process, until you have all aspects mapped out.
Using this approach you will end up with a serious of pretty well-structured maps that will illustrate your core functions and how they should operate and spelled out in a way that should make it easier for you to have the conversation with the coder(s) who are going to build something.
Because even if you can’t completely speak their language, you have at least made a real effort to try to bridge the gap – and all things considered you will be a lot closer to a fruitful dialogue.
You can have the best idea or the best product out there but still get a resounding ‘No’ from your stakeholders. When that happens it is always hugely frustrating, and it is only naturel to ponder what the heck went wrong.
But instead of guessing try to understand by getting into the decision makers head. Because often, the way that they respond has little to do with your actual idea and the context at hand but a lot to do with the mental model(s) they are operating from.
Sit down, have a good conversation and seek to understand what’s driving their decision. There are even guides for how you can do that. Doing that will give you an edge as preciously few other people bother to try to understand. But if you’re able to, chances are that the next time you will be able to navigate to a ‘Yes’.