Strategy & Best Practices

Delivering “Predictable” Innovation for Today’s Fast-Moving Digital Economy

By Michael Cassin / October 12, 2020

If you work in the product management organization of a technology company, you know firsthand that the pace of technology change continues to accelerate, along with customer demands for the innovative products or services they need to help them grow and stay competitive.

The AppDirect product team has been working harder than ever before to get new products and features out faster than ever before. And now, incredibly, in the wake of the global COVID-19 pandemic, we're focusing on delivering even faster with an even greater sense of urgency. Our everyday product delivery race has turned into an all out sprint.

As speed becomes part of our new normal, execution quality has emerged as a critical success factor. Developing and releasing performant, bug-free software with product-market fit has always been important, of course, but the focus on being fast has eaten away at the margin for “zero defect.”

To cope with this new reality, technology product organizations like ours need to take a step back and reevaluate their product development and go-to-market processes. Releasing code each week in a CI/CD (continuous integration / continuous delivery) process allows AppDirect to drive innovation at speed, but ultimately, that doesn’t matter if we deliver incomplete or unstable features to our customers.

Step one is to commit to transparency. It may feel uncomfortable to pull back the curtain and give customers a more direct view of product / feature readiness, but it can help set expectations and reduce stress on both sides of the provider-customer relationship. Here at AppDirect, we have started breaking down best practices for defining feature release phases and how to communicate them clearly, both internally and to customers.

Define your Release Phases and Communicate Their Purpose

When is a new product or feature considered ready for customers? It seems like a simple question, but when you start to dig in, there are layers of complexity that product teams need to address. Key to this effort is taking the time to thoroughly define the release phases for your products and features.

At AppDirect, we focus on four main phases:

• Preview phase
• Early availability phase
• General availability phase
• Deprecation phase

Here's how we define them.

Preview phase: Testing and feedback

In the preview phase, you should set the expectation that all products and features are for testing only. This is the time to get feedback from customers about product-market fit, usability, and all of the things that have been conceptual up until this point. A product in the preview phase is not intended to be used to carry production load for any customer.

During this high-touch phase, the product manager and software engineers who are developing the feature should interact directly with customers (who know it’s a preview feature), answering their questions and quickly smashing any bugs that come up. It's also important to set expectations around support. At AppDirect, there's no SLA for preview phase products. For customers that prefer to take advantage of our SLAs, we are happy for them to follow our regular support processes once the feature advances to the more mature early availability or general availability phase.

Early availability phase: Almost ready, but not a “customer QA” cycle

The early availability (EA) phase is intended to give your team the chance to fine tune a product or feature. That means it should be almost complete, it should function as intended for the supported use case, and it should be stable.

Consider this phase your chance to test the performance of the product or feature and to make sure that it scales. For this reason, it's a good idea to limit availability to a select group of customers. It’s also important to remember that this phase is not meant to be a QA cycle with your customers. The product team shouldn't release a feature as EA and expect customers to find bugs for you.

General availability phase: All systems go

In the general availability (GA) phase, your product or feature is ready to be put to the test and used by all of your customers. Because you followed the process and went through the other phases, moving to GA should also imply that your product or feature is complete, can perform at scale, and is fully documented and supported, both in pre- and post-sales.

Deprecation phases: Helping customers adopt new solutions

Inevitably, most products or features will stop being as useful as they once were. This is actually a good sign, because it usually means your product team has gone on to create more innovative products and features that support even more use cases, with more functionality and ease of use that can take the place of the outdated solutions.

When this happens, you need a process to deprecate the old products and features and communicate the changes to your customers. At AppDirect, we support deprecated features and products and abide by our SLAs for a time. However, we don't onboard new customers and encourage existing customers to adopt our new software, with as much lead time as is feasible, before feature retirement and eventual decommissioning.

Once You Define Your Phases, Stick to Them

Over time, the clean delineations between your feature release phases may start to slip. Maybe customers ask for features that aren't quite ready for prime time, or maybe you get pressured to mix-and-match the criteria for different phases to create a unique offer to meet a certain use case. We know it's tempting, but try to resist the temptation.

Even when your team is working its hardest and has the best of intentions, bending the rules is a surefire way to give the impression of a sloppy go-to-market execution, careless delivery, and poor product quality. Following the phases that you have defined—and communicated to your customers—is the only way to enforce the discipline that drives a predictable product delivery experience from start to finish.

Don't Chase Your Sales Team

Sales are a vital function of every company; without them, there would be no customers to develop anything for. But, sometimes the enthusiasm for closing a deal can complicate the development process.

In many cases, skipping release phases to accelerate a product or feature into general availability is a noble effort. Who doesn't want to make customers happy? But, it can also create the expectation that the feature will be at a high state of readiness—battle-tested, scalable, and bug-free. In reality, you know how this story usually ends, with disappointed customers and frustrated product teams. To solve this issue, work closely with your sales organization to ensure that there is internal alignment and transparency around product release phases and the overall process. It’s less stressful for everyone involved if they all know what to expect, even if the release phases don’t line up perfectly with a customer’s desired feature adoption timeline.

Modern software engineering has always been a complicated endeavor, one that’s not for the faint of heart. As the pace of technology change accelerates, it is becoming even more challenging for product teams to clearly communicate their delivery plans and manage expectations around feature readiness / completeness. To be successful, product teams—and the customers who depend on them for innovation—need clear vision, strong leadership, and steady execution. A solid product and feature release process, with well-structured phases can help technology companies cultivate and achieve all three.

Michael Cassin is Vice President of Product Management at AppDirect