You're reading the free online version of this book. If you'd like to support me, please considering purchasing the e-book.

Product Release vs. Marketing Release

One of the most frustrating mistakes that I repeatedly see within an organization is the conflation of a product release with a marketing release. A product release is the exposure of new functionality to users within the product. A marketing release is the announcement of product updates to the rest of the world.

There is no reason that these two releases need to happen at the same time. In fact, attempting to combine the product release and the marketing release is misguided.

Consider the amount of information that your team has about a feature that it is building. As we discussed in the life-cycle chapter (see Life-Cycle of a Feature Flag), we continue to gather new information throughout the product development life-cycle. This leads up to and includes the release of the feature to the users.

Which means, the product release will necessarily represent an incomplete version of the feature. This is OK when your goal is to co-create an inclusive product with customers that are already enrolled in the product journey. But, this is not great if you're about to share your new wares with the rest of the world.

Instead, you should be releasing your product continually, allowing individual features to evolve in production with your customers. Then, at some point in the future, release a set of features to the rest of the world in some razzle-dazzle-infused marketing moment.

Which is to say that feature flags are not in conflict with marketing releases; because, product releases are not in conflict with marketing releases. In fact, you can use feature flags for both product releases and marketing releases (so long as they are different feature flags owned by different teams).

As product engineers, you should not expect the marketing team to think about this. The marketing team's job is to market the product—not to manage the product engineers. It is the sole responsibility of the product engineers to enforce a process internally that ensures the success of the product.

This may mean pushing back against deadlines. Or, at the very least, negotiating over scope. This can be uncomfortable. But, remember that what you're doing is choosing to build a culture that does right by the customer and creates psychological safety for the team. This is an act of love and generosity.

Have questions? Let's discuss this chapter: https://bennadel.com/go/4565