Yesterday, I wrote about my perspective on controlling and launching a minimally viable product (MVP) in SaaS. That MVP process could apply to a startup with an unreleased, pre-revenue product. But, it could also apply to an established product adding new capabilities or features. Today I want to focus on the SaaS product development process for a post-launch product. More specifically, I want to frame balancing 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. We had regular leadership meetings that included engineering updates and near-term development priorities. We set priorities in the context of holistic, strategic roadmap-level planning done on a quarterly cadence. The balance of competing priorities was always the elephant in the room.
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’re 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. However, 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, and those are the ones we’re worried about here. 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 my CEO background, 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. And again, we’re only looking at post-launch scenarios.
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.
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.
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, 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.