How Using a Framework Mindset Increased Business Agility
Software Developers love to complain about Product Managers who can’t make up their minds, about “the business” constantly changing priorities, about requirements that come so late everything is urgent? Complaints like these are too common in our industry — I’ve been hearing them for my entire career in Tech — but they are almost always invalid.
In the digital age, shifting priorities might actually be a feature not a bug. Agile and adaptable organizations are the ones who thrive in today’s ever-changing world. If developers are complaining about changing priorities the answer is not to ask the business to make up its mind. Instead, ask your developers, “what are you doing to allow the business to change their mind whenever they want”?
There are many ways to answer this question. Agile practices, thin vertical slicing and continuous delivery are common, but there are also solutions using an architecture lens. In this blog, I’ll share the story of how I worked with my team to reimagine our Feature Enablement value stream, which at the time was constantly a victim of changing priorities and requirements coming to us months after they were actually needed in production. This story takes place years ago, but the lessons we learned are just as relevant today.
First, what is Feature Enablement?
Feature Enablement is unique to Enterprise SaaS and refers to ensuring our customers get exactly the features and products they purchased. Sounds simple, but it’s often anything but.
Why feature enablement was so challenging.
From Cornerstone’s beginning in 1999, it operated under a single code base, multi-tenant SaaS model. Over our 20+ year history we built and deployed thousands of features across our everchanging line of products. Historically our Product Development teams would work closely with customers to design, build and deploy new features and enhancements on a regular cadence. Being hyper focused on our customers, they didn’t concern themselves with how to package, sell and market the new features and products they were building. That was left up to Sales and Marketing teams. And Feature Enablement was left up to a small internal tools team I was leading at the time. We had developed a simple tool for our Operations folks to run every time we signed a new customer. All they had to do was read the contract to see which product a customer purchased, then come to our tool and click a button, and a backend script would run to turn on the hundreds of features that were considered part of that product. For example, if a customer purchased our Performance product, the script would turn on goal setting, performance reviews, 360 feedback and the rest of the features that went with the Performance product.
This tool we built was a huge improvement from the manual process it replaced which had been around since our early days. Before our tool, Business analysts would manually configure a portal by enabling each feature one by one, a process which could take an hour or more per customer, and was prone to error. When we first launched our tool, the business congratulated us for automating one of their more painful manual processes. We celebrated. Our tool was saving hours upon hours of manual work and creating more accurate portals than the manual process we replaced.
But the High Didn’t Last Long
As our business continued to grow, as more and more features and products were built, and as our customer base grew year after year, we came to realize that the tool we created did not solve all our problems. It was working for the Cornerstone of yesterday, but it was no longer working for the Cornerstone at the present time.
The goal for the first version of our Feature Enablement was to automate a manual process. And it did that well. It was a simple tool with a button for each product that an analyst would click to turn on the hundreds of features that make up a given product. But for the tool to work, it required someone to tell us what features make up a product, what we call our Product Taxonomy. The problem back then was that we didn’t have any single person or function owning the product taxonomy. Product Development team would have one point of view, Marketing would have another, and among our global Sales team there could be actually be dozens of different taxonomies.
Our tool had two problems:
- No single source of truth for Product Taxonomy. No one spoke the same language and my team was stuck in the middle. We needed someone to tell us the logic for our scripts, but no one could agree. As new products were released on a quarterly basis, product managers might tell us one thing, but Sales or Marketing would tell us something else and we didn’t have a way to arbitrate the discrepancies, so anytime someone told us to change our code, we did. This resulted with a nonstop whack-a-mole approach of constantly changing requirements, which kept the developers on my team quite busy but easily frustrated.
- Requirements would come to us months too late. My team would only be notified of new products after they launched. Then there was a mad scramble to give my team the logic to update our scripts, then we’d have to go through our entire scrum process of user story creation, story review, sprint planning, development and release. By the time our tool was updated, the business was off changing the product taxonomy again.
World Block or Personal Block
This wasn’t a great time for my team. Our business partners who celebrated our tool earlier slowly lost trust in us. And the developers on my team weren’t any happier. If only “the business” would make up their mind and agree about what features go with each product, if only “the business” would remember to tell us ahead of time before launching a new product — then we could have our tool updated and accurate in time and everyone would be happy.
This is when we flipped the script and changed a world block to a personal block. We changed the goal of the Feature Enablement tool from “automate the feature enablement process” to “make it easy to change the Product Taxonomy in our tool.” We asked ourselves, what would it look like if we could remove ourselves from the Enablement process altogether? And that shift in thinking required us to change our mindset from owning a tool to automate a process to creating a framework that enables other teams to manage the process.
The solution
The solution was to rearchitect the tool to sit on top of a meta data framework. Instead of writing code after each release to map features to products, we would write code once and base it off the dynamic mapping inside of our tables. The difficult part was designing the relational data in a way that could bridge the communication gap between our product development teams and our sales & marketing teams. Product developers were accustomed to thinking about features and products in terms of permissions and the navigation menu, essentially the controls in our code that determine whether a specific page or feature is made available to a specific user. Sales and marketing teams were accustomed to thinking about broad functionality without even being bothered by the details of how we control what shows up for a given customer.
We created a data model to represent the relationship between Suites, Products, Features and Permissions. At the end of the day, a permission is the only construct that actually exists in our code, while the other elements — Features, Products and Suites — are purely conceptual. Our system has thousands of individual permissions. When grouped together, permissions make up the concept of a feature, something our entire company would often talk about but never had a common language for. As an enterprise business however, we don’t sell individual features; our customers purchase individual products, or suites which is a package of products.
The design is quite simple, though we did have to consider a few areas of complexity:
- Permissions that apply to multiple Features. Some permissions would be turned on for multiple features. Doesn’t present a problem when turning on a product, but if you are disabling a product, we needed to make sure we didn’t shut off all permissions for that product if some were being used for other products.
- Not all permissions are treated equally. In some cases, there are permissions for features we don’t consider as standard. Maybe it’s for functionality we built for a narrow use case and only a small percentage of our customer base wants it. Maybe it’s a permission for a feature we are deprecating but a few customers are still using it. In this case we made it so some features are enabled by default, while others can be manually configured for specific customer situations.
Conclusion
The data driven framework for managing Feature Enablement has been live since 2018 and is still serving its intended purpose with much success. My team used to spend time writing code, only to deliver updates to Feature Enablement months after the product team created new features. Now we are shipping new portals with 100% accuracy and my team no longer has to write any code. It’s all automated into the product development lifecycle. The best part about re-architecting our former tool to take a meta-data driven framework approach are the benefits we discovered:
- Single Source of Truth for Product Taxonomy: Our entire eco system including Product, Marketing, Sales, Partners and Customers can now speak the same language now that we have a data framework acting as the arbiter of truth.
- Shipping Accurate Portals: New customers get access to all new features as soon as they are ready.
- Developer Time Recouped: The developers who used to write the same type of code month after month to maintain the Feature Enablement process, are now freed to work on higher value work.
To summarize some of the important lessons we learned:
- If developers are complaining about constantly changing priorities, use it as an opportunity to consider how to turn a personal block into a world block.
- Agile practices (thin vertical slices, small increments of work) are known to increase agility but architecture patterns and the use of data can also unlock agility.
- Automation should not just be about automating an existing process, but reimaging the entire process. You may be able to eliminate work instead of automating it.
How have you increased agility? What are you doing inside engineering to enable your business partners to change their mind anytime they want? Tell me about it!
If you’re in the enterprise SaaS B2B space you might be solving similar problems and I’d love to hear how you approached them.
