Selling Software
In marketing there are two ways to increase ROI. Your input is cash. It pays for time and materials to create a product.
- Sell more of it
- Increase the profit on it
In software, the input is cash. It pays for people's time to create a solution.
To increase ROI, we can
- Sell more of it
- Increase the profit on it
Sell more of it
In order for selling more products to make sense we need raw materials and have the ability to scale up production. This means supply chains and factories.
For software we worry about the amount of money and effort required to maintain a customer. As an example, for a product we might have £10 of raw materials. For a software solution we might have £10 of server bills per customer.
There are of course differences in things like subscription models that complicate both physical and digital delivery, so we will neatly skip over these problems for this example.
Assuming both can scale, and that software can be delivered without expensive humans to back it up then software has a clear advantage. It is usually orders of magnitude cheaper to deliver per customer than physical items.
Things that stop scalability in software are surprisingly common and block true growth of a SaaS solution. Though not the focus here, this is a non-exhaustive list of things that hamper scalability.
- Reliance on humans for part of the service or process
- A complex schema, unwieldy setup or badly thought-out data set.
- Humans being required to on board the customer into the system
- And off board them...
- The requirements for humans to get involved with upgrades to plans and upgrades
- A coupled monolithic platform hindering fast deployment cadence
- The five thieves of time occupying your development team with something that isn't customer value streams.
- And many more...
What can we do?
It is rarely the case that the development team, no matter how green, is responsible for the lack of profitability in a digital business. More often than not the business itself has a problem with the way it requests value on behalf of the customer.
To correctly have a team build a solution, it's makes logical sense that we understand the problem first. Without this understanding we are guessing. These guesses are often the imagination of a development team in the dark, or an assumption from an analyst trying their best to fill in the blanks from a lack of customer research.
In marketing we have methods of finding out what the customer needs. Usually by feedback, either direct or implied from behaviours. Since money is involved in sales and it is easier to understand for the layperson, we can usually calculate the profit, but for software how do we measure value?
Simplified, we measure value in customer satisfaction. This usually leads to an uptick in customer numbers or an increase in add on sales, or both.
Sales are not something to chase, more, making sure the customer needs are met and they can easily justify the amount of money they spend for your offering. Ask yourself, what can I do to make the customer see my offering as more valuable?
Increase the profit
So generally, we need to do some basic discovery and then choose an action
- We need to look at our offering and choose a pain point for the customer.
- We need to see how we can make this pain go away
- We need to start development, and incrementally move towards fixing the customers problem, one small step at a time
- Constantly gather feedback, both direct and inferred.
- When this problem is solved move onto the next, rinse and repeat
Though this seems simple, many companies simply miss the boat here. Their efforts are concerned around perceived problems without consulting the user or looking at their journey at all. Assumptions are made about what the customer might want, a sort of random shot in the dark.
🎙️ Lee here. Sometimes in a target rich environment this can yield results. Sometimes we develop features through guesswork and gut feel that the customer needs and we get some success. Sadly, this can never be as effective as actually finding out what the customer wants. It's always more expensive in the long run to guess.
We can reduce the cost of development by knowing where to start and where we need to be. Guessing costs money but we can get closer with some simple, often informal chats with the person paying the bills.
Perhaps the reason we think we know what they want is ignorance on our part, perhaps it's ego. We think we know. Perhaps we even think they are happy? Perhaps we all think it's somebody else's job. Who knows.
No communication with the customer before, during or after value has been added proves we do not know if this is working or not and is as strong as rolling the dice in a game of opinion on toast. You need feedback for each attempt, so we know if we are barking up the right tree. If we don't (or worse, can't) get feedback on how effective a change is then we really shouldn't have done it. It's wasted effort.
So, does all of this really boil down to talking to the customer? Both selling more of something and increasing the profit is really this. Because it is a less direct link, is it something we miss or miscalculate?
Yes, on both counts.