Sustainable development of software functionality is an important part of the vendor relationship many clients sign on the dotted line for. The vendor relationship does not end when the contractual requirements are met, it is only just beginning. Once the list of contractual requirements is met, good software products are ready to be further expanded upon as your business needs evolve.  To do this, we need to stay current with accessibility standards and other legal requirements. We also need to address the critical issues related to data and transaction security and we need to measure whether we are meeting the needs of the client as well as end users. 

The tech industry has a reputation for overpromising and under delivering; trying too hard to deliver features fast and inexpensively. But every good product manager and development team knows that you can’t have it all; that is to say, you cannot expect a top-quality product, with the functionality you want, and have it on budget and delivered super-fast – it’s a formula for a failing product and exposes you to bigger problems than you might expect! Since software is much like a pyramid and builds on itself, if the foundation is poor, the future development of new functionality can be concerning. 

So, how should new functionality be built for success? It starts with not over promising in the first place. At Camis, we schedule new products and features on our product road map. The development is prioritized based on end user demand and readiness, client needs, and industry trends. From idea to release it methodically goes through various stages before it is released for public use. This proactive, rather than reactive approach to product engineering ultimately produces a more stable and efficient software expansion rather than a volatile quick add on. 

As a product moves towards a public release, it goes through 5 steps; these Progressive Release steps help answer two critical questions, “did we build the right thing, and did we build it well?”. Each product and feature in development is assigned to a step on the progressive release ladder. Each successive release stage expands the scope of users that experience the product or feature. 

There are five steps: Internal Access, Private Access, Limited Release, Private Release, and Public Release. Most of our products and features are currently available and initially introduced at the final ladder step: Public Release. Larger initiatives climb the ladder as they prove themselves.


Progressive Release Ladder

A recent example of this system in action is our new Site Availability Notifications functionality. 

As of the 5.48 release, Site Availability Notifications will be promoted from the Private Release stage to a full Public Release. This feature had to meet our criteria for success across the categories of business, performance, security, and stability to achieve this promotion. 

The questions we use to evaluate the Site Availability Notification: 

  1. Were users registering for notifications? 

  1. Were the notifications getting to people quickly? 

  1. Did notified users then pay for new reservations. 

  1. Did the feature log any errors? 

  1. Were any creative users able to abuse the feature? 

To answer these questions, Camis used Tableau, Google Analytics, and Splunk – our business intelligence, analytics, and telemetry tools of choice.   

The Progressive Release Ladder is one example of the many quality management strategies we use to produce the quality and functionality we can be confident will meet the needs of the user, our client and can reliably be built on for sustainable future expansions.