Navigating the SaaSpocalypse – AI SDLCs Reinvent How SaaS is Planned & Delivered

Introduction:

B2B SaaS companies have largely been planning and delivering software the same way for years. AI-native SDLCs are upending this and allowing those reinventing their planning and delivery processes to get value in customers hands – and get feedback – at much higher rates of speed. In this post of Navigating the SaaSpocalypse, I’ll analyze what has changed and ways to reconsider the delivery lifecycle to take advantage of newfound engineering velocity. And provide a simple 2-step formula for freeing oneself from legacy planning and delivery constraints.

Where We Came From:

Most B2B SaaS planning and delivery processes have optimized around an extremely expensive build cycle. Because the cost of building the software was so high, significant scrutiny was taken up front to ensure that the build itself was justified and then delivered accordingly.

What this looked like from the customer’s perspective:

  • A moderate detail long-term roadmap, typically 1-3 years forward looking with a quarterly breakdown
  • A detailed roadmap for the next quarter, with elaborations and previews of individual features being delivered

Features typically had their own individualized beta cycles – if they were offered prior to roadmap delivery – with these cycles being managed on a one-off basis.

Backing this all up was a laborious annual and quarterly planning process requiring Product Requirements Documents (PRDs) at various stages of elaboration in order to get sufficient engineering t-shirt sizing that there was a reasonable confidence of an ability to deliver within the promised timeframes. These PRDs often required weeks-to-months of research and preparation combined with significant additional time for requisite analysis by design and engineering.

Changes to this roadmap ended up being major breaches of both Go-to-Market and customer trust. And it handcuffed the organization to not being able to respond to rapidly changing market conditions in an agile manner. Or, if the need to pivot did manifest – the tax to do so was quite high given the amount of replanning involved.

In short, this all added up to an extremely expensive recurring cost in order to justify the fact that software has historically been extremely expensive to build.

We’re At a Matrix-like “Red Pill” Moment (and it’ll be Amazing):

Fully embracing the opportunities afforded by AI-native SDLCs requires a “freeing of the mind” moment on a number of dimensions:

  • Shipping will be much faster – and it won’t be perfect. This is a prime opportunity for learning while taking advantage of a greatly reduced cost of delivery. There are some easy mitigations for how to manage this lack of “baked perfection” with enterprise customers.
  • Talking about forward-looking features at a detail level is dead. The only way to free oneself from the proverbial ball-and-chain of expensive planning processes is to change the the game by talking about customer problems and what has been shipped instead of trying to paint a hyper-detailed look at the future.

In two relatively simple steps, the pain and complexity of the past can be effectively abandoned in lieu of a much lighter weight process that delivers agility and velocity at the speed of the best AI-first companies.

Step 1 of 2: Create an Opt-In Fast/Polished Release Ring

The first step is to create the notion of a “Fast” release ring and a “Polished” release ring. The naming can vary based upon one’s organizational needs and conventions. In-practice Steps 1 and 2 are done in parallel and managed together. However, Step 1 is being covered first as it makes Step 2 (the planning process) much easier to understand if the delivery process is cleanly laid out.

The “Fast” ring is software that is immediately delivered to production after being built by the AI SDLC. It may not be perfect – and that’s OK. It is also an incredible opportunity to learn at scale across the breadth of the platform in a centralized fashion and makes the notions of individual feature betas largely obsolete unless warranted by extraordinary circumstances. The “Fast” ring should be opt-in for any customer cohorts where extreme stability, polish, and predictability matter. And it should be the default for any lower value cohorts, such as those on self-serve plans for hybrid Product-led/Sales-led Growth businesses. Once a feature has some live experience under its belt and perhaps a few more iterations of polishing (and GTM-enablement), it graduates to the “Polished” release ring.

The “Polished” ring is for features that have some mileage behind them in the “Fast” ring and that have likely gone through several iterations of polish. It is meant for releasing to the highest value customers where maturity and predictability matter the most. It is also the vehicle to handle Customer and GTM-enablement. When a SaaS software team is delivering at maximum AI-velocity, Enablement becomes the new bottleneck. And there are not a lot of blueprints yet on how to effectively solve this. So, the easy fix is to simply gate releases until Enablement is complete and the underlying features are polished enough.

In practice this looks like:

  • “Fast” ring features deliver every day/week/month as they are ready
  • “Fast” ring features get matured after several iterations of rapid learning in the hands of actual customers and full traditional enablement gets conducted
  • “Graduation-ready” “Fast” ring features are packaged together and launched (including the marketing moments) at say in a quarterly or monthly cadence with promotion to the “Polished” ring

Now, SaaS teams have the benefit of near-instantaneous feedback, the ability to move at top speed, and the ability to maintain trust with GTM teams and high-value enterprise customers.

Step 2: A Greatly Simplified Planning Process:

The key to operating in an AI-native manner is to shift all longer term roadmap planning artifacts and conventions to a clearly prioritized list of fully elaborated customer problems. For a piece of accounting software this would be umbrellas like:

  • Streamlining the workflow of producing payables
  • Expediting the collection of cash from receivables
  • Staying abreast of the latest capabilities offered from banks

In short, what are the most important customer problems and why that one’s company is continually obsessing over and seeking to drive material improvements. A fully elaborated, customer-ready version of this list replaces all long-term roadmap artifacts. And, when it is changed, there is requisite change management explaining the rationale of why-the-change.

The quarterly roadmap artifact is simply replaced with a full elaboration of what has been delivered and how it aligns to the prioritized list of problems and the requisite release rings. This can be published based in real-time (for the “Fast” ring) or on a cadence that makes sense and fully aligns with the business given requisite enablement (for the “Polished” ring).

Aligning on what to build is much more of a conversation now than an elaborate ritual – it comes down to choosing which problems and which ideas to focus on for whatever timeframe now makes sense to the business (next sprint, next month, next quarter, etc.) – and fully encapsulates the learnings from delivering at full AI-native warp speed.

One’s individual organizational and customer needs vary considerably. So the level of rigor and cadence needed has to be established on meeting ultimately both organizational and customer need. But, the punch-line here is that the significantly expensive and laborious processes of planning and delivering B2B SaaS, all of which inhibited fast learning and quick iteration – are effectively obsolete and can be now replaced with something right-sized and far more sensible for the AI-first era.

Leave a Reply

Up ↑

Discover more from Ryan Donovan's Blog

Subscribe now to keep reading and get access to the full archive.

Continue reading