I Don’t Have Time = It Doesn’t Seem Valuable Enough

“I don’t have time” doesn’t mean a lack of hours or minutes on the calendar; it means: I’m not seeing enough value here to make the effort.

When something is obviously and immediately valuable, we as humans WILL make time for it.  We will make time to obtain, learn, configure, or use a solution by displacing some other activity. 

“I don’t have time” is one of the polite yesses that trap product people.   It allows us to continue thinking that the problem is with the customer, not with our solution.

We hear “I don’t have time” and think, “well, I’ll leave that customer alone and come back to them later”.  Or we take that feedback at face value and try extending our trial period or rewriting the configuration docs or adding a setup wizard. Those fixes rarely help.

How can you learn your way out of this?

You’ll need to be intentional about what you observe and ask. You may already have access to customer support tickets or notes from your coworkers in the field — and also, those are more likely to be centered around feature gaps or change requests. Customers don’t bother complaining about products they couldn’t really even get started with. You may already have access to usage data — and also, that information is full of survivorship bias.

If the plane can land with bullet holes here, then those areas are strong enough already – it’s everywhere else that needs reinforcing. Thanks, Abraham Wald!

Ideally you’ll want to talk with a mix of ‘good’ customers (have contacted you, relatively active in usage metrics) and some ‘meh’ customers (low active usage) to highlight the contrasts. Where those differ is a great opportunity space.

When you hear “I don’t have time”, here’s what you want to go learn

  • Listen to / observe customers’ first impressions of your product. 
  • Figure out how long it takes a customer to configure / start using your product.
  • Then, figure out the variance across customers. Who is it fast/easy for? Who is it slow/complicated for?
  • Discover what customers are dreading
  • Find the customers’ existing habit/process that your product is most similar to

Start here: Listen to / observe customers’ first impression of your product.

Why start here? Because there is so much low-hanging fruit in initial impressions! I’ve often seen a single phrase or image that customers interpret unexpectedly. For example, the word “comprehensive” could be interpreted as ‘this product does it all!’ or as ‘there are so many settings for you, the customer, to configure!’

If customers get the initial impression that it takes a long time to start using your product, or that it requires them to make a lot of decisions, then there’s a really high bar for how valuable it must be in order to be worth using.

Next: Figure out how long it takes a customer to configure / start using your product.

Some teams have started pursuing a “5 minutes to ‘wow'” metric – the first step of that is getting a baseline. Once you know generally how long it takes for a customer to receive real value, then you can ruthlessly cut out friction to reduce that time.

The clock starts once a customer submits a form or downloads something. Even if the next step is an action the customer needs to take (i.e. installing this code snippet on their site), they are counting this time against you.

A subset of that is figure out the variance across customers, and which find getting to value slowest/fastest.

This might reveal problems you need to fix in the product; it may also reveal that some customers are not a good fit. (A high revenue customer who finds it slow/difficult to get to value may = throw professional services at the problem; a low-margin customer who struggles may not be a target you invest in.)

Discover what your customers are dreading.

Whenever people adopt a new habit or roll out a new solution, there are tasks that we’re dreading. We’re sure it will take forever. Last time we did something similar, we made a mistake that we then had to fix. There’s a lot of uncertainty around it and we dislike that feeling. We’ve got to train other reluctant stakeholders to switch. We’ve got to make a case for it to our boss.

There’s always a ‘this is the worst part of the setup experience’ piece, and that’s an opportunity for us to make that part less painful.

Find the customers’ existing habit/process that they’re already used to.

In education, we call this scaffolding: building off existing knowledge so that the learner feels confident and competent. No one wants to figure out a whole process from scratch. We like to see “oh, this is similar to X which I already know how to do”.

This is also a great way to ‘learn by analogy’. It’s often true that a customer has never used anything like [solution] before – so you can’t learn from past behavior! But you can learn from how they adopted a similar or adjacent solution.