April 22, 2019

Конспект Intercom on Product Management

Chapter 1: Evaluate your product

When planning your roadmap, and where your team spend their time, it’s useful to ask “how many people are actually using each of our product’s features?”. Build a chart.

What do you do with your feature audit?

For any given feature with limited adoption, you have four choices:

  • Kill it: admit defeat, and start to remove it from your product.
  • Increase the adoption rate: get more people to use it.
  • Increase the frequency: get people to use it more often.
  • Deliberately improve it: make it quantifiably better for those who use it.

The two most popular ways to improve a product are to add new features, or to improve existing ones.

You can improve an existing feature in three different ways:

  • You can make it better (deliberate improvement).

Use it when there is a feature that all your customers use and like, and you see opportunity to add significant value to it. It’s worth noting that deliberately improving a well-adopted frequently used feature is high risk high reward.

  • You can change it so customers use it more often (frequency improvement).

Trigger: the reason the user goes to the product (e.g. you received an emailto say a contact had endorsed you for a skill).

Action: they take in anticipation of the reward (e.g. scroll, search, browse, etc).

Reward: the user gets from taking their action (e.g. seeing a beautiful Pinterest board).

Investment: the user makes which will plant the seed for more triggers (e.g. subscribe, pin, like, connect, etc).

Use it when there is a feature that the majority ofyour customers use infrequently, and you believe that using it more would be of benefit to them. It’s worth considering how your business will profit from this increased frequency.

  • Or you can change it so more people can use it (adoption improvement).

Adoption improvements target those who don’t use a feature. To get more people using it, rank and resolve the issues that are stopping them from using it. This is where the five whys technique is genuinely useful.

Use it 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. When planning adoption improvements, always consider improvements outside of the software too. Sometimes it’s not about how the feature is designed or built, it’s about how it’s explained.

Chapter 2: When to say no to new features

If you focus only on new features you’ll build a product that is miles wide and inches deep. And if you focus only on repairs you’ll never innovate, thus becoming irrelevant.

When you are focusing on improving your product, a great question to ask is “Where do we suck, and where does it matter?”

Ullwick’s simple opportunity algorithm cleanly identifies the shortcomings in a product, by getting customers to rank the jobs they need to do by how important they are, and how satisfied they are currently. The opportunity is then simply expressed as:

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.

Product managers, or founders fulfilling that role, have to be great at saying no.

Avoid this points for adding new features as they leave you far away from a good product:

1. BUT THE DATA LOOKS GOOD - the interpretation is not always correct

2. BUT IT’LL ONLY TAKE A FEW MINUTES - there's no few minutes changes as it involve planning, explaining to customer and support

3. BUT THIS CUSTOMER IS ABOUT TO QUIT - what's good for one can be bad for the other

4. BUT WE CAN JUST MAKE IT OPTIONAL - it makes product too difficult

5. BUT MY COUSIN’S NEIGHBOUR SAID...

Ponts contr this:

  • what your product actually does.
  • whether your brother’s company are a good target customer.
  • whether they actually use it or just say they do.
  • and whether advanced segments are actually the right solution for what your customers are trying to do.

6. BUT WE’VE NOTHING ELSE PLANNED - than improve code

7. BUT WE’RE SUPPOSED TO BE ALLOWED TO WORK ON WHATEVER WE WANT

8. BUT 713,000 PEOPLE WANT IT - is this a valuable feature, within our purview, that all our customers will use?

9. BUT OUR COMPETITORS ALREADY HAVE IT - that doesn’t mean it’s a good idea

10. BUT IF WE DON’T BUILD IT, SOMEONE ELSE WILL - it's impossible to build everithing, but important to make a good product

11. BUT THE BOSS REALLY WANTS IT

12. BUT THIS COULD BE “THE ONE” - when you’re afraid to make hard decisions, you fall back on appealing to the unknown, and therefore building everything. You end up with a repository of features, not a product.

Chapter 3: Which new features to build

People don’t buy a product because they fall into a particular group. But they do buy a product to solve a problem. If you understand the “job” that 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.

The problems people encounter in their lives rarely change from generation to generation. The products they hire to solve these problems change all the time. When you’re building or managing a new product, you have to believe you can create a better solution that people will want to use because it delivers a better outcome for them. A strong understanding of the outcome customers want, and how they currently get it, is essential for you to succeed in product management.

If you can’t find what product they’re currently using, the chances are that it’s a fictitious outcome.

Making things people want involves understanding a long standing human or business need and then using technology to:

  • take out steps.

Pick a need where the existing solutions are old, complex, and bloated, and find the simplest smallest set of steps possible to deliver the same outcome.

  • make it possible for more people.

The second approach usually involves reducing the cost (in time or money), or barriers to using a product so that more people can use it, thus expanding the market.

  • make it possible in more situations.

This approach involves removing common situational limitations on a workflow.

An acid test for new features:

1. DOES IT FIT YOUR VISION?

2. WILL IT STILL MATTER IN 5 YEARS?

3. WILL EVERYONE BENEFIT FROM IT?

4. WILL IT IMPROVE, COMPLEMENT OR INNOVATE ON THE EXISTING WORKFLOW?

5. DOES IT GROW THE BUSINESS?

6. WILL IT GENERATE NEW MEANINGFUL ENGAGEMENT?

7. IF IT SUCCEEDS, CAN WE SUPPORT AND AFFORD IT?

8. CAN WE DESIGN IT SO THAT REWARD IS GREATER THAN EFFORT?

9. CAN WE DO IT WELL?

10. CAN WE SCOPE IT WELL?

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

The trick is to plan your roadmap so there’s never long periods where customers feel the application has been abandoned. This is precisely where quick wins are useful.

A series of steps to progressively release it using feature flags:

1) Team testing

2) Company testing

3) Restricted beta

What you’re looking for here is:

  • Discoverability – are people finding this feature?
  • Engagement – are people using this feature?
  • Adoption – is it now being used as part of a workflow?
  • Use Cases – how is it being used? what use-cases are popular?
  • Barriers – Who isn’t using it? why? what’s preventing them?

4) Full roll out

Chapter 4: Getting that feature used

The majority of new features flop. You just don’t notice it happening. To prevent it, ask:

1. WILL EVERYONE SEE AND UNDERSTAND IT?

2. ARE YOU SHOWING USERS WHAT YOU DID, OR WHAT THEY CAN DO?

3. ARE YOU ANNOUNCING IT IN CONTEXT?

The right time to promote an improvement is when someone is in your product in a position to use it i.e. an in-app announcement that is triggered according to rules and events.

4. HOW WILL TOMORROW’S SIGN UPS HEAR ABOUT IT?

5. DO YOU PLAN TO FOLLOW UP WITH USERS & NON-USERS?

Once a feature is live, you should follow up with those who use it to understand how, why, and when it’s used. Look for ways to increase usage of it. Here’s some questions I’ve asked customers about a new feature:

When did you notice it? What did you think? Did you use it straight away? What attracted you to it?

  • Did you need to read the documentation? Was it sufficient?
  • Were there any barriers to you using it?
  • Are there times in your work day that you want to use this but can’t?
  • Have you told anyone about what you use it for? What did you say?

Here’s three ways to increase user engagement:

1. MAKE A STRONG FIRST IMPRESSION

The first screen your users see has three important jobs:

  • Explain how your application works.
  • Motivate your users to get started.
  • Let your users know how to get help, if and when they need it.

2. GRADUALLY EXPOSE THE DEPTH OF YOUR PRODUCT

Emails arrive out of context, out of time, and are more likely to interrupt a user than to interest them. It's better to create message schedules to gradually promote certain features. When you have good insight into your userbase you can work out which secondary features delight users and at what point they’re useful.

3. ANNOUNCE FEATURES AND IMPROVEMENTS IN-APP

Features struggle for adoption for lots of reasons, users don’t see the value in using it, they find it too complicated, it’s hidden somewhere clever in your product, they’re the wrong type of users, and dozens more. This is why it’s important to say no. When you’re faced with a feature that only 8% of your user base are using, you have to make a call: Kill it or Keep it.

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.