This is the eighth post in a <\/span><\/i>series exploring our product principles<\/span><\/i><\/a>. Here, Stephen discusses our engineering principle \u201cStart with the problem\u201d.<\/span><\/i><\/p><\/blockquote>\n In our ritual Friday afternoon \u2018Show and Tells\u2019 people from across the company demo what they\u2019ve been working on, and that\u2019s how they open their presentation \u2013 they describe the problem. When anyone new joins Intercom, their onboarding pack contains their first \u201cIntermission\u201d\u2013 our name for a problem statement. When you start, you start by focusing on a problem.<\/p>\n We obsess over problems for good reason.<\/p>\n Most companies fail. One of the reasons that many fail \u2013 particularly in earlier stages \u2013 is because they didn\u2019t offer a compelling solution to a real problem that exists for customers.<\/p>\n There are several common patterns among failed solutions:<\/p>\n 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.<\/p>\n \u201cTruly great companies realize that it\u2019s easier to make things people want, than to make people want things\u201d<\/p><\/blockquote>\n Truly great companies realize that it\u2019s easier to make things people want, than to make people want things. That\u2019s what we try to do at Intercom \u2013 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?<\/p>\n We\u2019ve all heard the phrase \u201cDon\u2019t bring me problems, bring me solutions.\u201d 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\u2019 problems, our solutions risk missing the mark. Here are some of the reasons problems are overlooked in favor of immediate solutions.<\/p>\n \u201cThe challenge is to create a system view and understand how the system is working \u2013 or not working \u2013 together\u201d<\/p><\/blockquote>\n The larger your product, company, and customer base grows, the more challenging it can become to accurately diagnose ambiguous problems.<\/p>\n There are more and more factors at play, and the challenge is to create a system view and understand how the system is working \u2013 or not working \u2013 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?<\/p>\n 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<\/a> because the actual problem is buried a few layers deeper. Good product teams keep going, keep asking why.<\/p>\n \u201cProblem definition means getting out of your head and into theirs, getting to the bottom of their actual need \u2013 not the first thing they describe\u201d<\/p><\/blockquote>\n 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 \u2013 not the first thing they describe.<\/p>\n What\u2019s 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\u2019t have time to read reports; reflecting and gaining deep knowledge is often considered tedious or unimportant.<\/p>\n 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.<\/p>\n 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\u2019t value this process, it\u2019s hard to sell the importance based on the output.<\/p>\n Stakeholders who are further from the actual problem will orientate towards \u2018tangible progress\u2019 \u2013 they are more likely to be comforted by any solution, regardless of whether it will solve the problem or not.<\/p>\n \u201cStart with the problem\u201d 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\u2019s 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.<\/p>\n We value principles over process<\/a> at Intercom, so regardless of whether we follow agile, lean, or some other product development process \u2013 this principle tells us where we should focus.<\/p>\n 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:<\/p>\n Most companies spend the majority of their time designing and building solutions<\/em><\/p>\n Most companies will spend the majority of their time designing and building the solution, then releasing a beta to their customers. We believe<\/a> that is a flawed approach, too heavily skewed towards building solutions based on weak problem comprehension. In contrast, here\u2019s a rough guide to how we spend our time at Intercom:<\/p>\n At Intercom, we spread our time more evenly across the stages, spending a lot of time prioritising and refining the problem<\/em><\/p>\n A third of our 100 units are spent before we\u2019ve 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\u2019 hands faster.<\/p>\n All of our principles can vary in scale or effort, and there\u2019s 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:<\/p>\nYour solution is only as good as your understanding of the problem.<\/h2>\n
\n
People are wired to think in solutions<\/h2>\n
1. Your product is a system<\/h3>\n
2. Problem definition is hard<\/h3>\n
3. Solutions are shiny<\/h3>\n
4. Visible output and bias towards \u201cprogress\u201d<\/h3>\n
So if that\u2019s the problem, what\u2019s the solution?<\/h2>\n
We give permission to focus on problems<\/h3>\n
![\"\"](\"https:\/\/www.intercom.com\/blog\/wp-content\/uploads\/2022\/10\/The-Intercom-Way-2021-Principles-RD-Org-version-e1664889804167.png\")
<\/p>\n![\"\"](\"https:\/\/www.intercom.com\/blog\/wp-content\/uploads\/2022\/10\/The-Intercom-Way-2021-Principles-RD-Org-version-2-e1664889897957.png\")
<\/p>\nWe identify problem definition expectations<\/h3>\n
1. It\u2019s ok to bounce between problems and solutions<\/h4>\n