In SaaS the next release milestone does not matter. Your customers matter.
Your roadmap is loaded with ideas. Lots of stuff to build. Feature requests coming from all your stakeholders. Strategic innovations, cool new features, operations improvement and a new UI design. The sales guys increase pressure: they say the company/department/product will survive only when you ship feature X in the next release. Set aside product improvements, set aside operations improvements. X is your life-saver. You must ship X in the next release. Only X can open that new market for you…
Does that sound familiar?
The truth is: X is important. But it does not matter for the next release.
There is a common misconception about what your product can reach in the next release and also about what can be done in the next 5–10 releases. Growing a product is about ‘winning a war’, not just the next battle. The next release tends to be overvalued and the mid term goals undervalued. Next release should be business as usual: one new feature, one new customer, a UI design refresh or operations improvements. Chances are high that next release won’t be a blockbuster release — but rather a release similar to the ones you did before. Steady improvements, steady growth, no revenue big-bang. Business as usual.
However, with a sustainable product strategy and clean execution you can reach much more than you would think in the next 5–10 releases. A sustainable product strategy requires planning your releases wisely: you nourish your existing customers to minimize churn (reduced churn equals increased growth). You maintain a healthy product core such that support and operations run efficient. You foster new capabilities step-by-step so you can address additional markets. Keep trying new things, and failing on a small scale, but avoid expensive mistakes that churn your business or build up debt of any sort.
Example: mobile apps. To further understand why the next release does not matter for feature X let us look at the mobile app market. Mobile apps are largely driven by marketing power and app store visibility. Both require the user to install the app from an app store. Users like high-quality apps, the app store ranking and feedback score is essential. Just check: when you search for an app and the search result contains two apps, a 5-star and a 3-star entry, which one do you install? Of course, the 5-star app always goes first. The point is: quality goes first, there is only limited value in pushing a new, immature feature out to all active users while it may actually hurt their way of using the app by producing crashes, incoherent results or a frustrating usage experience. Once your product has a stable core an immature feature will typically offend more users than it will attract new ones. A fail-fast-and-early strategy must be managed by a well-coordinated roll-out strategy to the appropriate market segments or strict A/B testing.
It’s all about money. Usually, your main constraint is financial resources or the capacity to build new things. So be efficient on both. Avoid expensive mistakes and invest your capacity of building new things wisely into the right features. Shipping an immature feature can come at the cost of large follow-up investments. So try new things for your product but don’t lock yourself up in hidden debt with the need to repair immature features.
For any feature X the next release does not matter. Actually, the next release is important. Too important to mess it up with feature X. As an owner of a product you should not be worried about squeezing feature X into the next release — you need to be worried about not messing up the next release for your customers because it will break your trajectory. You can’t afford to scare away your existing customers. Of course can move fast and break things. Do that when appropriate but don’t put your customer base at risk of breaking. Your customers are driving your revenue, keep your revenue safeguarded. The approach of “move fast and break things” works for innovation and new product introduction, for a running business the act of “break things” has a few drawbacks. In SaaS, next year’s ARR is this year’s ARR plus growth minus churn. To safeguard your running revenue just apply appropriate risk management when trying new things in your product.
TL;DR
Safeguard your revenue in SaaS once you have a stable customer base. Do worry about not breaking your next release because it will break your running business with customers. Don’t worry about feature X making it into the next release. Next release does not matter for feature X, the release after that will do just fine.
For customer feedback tool support please check our tool Productific: a free plan is available for testing.
