Summary: Intercom on Product Management

This is a short summary of key points on building a software product from the book “Intercom on Product Management”. Intercom develops analytics solutions for businesses and enables them to communicate easily with their users through emails and in-app messages. Also, they have own corporate blog, where they share their thoughts on product management, design, startups and the business of software.

Introduction

• Great product should be the first focus of every startup;
• Product management (PM) has elements of engineering, marketing, research and project management.

(1) First step: Evaluate your product

The main questions every PM needs to understand are:

• what are people actually doing in your product?
• how many people are actually using each of our product’s features?

Features usage can be visualized on two axes: (1) how many people use the feature; (2) how often people use the feature

Features in a right top corner are the core features of your product most valuable for your users (administrative features like registration, password reset, etc., are not relevant here and should be excluded from the chart). Features in the top left corner are features with low adoption by users.

Another, even simpler way to estimate features usage is to use the bar chart to visualize it by % of users using the in-app feature.

For any feature with a limited adoption there are four choices:

1. Kill it (remove from the product)
2. Increase the adoption (get more people to use it)
3. Increase the frequency (get people to use it often)
4. Deliberately improve it to make it better for its current users

How to improve existing features?

1. Deliberate improvements

Use deliberate improvements when: there is a feature that all/majority of your customers use and like, and you see an opportunity to add a significant value. The deliberate improvement of a well-adopted feature is a high-risk high-reward issue. If something goes wrong — many users will be affected.

2. Frequency improvements

Use frequency improvements when: there is a feature that the majority of
your customers use infrequently, and you believe that using it more would be good for them.

Frequency improvements target those who use a feature. The pattern of hooked approach can be used for frequency improvement: Trigger > Action > Reward > Investment

3. Adoption improvements

Use adoption improvements when: there is an important feature that a good chunk of your users does not use, and you see changes that will make it easier for them to use it. Adoption improvements target those who don’t use a feature. To get more people using the feature, define and resolve the issues and blockers that are stopping users from using it.

(2) When to say “No” to new features

There is a finite amount of improvement you can put into your existing product. New features are risky. You have to be very confident they will be valued, as you have to spend the time to support them after. When planning new features it’s important to understand the trade-offs (e.g., would it be better to add new labels or improve a loading speed).

Where do you suck? Where does it matter?

If you are going to build new features then you need to decide which features you need to build and get them on your product roadmap. The bugs you must fix will fight in priorities with the features you must finish, the features your customers want will compete with the ones you know they need.

When you are focusing on improving your product, a great question to ask is “Where do we suck, and where does it matter?” A minor improvement on an important task is almost always a larger opportunity than a big improvement on an ancillary one.

Why you don’t add new features

Building a great product is about delivering a cohesive product within well-defined parameters. Here 12 reasons why you may consider to include new features, and why you should resist and say no:

1. But the data looks good! — even if data looks good, does this feature fits within the pure view of a product?
2. But it’ll take only a few minutes! — the scope of work should never be a reason to include a feature in a product if this is not in line with the roadmap. And there are always uncounted hours of work of people behind such statements.
3. But this customer is about to quit! — no customer can be more important than a good product. Delivering extra value to one customer comes at the cost of taking value away from many others.
4. But we can make it optional — The visible cost of this is a messy interface with lots of conditional design and heaps of configuration. The hidden cost is that every optional feature weakens your product definition.
5. But someone is doing this (brother, friend, “syn maminoi podrugi”) — is this relevant to your product? is this applicable to your business?
6. But we’ve nothing else planned — Instead of adding to technical debt here, there’s an opportunity to pay some off. Idle time is for fixing bugs, cleaning up test suites, refactoring, etc.
7. But we were supposed to be allowed to work on whatever we want — There’s a difference between encouraging engineers to build things internally (a good thing) and letting people add features to a product bypassing product management (a bad thing).
8. But millions of people need this — you should not care about some people that may demand this feature, you should think if it is a valuable feature, within our purview, that all our customers will use?”.
9. But our competitors have it! — this does not mean it is a good idea. It may be a shitty idea that they want to remove from their product. Do not assume that your competitors are always smarter than you.
10. But if we don’t build it, someone will! — That doesn’t mean it should be in your product. If someone else builds it, do customers no longer need your product?
11. But the boss wants this! — your boss may not have the necessary time and insights to make smart holistic decisions on the product.
12. But this could be the best feature! — You can speculate that any unbuilt feature could potentially or probably transform your product. But you should have a roadmap and vision for your product without appealing to unknown.

“No” is the most important for refusing great ideas since no one keeps crappy ideas in the roadmap. You need to have the strength to say that “this is a great idea and our users may like it, but we are not going to build it, instead here’s what we’re doing”.

There are no small changes & Nothing is free

There are no small changes when you’re committed to delivering quality software. Small changes in the app’s code may involve additional hours of work for many team members.

Agreeing to features is deceptively easy. Coding them rarely is. Maintaining them can be a nightmare. When you’re striving for quality, there are no small changes.

When you implement new features it costs you: time of team members; communication efforts to communicate feature internally and externally to the users; you need to support it in future; it is not free to undo it.

(3) Which new features to build

People use the product to solve a problem. The features you choose to build should be the ones that will help them do the job that needs to be done.

Making things people want involves understanding a longstanding human or business needs and then using technology to:

• remove steps (e.g., Uber for getting a taxi instead of calling to an operator and ordering a cab).
• make it possible for more people (e.g., Tik Tok enables more people to create engaging and high-quality short video content).
• make it possible in more situations (e.g., allow users to read news offline in your news apps).

Remember: It’s easier to make things people want than it is to make people want things.

Test for new features:

1. Does this fit your vision of the product? This is a hard decision, and you’ll never truly know if you got it right. You may even face the resistance of other team members.
2. Would it still matter in a few years? If you’re going to spend the best years of your life on a product ignore the trendy, and focus on the meaningful.
3. Would everyone benefit from it? Beware the “fre-cently” bias (frequently & recently). “Sure we’ll build that, I’ve heard it twice today already” says the founder with 4,800 daily active users, to the unbridled joy of 0.0625% of the users’ base.
4. Will it improve the existing workflow? “Will more people use it? Will people use it more? If neither, then Will be it definitely better for those who use it?”
5. Does it grow the business? Can you join the dots between the new feature and new revenue? (Note: reducing churn, increase engagement also grows the business).
6. Will it generate new meaningful engagement? if you add a metric to track new area of your product, you must also analyze the effect on other areas that are likely to be impacted.
7. If it succeeds, can we support and afford it? — what is the cost to maintain/fix/amend the new feature in the future?
8. Can we do it well? — To build a feature well, you have to understand the job it does. People, who do not use to do lists, can’t build a good to-do list app.
9. Can we scope task it well? — Early MVP releases provide the feedback necessary for the feature to develop. A clear sign that a feature isn’t well scoped is when it lacks specifics and feedbacks from MVP users.
10. Can we design it, so that reward is greater than effort? Product design is about cost-benefit analysis. How useful vs how hard is it to do:

Features & physics envy

When you’re planning your next few months work, plot your features on this chart:

Anything in the lower right corner is special. These are features where the return is disproportionate to the effort. Customers won’t value all the development you do on a project. Some necessary tasks such as back-ups, refactoring, optimization, improving infrastructure offer a little immediate reward. This doesn’t mean you can ignore those issues. The trick is to plan your roadmap so there’s never long periods where customers feel the application has been abandoned.

Rolling out new features by Intercom team

1. Team testing — the first step is to deploy it live with real data, but only visible to the team that built it. The team themselves know what’s a bug versus what’s simply incomplete.
2. Company testing — when a team believes their feature is complete, it is released it to the entire company. It’s simply shipped, just like Intercom intend to ship it to customers. This catches any confusions developers might have created.
3. Restricted beta — the first public release is to a single-digit percentage of users. Intercom communicates it as a beta and specifically asks for feedback later, once they have used it. For new features Intercom is looking for: (1) Discoverability; (2) Engagement; (3) Adoption; (4) Use Cases; (5) Barriers.
4. Full roll out — not all features are available for free to all users — there’s some basic price discrimination at play (free trials and subscription).

For the released feature you need to have plans for those who use it, and those who don’t. You should focus on the growing usage of your product, not growing your product.

Getting feature used

Before you ship the next feature, ask yourself these questions:

1. Will everyone see and understand it? — When you design the first version of a product, you want it to look complete. So you don’t necessarily plan for expansion or leave space for future features, but you should.
2. Are showing users what you did or what they can do? No one cares what you did, or often even how you did it. Your customers care about what they can do.
3. Are you announcing it in context? Your goal should never be to “just get it launched”. The goal should be to “just get it used”. The right time to promote an improvement is when someone is in your product with an in-app announcement that is triggered according to rules and events.
4. How will new future users learn about the feature? As a product grows, it expands beyond what’s learnable in one sitting. There’s a right time to introduce features to customers, and this is where targeted messaging matters.
5. Do you plan to follow-up with users and non-users? You should follow up with those who use it to understand how, why, and when it’s used.

Designers and product people get things wrong all the time and when they do, they’re faced with two choices: (1) improve it, or (2) ignore it and jump onto the next feature.

Increase user engagement

1. Make a strong first impression. The first screen your users see has three important jobs:
   (1) Explain how your application works.
   (2) Motivate your users to get started.
   (3) Let your users know how to get help, if and when they need it.
2. Gradually expose the depth of your product. Every worthwhile application has features that aren’t immediately apparent or useful.
3. Announce features and improvements in-app. The only time your users care about features or improvements is in your application, so that’s exactly where you should be announcing them.
4. Develop your message schedule and you may split different users into different groups for different messages.

Be comfortable killing a feature

1. If you want a well-defined product, you must be comfortable killing features that have little usage — do feature audit to define those.
2. When you’re faced with a feature that less than 8% of your user base is using, you have to make a call: Kill it or Keep it.
3. Killing a feature can take many forms, you can hide it from new users, message current users to explain your decision and give them time to prepare. Or you can just tear it out of the UI and never mention it again.
4. Keeping a feature that has no adoption requires design and communication. You need to target the users who are using it and work out why. Target some users who aren’t, and work out why they are not using.
5. Often you’ll find simply promoting the feature through in-app messaging works and drives feature adoption.

___________________

I hope you enjoyed this short summary and you find it useful.

Here is the link to my other summaries.

My Facebook
My LinkedIn