Releasing often helps us to learn and respond swiftly to feedback, but how often is often? A combination of timeline, effort, and desired outcomes (business and customer impact) may determine how often we release. Some functionality can be built in a few hours. Some can take a few days or weeks. Also, based on the stage of product maturity, we may need less or more focus on technical stability. Technical success criteria are likely to vary based on desired outcomes. Customer context and market needs also have a bearing on how soon or frequently we can update our product.

If something can be released in a few hours and can speed up our feedback cycle, then why wait until the end of day? If something can be released in a day, then why wait until the weekly release cycle? Part of this is how development and production environments are set up, or how code pipelines are structured and so on, but there is also a process component to this.

I have faced these issues in many of the organizations where I have worked. In one instance, I was part of the team that was developing the retail website for a brand. Once the core website was launched, the team's time was split between building new features, fixing defects, and responding to constant requests from customer communications about changing mailer content or website redesigns, or creating new campaigns based on the marketing needs for that week. The team had been following regular monthly releases during the development of the website. They continued to follow their monthly release cycle even after the launch. This meant that communications and marketing had to structure their work around the product team's monthly release cycles. This constantly frustrated them, since it greatly reduced their flexibility for running weekly campaigns.

The product team was fighting off ad hoc requests. It was like they were forever saying no to every request. By the time a monthly release came, some of these requests were missed out, or had escalated. On the other hand, the team was also responding to production support requests. Again, in the absence of a data-based approach, an influential customer's trivial request was being prioritized over a recurring pattern of critical requests from various users. Since the team was switching context between support hot fixes, marketing support and feature enhancements, they dropped the ball quite often. The impression that management had was that the product team was not productive enough.

We then decided to investigate how we could solve this problem. We reviewed the data of all the requests they had worked on for the past three months. We noticed a pattern in terms of the time spent by the team across various activities. We then did something counter-intuitive: we restructured the team based on the swiftness of the response required.

We figured that production support required swift action, but also needed sufficient product context and the mindset to investigate impact. Regular marketing and communications needed quick turnaround and Agility, but not a great level of technical expertise. Product building needed a balance of sound technical expertise and product context. Some features needed quick turnaround and Agility. Some others needed strategic, long-term solutioning.

So, the teams organized themselves into smaller groups based on response cycles and outcomes. We also set up smaller cross-functional groups based on the outcomes. For instance, communications and marketing representatives would have a daily check-in with a couple of members from the product team, who owned the delivery of shorter release cycles. They could track and plan their work based on the pace at which they needed to respond to requests/feedback or new feature idea development. For this, we also had to structure product backlog requests, release pipelines and so on. The key outcome from this restructuring was that the team could now work without distractions, and by having created subteams, based on the speed of response required, we had managed to remove a big bottleneck. Each of the preceding solutions are only indicative and intended to serve as a guideline in the absence of other indicators. In essence though, every team would benefit by assessing their specific needs and creating processes around their needs, rather than following a standard process.