Intercom on Product Management
Typical Feature Audit
People graph with the axises going from
Kaizen is the philosophy of continuous improvement.
Improving Existing Features
- You can make it better (deliberate improvement): use it when there is a feature that all of your customers use and like, and you see an opportunity to add significant value to it.
- You can change it so customers use it more often (frequency improvement) ie adding more items to an activity feed, more options to a search tool etc: use when there is a feature that the majority of your customers use infrequently and you believe that using it more would be of benefit to them. Eg. if Basecamp improve the frequency at which users create projects they'll naturall profit through their pricing schematics. There are lots of easy ways to gamify/hack feature usage to have no net profit, or in some cases actually damage the core product offering. LinkedIn's metrics for endorsements might look much better as a result, but it's worth asking if they paid the price in credibility.
- You change it so more people can use it (adoption improvement): use when there is an important feature that a good chunk of your users have yet to adopt, and you see some obvious integrations or changes that will make it easier for them to get on board.
Frequency Improvement with the Hook Canvas
There are 4 steps involved with the hook canvas:
- Trigger: the reason the user goes to the product (eg you received an email to say a contact had endorsed you for a skill)
- Action: they take in anticipation of the reward (eg scroll, search, browse).
- Reward: the user gets from taking their action (eg seeing a beautiful Pinterest board)
- Investment: the user makes which will plant the seed for more triggers (eg subscribe, pin, like, connect etc)
Hook Canvas Pinterest Example
- Trigger: Emails and notifications (external), Fear of losing content, boredom (internal)
- Action: Log-in
- Reward: What did friend post (tribe), interesting objects (hunt)
- Investment: Install
Pin it! button, Pin, Re-pin, follow, comment
To rank and resolve issues that are stopping people from using the product, use the "5 Whys" technique.
This technique also works well when there are many responses as the initial "why" to branch out from.
Early stage startups have advantages over the incumbents. They move quicker and adapt faster, without much technical debt, legacy features, compatibility issues, or high value customers restricting their movement.
Because if there's one thing that's true for startup web products, it's this: if you're not shipping, you're dead.
When To Say "No" to New Features
There is a finite amount of improvement you can put into your existing product and feature set.
New features are risky - you MUST be confident that they will be valued. The analogy is that they are like children, you have to support them no matter what.
Asking customers for concrete features like a calendar, Gantt chart etc and they will always say "yes".
Instead, ask customers tradeoff questions. "Would you rather us make the product faster, or enable more labelling features?" This leads to a different answer and is important to understand the trade-offs at play.
Where Do You Suck?
A product roadmap is built out of hard decisions. The bugs you must fix will fight with the features you must finish, the features your customers want will compete with the ones you know they need.
- Focusing only on new features = a product that is miles wide and inches deep.
- Focusing on repairs = you'll never innovate, thus becoming irrelevant.
Where opportunities lie
Opportunity = Importance + (Importance - Satisfaction)
Put simply: a minor improvement on an important task is almost always a larger opportunity than a big improvement on an ancillary one.
"You can't just 80/20 everything. There have to be certain things that you just are the best at. Things where you go way further than anyone else does, to establish this quality bar and have your product be the best thing that's out there" - Mark Zuckerburg
There is no right way to prioritise a roadmap, but plenty of wrong ones.
Why you don't add new features
Product managers, or founders fulfilling that role, have to be great at saying no. Not "maybe" or "later". The only word is "No".
When your product gets traction, you'll find yourself inundated with good ideas for features. Because they're good, there will be lots of reasons to say yes to them. Some common arguments used to sneak features into a product:
- But the data looks good
- But it'll only take a few minutes
- But this customer is about to quit
- But we can just make it optional
- But my cousin's neighbour said...
- But we've nothing else planned
- But we're supposed to be allowed to work on whatever we want
- But 713,000 people want it
- But our competitors already have it
- But if we don't build it, someone else will
- But the boss really wants it
- But this could be "the one"
The most important line: "This is a really great idea, I can see why our customers would like it. Well done. But we're not going to build it. Instead, here's what we're doing."
There Are No Small Changes
When you're committed to delivering quality software, there are no small changes.
What New Features To Build
Intercom uses the "Jobs-to-be-Done Framework".
If you understand the job that your customers are hiring your product to do, then you can make sure that you have a razor sharp focus on helping them achieve the desired result.
The features you choose to build should be the ones that will help them do the job that needs to be done.
Age Old Jobs, New Solutions
This is the idea of looking at solutions for older issues, and applying a modern lens for a new solution today.
Examples includes scrapbooking (so now they use Pinterest), place to be their favourite photos to showcase (so now, they use Instagram) etc.
"Focus on the things that don't change" - Jeff Bezos.
The Acid Test For New Features
- Does it fit your vision?
- Will it still matter in 5 years?
- Will everyone benefit from it?
- Will it improve, complement or innovate on the existing workflow?
- Does it grow the business?
- Will it generate new meaningful engagement?
- If it succeeds, can we support and afford it?
- Can we design it so that reward is greater than effort?
- Can we do it well?
- Can we scope it well? (Cupcake release)
Plot Return On Development
This is an XY axis where X is
Not valued by users to
Highly valued by users, and Y is
Low development effort to
High development effort.
Rolling out new features
- Team testing
- Company testing
- Restricted beta
- Full roll out
Why New Features Usually Flop
- Will everyone see and understand it?
- Are you showing users what you did, or what they can do?
- Are you announcing it in context?
- How will tomorrow's sign ups hear about it?
- Do you plan to follow up with users and non-users?
Increase User Engagement
- Make a strong first impression
- Gradually expose the depth of your product
- Announce features and improvements in-app