Recognize When It’s Time to Stop Rapid Release of Great Features

Recently, my team at Atomic released a new build to production that contained many new features. The software was declared production ready by the client and by us. Shortly after we announced the deployment via Slack, the client instructed us to roll back the build ASAP. We were told that the client’s product team had not informed customer support of the changes coming with the build.

No product team feels good about having to roll back a build, especially when the situation could have been avoided. This specific incident highlighted that it was time to move out of Feature Factory mode.

 

Early Phase of Product Management: Feature Factory

John Cutler coined the term Feature Factory. He used it to describe a situation where software features are rapidly built and deployed with little consideration for customer needs. In our case, the client’s product team approved the timing of the latest build because it contained a lot of features. And, by their metrics, the rapid delivery of features is a very good thing.

When the project was established, the senior-level managers decided to have their product teams operate in rapid delivery mode. Our team has been working in that mode for nearly two years now. Essentially, we’ve managed to delight and impress two significant stakeholder groups: the board of directors and executive-level management.

Signs of operating in Feature Factory Mode

In our project, the characteristics of this early rapid delivery stage include the following:

  1. Reduced discovery time
  2. Ongoing feature delivery every sprint
  3. Unpolished features
  4. Multiple Scrum teams, each with their backlog of work
  5. Customer experience inconsistencies
  6. Absence of customer outcome metrics

Sometimes, it feels exhilarating to operate in this high-rewards and fast-paced environment. Making executives happy by delivering features feels great until it doesn’t.

When Working Faster No Longer Works

Back to the build release I mentioned. We rolled it back because the team that supports customers was not prepared for the release. The customer success team plays an essential part in our client’s customer journey. When that team saw the features deployed to production that morning, they recognized some inconsistencies. Those inconsistencies were going to lead to customer confusion.

After the rollback, we spent the next several hours proactively communicating the change in Slack, monitoring a flurry of threads about the rollback, and attending impromptu meetings to debrief. Finally, we found ourselves in a new and uncomfortable place where we needed damage control.

Operating in the mode of rapid delivery is best for the early phases of product development. Once real customers begin using the product, it is arguably time for product management to evolve.

Ensuring Cross-team Success

We are advocating for a transition from Feature Factory mode to customer experience management on our project. It will take planning, discipline, and patience to shift away from the familiar way we are used to. We plan to begin moving toward the following:

  1. Unified customer experience
  2. Decisions based on desired customer outcomes and metrics
  3. Extended purview of the product team to include other areas of the business such as customer service
  4. Building user testing into the development schedule
  5. One clear leader who is accountable for cross-team success

Our team has gotten good at rapid delivery. We have honed the skills and processes to support operating in that mode. However, we need a shift in our product management approach. We’ve hit a tipping point where rapid delivery of features is no longer sufficient for both the customer and the business.