Everyone with a smartphone knows it: apps get updated all the time. Whether you’re looking for a new feature or not, suddenly: there it is. This seems easy, but it’s not, especially when you’re building a SaaS stack and don’t have the deep technical resources to compete with Apple, Facebook, or Google (you’ll get compared to them whether you like it or not).
Customers may tell you what they don’t like, but they can’t always tell you how to fix it (nor would you ask them). You’re going to have to experiment. Finally, you need to do it quickly, because if you’re not competitive, your customers can and will take their business elsewhere.
So, what do you have to do to be the winning choice? Hint: All the public cloud companies are doubling down on full-stack SaaS, betting that it’s the best way to get more companies growing via the cloud.
If there’s one thing we’ve learned as we build full-stack SaaS across industries and user cases, it’s this: SaaS is a 3-sided balancing act: feature agility; compliance readiness; and return on infrastructure investment. And without a focus on features and customers, spending money on infrastructure alone won’t cut it. Modernizing your app is not a destination; it’s a journey.
The Race Toward Feature Agility
The answer to remaining competitive lies in accelerating the journey from traditional forms of software development toward feature agility – finding what your customers value and figuring out how to get it into your development process faster.
Optimize cloud economics and drive Business Goals.Proven best practices that help both finance & engineering teams
The State of DevOps Dora Report shows the progression of everyone in this SaaS arms race – leaders and laggards alike – towards a model that produces faster cloud-driven commercial and technical success. And here’s the good news: most companies are pretty good at building their platform on reliable foundations.
With 6+ years of research and data from over 31,000 professionals worldwide, DORA provides an independent view into the practices and capabilities that drive high performance. The research uses behavioral science to identify the most effective and efficient ways to develop and deliver software.
The difference in change failure rate is an eye-opener: there is no material difference between elite performers and everyone else – all have about an 85% deployment success rate. Seven out of eight can manage outages readily, and across the industry, the fight against downtime is on track. Call this “Platform Stability”
Contrast the victory against downtime with the ability to deliver new features. The top 20% of companies can deploy multiple changes per day. If you can’t push the features your customers are asking for as fast as you want to, one of those elite companies is probably waiting to eat your lunch. Call this “Feature Agility”
As you’re determining your position on the spectrum and thinking about change, it’s important to remember that a transition to greater feature agility isn’t a one-and-done job, and it certainly doesn’t happen overnight. Let’s look a bit closer at why.
What Makes Feature Agility Hard?
Feature agility is about delivering value to customers and overtime while reducing feature friction caused by architectural dependencies so you can introduce those changes more quickly.
But talking about how to improve feature agility is a little like putting the cart before the horse. We can’t improve feature agility without first scrutinizing your internal architecture. There are many ways to think about this problem, from a customer perspective. We believe it requires a tighter focus on feature friction as an aspect of technical debt.
Feature Friction
Your customers tell you what they want all the time, but it’s hard to introduce those changes as rapidly as customers ask for them. Feature friction is a subset of technical debt, which relates to how long it takes to deploy a user-facing feature to increase their loyalty to your product.
Feature friction is painful, but often unavoidable. For instance, when a developer is seeking to introduce new functionality, and pushes new code to a branch, it can trigger bugs because the developer lacks visibility into the dependencies before it gums up your release train.
Over time, such change is going to require dismantling more parts of the application stack. Agility and improvement to the application become more complex because limitations are harder to unravel. That’s tough. But at least if you know how the customer benefits, you’ll know if it’s worthwhile.
Technical debt is a feature, not a bug
It’s a cruel irony: attempting to drive more feature agility into your architecture, you will often expose architectural dependencies and will need a plan to resolve the technical debt that follows.
Technical debt is frequently referred to as something you must get rid of. True that. However, in SaaS, the leaders are those who understand that customer needs will always be evolving. There will always be some level of technical debt in the evolution of your application. It’s the price you pay for speed.
Addressing feature friction requires a delicate balancing act between your ability to introduce change quickly without compromising the reliability of the application. Viewing technical debt through the lens of feature friction helps prioritize what matters to customers. (It doesn’t take much imagination to think of ways in which friction can be beneficial).
The journey toward improving feature agility
Now what? In many circumstances, this becomes a debate between product managers and developers. The PM is focused on implementing a change to make some set of customers happy; the developer explains the complexity of meeting those demands.
Instead of getting too far into the weeds, it’s better to determine where paying down technical debt pays off the most, and tackling that first. This will often result in a compromise: instead of doing exactly what you want, here’s what you can do first.
Remember, the ultimate goal of feature agility is to increase the velocity of feature releases, simultaneously reducing the feature friction in our internal architecture that makes it difficult to do that. Feature agility is worse than useless if it undermines reliability and performance. Feature agility wins when it exposes architectural improvements that deliver benefits to customers.
So, how can you continually modernize key aspects of your existing architecture to make cool stuff that keeps customers happy, while also draining technical debt or at least keeping it under control?
Determine Customer-centric Priorities
The 5 Pillars of the AWS Well-Architected Framework fron AWS enumerates the elements of a well-architected development framework. It provides a consistent approach that centers on improving customer satisfaction and seeking new ways scaling the capacity of your SaaS architecture, iteratively, over time.
But the most important priorities for software developers are those that drive features, make your customers happy, and ultimately, encourage them to keep paying more for your application.
Start with one customer-facing application feature
For engineering executives, mapping the organizational structure into how applications are decoupled and divided up among the specialized is a perennial challenge. Teams who focus solely on the building, testing, releasing, and monitoring of their aspect of the application ideally increase focus, less responsibility, and full autonomy over their work.
Ideally, this can maximize the positive impact of change in the pursuit of increased performance. On the DevOps side, teams can make decisions faster and ensure they can deliver on change that is visible to customers.
Let’s be realistic. You aren’t going to restructure your entire workforce and architecture overnight. Either you’ll quit or they will. Instead, we recommend you start by looking at what the customer is doing with your application.
This is where to find the opportunities where you can search for architectural patterns and events. It provides a good indication of where that feature can be decoupled or extended without disrupting the entire application. For example, you can begin to create APIs for components of your application that allow you to decouple major services.
That isn’t simply a shift in your application architecture. It’s going to require a cultural shift in your team as well. Engineers may have a hard time unlearning long-held beliefs of attaining perfection in the application. However, to implement these changes, product executives must firmly encourage a shift to the ‘done that is better than perfect’ philosophy of pragmatic, agile software delivery.
The difference between the top 20% of technology organizations is not in (laudable) resilience in the face of downtime. It’s in the speed and frequency of adding features customers care about.
