"We really like your design philosophy. It gives us peace of mind, because the end user data doesn’t leave our application context."
Misha Karpenko
Engineer and co-founder of Pitch
CASE STUDY
Through adopting feature flags and more frequent software updates, Pitch was able to reduce its amount of hotfixes by 75 percent. But how?
Significantly cut down on your time spent on hotfixes
Gain fine-grained control of user access to new features
Get personalized support with user-level feature overviews
Pitch is the collaborative presentation software for modern teams. Founded in 2018 by the team behind Wunderlist, Pitch is headquartered in Berlin, Germany. Tens of thousands of teams use Pitch, including notable software brands like Notion, Superhuman, Maze, and Intercom.
Pitch, an organization driven by engineering with all teams working inside the product source code, found that with a rapidly growing user base, they needed a better way to scale. Engineers found their time occupied by user requests and code branch management, with little space left for creativity.
After switching to daily releases through feature flags using Unleash, Pitch was able to significantly reduce the amount of hotfixes, spend a lot less time on code maintenance and repeatable work, and produce a best-in-class user experience, all with the ability to release software whenever they felt ready.
Pitch is a highly engineering-driven organization. As a company started by tech entrepreneurs, the source code was considered the single source of truth from very early on, and the engineering team put time and effort into a fully automated continuous integration and continuous deployment (CI/CD) pipeline to support it.
The focus on the source code as the single source of truth was so great that even the product marketing team was working inside the product source code. The fully automated CI/CD pipeline allowed Pitch to effectively push their code to production. At first, they pushed new releases bi-weekly, before moving on to weekly releases shortly thereafter.
The capability to ship rapidly is critical to Pitch’s product development approach. Since its earliest days, the team has relied on the ability to quickly test and validate new features by giving customers early beta access, and iterating on feedback.
The need to control user access to new features in development was clear to Pitch early on in their journey. A homegrown feature management solution was sufficient in the early days: Back then, the number of requests from the product marketing team was low, and the engineers could handle it.
But as Pitch started to grow rapidly, their user base significantly increased, and it became apparent that the engineering team didn’t have a scalable solution for managing requests.
Although Pitch’s homegrown solution made it simple to enable or disable a feature, these requests started to pile up. Suddenly the engineers found their much-needed “creativity time” increasingly consumed by managing a request backlog.
Handling the configuration of the multiple releases in source code made it difficult for the support team to track which users had access to new features. This, in turn, interfered with the team’s efforts to provide the world-class quality support that matched Pitch’s ambition.
On the engineering side, the team wanted its developers to be able to spend as much time as possible on being creative, and as little time as possible on unnecessary processes and other tasks that don’t improve the product. The team was eager to decrease their lead time to change, and to go from weekly to daily releases.
In transitioning to daily releases, Pitch faced another challenge: source code branch management. Although still working on branches, the branch management is much simplified after using feature flags.
Before, hotfixes were piling up, and the release branch often diverged a lot from the main trunk. After switching to feature flags, Pitch was able to switch to a daily release cycle, and this switch caused less differences between main trunk and the release branch. Further; the number of hotfixes went down.
As they moved from weekly to daily releases, Pitch discovered that their branching strategy didn’t scale well, and started looking for a solution. They realized that the most challenging part of increasing their release frequency was changing how their developers worked. Shipping daily meant that the code changes needed to be available in production before they were finalized—they had to be hidden behind feature flags.
Pitch was also looking for a way to make the work in the engineering and product marketing teams less interdependent. Although they collaborated closely, giving the two departments a way to independently plan their work items was important.
Engineering had a strong desire to have a steady flow of getting the code to production, while the product marketing team had different expectations toward communicating new releases to users. By utilizing feature flags, Pitch realized that this was achievable.
A feature management system with a centralized view would allow the engineering team to continue pushing the new software to production continuously, while giving the product marketing management team the control they needed to release new features to users in a clear, predictable and consistent way.
As an EU-based company, data privacy was top of mind for Pitch in choosing their feature management vendor.
“We really like your design philosophy. It gives us peace of mind, because the end user data doesn’t leave our application context,” says Misha Karpenko, engineer and co-founder of Pitch.
Not only did the focus on privacy make the vendor assessment easier, it also simplified the process of onboarding new Pitch users and teams: “When people now ask, ‘What kind of data do we send to Unleash?’, we can simply say ‘we don’t send any data,’” says Misha. “The only data that Unleash sees is the configuration.”
One of the clearest indicators of the success of the transition to daily releases is the sharp decline in hotfixes. When the engineering team released weekly, they would have to push 1 to 3 hotfixes every week. With the daily cadence, the number of hotfixes has decreased to an average of 2 per month. That’s a 75% reduction!
On average, 2 engineers worked 2 hours per hotfix. This means that with the weekly cadence, Pitch spent about 32 engineering hours every month on hotfixes. Now, with the daily cadence, they only spend about 4 hours every month; a reduction of a whopping 28 engineering hours every month. Considering the other roles involved in planning the fix and communicating it to the customers, that amounts to even more time saved.
The Unleash user interface made it very easy for the product marketing team to put end-users into a group for reviewing early feature releases, which allowed easy management of beta programs. Now, product marketing operates independently from the engineering team, and it’s entirely up to them to decide when to release a new feature.
If the engineering team has a new feature ready to go on the 10th of the month, the product marketing team can easily decide to push the release of the new feature until the 15th of the month without the engineering team having to do anything.
“In addition to that, and maybe this is a technical detail, but we report which features a user has when the user contacts our support team. This is a small integration we created to integrate the data we get from Unleash with our customer support system”
Misha KarpenkoEngineer and co-founder of Pitch |
Unleash is flexible enough for teams to write custom integrations that suit their needs.
Another benefit Pitch got when moving from an in-house feature management tool to Unleash is the fact that they no longer need to write and publish documentation and training material for feature management:
“The fact that most new features in Unleash come with a short how-to video, makes it really easy for our developers and product marketers to get started on the new features you guys push,” says Misha.
By adopting Unleash, Pitch has improved their product development processes in multiple ways:
The engineering team can spend more time on creative work, owing to the 75% reduction in hotfixes.
Moving away from internal, in-code feature switches has also freed up engineering time as developers no longer have to update the source code or keep the internal documentation up to date.
By removing the need to update feature flags that the previous homegrown solution required, Pitch has also removed repeatable work for the engineering team.
Now, they can release new software whenever they feel it’s ready, while the product marketing team has full, fine-grained control of user access to new features. This flexibility makes Pitch much more agile.
And finally, by utilizing Unleash’s flexibility, Pitch’s support teams get a full overview of the features available to each user during the support call, allowing Pitch to offer a best-in-class support experience.
Hosted, or self-hosted: it’s your call. It’s quick and easy to set up. Get started in 2 steps with the functionality you need to improve your software delivery workflow.