Notes on Intercom’s Product Management Advice
My notes on Intercom's product management book: improving existing features, prioritizing opportunities, and deciding what not to build.
Originally published in Russian on Facebook on July 5, 2015. This is an English translation of my notes and commentary on Intercom on Product Management, not a framework I developed. The original book illustrations are credited to Intercom.
Well-structured, concise material with concrete examples.
There are plenty of excellent product management books, such as Shipping Greatness: Practical Lessons on Building and Launching Outstanding Software, Learned on the Job at Google and Amazon by Chris Vander Mey, and Inspired: How to Create Products Customers Love by Marty Cagan. I would say that this material fits well on top of those.
Improving existing features
We can divide work on existing product features into three types:
-
Make a feature better: deliberate improvement.
This applies to features people already use and love, where you see a chance to add significant value. You might make them faster, easier to use, or better designed.
-
Change a feature so people use it more often: frequency improvement.
The hope is that people will use the feature much more frequently. Adding more activity information to a feed or more options to a search tool might make people check it more often or use it for everyday tasks. A weekly feature could become a daily one.
The trigger–action–reward–investment pattern is particularly interesting here. You can read more about it in Nir Eyal’s Hooked: How to Build Habit-Forming Products.
-
Change a feature so more people use it: adoption improvement.
The audience for an adoption improvement is people who do not use the feature. To reach them, you need to make it more prominent or solve whatever stops them from using it. Perhaps they do not see its value, or the way it works is too complicated.
Prioritizing work and building a roadmap
Where are the opportunities? One formula you can use is:
Opportunity = importance + (importance − satisfaction)
An opportunity is something you could improve. The higher its score, the higher its priority might be.
Importance means value to the user: what they need from the product. Satisfaction means how happy they are with the current way of getting that job done.
The focus here is not on features but on users’ jobs and needs. For example: “find a client’s contact details quickly” or “stay aware of all the problems across my projects.”
There is no single correct way to prioritize a roadmap. But there are plenty of wrong ones.
What is not a good reason to add a feature
-
“The data supporting it looks good.”
You can fall into the trap of selectively analyzing the data.
-
“But it will only take a couple of minutes.”
The main problem with this argument is that the amount of work is not, by itself, a reason to add a feature.
-
“But the customer is about to leave.”
No single customer should matter more than a good product. Adding value for one customer can take value away from many others.
-
“But we can make it optional.”
Too many settings can overload an interface. Eventually, your system becomes a time tracker that can also send invoices and buy cinema tickets.
-
“But my cousin’s neighbors say…”
You cannot apply the same reasoning to different products. What is useful for one may not be useful for another. There are many questions to answer before considering it.
-
“But we have nothing else planned.”
This is a terrible way to improve a product. Someone has seen an engineer looking bored on VKontakte and thought, “Let’s find something for them to do.” The decision has nothing to do with improving the product.
-
“But we developers were promised we could work on whatever we wanted and be creative.”
Forget it. They lied in the interview. There is a big difference between giving engineers room to improve the code inside a product and letting them add product functionality without going through the product manager.
-
“But 713,000 users want this feature.”
Be careful when someone uses numbers to persuade you. The argument can sound like, “We could fill Palace Square with people who want an Excel integration!” The actual question is whether it is a valuable feature within the product’s scope that all users will use.
-
“But our competitors already have it.”
That does not make it a good idea. They might have built it, made a mistake, and discovered that nobody needed or used it.
-
“If we do not build it, someone else will.”
That still does not mean it belongs in your product. Would someone else building it make your product unnecessary? Would all your users switch? “Someone might switch” sounds plausible but tells you nothing.
-
“The boss really wants it.”
If your boss is also the product manager and has the time and understanding to propose a thoughtful, coherent solution, that is great.
-
“But this has to be the one.”
Without supporting arguments, this is little more than speculation. Eventually, it turns your product into a warehouse of features.
Three broader ways to improve a product
-
Reduce the unnecessary steps between the user and their goal. Simplify the process. People used to call a taxi and spend time explaining where they were and where the driver should go. Now they press a button, and a car arrives.
-
Let more people do something at a lower cost in time or money. Remove barriers, complexity, and expense. Building a website used to require programming and server configuration. Now services let people assemble one by clicking its blocks into place.
-
Let people do something in more situations. Remove limits on where or how it can be used. Accepting payments used to mean buying a cash register and dealing with connectivity. Now you can connect a card reader to a phone or tablet and take payment with a swipe or a tap.
It is much easier to build things people want than to persuade people to want things.
A test for approving new features
A simple test for the question: “Should this feature go on the roadmap?”
-
Does it fit your vision?
What do you believe that others do not? What do you know about users’ problems that others do not? What solution do you believe in? Anyone can gather data, run a focus group, read another Gartner report, or go out and talk to users. But your vision is your own. Product decisions based on a particular point of view can sometimes seem irrational because they involve firm choices.
-
Will it matter in five years?
This is a difficult, boring question, but will the feature still be valuable in five years? It helps you decide whether you are spending the best years of your life on a product that goes beyond passing trends and focuses on something that really matters.
-
Will everyone benefit?
Do not fall into the trap of wishful thinking or laziness by meeting the needs of a small group instead of investigating how many people actually want or need the feature.
-
Will it improve, extend, or innovate on an existing core workflow?
Adding a new workflow should be rare. Most of your time and effort should go into improving the workflows the product already supports.
-
Will it help the business grow?
Can you clearly connect the new feature to revenue for the business?
-
Will it create meaningful interactions across the product?
Most metrics are isolated and essentially useless. Add a new button, and people will click it. You can collect enough clicks to claim an improvement, but that is nonsense. If you measure a new feature separately, you also need to measure the other parts of the system it affects.
-
If it succeeds, can we support and afford it?
Do not estimate only the effort needed to implement something while ignoring its consequences, such as the support burden created by added complexity.
-
Can we make the benefit greater than the effort?
For any feature, the benefit should exceed the effort invested.
An example of how feature costs and benefits can be distributed:
-
Can we do it well?
Teams sometimes take on areas where they do not understand what it takes to build a good feature. A team might build a time tracker without ever tracking its own time, or design a calendar without using one.
-
Can we define, estimate, and scope it properly?
Poorly defined and poorly estimated features arrive late and add nothing but confusion.
I strongly recommend reading the original material in full. I have deliberately left out the fourth chapter here.