Earlier this week I reviewed the short-term product plan with the development team as part of my day-to-day product management role.
One product enhancement on the list was a bit unusual. This enhancement was nothing but installing a standard OS component on our production machines. Why would such a change—operational, operating system related—even appear on the product plan, as tactical as this plan may have been?
It turns out that when we originally added this change request, engineering recommended running a short regression QA cycle to ensure the change would not have an adverse effect. Hence, we figured it should be prioritized vis-à-vis other product enhancement. As such, this change was also bundled into a product release.
While this anecdote may be an exception rather than the norm, we did consciously decide a while back to incorporate product enhancements that are traditionally classified as “system”, “IT” or “operations” into the product plan. This wasn’t obvious, because product plans for on-premises software (where we all grew up) don’t normally deal with these types of product enhancements.
Here’s why this is works well, and why this is part of SaaS product planning:
In SaaS products, system and configuration changes quickly transform into engineering and QA tasks
SaaS products are substantially different than on-premises software when it comes to configurability.
On-premises software is designed from the get-go with configurability in mind. On-premises software developers know that users will deploy the software with different settings. So, they build the software to support different hardware, operating systems, and other environment differences. The type of configurability required is one of the aspects of the product design.
One of the big benefits in running a SaaS business is that such configurability is no longer required. You either run your application on a Linux server or on a Windows server, not both. Your database may be MySQL, Oracle or SQL Server, but normally only one. Other elements of your environment are fixed too.
But then what? Not surprisingly, only comparatively small level of configurability is built into the applications. And, the applications are only tested in the environment they actually run on. Both restrictions are helpful, because they push down costs. As a result, though, many configuration changes require at least some code changes to support them. And, each non-trivial system change requires some regression testing.
Short development cycles make system and configuration changes even more frequent
In the on-premises software days, software vendors could advertise the support for a certain environment in “the next release”, which was “due some time next year”. SaaS software tends to have shorter release cycles.
Why does this affect the frequency of system and configuration changes? It’s a numbers game. As you’re introducing new product functionality (which happens more frequently), you’re increasing the chance that some system change would be required. This change may be triggered by the new functionality. Or, it may simply be some third-party component that was introduced or upgraded, which drove the need for a change (and, third-party components are nowadays also updated more often). Either way, a change is required.
Interestingly, a psychological effect seems to also play into this. People working in SaaS companies get accustomed to faster turnaround times than in on-premises software providers, especially when it comes to small changes. So, when a certain change is required and deemed a priority, timing expectation is different than it might be at an on-premises software vendor.
Multitenancy forces more attention to system and configuration changes
System and configuration changes require more attention in a multitenant SaaS environment. Most likely, you’re going to roll the change to all customers simultaneously. So, the bar is set up pretty high when it comes to quality.
What’s typical with (and perhaps even unique to) system and configuration changes is that the impact is disproportional to the size of the change. In other words, even a minor change may have a major impact on application performance and stability.
Hence, special attention needs to be paid to the quality management process around system and configuration changes.
Bottom line: system and configuration changes are part of SaaS product planning
Like it or not, such enhancements need to be managed as part of the overall product plan(s), most likely by the product management team(s). The methodology for managing the planning process is interesting in itself, but is beyond the scope of this discussion.
How we adjusted our methodology to handle system and configuration changes
During a recent evolution of the development methodology used at WebCollage we’ve tweaked our internal terminology a bit to make incorporation of system and configuration changes more intuitive:
- We changed how we name product enhancements. We used to call each product enhancement a feature, and named them FEATURE-192, etc. We now call them change requests, and name them CR-192, etc.
- We categorize change request into four types: new feature, feature enhancement, bug fix and internal change. The first three types map, more or less, to traditional product planning. The fourth option captures—among other things—system and configuration changes.