How to Balance SaaS Product Development and Evolution
I think controlling and launching a minimally viable product (MVP) in SaaS is important. The MVP process can apply to a startup with an unreleased, pre-revenue product. And, it can also apply to an established product adding new capabilities or features. The SaaS product development process for a post-launch product is incredibly important. Founders and product teams have to balance innovation, iteration, technical debt, and hotfixes.
This isn’t an article on agile development, but I will refer to sprints and sprint planning throughout. Regardless of how long your development sprints are and how you manage your process, I’m going to assume you’re having regular sprint plannings and release cycles.
Scale and organization structure dictate how involved the executive team is in SaaS product development planning. I favor regular leadership meetings that include engineering updates and near-term development priorities. Priorities in the context of holistic, strategic roadmap-level planning can then be done on a quarterly cadence. The balance of competing priorities is always the elephant in the room, and it’s never easy. There is always more to do than bandwidth and resources will allow. That’s why striking the right balance is so important.
Defining Four Buckets of SaaS Product Development
1. SaaS Product Innovation
New product features and capabilities are often high strategic and competitive priorities for growing SaaS companies. The resources required when you are innovating are less predictable; the risks are higher; but so is the potential upside. Innovation can be sexy and forward-facing, but it can also be fundamental and invisible. The latter can be harder to prioritize but potentially more important strategically.
2. SaaS Product Iteration
Existing features are often deepened and finished based on user feedback after launch — especially true if you’re executing against MVP releases. Iteration is more predictable than innovation; the risks are typically lower; as is the upside. But, it’s often where customer retention is won or lost. And how to show you’re listening.
3. SaaS Product Technical Debt
Technical debt is everything you punt ‘til later when you’ve prioritized too much of the above. These are often ‘nice to have’ which makes them challenging to prioritize or code that has to be cleaned up, documented, or modernized. When too much technical debt builds up, customer retention suffers, and bugs multiply. And, depending on the nature of the debt, you could be putting yourself at a competitive, compliance, or technical disadvantage.
4. SaaS Product Bugs or Hotfixes
All bugs are not must-fix priorities, but hotfix-level ones are. These are things you have to fix, now. Something should be broken, customer-facing, and causing pain to leapfrog the list. There are two classes of prioritization within this category as well: in-sprint and out-of-sprint. If something is urgent enough, it can rise to the level of drop everything/fix and patch NOW — outside of the current sprint. But, let’s hope those are few and far between.
Prioritizing Your SaaS Product Development Pie
Contrary to what I want, I now know there is not more than 100% in a pie chart. I’ve helped manage SaaS product development priorities for all stages of product maturity and am going to frame prioritization around my product lifecycle stages. How you get to 100% in your SaaS product development pie chart varies by where your product is and how it’s performing. This should be a leadership-level intentional decision.
Fresh MVP
A freshly launched MVP is going to emphasize iteration, with innovation a close second, little technical debt, and a healthy allocation for bug fixes. Deeper and new features continue to come online throughout this stage. Depending on your product scope, depth, and market, you may be in this stage 3-18 months post-launch.
Stabilizing MVP
An MVP that’s months into its evolution is beginning to stabilize. It will likely need continuing iteration, longer-term innovation, quite a bit of technical debt mop up (from the flurry of MVP punting), and continuing allocation for bug fixes. New features are few and far between, and iterative ones are shallower in scope than in the earlier MVP stage. You could be managing this stage for 3-24 months.
Feature Complete
Little, if anything, new gets added when your product is feature complete. Technical debt mop-up may move to the forefront, bugs become less frequent, and long-term innovation (multi-sprint) may be the focus if you’re in a competitive space. So there’s a couple of ways to visualize this stage, depending on where you’re headed. You could be managing this stage never or forever.
Strategic Overlay of the SaaS Product Development Pie
It’s far easier to abstract these decisions than to make them in the heat of growth. Strategic business priorities must overlay product decision making to move the company forward. Sometimes these decisions aren’t the sexiest to make, but they’re still worth it. Teams must be educated on why less sexy things are essential and feel part of the process. And often, the most valuable improvements aren’t the most fun to work on, so engineering needs transparency and appreciation to keep rowing.
For Example…
For example, let’s say you have a feature-complete SaaS that has sizable technical debt around infrastructure. These needs are fundamental and deep — requiring 9-12 months of high-resource, high-risk engineering. On the other side of the work, the company will reduce its cost to deliver the software, lower its pricing and widen its addressable market by making it competitive beyond the upper and lower edges of its current sweet spot. It will also improve the software’s performance. The downsides are that the work is deep plumbing — lightyears away from being fun or sexy. It’s all below decks. No one — customers, employees, investors — will see the changes. The scope is known and relatively predictable, although it is software.
Competing for prioritization with the technical debt infrastructure project is a shiny, modern product extension that everyone wants to work on. It’s high risk, and potentially high reward, with a lot of unknowns. It’s innovation in its most stereotypical form. As a result, what’s on the other side of the work is unclear. As is the scope and timeline.
It may be hard for your engineering VP to impartially make the right choice between these two alternatives. If she’s leaning toward the shiny object, senior leadership needs to justify the uglier path for the betterment of the company. I believe that means educating the entire product development team on the value, purpose, and business reasons for sacrificing for the greater good. And, giving them whatever assurances are plausible that the shiny object will have an even better chance of coming to market once the infrastructure advantages are realized.
Moving Your SaaS Product and Your Business Forward
When you’re mindful of your product lifecycle stage, and your allocation of resources for innovation, iteration, debt, and fixes, you can make sound decisions. When those choices are inclusive and transparent, you’re more likely to have them well-received. And when you can perpetuate that culture, you’re highly likely to continually move your product and your business forward.