Intercom's product principles: Building product that's opinionated by default, but flexible under the hood

Designing a product is a balancing act.

At Intercom, we balance strong opinions about the future of customer support with our goal of meeting a huge variety of customer needs. Some customers want a simple, out-of-the-box solution, but others need customizability – that’s where flexibility comes in.

“Opinionated by default and flexible under the hood means our solutions are easy to use out of the box, but can be customized to suit specific needs”

Opinionated by default and flexible under the hood means our solutions are easy to use out of the box, but can be customized to suit specific needs. This balance between opinionated design and flexibility is crucial for creating products that are both functional and appealing to users.

A product that’s too rigid and inflexible may be difficult to use and fail to meet the needs of some users – while a product that is too flexible and lacks a strong vision may be confusing and difficult to navigate. By striking the right balance between these two extremes, we design a product that’s both effective and user-friendly. But sometimes keeping this balance is quite a challenge.

Applying this principle to our work

It’s usually easier to apply this principle to individual feature levels and interaction design, where we express our opinions through defaults, templates, and education, rather than restrictions. This means we offer our customers a default behavior for a clear and easily adopted solution, but also include customization options to allow customers to tailor product behavior based on their needs.

Examples include:

• Offering defaults and templates when creating outbound messages
• Enabling different filters on reports (e.g. Tickets report)
• The option to build a custom report
• Allowing custom data attributes on top of default standard ones

Measure what’s important to your team when you build a custom report

Choose from a range of templates, or create your own outbound message from scratch

Striking the balance within a complex product

The principle is easy to follow when your product is small or the problem you’re solving is narrow, but it gets more challenging when you start designing something more complex – like a whole new product area or a capability that should work across several product areas.

It can be difficult to predict what kind of flexibility your customers will need, and how and where to reveal it to a customer. The list of variables and unknowns can seem endless. How should this capability behave in different product areas? How will customers interact with this capability?

I’ve been working in Intercom’s Platform group since I joined, shaping horizontal capabilities—like the data layer, or reporting—which empower workflows and insights in the product. Our challenge is that we are designing foundations for the long term; they might be used for different purposes by different customers, but overall, they need to allow for consistent solutions that are easy to understand, adopt, and build on.

How do we overcome this challenge?

When working on a platform capability or solving a platform-related problem, we start with a system. In accordance with Gall’s Law, we aim to design a simple, flexible, scalable system that works, that allows for simple use cases and can be scaled up as needed. The system should be modular and connected to other parts of the product so that it addresses the core problem, but can also be evolved and built on.

“When developing a solution, we think about as many problem spaces as possible to ensure that the solution is scalable and not too narrow”

To do this, we think big but start small. When developing a solution, we think about as many problem spaces as possible to ensure that the solution is scalable and not too narrow. This makes it easier to scope down to the most important and impactful parts, or as we call it, our cupcake.

Starting with a cupcake helps us deliver customer value faster and get feedback quicker. We learn, and based on these learnings we decide how and where to evolve our solution and make it more flexible and powerful – and how to reveal this flexibility to customers.

Principle in practice

Our “opinionated by default, flexible under the hood” principle played a major role in our improvements to Intercom’s data model.

Intercom’s data model represents the way that data is organized and structured within the product. It specifies the different types of data that Intercom can store and manage, as well as the relationships between that data.

“Our data model is built around the concept of ‘conversations,’ which are the primary way that businesses communicate with their customers using the Intercom product”

Our data model is built around the concept of “conversations,” which are the primary way that businesses communicate with their customers using the Intercom product. Conversations can take many different forms, including live chats, in-app messages, and emails. As well as storing data about individual conversations, the Intercom data model also includes customer data (users and companies they belong to).

Introducing more flexibility and control

We used to have a pretty inflexible and opinionated data model, which included only a limited number of data types I listed above: data about conversations, and customer data about individual users and companies they belong to.

We learned that this opinionated approach wasn’t enough for our customers. So, we introduced Custom Objects to offer our customers more flexibility and control by allowing them to import and model their data in a way that makes sense for their business. For example, on top of the default conversation and customer data, an e-commerce customer is now able to add “order data” to their data model in Intercom and then use it however they choose.

“Starting with only one use case allowed us to learn and iterate, how to evolve the system and the solution”

When it comes to Custom Objects, every customer has different needs, so we dealt with many variables and unknowns. We first developed the system and infrastructure of this new data model: where custom objects would sit within the model, how they would connect to other data types, and how the new model would enable the usage of data in different product areas like Inbox, bots, etc.

We started small and introduced Custom Objects to our bots, where we saw a great opportunity to significantly increase the self-serve rate and boost customer satisfaction. Starting with only one use case allowed us to learn and iterate, how to evolve the system and the solution, and where to introduce Custom Objects next.

We realized that our initial system was too flexible; customers had difficulties understanding and adopting it, and we needed to introduce some opinionated behaviors and defaults. It helped us to correct the system and allow both simple default behaviors and any necessary flexibility in each product part.

I believe that keeping this principle in mind will be even more important for us in the future. Our product is constantly growing and evolving, becoming more complex and sophisticated. Despite this organic complexity, we believe it shouldn’t be complicated for those who are using it – it should be easy and quick to adopt, and flexible and powerful when they need it to be. To achieve this, we need to keep this principle in mind when designing foundations throughout the whole product experience.

Explore other posts in our series discussing Intercom’s product principles.