Ever tried to move a couch into an apartment and realized that it doesn’t fit through the stairwell to get there? Ever picked a mixing bowl that turned out to be too small for the recipe? It’s a terrible feeling to realize that you didn’t calculate correctly before you embarked on a project and now you’re stuck with resources that you can’t use.
You would never just accept that your couch lives in the stairwell, nor would you accept that your cake batter simply won’t have flour in it. So why would a company insist on just resigning themselves to the fate of software that doesn’t fit their revenue needs?
Plan first, build later
The easiest way to earn a positive return on your tech investment is to plan well before a single line of code is written. That’s not always an option, especially for businesses that have been around for years or for an investor or advisor who comes in after the launch of a startup, but if it’s possible, it’s always best to plan first. It’s easier to build the front walk when you know where the door to the house will be, rather than building a path and breaking open a solid wall to make a door later.
Let’s use a note-taking and reminder app as an example. You could list it at $0.99 per month in the App Store and Play Store, and your entire user base pays the same amount to use your app. Some users will be heavier users who ultimately could pay more, and other users won’t get their full money’s worth from the app. You might hope that these even out and the under-utilizing users compensate for the die-hard users. But what if you could break features into tiers, and your light users don’t pay while your intense users pay $4.99 per month? You start to see your customer satisfaction increase because payment corresponds with usage.
In the above example, changing from the first monetization model to the second one with a live product decreases customer satisfaction because the light users feel like they wasted their money and the heavy users are now forced to pay more. Digging yourself out of a hole can be difficult. Your brand reputation is better if you can make that decision before developing and launching.
Monetizing the right user
The end user isn’t always the one who should be paying for the software. Really. Monetization should always correspond with value. While the way they went about it was ethically murky at best, Facebook has always understood this concept. Their end users couldn’t attribute any monetary value to their profiles, friends, and feeds, but the companies that wanted access to screen real estate could.
This plays a huge role in determining what revenue streams your software will create. For SaaS products, the difference between charging by seat, by feature set, or by capacity can dramatically impact the revenue. You must understand your audience to determine what is of most value to them and what they are most likely to pay for. By monetizing aspects your audience doesn’t value, you’ll miss out on revenue from overuse of low-dollar accounts and lost sales opportunities for promising accounts that couldn’t justify the cost.
Improving an existing model
Sometimes it’s too late to talk about laying the right foundation and the product is already out in the world. In the famous words of Ross Gellar, it might be time to “Pivot!” that couch stuck in the stairwell.
When improving software that is core to a business, any changes must be done cautiously and intentionally. Prioritize fixes and enhancements based on the most valuable opportunities and most costly inefficiencies. If a large portion of your user base is underpaying for your services, you’re watching money go into someone else’s bank account. If a process creates unnecessary hours of work every week for an employee, you’re lighting money on fire. If you don’t plan your development to support your current business functions, you might end up spending exponentially more to fix what you broke with a bad plan.
Sometimes an improvement includes changing the core monetization strategy. It’s normal to lose a small fraction of users during a monetization change, but you can communicate well and make choices that recognize a user’s loyalty to help minimize the effect. Perhaps grandfathering existing users into the new strategy at their old rate is the right choice. Maybe you offer them a free month or year of the new plan that matches their old feature set and then automatically downgrade if the user hasn’t upgraded by the time the free period ends.
From a technical perspective, you have to plan a roadmap for every possible combination so that when the switch goes into effect, you can avoid data loss. How does user data get preserved through an upgrade or a downgrade? How are auto-recurring payments impacted by new options? How does a new feature or system connect to the old software? Plan now, not after you’ve broken your app.
Stuck in a stairwell?
If you’re banging your head against a wall trying to make sense of how your software product is going to hit the right unit economics to keep your account in the black, we can help. Our goal for every client is to find a solution that increases their EBITDA. Sound like what you’re looking for? Drop us a note.