How to not suck at managing products

Build something that should exist, not something that just could exist.

The ability to create and manage products is a beautiful skill to have — don’t suck at it.

Des Traynor is one of my favorite people when it comes to articulating the clear thinking required to create delightful software products.

In a talk at LAUNCH Incubator a few months ago, Des gave a great overview on how to:

1. Manage a product
2. Manage a product scope
3. Manage feature creep
4. Focus a product
5. Deliver magic

Here are my notes from the podcast and the slides.

Introduction

• It’s a crazy time to be building products — Every normal human activity is being replaced by software
• Another way to say “Software is eating the world” — Marc Andreessen, Wall Street Journal, 2011

Where do products come from?

There are 5 reasons a product is created, and exists in the world:

1. You have a clear vision of what the product will be and how it will be used.
2. The product was based upon, designed in accordance with, and managed according to, what you hear from customers.
3. You are delivering things that you want to exist in the world, with a distinct flavour of you in them, regardless of market impact.
4. You build a solution to a specific problem you experience, or one have empathy for.
5. You observe a pattern in products and apply it to a new domain.

A very common way products are created is the “pattern-matching” product creation:

Tinder led to “Tinder for professionals”, “Tinder for Pets”, “Tinder for Jobs”, “Tinder for creatives”.

Similarly, success of Uber has led to products created by using the “Uber-pattern” i.e. Taking something that is expensive, rarely used, and delivers no value when out of use (a car) and replace it with a service that provides it on-demand.

Example 1: Tuxedos -> Uber for suits

Example 2: Lawn mowing -> Uber for Lawnmoving

How do you manage a product?

“You manage a product in accordance with the principles that created it”

1. Follow the product leader — When you have a clear vision of what the product will be and how it will be used —
2. Follow the customers — When the product was based upon, designed in accordance with, and managed according to, what you hear from customers.
3. Follow the auteur — When you are delivering things that you want to exist in the world, with a distinct flavour of you in them, regardless of market impact.
4. Follow the itch — When you build a solution to a specific problem you experience, or one have empathy for.
5. Follow the pattern — When you observe a pattern in products and apply it to a new domain.

How do you manage product scope?

To make a simple product, you have to decide where it starts and stops.

Think of a Scalpel versus a Swiss-Army Knife

• Easy to market/explain v/s Hard to market/explain
• Easy to adopt v/s Hard to adopt
• Does 1 thing well v/s Does nothing well
• Quick to build & test v/s Long time to build

When you are starting out with your product, you want it to be closer to a scalpel than a Swiss-Army knife. Because, Gall’s Law.

Gall’s Law

A complex system that works is invariably found to have evolved from a simple system that worked.

A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system.

Gall’s Law gives us a framework for how to think about the first product/feature:

1. Is it a solution to a real problem that exists today?
2. Is it easy to build, test, and refine?
3. Is it easy to explain to a consumer/business?
4. Is it easy to adopt for consumer or companies of all sizes?

There’s a difference between making a simple product, and making a product simple.

Your product should be designed to capture a subset of a workflow — i.e. be closer to a scalpel than a Swiss-Army knife.

Scope = Understanding where to start and where to stop.

Workflow — Step 1 > Step 2 > Step 3 > Step 4

• Where to start? For any problem you are solving with your product, figure out which step you can add value (faster, easier, cheaper, or available in more places) instead of trying to “solve” the entire workflow. Then figure out how to transition from previous step seamlessly.
• Where to stop? Figure out if the next step is 1) done through a market leader or 2) completed in many different ways or 3) it’s something you can’t innovate on, stop.

The cupcake principle

Say your goal is to build a wedding cake. There are two ways to go about it:

1. Method 1: Build the cake base. Then create the filling. Add the icing.
2. Method 2: Create a cupcake. If it’s great, create a cake. If it’s great, create the wedding cake.

How to manage feature creep?

What does feature creep look like? — https://blog.intercom.io/what-does-feature-creep-look-like/

As a product manager, your job is to figure out — Who is doing what? How often?

What does a well rounded product look like?

We start with a small number of features that most of all of the people use all the time.

As we grow the product, we want all the features that are added to have that high level of adoption.

But we often end up with a few features that most of the users find useful.

So how do you know if the feature you are considering adding next is worthwhile?

Answer the following questions and the answer will be clear:

1. Does it fit your vision?
2. Is Reward > Effort?
3. Does it benefit all customers?
4. Will it grow the business?
5. Will it matter in 5 years?
6. Is this a forward step?
7. Will it generate new engagement?
8. If it succeeds, can we support it?

Usually it’s not an easy answer to “Does it fit your vision?” and it’s gets harder as the team grows. There is not a simple yes or no. However, keep the following in mind:

If you’ve never said no because of your product vision, then you have no product vision.

Another useful question to think about is, will it matter in 5 years?

Focus on the things that don’t change — Jeff Bezos

Some jobs that users need to do don’t change.

Another question to ask is does it benefit all customers?

The plural of anecdote is not evidence

It’s tempting to think that of something that you hear a few times as a need for everyone.

Does a new feature that we are considering adding improve, complement or innovate existing features?

Example — Diet Coke with Lime was not considered a good idea, even though a lot of people were drinking Diet Coke.

It’s really easy to build stuff and think that people are using it, so it’s a success. But you have to ask, what are they not doing in the product too.

Can we design it so that reward for usage > effort required

Example — Google Group: A good idea, but not worth a user’s time to do it.

Ask yourself, can we do it well?

If you can’t do it well, it’s not a good feature.

Example — Credit card processing, reconciling payments or Accounting are usually things that have high competition and that you probably don’t have the expertise to do well.

What are some things that are never a good reason to ship bad software:

• “But we have talked about this feature forever”
• “It’s months late”
• “We can product this feature pretty quickly”
• “We’ve worked on this feature for so long”

The reason to be so mindful about what you add and not add in your product is because once you add something, it’s hard to take it back. The perceived value of a feature is a lot more to your customers when you say you are killing it.

There are long & short term implications for every product decision Don’t swap the long term “ow” for a short term “wow”

E.g. — LinkedIn Connections

I closed my LinkedIn account a few years ago after enough spam for connections.

However, always remember,

Decisions are perishable, not final

Don’t create a product where the only way people will be able to use it is if they first take all the crap out of it.

How to focus a product?

There should be only 4 types of work in your product roadmap:

1. Work that improves a feature: (⬆ Customer satisfaction)
2. Work that gets more people to use it: (⬆ % adoption)
3. Work that gets people to use it more: (⬆ frequency)
4. Work on a new feature to support a new workflow: (⬆ customers / revenue)

Get more people to use it or get people using it more. Nothing else matters.

To improve a feature, you focus on the job it does (not the customer, not the category)

Example — A feature in Intercom.io that shows a “map” of your users worldwide. So we think it’s a map and we build the “map” features (zooming, geographical accuracy, etc).

However the feature is not a map, it’s a vanity feature that the customers of Intercom.io use to show off where there users are. So what matters are things like making it easier to print it and share it.

So the features to be build were not in the “map” category.

Never confuse “category you’re in” with the “value you deliver” Customers only care about the latter.

Example — Weather websites obssess about being in the “weather” cateogry. And they provide data about precipitation, humidity, and things that the customers don’t care about. The customers care about things like “do I need an umbrella?”

“The customer rarely buys what the company thinks it is selling them” — Peter Drucker

How to deliver magic?

The story of the Bean Company

In 1901 Heinz Beans had the core business of selling beans.

In 1955, they were selling beans in cans, but the core of the business was still selling beans.

In 2014, what do you think the core of their business was? Yup, selling beans.

The core output of a beans company is beans.
The core output of a technology company is innovation.

There’s a difference.

— Marc Andreessen

So if you are creating a technology product, you are not in the business of making apps. You are in the business of delivering value using innovation.

Old Magic versus New Magic

Any sufficiently advanced technology is indistinguishable from magic

Old Magic:

Things like “cloud based”, “easy to use”, “no install required”, “social”, “mobile”, “beautiful design” which was considered as magic before are now basic expectations.

New Magic:

Uber-fication of interactions, Automated Inputs and Ambient Insights.

1. The “Uber-fication” of interaction

Examples:

Uber — 1 button to “Order Car”

Pizza Delivery — “Push for Pizza”

Your design is only complete when you’ve reduced the frequently recurring problem to a single swipe, tap, or click.

2. Automated inputs

You are no longer the source of the data about you. You authorize the data source (Facebook, Google, LinkedIn, etc) to provide the data about you to the network.

Examples:

TripIt — Authorize Gmail once and it will pull in all the information about your trips.

Baremetrics — Authroize Stripe and it will give you valuable Stripe metrics about your business.

Anywhere you’re asking users for input, first ask yourself, does this data/content already exist somewhere else?

3. Ambient insights

You no longer have to go get your reports and insights. Reports and insights all come to you.

Examples:

Intercom — Sends me a daily report about who signed up for my service yesterday.

Mention — Sends you a daily summary of everywhere you have been mentioned online.

Your product is only ever a small part of someone’s job.
Design it as a system that shares valuable information, not a destination that must be visited to get any value.

Summary

There are way too many products and services competing for your customer’s attention. If you want to create something that should exist in this world because it provides value to the people who use it, do yourself a favor and figure out how not to suck at making products.

Thanks a lot Des Traynor for sharing your thinking on how to manage a product. If you want slides from this talk, email des-slides@intercom.io.

If you liked my notes from this talk and like to read about the art of product design, you will probably enjoy this collection.