Halve the features and double the price.
I've been around technology and startups for a couple of decades. In my experience, most offerings are overburdened by features and underpriced. Further, these two issues drive each other. Understanding this interrelationship is the first step to unlocking extraordinary value.
First, feature creep happens. Sometimes, this results from customers asking for additional capabilities to solve one issue or another they have. Often, the source of feature creep is the founder's own set of "Hiten bomb" ideas that go in because of an a priori idea of what drives value. This latter is even more dangerous because they get baked into the structure of the codebase. These include additional "just in case" feature flags and capabilities that never got completed because the bomb never entirely went off. I imagine the feature set as an iceberg of complexity.
The training requirements for users go up as there are more paths to success - and many more to failure. The complexity of the system increases the complexity of accommodating particular customer needs at a geometric rate.
And since we focus on the codebase, the surrounding value-add services that our clients want and will pay for go unhandled. Documentation, training, consulting: all areas that let us either increase the value or monetize get less oxygen when we are ever-increasing the volume or surface area of the product.
Further, we often undercharge. "My product isn't quite ready, so I am offering a lower price for now" is a common refrain from founders. They are insecure about the value of their product. They don't "love it yet." Sometimes this prevents shipping the product to market at all - a topic for another day. But when in the market, this manifests as an unwillingness to ship pricing. The product remains free or undercharged.
So now we are impoverished from too little cash coming in the door. We lack the resource to spend on new initiatives. The easy thing to do is work the existing resources a little more. That resource is often the founder's own time. We do what we were doing before - just more. That will win applause from fans of hustle. But the doom loop is turning.
One sets the parameters of the economic relationship through pricing. When the founder is in a supplicant position, the customer demands more features. Those features are ever-harder to add because of the volume of complexity from the a priori ideas, and they crowd other features other clients have requested. Our interface gets busier. The need for documentation and training goes up. The doom loop speeds up.
The solution to all this? Halve the features and double the price. But, I hear, "not everyone can afford the doubled price! I will lose customers!" Yes, that's the plan. The problem was solving for multiple customer segments.
Maybe you thought you were serving a concentrated market, but their requests revealed multiple markets with different needs. Our external view of a market is often right enough to get started and wrong enough to get stuck inside. Take this opportunity to break through and serve a high-value segment very well.
Later, one can look at going more horizontal through even more aggressive pruning and positioning. But if a capital-intensive horizontal play were working, you would not have gotten so far into this essay.
Five steps can take us out of this chasm.
First, identify the segment that will most richly pay for one's product. Forget the VC-facing TAM calculation. The goal is a focused market of customers of which an outsider would be unaware. The evidence for the secret is that you didn't know about it a year ago. A review of your customers can often surface this occult segmentation.
This work is not easy, but it is the most important: superior understanding of the customer and market is the single most meaningful predictor of business success. Give this step time to work.
Second, quarter the features. Get rid of everything that was not super-critical to this customer segment. Hurt the design: aesthetics are a servant to utility in this exercise and should take a hit. Rip out the "back of the closet" feature flags. It's incredible how much is in here that can come out.
Are you worried about stability and cross-effects? Good news: now that the product is smaller, there's a lot less to test! Time for a testing regime.
Third, re-add features to support composition. APIs are easier to expose today than they were five or ten years ago. I have been astonished at how easy it is to assemble and document a GraphQL interface. Webhooks support event-driven automation. APIs can look scary to those who have more front-end experience. But they are much less work to put together. And when they are empowered to do what you could through the UI, the options for "custom" work that does not involve changing your codebase explodes. I strongly recommend checking out Zapier and its competitors to see how one can use these APIs without code.
Fourth, invest in some documentation. I would define documentation as content that enables the successful application of your product to the client's most important problems. I like to make documentation part of the development and support processes: auto-generate docs from the codebase and write up the support cases. The perfect is the enemy of the good: a habit of shipping on a very regular basis is a hard thing to make happen, but when you permit roughness, you get flow. Think of it like turning on the tap after a winter with drained pipes. You don't want to drink what spits out at first, but the process is necessary to get a flow of potable water.
As a result, the feature surface area is about half the size it was, and half of that is now in APIs and documentation. This combination will let clients drive more value without you changing your codebase.
Fifth, multiply the price. The feature set is more valuable to your target audience: charge for that value. Note that doubling the price is really about doubling the quantity of money flowing to your coffers. Why are clients paying? A solution to their problems. Take cash in multiple forms: consulting, subscriptions, custom work. Now that you have APIs to run custom logic elsewhere, the custom work could be the domain of outside consultants, but you can also do it yourself or with internal staff for far lower risk than editing your codebase.
This money is not all recurring: that's ok. "Software with a service" is a thing, and you have positioned yourself to profit from it. The strategic value of getting your clients to a high level of success dramatically outweighs the particular pricing structure.
Halve the features and double the price. Utilize APIs and documentation to loosen your clients' ability to realize value. You will create value - and meaning - for yourself, your team, and the customers we are here to serve.