Within a technology company, Product Management entails turning the chaos of numerous competing demands into a coherent roadmap that yields meaningful product releases. It’s a challenging job, which varies considerably from one organization to the next. But throughout my career, it’s been a role to which I inevitably gravitate.
With that said, I thought I’d provide some insight into how products are managed at Axcient.
The Agile development methodology provides a wonderful means of establishing a release tempo. Every six weeks there’s a concrete deliverable, known as a “release train.” Picture a schedule where a train departs every six weeks with passengers on board. The passengers are the features and bug fixes targeted for a release. If for any reason a passenger misses a train, another train is only six weeks away.
As a side note, not everything delivered in a release train is immediately visible to the user. A feature may take multiple trains to complete, but at the end of each train there’s tangible progress on the feature. Additionally, a new product may span several trains before a customer ever sees it. Or the standard release process is augmented by a formal Beta program for field testing and capturing structured feedback prior to final release.
Requirements, Requirements Everywhere
With such a rapid tempo, it’s critical to maintain tight control over the release process, starting with requirements. To ensure all inputs are captured and cataloged, requirements are managed in a database where specifics, such as detailed use cases and customer demand, can be tracked. When Axcient partners open a feature request through Technical Support or Sales, it will find its way into this database.
Burning Down the List
Complementing the requirements database is a “burn down list,” which is a tool for managing the prioritization of development tasks with transparency and accountability. Its main purpose is to provide crystal clarity across the organization about which items are being worked on, who the responsible engineers are, and what primary business drivers lie behind the requirements.
Prior to each release, passengers (features and bug fixes) are nominated for inclusion in the train (release cycle). Consideration is based on a number of factors, including enhancement of current capabilities in response to customer needs, removal of friction points for setting up and using the product, improvements to product performance and operation, and expanded capabilities to pursue new market opportunities.
When planning the burn down list for a release, the objective is to capture a realistic payload against which engineering resources have been properly balanced. This necessitates tight collaboration between the Product Manager and Engineering Manager.
Ready, Set, Go!
The central part of a release train is the span of time when engineering does its magic. This six week window is called a “sprint.” Once the sprint for a release gets underway, all the expected engineering development and QA activities kick in. At the end of the sprint, the release achieves a readiness milestone called Controlled Availability (CA).
The Train has Left the Station
At CA, release into the Axcient data center goes through a multi-step commissioning process. For appliance firmware, a CA release is pushed over the wire to a set of customer appliances and monitored for a period of time. If any issues are uncovered, they’re addressed immediately.
Upon a successful CA phase, victory is declared and General Availability (GA) status is achieved. Meanwhile, as of the CA milestone that occurred earlier, the sprint for the next release has already gotten underway.
And so the next set of passengers have been identified and are preparing for departure on the next train. All aboard!