How Using a Framework Mindset Increased Business Agility

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.

An illustration of Feature Enablement
Feature Enablement was disconnected from product development, 2012–2017
Feature Enablement 1.0 came out around 2013 and was a simple UI that automated a manual process.

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.

  1. 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.
  2. 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.

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.

Hierarchical data model mapping permissions to features to products to suites.
  1. 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.
  2. 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.
  1. 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.
  2. 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.
  3. 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.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Adrienne

Adrienne

35 Followers

IT Executive, Engineer, Enterprise B2B SaaS. Interested in innovation, cloud, devops, agility. Passionate about making tech more inclusive.