Intercom’s product principles: What you ship is what matters
At Intercom, we take pride in what we ship – from the planning stage right through to customer feedback and iteration.
When I first started designing digital products, my goal was to get the design of the solution to its final destination: the engineering team. I’d hand it off to the engineers and by the time they’d start coding, I’d have moved on to focus on the next project.
This is the eighth post in a series exploring our product principles. Here, Eugenia discusses our engineering principle “What you ship is what matters”.
I soon realized that I was missing the opportunity to ensure that what I designed was what was being shipped, and most importantly, whether the solution actually solved our customer’s problem. I was missing the chance to answer key questions: Is the solution successfully solving a customer problem? Is it useful? Does it have any impact on the company’s business results?
“Launching a solution is just the beginning of the journey”
As a designer, I needed to take initiative and own what I was shipping – both to ensure the customer got the best solution possible, and to continue to learn and improve my design skills. I quickly realized that launching a solution is just the beginning of the journey.
Taking ownership of what we ship
At Intercom, when we say ‘What you ship is what matters’, we are essentially saying that our deliverable is the end product or feature that our customers use – what gets into their hands. Customers don’t pay for design files, they pay for solutions that solve their problems.
Designing a solution means not only building out the ideal states of the design, but also anticipating how the product will actually be used in the customer’s context. We work closely with product managers to build a common understanding of the problem to be solved – we make scoping calls together, and we’re heavily involved in the process of shipping solutions.
“Rather than just passing off our designs to the engineers, we work with the team at every stage of the production process”
Rather than just passing off our designs to the engineers, we work with the team at every stage of the production process. We collaborate constantly, communicating, gathering their feedback, making tradeoffs, reducing ambiguity, and iterating if necessary. There are no big handoffs or surprise reveals.
We continue to own our solutions after they ship
But shipping is just the beginning. As designers, we also have a share of ownership in what happens after we ship. Does it solve the customers’ problem? Are we done (however we measure done)? If not, what doesn’t work? Why is that important? How can we fix it?
Shipping is when we start to learn whether we need to improve the solution or do something different. We love seeing customers start to use our solutions and tell us what’s good and what’s not. We look at the data, talk to customers, gather feedback, and prioritize it. So the cycle of iterating begins.
Understanding post-launch problems
Back in 2020, I worked as part of a team building a way to sync company data between Intercom and Salesforce. But after launching the solution, we noticed there was little sync activity. Why was this happening? We wanted to understand the reasons why sync activity was low. Was it the configuration? Was it an issue with the data? Due to the complexity of the problem, there was no single change we could make that would work for all of our customers.
We decided to go with a series of small experiments. One of them simply made the sync activity details visible to the customer, empowering them to debug their own setup – a simple design solution that had not been obvious to the team at first.
“By owning the problem we were able to make the solution incrementally better for our customers”
After implementing these experiments, we saw an improvement of 10-15 percentage points. We still had more to do, but by owning the problem we were able to make the solution incrementally better for our customers.
As designers, we take ownership of what we ship because we believe that the quality of the solution is the responsibility of everyone who works on it, not just the last team to touch it. We’re accountable for it, even while working with others. We sweat the details and fight for quality. And, as a team, we take pride in the work that we ship to our customers, before and after launching it.
Want to learn more about working with the Intercom team? Check out our open roles.