10 Product Management takeaways from Intercom (Part 2)

The 10 key actionable insights from Intercom on Product Management that will help you build better products and be a better Product Manager:

(See Part 1 for takeaways 1–5)

There are 3 ways to improve a feature

• Deliberate Improvements: Your aim is to make a feature better

These improvements make a feature better for the people who are already using it e.g. easier to use, faster. Deliberate improvements on core value features (see lesson #1) are high risk/high reward because you can delight your entire user base or break your core workflow.

• Frequency Improvements: Your aim is to make a feature be used more often

Adding more options or more hooks into a feature e.g. notifications, might get existing users to use the feature more. The Hooked Model by Nir Eyal is an excellent guide to help with Frequency Improvements:

The Hooked Model can help to increase how often a feature is used

• Adoption Improvements: Your aim is to make more people use a feature

These improvements target people who aren’t using a feature. Examples include: better onboarding, in-product help and viral gamification. The 5 Why’s technique is a great way to get to the root cause of why someone might not be using one of your features.

Have an acid test to approve new features

We’ve discussed that you should not continue to add features to your product without seriously considering the value they add. As a Product Manager it can be hard to keep multiple stakeholders happy with a finite development team at your disposal. Having a list of criteria that any feature request must pass before it is eligible for prioritisation can help make your decision making transparent and unequivocal.

Intercom list 10 questions that a feature must score straight yes’s on. You can check their list in the book but here are my favourites and some of my own:

1. Does it fit in with the product vision? (Gospel! Always move towards your vision)
2. Does it grow the business? (A yes here can conflict with #1 so be careful as growth should always be front and centre)
3. Does it contribute to a predefined, measurable goal? (e.g. adoption. This will stop you accepting ad-hoc requests that don’t support #1 or #2)
4. Will the the benefit out-way the support and maintenance costs? (think ahead, technical debt piles up)
5. Do we have the competencies to build it well? (releasing early is not an excuse for a botched job)

Prioritise using ROI

Takeaway #4, there are no small features! (see part 1). With that in mind, focus your roadmap around features that offer value for money, because everything costs money. Plot your backlog items on a quadrant with User Value and Effort as the axis.

Intercom suggest plotting the ROI of features like this

Users only care about items on the right hand side of the quadrant so make sure your roadmap doesn’t have long period with none of these items. Of course it’s necessary to to do work from the left hand side e.g. Architecture improvements, but spread these out so users can see constant improvement in your product.

Items in the bottom right are the Low Hanging Fruit, this is usually the rarest category as the benefit disproportionally outweighs the investment. Use these to balance out periods where you need to add changes from the left hand side.

Here is another way of prioritising features based upon ROI (taken from Product Management is like roulette, except the house doesn’t always win):

A matrix to find quick wins that benefit users

Roll out strategy matters

This one depends on the stage of your product/company, the size of your user base and the nature of your workflow. Early stage companies with few users and non-essential workflows can consider immediately launching features to all users once they are test complete. However, if you are are an established company with lots of users who rely on your product for mission critical tasks (think B2B) then a phased rollout is safer.

Intercom using the following approach: Team testing ➡️ Company testing ➡️ Beta testing ➡️ Full roll out

Communicate about new features properly

Designing, building and testing features is engaging so it’s easy to get addicted to doing this and never look up from the trenches. Once code is shipped it’s easy to forget about it and move on.

A feature without engagement is not a feature, it’s technical debt.

Companies and Product Managers do not win by having an ‘all encompassing’ product with lots of features . Engagement = winning!

Here are some ways to properly communicate a new feature so users become engaged:

1. Show how it benefits them — Gospel! Nobody cares how smart your product is, they care how it can help them.
2. Show how they can use it — Don’t patronise…but never assume that they know it as well as you, because you built it.
3. Announce it in the right place — Communicating inside your product is better than outside via email. If you want a user to try your new filter feature then they are far more likely to do that if they are already filtering information when you alert them.
4. Announce it at the right time — If a user has just joined your product, the first onboarding popup should not be about data export as the user hasn’t got any data yet. Map out your user journey and introduce features gradually at the relevant point as your users advance.

An Intercom example of good communication along a user journey

Summary

There are plenty of great lessons for Product Managers in Intercom on Product Management and here are my top 10:

1. Audit your feature usage
2. Be careful with customer priorities
3. Say No to features more (there are no small changes!)
4. People only use your product to solve a problem
5. The 3 ways to make products people want
6. There are 3 ways to improve a feature
7. Have an acid test to approve new features
8. Prioritise using Return on Investment
9. Roll out strategy matters
10. Communicate about new features properly

If you’re interested in learning more about all things Product Development then make sure to hold down on the clap button and follow me and the publication.