{"id":12557,"date":"2017-05-08T18:52:10","date_gmt":"2017-05-08T17:52:10","guid":{"rendered":"http:\/\/blog.intercom.com\/?p=12557"},"modified":"2025-01-07T16:12:38","modified_gmt":"2025-01-07T16:12:38","slug":"great-product-managers-dont-spend-time-on-solutions","status":"publish","type":"post","link":"https:\/\/www.intercom.com\/blog\/great-product-managers-dont-spend-time-on-solutions\/","title":{"rendered":"Great PMs don’t spend their time on solutions"},"content":{"rendered":"

Over the past few years, we\u2019ve learned a lot about building product at Intercom.<\/p>\n

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\u2019ve been doing a lot of reflecting on how we work.<\/p>\n

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.<\/p>\n

This is a pretty standard product development process that most companies follow some version of:<\/p>\n

\"\"<\/p>\n

And if you\u2019re more \u2018agile\u2019 than \u2018waterfall\u2019 it probably looks like this:
\n\"\"<\/p>\n

And has some activities like this:
\n\"\"<\/p>\n

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

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

For most product development teams I know outside of Intercom it looks like this:<\/p>\n

\"\"<\/p>\n

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.<\/p>\n

Sometimes however, it looks like this:<\/p>\n

\"\"<\/p>\n

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

How we decide to work now is shaped by our prior experiences. For me, the \u2018important person\u2019s idea\u2019 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.<\/p>\n

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\u2019s just lip service, or a token gesture.<\/p>\n

Most projects I witnessed at Facebook looked like this:<\/p>\n

\"\"<\/p>\n

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:<\/p>\n

<\/p>\n

<\/p>\n

So spend time picking the right problem, but get things in code asap. I don\u2019t 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.<\/p>\n

At Intercom, how we spend our time looks more like this:<\/p>\n

\"\"<\/p>\n

40% of our 100 units spent before we\u2019ve 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\u2019re attempting to solve. It is highly encouraged for our PMs to openly share and debate early definitions of the problems we\u2019re defining.<\/p>\n

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

We go to great lengths to apply science to this heavy upfront process. We use our:<\/p>\n