Over the past few years, we’ve learned a lot about building product at Intercom.

Some things have worked really well, some less so. To try and learn how to replicate our product successes as we scale, and teach new people what is working, we’ve been doing a lot of reflecting on how we work.

There is one thing we do at Intercom that I believe is a major factor in contributing to our progress so far. This thing, is deeply understanding the problem each project sets out to solve. This sounds obvious, and is something that others say they do too, but we do it a little differently. Let me explain.

This is a pretty standard product development process that most companies follow some version of:

And if you’re more ‘agile’ than ‘waterfall’ it probably looks like this:

And has some activities like this:

Maybe your process is not exactly like this and you go from beta back to design etc. but it doesn’t actually matter. This post is not about a perfect diagram that illustrates your agile/lean/scrum/blah/etc. process. It’s about something else – where you spend your time.

Imagine all the time you use on a project was contained in 100 units. So all the PM work, the designers, researchers, analysts, engineers, etc. How would it break down?

For most product development teams I know outside of Intercom it looks like this:

A little upfront work deciding to prioritise the problem, then defining it, then a bigger chunk of time designing, and then most of the time spent building the thing.

Sometimes however, it looks like this:

This is when a senior important person has an idea and just wants to get it built. This ‘very important idea’ usually appears in the car, sometimes the shower, or because they asked their neighbour (who represents ‘normal people’) how the product could be better. Once formulated, no time to waste, get it designed, get it built. This very important person’s idea might be big or small. Worst case scenario is when your roadmap is just full of many small, ever changing, very important person’s ideas, most of which have no cohesion.

How we decide to work now is shaped by our prior experiences. For me, the ‘important person’s idea’ happened a lot on the projects I worked on at Google back in the day. There were a lot of people with big car/shower/neighbour ideas. Most of those projects were failures. I know other parts of Google were better, but that was my experience.

This also happens a lot in startups that are failing. When I talk to people in these startups, and ask them how they work, this is often how they work. They may talk about doing research, about talking to customers, but it’s just lip service, or a token gesture.

Most projects I witnessed at Facebook looked like this:

Better than my experience at Google, but there were two things in tension at Facebook. Here they are, taken from the (fantastic) book we all got the day of the IPO a few years back:

So spend time picking the right problem, but get things in code asap. I don’t fully agree with this. Code wins arguments about solutions. But the success of the solution is predicated on understanding the problem. It did happen that someone might write code to help understand a problem, but these were typically technical problems rather than customer problems, and so the latter was very rare. So this bias to get things in code pushed people to move through the problem phase too fast.

At Intercom, how we spend our time looks more like this:

40% of our 100 units spent before we’ve even started designing anything. We obsess about problem prioritisation and problem definition. I mean obsess. I drive our people crazy sometimes interrogating whether we really truly deeply understand the problem we’re attempting to solve. It is highly encouraged for our PMs to openly share and debate early definitions of the problems we’re defining.

So why do we do this? We do it because a solution can only be as good as your understanding of the problem you’re addressing. This is non-controversial. Like an irrefutable fact. And yet most software teams fly right through the problem definition part.

We go to great lengths to apply science to this heavy upfront process. We use our:

• Customer Support team (who tag every single conversation they have with customers for our PMs to review. We naturally use Intercom to do this btw)
• Sales team and Marketing team (who build a product/market matrix based on inputs from the field)
• Research team (who we invested heavily in since the very start)
• Analytics team (who we are investing very heavily in now)

We sometimes get to beta only to realise that we still don’t understand the problem enough, and go back to defining it. So this happens sometimes:

The question at this point is if your solution can only be as good as your understanding of the problem, why do so many companies and teams fly right through that part? I think there are three big reasons:

1. It’s seriously hard work to do it right. Like really hard. It requires talking to many customers, over and over, digging in, new lines of questioning. It takes getting out of your head and into theirs. Getting to the bottom of their actual need – not the first thing they described. People often describe problems they have in the form of solutions they want. Bad product teams stop there and build that. That usually misses the mark because their actual problem is buried a few layers deeper in their thinking. Good product teams keep going, keep asking why. Which is emotionally challenging and time consuming.
2. It’s not viewed as glamorous work. What’s cooler: a research report, a new UI mock-up, or a working prototype of something new? Most senior people love looking at new cool things that kinda work, but don’t have time to read reports. In the modern workplace, deep reading and reflecting to gain deep knowledge is not considered exciting or important. That’s really bad. There is no glamorous thing. Only important things.
3. The visible output doesn’t reflect the amount of work done, and makes it harder to justify. Sometimes multiple people could do multiple weeks of work and the output is a short simple paragraph articulating a problem to solve. For management who don’t value this process, it’s hard to sell the value based on the output.

That’s it. That’s why most companies don’t do it. It’s hard work, it’s wrongly viewed as unexciting, it can be hard to justify the initial output. And yet I believe it is one of the most important things we do, one of the biggest factors in our successful projects. Doing it drastically reduces the likelihood that you have built something not valuable or useful to people, rather than finding out later after you’ve also put in a huge amount of design and engineering time.

I encourage you to try changing how you spend your time. Do it on something small, obsess about the problem definition. Then see how fast and easy it is to know what to build, to build it, and to see customers value it because you truly understood what they needed.