Intercom Product Principles: Build in Small Steps to Deliver Maximum Customer Value

Major changes are hard to understand and harder to debug.

At Intercom, we make complex changes in a series of small, controlled and easy to understand steps. Small changes are easier to create and faster to review, allowing us to deliver value to customers faster.

This is the seventh article in a series exploring our product principles. Here, Aidan discusses our "Build in Small Steps" engineering principle.

No one succeeds all the time

Mistakes happen on every team, in every company in the world. Once you accept that you're not going to do everything right, you can adjust in one of two ways:

Try to fix errors before shipping, taking steps to validate or verify your work. Give yourself room to make mistakes, learn from the mistake, and quickly adjust to correct it.

If you've already sunk weeks into a change, there's often less room to go wrong. This may cause you to rely on validation to avoid surprises when you ship your change. Validation has its place, but it's a poor substitute for deploying something real. The more validation you have to do before shipping, the longer it takes before you can iterate or move on to the next feature - this ultimately slows you down.

When shipping a modification, we aim to check:

The number of variables affected: The more variables affected during a change, the harder it is to determine which part of the change caused the problem. By reducing the size of each step, we tighten the feedback loop and prepare ourselves to learn and adjust much more quickly if we need to. Shift Size: By reducing the size of our shifts, we are also reducing the blast radius of each shift. It's important to test the changes, but there's not much the initial commit will catch. Smaller changes allow us to focus our attention on gradually reaching your goal, and not worry too much about making each change perfect. Which customers are experiencing the change: We rely on functionality metrics to validate changes in production and gradually release them to customers.

We're not sure if the feature will solve a customer's problem until they get it in their hands. This commitment to shipping small iterations quickly ties into another Intercom principle: shipping to learn.

Manage complexity

Building within complex systems is a challenge. When bugs appear during major changes or bloated features miss the mark, it's hard to pinpoint the specific problem. Small steps make it easy to commit, modify, and progress, knowing you're building on solid ground.

Big changes include many assumptions:

External assumptions about the impact of your change on your customers' workflows. Internal assumptions about how different parts of your change interact and depend on each other.

While you can do your best to verify external assumptions, it's often faster and more reliable to ship your change and commit or adjust. Internal assumptions are where complexity can creep in. When your change becomes big enough to encompass multiple building blocks that all depend on each other, testing them together can be risky. It's much safer to release them gradually, building on each other and monitoring the impact as you go.

Lasting speed builds momentum

Speed ​​is great, but durable, reliable speed is a game-changer. Shipping a big change means there's a much higher chance of it being successful and a higher risk of surprises compared to a series of small, quick iterations.

"A tight cycle of committing small changes, learning and iterating creates strong momentum"

A tight cycle of committing small changes, learning, and iterating creates strong momentum. It eliminates the need to be right the first time, encourages faster decision-making, and reduces the explosion radius of errors. Additionally, the division of labor into smaller units means engineers can progress in parallel, allowing the team to move forward faster as a whole.

Building in small steps requires a good team culture

Building in small steps doesn't happen by accident, it takes deliberate intention and the right environment. Our team culture and infrastructure stack play a crucial role in our ability to make small changes quickly.

Once teams understand the importance of making small changes quickly, peer reviews are prioritized and completed faster. Since small changes are easier to understand and review, there is a higher chance of bugs being found...