Delivering big projects

ยท

3 min read

Big projects carry inherent risks. What if you invest months in building something, only to discover that customers are not using it? I have witnessed this phenomenon negatively impacting team morale on multiple occasions throughout my career. Ultimately, these are all indications that such projects can be detrimental to the company, regardless of the scale of the resulting damage.

While working on one such project, we had to determine the strategy to address these issues. The solution we discovered can be summarised in one line: "Deliver value to customers in small increments.โ€

Let's break it down. First is having early adopters for the feature, second is delivering value, and the third is doing it in small increments rather than doing a big bang release.

Early adopters

If you have an idea that needs to be turned into a product, the most important thing is to find customers who are eager or at least interested in having it. These customers are usually enthusiastic about having this feature in your product, which is why they will be supportive throughout the process. It's important to ensure that you are solving a common use case by having more than one early adopter. In our case, having five early adopters worked well.

The next step is to establish a cadence with these customers. Initially, the main purpose of these meetings is to validate the riskiest hypothesis [1] about the project. Later on, these meetings can also be used for onboarding and gathering feedback.

Delivering Value

Delivering value to customers means that each release of the project should have a measurable impact or benefit associated with it. For example, this could include an increase in earnings, a reduction in costs, an improvement in customer satisfaction ratings (CSAT), or an increase in Net Promoter Score (NPS), etc. While the value delivered may not always be immediately apparent, it is important to track and ask relevant questions to understand the impact. By consistently delivering value with each release, it becomes easier to justify the project's cost and demonstrate its worth.

Small releases

Handling engineering complexity and team management are two main aspects to consider when it comes to small releases.

Engineering Complexity

Introducing meaningful milestones throughout the project helps reduce code conflicts with the rest of the engineering team. By keeping the feature branch close to the master, the engineering team stays updated with the work, facilitating manageable changes in the development, test, & production environments.

Utilise feature flags [2] to enable the feature only for early adopters. In situations where delivering value with each release is not feasible or where there may be concerns about the stability or impact of a feature, rollout flags provide a way to mitigate risks. By rolling out features only for a specific set of users or a percentage of the user base, the impact of any potential issues or bugs can be limited.

Team Management

Small releases are way to keep your team flexible and reduce team fatigue as achieving small & meaningful milestones is encouraging and gives a sense of accomplishment. Flexibility can come in handy while addressing other burning issues within the team.


  1. Riskiest hypothesis

  2. Feature flags

ย