Intercom’s product principles: Start with the problem to achieve better solutions
“The problem we’re trying to solve is…”
That’s a common opening statement at Intercom. Not just in product reviews, roadmap meetings, or design critiques from product people, but across the company.
This is the eighth post in a series exploring our product principles. Here, Stephen discusses our engineering principle “Start with the problem”.
In our ritual Friday afternoon ‘Show and Tells’ people from across the company demo what they’ve been working on, and that’s how they open their presentation – they describe the problem. When anyone new joins Intercom, their onboarding pack contains their first “Intermission”– our name for a problem statement. When you start, you start by focusing on a problem.
We obsess over problems for good reason.
Your solution is only as good as your understanding of the problem.
Most companies fail. One of the reasons that many fail – particularly in earlier stages – is because they didn’t offer a compelling solution to a real problem that exists for customers.
There are several common patterns among failed solutions:
- The team didn’t have a good understanding of the problem to begin with
- The team failed to continually update their understanding of the problem and how it mapped to the solution over time
- The problem wasn’t worth solving – it may have been too niche or not urgent enough to prompt action
All too often, companies jump quickly from the problem to a single solution that they fall in love with. They invest time, money, and energy into this solution, only to eventually realize that no one actually cares about it.
“Truly great companies realize that it’s easier to make things people want, than to make people want things”
Truly great companies realize that it’s easier to make things people want, than to make people want things. That’s what we try to do at Intercom – we start with an understanding of a real problem that our target customers experience. It sounds so simple, but if focusing on the problem is so critical, why do so few companies do it?
People are wired to think in solutions
We’ve all heard the phrase “Don’t bring me problems, bring me solutions.” Our brains are constantly trying to solve the problems in front of us. But if we fail to spend time breaking down, exploring, and analyzing our customers’ problems, our solutions risk missing the mark. Here are some of the reasons problems are overlooked in favor of immediate solutions.
“The challenge is to create a system view and understand how the system is working – or not working – together”
1. Your product is a system
The larger your product, company, and customer base grows, the more challenging it can become to accurately diagnose ambiguous problems.
There are more and more factors at play, and the challenge is to create a system view and understand how the system is working – or not working – together. For instance, if usage is low for a product, why is that? Is it a user experience or education problem, a missing feature, or something else?
2. Problem definition is hard
People often describe problems they have in the form of solutions they want. Many product teams stop there and build that solution, which usually misses the mark because the actual problem is buried a few layers deeper. Good product teams keep going, keep asking why.
“Problem definition means getting out of your head and into theirs, getting to the bottom of their actual need – not the first thing they describe”
This can be emotionally challenging and time-consuming. It requires talking to many customers over and over, digging in with new angles and new lines of questioning. It means getting out of your head and into theirs, getting to the bottom of their actual need – not the first thing they describe.
3. Solutions are shiny
What’s more exciting: a research report or a new working prototype? Most of us love looking at new cool things that sort of work. We don’t have time to read reports; reflecting and gaining deep knowledge is often considered tedious or unimportant.
At Intercom, we understand that impact is more important than glamor. We get excited when we see wonderfully written problem statements that we know will be a strong compass for the work that follows.
4. Visible output and bias towards “progress”
Sometimes, a team could put in weeks of work and produce an output of a short, simple paragraph articulating a problem to be solved. For anyone that doesn’t value this process, it’s hard to sell the importance based on the output.
Stakeholders who are further from the actual problem will orientate towards ‘tangible progress’ – they are more likely to be comforted by any solution, regardless of whether it will solve the problem or not.
So if that’s the problem, what’s the solution?
“Start with the problem” appears front and center as one of our core R&D principles, signifying its importance and ensuring we keep it in mind as we work. It’s also a trigger; it activates concrete expectations and tools that we can all leverage. Here are some of the ways we prioritize problems at Intercom.
We give permission to focus on problems
We value principles over process at Intercom, so regardless of whether we follow agile, lean, or some other product development process – this principle tells us where we should focus.
Most companies spend their time designing and building a solution with too little focus on understanding and prioritizing the problems they need to solve. If each team is given 100 units of focus, this is often how they will spend it:
Most companies spend the majority of their time designing and building solutions
Most companies will spend the majority of their time designing and building the solution, then releasing a beta to their customers. We believe that is a flawed approach, too heavily skewed towards building solutions based on weak problem comprehension. In contrast, here’s a rough guide to how we spend our time at Intercom:
At Intercom, we spread our time more evenly across the stages, spending a lot of time prioritising and refining the problem
A third of our 100 units are spent before we’ve even started designing anything. We obsess about problem prioritization and problem definition at this stage, and continually redefine our understanding of the problem as we learn more. Spending this time at the start of the process means we know what we need to build and we can deliver it into customers’ hands faster.
We identify problem definition expectations
All of our principles can vary in scale or effort, and there’s no fixed amount of time you should spend defining the problem. You can spend an hour, a day, a week, or 10 weeks running end to end through the process. To help individuals and teams triage and determine the appropriate effort to invest in a given problem, we use several guidelines:
1. It’s ok to bounce between problems and solutions
In their book, Bulletproof Problem Solving, Charles Conn and Robert McLean refer to this as “porpoising between problem and solutions”. The idea is that going between the two will sharpen your understanding of each, but the key is to not fall in love with your view of either the problem or the solution.
“When you try to account for customer and business needs simultaneously, it can cause confusion”
2. Start with the customer’s problem, not the business’
When you try to account for customer and business needs simultaneously, it can cause confusion. We deliberately start by focusing on the customers’ problems before considering the business impact of these problems. If what you’re trying to solve is a business problem, be sure to tie that back directly to customer problems.
3. Who is having this problem and what’s the job-to-be-done?
A problem exists where there’s a gap between the customer’s expectations and their reality. You need to define the expectations and experience you’re focused on, as well as the outcomes they are trying to achieve.
4. Focus on the severity of the problem
How many customers is the problem affecting, and how significantly are they affected?
“Too often, problem statements are fluffy and high-level”
5. Follow the impact
At Intercom, we specify success metrics upfront as part of the problem definition process. This lets us know which key customer behavior changes we should be watching out for to confirm that we’ve solved the problem.
6. Be specific
Too often, problem statements are fluffy and high-level. It’s important to reach a level of specificity in your problem definition that’s enough to help you figure out a solution.
7. Scope the problem
Problems often have layers, and depending on your customers and product, they can be tentacled. It’s important to break down your problem to increase focus on each dimension, but also so you can map it to your solution options and decide which fits best.
We use a template as a guide to ensure everyone is following a common format, but this document is often accompanied by a lot of background research that lives elsewhere.
“We update our thinking of the problem as we learn more during the process and, most importantly, after we ship”
The problem definition is the foundation. From there, our principles work together as a system to move us from problem to solution. We update our thinking of the problem as we learn more during the process and, most importantly, after we ship.
We take a whole-team approach to problems
At Intercom, we’re all product people with different specialities. The product manager may own the problem definition, but every person has a responsibility to dig in, understand, and hold themselves accountable for actually solving the problems they’re facing.
This informs the approach to problem definition. It means involving more people in research, and sharing interviews and insights to build shared understanding. It can take people time to adapt to this approach and see the value, but it is well worth the effort to speed up the efficiency of the build and the accuracy of the solution.
Starting with the problem allows Intercom’s engineering team to design more thoughtful, suitable solutions. Are you interested in the way we work at Intercom? Find out more about our engineering team.
