Technical stuff: deployments and feature-flags
As a product manager, you are responsible for all parts of the product that are pushed to production. That’s why you need good processes in place where you either check things before they are live, or (when you’ve established a certain level of trust) take the trust-but-verify approach and check things after they have been deployed. These are actually pretty technical things, but depending on the size of your team, this might be something you should push for. They will definitely affect the quality of your products.
1. Deploying new code should be really easy
It does not matter if you take the go/no-go approach or go with trust-but-verify, a new release and rollbacks should be a press of a button away. With this process in place, it will get way easier to ship features, because everyone knows it is easy to test things. It will remove the pressure from fixing a critical bug in a new feature, because a rollback is just a matter of pushing a single button.
Next steps to research:
- Deploying automatically
- Auto-rollbacks on certain error levels
- Deploying code to a small set of servers
2. Features can be enabled or disabled easily
Once you get to a certain size, you probably have multiple features in the works. The longer you wait with merging a new feature, the more complicated it gets, from a code perspective. That’s where featureflags come in. These flags enable devs to get their code to production, even though the feature is not publicly visible yet.
Next steps to research:
- Enable features for a set of users instead of a set of environments
- Build a system where features can be turned off and on by you and devs inside the browser
- Enable features for a % of users and add the ability to dynamically scale this
Further reading: