So you wanna start a startup?

You’ve heard the siren’s song.

You’re done with the commute. The meetings. Management.

More importantly, it’s not about what you’re tired of. It’s about who you were meant to be and what you were meant to do.

You can’t help but be creative. You want to build something you own. You want to bet on yourself.

Ok. You’re on the right track. But before you take the leap, take advantage of your full-time stability to lay some groundwork and do some problem validation before you push all the chips in on an idea that came to you in a flash of brilliance. (I don’t wanna be a wet blanket, but most of those flashes of brilliance are misleading flashes in the pan.)

Instead, fall in love with your customer’s problem, not your solution.

One of the most common mistakes people make early on is jumping to a solution too quickly and getting attached to their idea.

If you’re early, you’ve got the benefit of avoiding that trap by doing as much problem validation as possible, as early as possible.

Arriving at a solution too early is lethal to a startup’s health for these two reasons:

In short, when you own or create something, you think it’s worth more than other people do.

Just imagine all the times you’ve heard someone else pitch their idea with zeal and excitement and you’ve thought, “Hm. Really? I’m their target market and this solution doesn’t excite me in the least.”

Their enthusiasm is fueled by ownership bias.

Or, think about a time you’ve faced the difficult decision of whether to keep pushing or abandon a project that seems to be failing. You haven’t reached your goals yet, but you’ve already sunk in a chunk of time and money! And we’re almost there … just one more push. That’s the sunk cost dilemma.

Those biases are heavy and they are real and you want to avoid falling victim to them for as long as you can!

This is why you should be doing customer discovery work to start getting familiar with the problem before you race to a solution.

And as you’re researching the problem, be objective about just how painful it is. Remember, you want to spend your time building a painkiller, not a vitamin.

Give those two articles a bit of your time and be as objective with yourself as you can. If you’re starting your journey with a solution in mind before you’ve validated the problem, you might be in for a world of pain that could be avoided.

Is this right up your alley?

I send a once-a-week newsletter that you’ll probably enjoy as well. I’ll never share your info with anyone for any reason and it’s easy to unsubscribe.

4 Customer Discovery Tips to Follow Before You Write or Pay for a Single Line of Code

If you’re starting an early-stage startup and you haven’t heard this nugget of truth yet, you will soon: “You’ve got to get out of the building.” This doesn’t mean go for a walk to clear your mind and get the blood flowing. It means you have to get out of your cozy little bubble and do some customer discovery.

The Dos and Don’ts of Customer Discovery

  1. Don’t try to get a couple hundred customers in your first few months. Instead, find a small handful of customers and get a deep understanding of their problems.
  2. Don’t convince yourself that every inconvenience they run into is a problem they would pay to solve. Instead, listen for their recurring, high-value pains.
  3. Don’t parachute into the communities you’re going to serve and start asking people to sign up for your thing. Instead, offer ten pieces of free value (free guides, lists of resources, short conversations) for every one request you make. Commiting to a 10:1 ratio is a good benchmark.
  4. Don’t let on that you’ve invested a lot of time and energy into fleshing out your idea, even if you have. Instead, keep the stakes low so that the person you’re talking to feels free to criticize or invalidate your assumptions.

What is Customer Discovery?

Steve Blank uses the term customer discovery in his book, “The Startup Owner’s Manual” to describe the process of finding customers and learning everything you can about their pains and needs in the early stages of product development.

If you’re not familiar with his work, I’d recommend starting with the talk below, and if it resonates, buy the book. It’s packed with practical advice and reads and feels like a manual as opposed to a conventional business book.

The idea is that you’ve made a handful of assumptions about why your thing needs to exist.

All good.

But, before you go too far down the road in building out your idea, shop your assumptions around to a handful of your potential customers and learn just how right or wrong you might be.

Let’s dig into those dos and don’ts I listed above to help you keep a few things in mind as you’re doing your customer discovery work.

1. Start Small

Don’t try to get a couple hundred customers in your first few months. Instead, find a small handful of customers and get a deep understanding of their problems.

It’s going to take a long time to grow your business. Embrace this by starting small and expecting to stay small in the early days.

Gail Goodman calls this the “Long, Slow, SaaS Ramp of Death.” Is that a less-than-heartening message?


Is it more realistic than the “Raise a metric jackton of money, work 80-hour weeks for a few years, and then join the three comma club when you sell to Google” bullshit that unicorn hunters want you to buy into?

Most definitely.

Chances are good that you’re going to be small for much longer than you’d like. Use that to your advantage rather than raging against it by treating your earliest adopters like the golden peeps they are.

You’re an underground band that nobody cares about. They’re the hipsters who heard about you first.

Figure out what makes them tick and do things for them that don’t scale. If you can design your product to make their wildest dreams come true, selling to people just like them down the road will be easier.

2. Listen for Pain

Don’t convince yourself that every inconvenience your audience runs into is a problem they would pay to solve. Instead, listen for their recurring, high-value pains.

The reason that it’s better to do this sort of customer discovery before investing too much of your time and money into a solution is that you have to remain as objective as possible.

Try as you might, if you’ve already started designing a solution, you’ll be susceptible to ownership bias.

I’ve seen this happen a hundred times: Founder already has a solution in mind or in the works, and every minor inconvenience the customer shares is a slam-dunk validation of their feature set and roadmap.

To stay as open and flexible as possible, delay investment for as long as you can and find real pains instead of inconveniences. I’ve written more about this specific tip here: Is Your Early-stage Startup a Vitamin or a Painkiller?

3. Give First

You need to be a part of the same communities as your target customers if you’re going to serve them well and build something they want. And yes, let’s be honest, you want to convert them into paying customers down the road.

But first, you need to become a valued personality who has earned a tremendous amount of trust within a community in order to (eventually) attract customers to your business.

If we invert the problem and think about the things a person would do in order to be ignored, it’s easy to imagine ways to behave exactly the opposite and build trust.

What’s the best way to guarantee that you get ignored or shunned? Simple. Be a self-oriented, self-serving taker who is constantly asking for favors, spamming the channel with their own updates, and bragging about recent successes.

The opposite of that person is others-oriented, sharing free resources related to their area of expertise, and helping people in the group who are struggling to make progress.

It’s ironic poetic that the “Give First” approach ends up being better for your Self. Keep it in mind and always find a way to teach and give things away to attract trust and attention.

4. Keep the Stakes Low

You’ve got to make people feel comfortable with declaring your idea a dud. If the truth is that they’d never even consider pulling into their existing workflow, they need to be able to say that.

If you tell them how excited you are about this concept and how certain you are that it’s going to make their life better and you can’t wait to show it to them, they’re more likely to protect your feelings and lie to your face.

It doesn’t matter if I created the work they’re looking at, or if we’re launching next week. I always tell interview participants:

“This is very low stakes because we’re still early on in this process.”

“We’re not at all invested in what we’re sharing today. But we are invested in getting it right so it’s no big deal to us to blow this whole thing up.”

“Feel free to be blunt, this isn’t my baby. I haven’t spent too much time fleshing this out yet. We’re trying to poke some holes in this to see if it’s worth investing in.”

You can read more of my thoughts on keeping the stakes low here: Pretend the Stakes Are Low … Even If They Aren’t.

Is this right up your alley?

I send a once-a-week newsletter that you’ll probably enjoy as well. I’ll never share your info with anyone for any reason and it’s easy to unsubscribe.

Is Your Early-stage Startup a Vitamin or a Painkiller?

Last week, I was recording an episode with Jane Portman for my podcast (stay tuned for links and release dates) and as we were talking about moving on from a previous early-stage startup she’d built and sold, she said something that jumped out at me:

“I realized that the product was a vitamin, not a painkiller.”

– Jane Portman

What a perfect analogy to keep in mind as you’re working on your startup.

Most people know they should be taking vitamins. They’d probably even tell you, “Yes! I would love that!” during customer discovery.

For example, the One-A-Day multivitamin that you and I both ought to be taking sounds incredible!

MedTech Startup:
“Imagine that I could help you improve heart health, maintain healthy blood pressure, support your immune system, strengthen your bones, and increase your energy. And here’s the best part! It’s all contained within a single pill that you take once in the morning!”


Everyone two weeks later:

The thing is, people set reminders to take their vitamins, but they keep painkillers close at hand.

You don’t have to be reminded to take an Excedrin. You reach for it when you’ve got a headache.

With a vitamin, you have to introduce the customer to some non-urgent problem in the future (important as it may be) and convince them that your pill is the solution.

It’s not impossible. There are plenty of successful vitamin companies.

But which would you rather try to sell? A vitamin that people turn to when they remember they should be taking it? Or an Excedrin they keep in their purse, bag, nightstand, glove box, and overnight kit?

Telltale Signs Your Startup is a Vitamin

Earlier this year I was working with a founder who’d already built about 85% of a fairly complicated product. We were doing a batch of customer interviews and every now and then the participant would say something that tangentially related to the software the founder had already built. The founder’s ears would perk up and she’d point to the phone and nod emphatically to those of us in the room. “Yes. That right there! That’s it!” she was trying to say.

“Ohhhh dear,” I thought.

If you’re doing customer research and you find yourself convincing the prospect that they’ve got a problem you can solve, chances are you created your solution too early and you probably created a vitamin.

Yes, the problem might exist. Yes, you may have found a way to address it. But, if you’re getting excited every time you catch just a glimpse of the problem in your customer’s workflow, that could be a bad sign.

Look for Signs of a Headache

Customer-centric research goes in search of a problem first. I won’t belabor the metaphor, but it’s a lot more like seeing someone pinching their forehead and groaning rather than pleasantly going about their day with a slight Vitamin C deficiency.

To discover the pain and then design a way to solve it, you need to run some high-impact customer interviews and listen to the customer without searching for validation of what you’ve already built.

Claire and Gia over at have a killer webinar to help you know which tools to use, which questions to ask, and which questions to avoid.

And if you’re still uncomfortable running these interviews after watching that video, shoot me an email let me know where you’re stuck.

What Do You Think?

Are some vitamins worth building? What are other distinctions between SaaS products that are vitamins vs painkillers?

Is this right up your alley?

I send a once-a-week newsletter that you’ll probably enjoy as well. I’ll never share your info with anyone for any reason and it’s easy to unsubscribe.

Early-stage Startups and Uncertainty Go Hand in Hand

I was a guest on a podcast talking about early-stage startups recently and the host asked: “We know most startups fail, but the number one reason is they don’t meet a market need. Why is that?

It’s true, the vast majority of startups fail. Depending on which study you’re looking at, the number is anywhere between 75 and 90%.

My answer on the podcast had more to do with the tendency for entrepreneurs’ vision and personal conviction to override what the market is telling them.

Don’t get me wrong, I’m a believer that in a startup’s early-stage, the entrepreneur’s vision is a legitimate compass for setting product strategy despite what conventional wisdom or market research might suggest.

The trade-off, of course, is that most of the time that vision will not find its way to a sustainable business, but when it does the opportunity is exponentially greater.

And even with market research and a well-defined target customer and maybe even some revenue on day one, the business can still fail. Growing a startup out of the early-stage is very difficult to do for a billion reasons.

The rest of the interview was mostly spent chatting about customer research, how much data is enough to course correct your product strategy, identifying market opportunities, etc. All things that are intended to give your startup a better chance of avoiding that big ol’ number that represents failure.

It was a fun conversation and you can listen to the episode here.

But, I was more interested in thinking through how people like you and me should deal with that inherent uncertainty: That sometimes no matter what you do, your early-stage startup will probably fail.

The Spectrum

If you’re working for or running a startup, or if you hear the siren song of entrepreneurship and are thinking about leaving a salaried position, a 75-90% failure rate is a frightening statistic!

I’m writing these very words as a business owner running a consulting practice while I bootstrap my SaaS, Feature Audit, in whatever spare time I can manage. Objectively, the odds are that both of these ventures will fail. So, how do I sleep at night?

Depending on the week, not very well! 😂

With startups, the highs are high, and the lows are low. Heidi Klum is talking about fashion when she says it, but it applies to entrepreneurship as well: “One day you’re in. And the next day, you’re out.”

Seriously though, the stakes are high. I’ve got a wife and three kids, so failure wouldn’t be a self-contained event. Your specifics are probably different, but the stakes for taking a risk and betting on yourself are most likely similar.

There’s just no way around it, if you want to start a startup or roll the dice and join an early stage, unproven business, you have to decide where on the spectrum you are comfortable living:

Certainty/Comfort/Establishment => Uncertainty/Risk/Freedom

If you’re too risk-averse, you’ll never jump in. The water is just too deep.

And on the other hand, if you’re overly risky and dive in blindly without any sort of plan, you’re even more likely to fail and find yourself as a picture perfect example of the 75-90%.

Find Your Place on the Spectrum of Certainty

Fortunately, the spectrum of certainty does exist and there are more choices to be made other than: a) Bootstrapped Startup, or b) Multi-national Enterprise.

If you want to join a startup, there’s a big difference between a seed-stage company and one that’s in their fifth year of profitability. The trade-off is in how much equity you’ll get to participate in.

If you want to start a startup, there’s a big difference between starting at $0 in the bank and sucking it up for a while to put 9-months of expenses in the bank first. The trade-off is in how long you’ll need to be patient.

As in most things, the “right” answer is contextual and personal, and you can’t answer it without knowing yourself and what your season of life might call for. What’s more, the “right” answer isn’t even right, it’s more like “relatively close to optimal.” 🤓

But hey, if you’re dipping your toe in startups and entrepreneurship, you’re probably already comfortable with that kind of ambiguity!

Feature Audit, Underdoing the Competition, and Hans Rosling on UI Breakfast Podcast

The following is a transcript of an interview with the Jane Portman on the UI Breakfast Podcast.

Jane: Hello ladies and gentlemen, and welcome to the UI Breakfast podcast. I’m your host Jane Portman, and today our guest is Brian Rhea, product strategist and founder of Feature Audit. We’re going to talk about SaaS feature audits today. Hi Brian!

Brian: How’s it going, Jane?

Jane: Going great. Can you tell us a bit about yourself, what kind of work you do, and how you ended up having a software product related to features.

Brian: You bet. Right now, I’m doing product strategy and consulting for startups. I’m based in Boulder, Colorado, but I have clients in New York, California and Texas. Which is just a whole lot of fun. It gives me a chance to hop around from time to time, which I enjoy. And I love working with folks from all sorts of different areas.

But the way I got into product, was about 6 or 7 years ago. I was living in Dallas and freelancing, doing web development. My wife and I just love Colorado, and have always just loved Colorado. We found ourselves vacationing out here often, as many people do, and on one of our drives back to Dallas, we just looked at each other and said, “You know? People live in Colorado. We could try that!”

So, I built this goofy little site at the time, called “,” and it was my best attempt at making some jokes about how hot the temperature was in Dallas, and how much we love Colorado, and also– here is my portfolio! Oh, I also build websites– is there somebody I could help out?

Then I reached out to Brad Feld, who is like the Godfather of startups in the Boulder area; many people are familiar with him and he is very influential. On a total lark, I emailed him and said, “Hey Brad, if there’s anyone who could make this happen, it’s you. If you tweeted ‘Someone should’, I am sure it would happen.” I sent it off and just didn’t expect anything would come of it.

I kept grinding at sending cover letters to startups in Boulder and Denver. And then one night — literally in the middle of the night, I was feeding our newborn while my wife got some sleep — I looked at my iPad, and I had 100 notifications on my email. I thought, “What in the world is going on?!,” and scrolled to the bottom, and the first one was a reply back from Brad Feld that said, “Tweeted. Good luck, buddy!” or something to that effect.

The next few weeks became a whirlwind of getting to talk to a bunch of different startups in the area, and I eventually joined an incredible team at a company called Mocavo. They were a Techstars company and backed by The Foundry Group, had a brilliant leadership team, and just a great team all-around. I joined up with them, and it was through that process of working at Mocavo that I went from Front-End Developer to UX Lead and eventually into an Executive Product role. And that is where I really fell in love with what I do now, which is product strategy and Jobs to Be Done, identifying priorities, and how to design an effective roadmap that a team can follow.

Jane: Wonderful. What was your value proposition back then, when you got that score of clients, because it is typically a beginner mistake to hope that someone famous is going to tweet about you, and the world will turn upside down. I’m surprised that worked for you. So what did you do “right”?

Brian: [laughing] Yeah, totally. That’s a great question. I’ve actually written about this on Brad’s blog. He asked me to do this thing. If people would google “hirebrianrhea one year later,” I go into a little more depth on what you’re asking: why did this work? I’m under no illusion that you can definitely mastermind that sort of thing. There was a fair amount of luck and timing that went into it.

But at the time, a couple of things worked. One was that the site that I built told a story. I got some help and feedback on it from my wife, who is really good at editing. I tried to make it much more like an interesting story, like “Here is a family” and put some jokes in there about the temperature in Texas vs. Colorado and let that guide you as you scrolled through. A Story unfolded; it wasn’t just a typical “here is all my stuff”.

Of course I included my portfolio and skills. And I also some included some personality stuff, like, “Here is my reading list. What is on the office bookshelf? Are we a fit for each other?” I was trying to hit on multiple things. Warranted or not, there was enough technical ability demonstrated in the site itself, and some design integrated as well, that enough of the companies that were able to see, “This guy is a good design and development unicorn, and we have to jump on it.” I am much more skeptical of my development skills, than those companies were, thankfully! But there was definitely a positioning piece there that worked.

As far as the email to Brad Feld, I was very direct. I said, “Look, you’re a busy guy. This is what I’m asking you to do. Here is how you can help me. Will you help me?” Important people don’t have time to read a big, long thing. If you’re asking someone of influence for help, be very direct and ask them for help. They either want to help and have time, or want to help and don’t have time. Either way, you need to respect their time as much as possible. I think those are the elements of it that worked.

Jane: Totally true. As a side note, those attempts to mask your outreach attempts never work. They look miserable. So going in short, brief and direct is the best strategy.

Brian: That’s right.

Product Strategy

Jane: So back to your product and strategy work. Who is your typical client, and what do you do for them?

Brian: My typical client is a startup who is still searching for product-market fit. I’ve had a number of clients who have a good idea of who their customer is, and they have a lot of clarity–well, that is a bit of an oxymoron. [laughing] They know if they had all the money in the world, and could fast-forward two years, they know exactly what their product would do. But, in the present day, with limited time, money, energy and no customers, they ask, “Ok Brian, what are the first four things we should build? Or, what is the one primary customer journey that we need to create?” That is my typical customer, who probably doesn’t have any users yet, or if they do, they’re not hockey-stick product-market fit raising tons and tons of money. They’ve got either a couple of interested people that they’re dying to put the first version of something in front of to start learning, or they’ve got that first thing out, but it isn’t exactly hitting yet.

What I can do is come in and help them understand their customers a bit better, give some additional perspective there, and then help them figure out how to prioritize. I help them prioritize among the things they’re imagining they’re going to do either because they’ve done some research themselves, or because they’re their own customer – they have domain expertise and know the things that it needs to do-, or because they have a handful of customers who are asking for things. The process of figuring out how to prioritize, to know what to say “yes” to and what to say “not now, not yet” to is quite hard. That is what I often end up helping folks with.

Jane: What is your “secret sauce”? Do you have any special process to help those struggling startups?

Brian: Yeah, I think the “secret sauce” is, well, consultants can get a bad rap, but I really do think there is immense value in pulling someone else in with an additional perspective. I always start with “No.” And that’s being able to help the entrepreneur say to themselves, “Yes, of course it would be better if it included *This’*, but we’re going to say, ‘No,’ and we’re going to force that feature or that additional thing you’re wanting to do to make a really, really strong case for itself.”

We can’t just respond emotionally right now and say, “Let’s do this,” and figure out how to slip it in and make it work within the budget. No. We’re going to say, “NONE of these; what are the FEW things that make a very, very, very strong case for themselves, either because they keep coming up or every single customer is asking for it, telling us it is extremely important and they’re very unsatisfied with their current solution.” And so, I think, offering that push and that perspective is most helpful.

Jane: That’s wonderful. And that’s also a perfect stepping stone to our main topic, which is Feature Audit. That’s also the name of your software product. It’s obviously supposed to help software companies prioritize and figure out what exactly brings the most value for their users. Tell us more about that.


Brian: Feature Audit is a tiny little analytic tool that helps you make better product decisions in seconds. The way that it helps you do that is that it plots each of your features on a chart that will show you how many people are using a feature, and how often. So, it answers questions like: Are all of your users using something all of the time? Are all of your users using something none of the time? Are very few of your people using a feature all of the time, or very little of the time? And everything in between.

If any of the listeners have ever seen Hans Rosling’s TED talk where he’s got those beautiful bubble charts moving across time, that is what Feature Audit is modeled after, because it allows you to see the movement of a particular feature on those quadrants over time. If you go to, you can click a little green button that says “See it in Action,” and you can kinda get a sense of what it does.

The original idea – the germ for where this came from – happened while I was working at Mocavo, the startup I was talking about earlier. There would be a lot of times in conversations where there would be an argument over a bug that came through. What sort of priority should that particular bug get? Even at the time, I was also coming from a position of, “We’re not going to prioritize it until it makes an argument for itself. We’ve set our priorities, we’re going to work on those things. We’re not going to do this just because a few people are trying to set off a fire alarm.”

Being able to get quickly to the answer to, “Well, somebody reported a bug on this feature. How many people are using it, and how often?” If only 5% of our customer base is, that’s actually not a very important thing, even if it is part of the core. I’m sure people might be able to relate to this, but you can get to the answer of that question without Feature Audit using a combination of Google Analytics and clicking three layers deep or a batch of sequel queries, where you have to wait on your back-end guys to get that answer back to you. So my goal with Feature Audit is that with just a tiny javascript segment, you’d be able to see that answer in just a few seconds.

Jane: One of my questions that I had prepared for you was, “How do you recreate similar functionality without your tool?” Because of course it is great to have a tool that solves everything, but you just mentioned that it is painful digging through inquiries and so forth.

Underdoing the Competition

Brian: Yeah, so that is my hypothesis, Jane. Analytics tools have been around for long enough that, in a lot of ways, they have overmatured. So they are very feature rich, which can be great. But, as we know, and especially, gosh, YOU — this is your whole thing with UI, right? — that as things become feature-rich, they become harder to use.

My hypothesis here is, “Ok, I want to dramatically under-do Google Analytics on purpose. I’m going to under-do Analytics on purpose so that I can get to a very specific answer in a few seconds.

And then — this is the part of the product I’m still working on and developing — allow my customer to reach out to those users in a very simple and seamless way.

So if you identify that very few of the people are using a particular feature all of the time, it would be nice to get 4 or 5 of them on the phone and get some qualitative feedback on:  What is going on here? How did you adopt this feature, and what can we learn from that, so that we can get more people to adopt the feature? And then we could move it from a few of the people all of the time, to most of the people all of the time.

Jane: That’s wonderful. I love the way you put it: Dramatically under-do. It is exactly the same strategy we followed with UserList, which was to under-do the email sending part of Intercom and do it well. That approach resonates with me so much; sounds amazing.

Brian: Real quick, I’m glad you mentioned Intercom there, because part of the origin story of Feature Audit that I didn’t get a chance to get to, is that, as I was struggling with those problems, asking, “How important is this? I wish there was an easier way for us to get to it,” Des Traynor wrote an article where he describes performing a “Feature Audit.” That is where the name comes from. I read that and thought, ‘Des! This is genius. Who is currently doing this?” And I still have yet to see a simple implementation of it, and so that’s what I’m going for. [laughing] So we’ll see, Jane, how it turns out!

Jane: Isn’t that amazing, that Des Traynor has so many amazing materials and talks about making the product simple and usable. However, Intercom itself is beautiful but so complex. Oh my goodness. How can you do both?

Brian: Yes. I think there answer there, Jane, is, can you imagine how complicated Intercom would be if Des Traynor were NOT on the leadership team there? [laughing] But you’re right. And I’m sure, five years ago, Intercom was easier to use than it is today. It’s just what products and software- software especially- want to do. It WANTS to get complex over time because you have to make these, what Clayton Christensen calls, “sustaining innovations.” You have to continually incrementally improve the thing, that add a little bit of value, but not as much as everything that has come before it. And every new thing you add reduces usability. It’s a tough balance to strike, right?

Jane:  Absolutely. So as a consultant, and product leader with experience with multiple products, what do you do with the results of that feature audit? Do you have any recommendations whether you can go as far as removing features from a product to make it better?

Brian: Yes. Being able to offer some visual proof and evidence that you should delete a thing is super helpful. Both at my startup and with multiple clients I’ve had as a consultant, there is such a resistance to removing a thing that very few people are using.

Most of my clients are small startups, but I have one client that has product-market fit, has been dominating their market for a decade, so they have some real big fish that are their clients. The thing was, there was this feature that we knew wasn’t used often and we knew it was only used by a few people. But it was used by some extremely important people. Certainly, that is a separate conversation about the business case.

More often than not, the resistance to removing something is emotional and reactive. My hope is to be able to provide statistical evidence and support for why we should do it– let’s remove it, no one uses it anyway, it will clean up our UI, it will improve the user experience because less people will be confused. The other part of it, like I alluded to before, is that if you see something that has high-frequency of usage, but low adoption — so a few of the people are using something most or all of the time — you can ask, “Why is that? How can we get more people to adopt it, and pull this piece of the product into their daily usage?”

One of the things that definitely helps in reducing churn is to increase habits. The more often people feel like a piece of your tool is absolutely essential to their daily work flow, the harder it is going to be for them to churn out, or adopt a new thing. Habit is a strong force.

Less is More

Jane: As you mentioned, one approach would be to remove something that is not used very much, and another would be to make your strong points, stronger- to work on them and improve your UX, adoption, etc. Do you recommend grandfathering in, or maybe turning on and off certain features for certain users? That is super handy. So maybe you could switch it off for everyone, and only keep it on for those important people that need it.

Brian: Ok, if there is a really, really strong “business case” for that, you could make that argument. The trade-off you’d be starting from is that you’re guaranteeing ongoing engineering maintenance for a sliver of customers. Now again, if the business case backs that up and funds that amount of time for X amount of engineers, then so be it. That is a C-Suite decision, and fine. But I would not start with that as a recommendation. It is not going to be as easy as it sounds, you know? It is going to hamstring you on future updates for sure, and so on.

Jane: The question is, if you have a number of loyal users who have been with you from the very beginning, and then you decide to focus your app and cut-off certain functionality, how do you manage those relationships with them?

Brian: Yeah…that is a very hard question to answer. And, it’s an unsatisfying answer. But I think that it depends. One example of this that, from the outside at least, it seemed like they did it very well, was when Basecamp froze a version. I forget what they’ve named them now, but at one point in the past, they froze a codebase and said, “OK, people, if this is where you want to stay, then you can stay here forever. This is where your data stays, we’re not making any additional updates, here you go. But we are moving on to this new version, and it is going to do some things differently, and if you’d like to come across, then here is how you do it.”

I’d be really curious to read a case study on how that worked out, but in general, I feel like the specifics of being able to give a blanket answer to, “Should you preserve and continue to maintain features that you know are not valuable for most of your audience because you have a few people who use them?” The default answer would be “No,” not if you think your future growth is most likely to come by leaving those things behind and moving on, but in the short term, figuring out how you manage that; that has to be so contextual.

Jane: Yeah, let’s not talk about WordPress enforcing their update onto everyone, and breaking half a million sites across the planet.

Brian: Ooooooo, Yeah…. [both laughing]

Jane: Let’s not talk about that! Let’s talk a little bit more about the technical side of your product, Feature Audit. I feel like UserList and Feature Audit are somewhat similar, because we kind of tap into the user behavior and try to record it. We do something, and analyze it and we send an email based off that, but the tracking part is pretty hard to implement and onboard users about.

Brian: [chuckling] Yes, oh me, too.

Jane: We’re struggling with that, because we require manual integration. Tell me, what are your decisions in that regard?

Brian: So, right now you install Feature Audit with a single-line javascript snippet. On the one hand, that is very straightforward. On the other hand, it’s not always super easy for my first customer to do, either because they’re in a Marketing role or a Product role, and don’t have immediate access to the codebase. So, there is that. Additionally, for Feature Audit to work best right now, individual events need to be posted in the same way events are posted to Google Analytics.

For sure, one thing that it is currently doing behind the scenes is automatically tracking each and every click. On the technical side, Feature Audit knows if you’re clicking on an anchor tag, an image tag, a piece of text, or just somewhere random in the document. So I’m recording all of those things.

One of the future improvements I want to make is to make it very, very easy to automatically map a click-type to a specific feature, if that makes sense. We can dig into the technicals on that if that is not immediately clear. But right now, yes – you include the one-line javascript snippet in the same way you would post events to Intercom or Analytics, or a number of other tools. You post an interaction as being a feature.

User Onboarding

Jane: So, what is troublesome about that approach? Is it the onboarding part or is it the technical part on your side?

Brian: It’s totally just getting it installed, for them – for the customer.

Jane: Even a snippet? Not to mention the full integration?

Brian: Yeah, what definitely increased some activation has been making the documents very, very specific with how to integrate with Google Tag Manager. Most people already have GTM set-up, and so I’m highlighting, “Look, you don’t even have to install anything new, you actually just have to log into Tag Manager and drop this in there, and Boom!, away you go.”

In terms of me being able to increase adoption on this thing, the next step is: “And also, you don’t have to worry about reporting or posting any sorts of events. Feature Audit is going to record them all, and then you’ll be able to just go in there and select ‘These click-events relate to this feature; these click-events relate to this feature, and so on’ and I will handle it all from there.”

Jane: I think that is similar to the approach that Heap takes. They record everything, and then they decide retrospectively what you want to do.

Brian: Yep, Heap and Pendo. Again, that just plays into my hypothesis. Those are great tools, but very heavy.

Jane: Another side and hardship is to decide what is actually called a feature, when you conduct that feature audit? Let’s’ say you’re a consultant and you want to come into a SaaS business and use your tool to write a report. How do you figure out what goes into that grid? What makes a feature, and how many should you track, and how do you organize them?

Brian: One of the events that Feature Audit tracks that I didn’t mention is “page load,” so in terms of grouping and mapping, where you often start is at the page-load URL level. Like, is someone going into Dashboards, into Events, into Community? Let’s start there and see which of these areas of the site or the application are most popular. Ok, we can begin there. And now we can group within that category or within that high-level feature, what “featurettes” or what tiny interactions, people are using.

One of the areas I recommend starting with is, “Ok, with our current UI and our current design, what are we saying are the most important pieces? What have our assumptions said, internally or with some degree of customer-research, that led to these design decisions. Let’s measure those. Are people actually using them?” And you can start to get a better sense through the data of how close to correct you were, and modifications you can make based on some support from qualitative customer interviews based on that data.

Jane: How did you arrive at this interesting representation of these floating bubbles? You mentioned the TED talk, and we will link to it in the show notes, but generally speaking what made you feel like this is going to be a legit and useful represernation? I think the deliverable is the video, and that is definitely not something that goes into PDF. It can go into PDF, but it is not very classic– you can’t print it.

Brian: It came to me in reading the Des Traynor post that I had mentioned, he has these different quadrants, and he is basically making the argument that as product owners, we probably want all of feature bubbles to be moving up and to the right. And I thought, “Ok, but you need to be able to see that and summarize it visually and over time.”

I remembered that brilliant Hans Rosling talk that is so fascinating, and did a little bit of looking into D3- Javascript library. Lo and behold, you can do exactly that, which is to show the movement of a plot point on an X- and Y-axis over time, which is basically what this is trying to do.

It wouldn’t be as instructive if you could only ever see today’s data. You would want to be able to look back over time and say, “We identified four months ago that this feature is high value to the very few people who use it. We decided we wanted to make it more valuable to more people. How have we done that? Let’s isolate that one specific feature, hit play, and watch it move.”

Jane: I can imagine that would be a moment of joy or a moment of tragedy, depending on how it moves actually.

Brian: [laughing] That’s totally true.

Product Vision & Strategy

Jane: With this product, what is your big vision for it? I know you set out to build an under-designed version of an analytic tool, but what is your grand vision for that?

Brian: My grand vision at the moment is for it to be successful enough that I can make the migration from full-time consulting over to running a software product again. I don’t want to end up raising money on it if I can bookstrap it or just get a little bit of angel investing, then great.

My total grand vision for Feature Audit is that it would never need to be more than 15 or 20 employees working remotely, or maybe a handful of us in downtown Lafayette, Colorado. It doesn’t need to be this massive juggernaut in order for me to feel like it is successful. I want us to have very high revenue per employee– that’s the metric I’m most fascinated with– not total MRR or anything like that. MRR per employee is most interesting.

Jane: That is perfect vision and aligns with my line of thought very much. Making a simple product and getting it into the hands of thousands of people is a success in itself. You don’t have to overcomplicate  the product to achieve that. So, as we’re wrapping up this episode, if you were to give advice to someone who decides to conduct a Feature Audit in their product, what would be a few simple steps that they could follow, with or without your product

Brian: Without the tool, it can definitely be done. I would say at least begin there. Chances are good that you have Google Analytics already installed. Chances may not be as good that you are tracking specific events, and so start there. Start at the high level we spoke about earlier.

You can use a tree map or something to that affect to identify the major areas or features of your application that are getting most of your resources — either engineering, design, marketing or otherwise. Drill into the high priority elements within each of those, and be sure that you are tracking them. Just start there. Collect a couple weeks worth of data, and observe what it tells you. Using that data, and without signing up for Feature Audit or using it, you can replicate what it does and what it shows you. Begin there.

Then, if you see a lot of value you in that and want someone to do it for you on your behalf, then check out: While we’re at it, you can use the coupon code: UIBREAKFAST to get 50% off your first 3 months.

Jane: That’s great! Thanks for that discount. If people want to follow your writing, your thoughts online, what would be the best place to do that.

Brian: You can find me at or on Twitter at brhea. I’m not on Twitter as much these days, but you can still find me there and reach out and talk. We talked a little bit about product strategy on the podcast and didn’t get too much into Jobs to Be Done, but that is a framework that I find a ton of value in.

One of the things you’ll see on is this Jobs to Be Done resource library. It’s basically my google drive folder where I’ve just put all of my resources that I use: Interview Timeline Sheet, Outcome Statements template, Forces of Progress template, Swipe file for customer interview emails that I send, workshop agendas, all sorts of things that I use, I throw into this Google Drive folder. If anyone wants access to that, there is a place where it asks for your email address, and you can get access to that.

Jane: Thank you so much for sharing that. I genuinely enjoyed our conversation today. It was awesome. I learned a ton and I hope our listeners did, too.

Brian: It was great! Thanks for having me.

Customer Acquisition & Customer Retention

If you’ve signed up for my JTBD Email Course, then you’ve heard me talk about the Forces of Progress already. Or, if you follow the Rework Group, you may have heard them unpack this powerful concept that can be helpful in understanding your customers’ decision-making process.

I originally posted this short video to LinkedIn, but I’ll share it here as well in case you’d rather watch than read:

The Forces of Progress

When someone is deciding between sticking with their current solution or switching to a new offer, they find themselves in the middle that image, experiencing the forces of Push, Pull, Anxiety, and Habit.

And if Push + Pull is greater than Anxiety + Habit, they’ll switch!

If not, then the benefits of the new thing aren’t worth the perceived pain of change.

Make sense?

Push is everything your current situation is doing that drives you crazy. It’s the classic infomercial “There’s Got to Be a Better Way!” feeling.

Pull is the promise of the new situation. The grass is greener on the other side. That new thing over there looks way better than what you’re currently doing.

Anxiety is that nagging fear that you’ll end up with Buyer’s Remorse. What if it isn’t as good as they’re making it out to be? And what if learning the new thing turns out to be super hard? What if you end up spending all the time learning the new thing that it was supposed to save you?

Habit is telling you, “Look, maybe our current solution isn’t perfect, but at least we understand it. It might be a mess, but it’s our mess.”

Customer Acquisition

Acquisition: Increase Pull and Reduce Anxiety

When we’re thinking about how these forces affect Customer Acquisition you only have total control over the right half of the diagram:

You can’t make your potential users’ current solution push them away and you don’t have an influence over the habits they’ve developed.

But! You can sure as heck pull them toward you and reduce any anxieties you know about.

What are people worried about that’s keeping them from giving you a try? Surface those fears through interviews and see if there isn’t a way to design a solution. For example, if you’re a CRM trying to pry a customer away from their existing system, create an automated process for importing their data and let them test out 100 rows for free.

Customer Retention

Retention: Reduce Push and Increase Habit

And in terms of Customer Retention, you have more control over the left-hand side of the model.

Reduce push by, you know, not sucking 😂.

Increase your customers’ habits by finding ways to deepen the sense of familiarity your customers feel toward your service.

Nothing shady and no dark patterns like locking up their data, but the goal of increasing DAUs is directly related to the effect that entrenched Habits have on the equation.

Conduct Some Interviews and Use the Forces of Progress Cheatsheet in my Resource Library

To make this Forces of Progress model actionable, you’re gonna need some data!

So, line up some customer interviews and use the “Forces of Progress Interview Template” I’ve shared in my JTBD Library. As you talk to your customers about their experience in using your product, listen for the stories they share and how they relate to each of the four forces.

Find ways to use that information to decrease churn, increase retention, and grow your business!

Want to Level Up Your Product Design Process?

Get free lifetime access to my personal Jobs to Be Done Knowledge Library and level-up your skills and resources in minutes!

Use the email scripts, interview templates, presentations, and book summaries I’ve created over the years to level-up your skills today.

Jobs to Be Done Framework on the Product Popcorn Podcast

The following is a transcript of an interview with the Product Popcorn podcast on Jobs to Be Done.

Welcome and Introductions

Kimberly: Hello and welcome to Product Popcorn- the podcast that explores topics related to product management … Most of the time. We talk with product managers and also designers and engineers that work on product teams, and only sometimes discuss the possibility of artificial intelligence taking over the world.

You can always

Today on the podcast my guest is Brian Rhea. I recently saw Brian speak at Rocky Mountain ProductCamp and he did a presentation on Jobs to Be Done Theory and I definitely wanted to share it with my podcast listeners. I had never heard of Jobs to Be Done (JTBD) before seeing Brian’s presentation, and now I am absolutely obsessed. It’s changed the way I think about my product and its features. Use this theory when you’re scoping out requirements, thinking about your product’s competitors and, especially, working with your UX team. When I originally saw Brian present on Jobs to Be Done at a product event, he talked about conducting JTBD customer interviews, demonstrating how to elicit the “job to be done” from the customer, and examples of a Job to Be Done.

Brian has a free email course about Jobs to Be Done, and the fourth and final email focuses on how to conduct these types of customer interviews. If you want to delve deeper, I highly recommend signing up for the Jobs to Be Done emails on his website.

Let’s go! I’m Kimberly and I’m a product manager.

Adam: I’m Adam and I’m a front-end developer.

Kimberly: We have Brian Rhea on the podcast today and he is going to talk about Jobs to Be Done. I’m super pumped. I saw him talk about this at Rocky Mountain Product Camp and it was great. It’s kind of a big topic in product management right now, so you should all really listen and take this one to heart. We are going to intro Brian right off the bat. Brian, you have a development background and now you freelance and do product strategy.

Brian: Yeah, so the career trajectory has been odd and winding, because even before Front-End Development, if you scroll all the way to the bottom of my LinkedIn profile, you’ll see I was an art teacher for five years. I got into the internet in 1994-95 because my dad owned the ISP (internet service provider) in our small town. When I was about 14 years old, he said, “Hey, Brian, I think the internet is going to be big, so you should learn how to build websites.”

And I was like, “Cool, let’s do it!” He would go around selling websites to the businesses in town, and then bring them home to his 15 year-old kid build.

So that’s how I got my start. Then I went to college and got into Art and Art Education, but got back into the internet after a bit of a winding road. My background was in HTML, CSS and JS and so I was a freelancer in the Dallas area. Then we moved to Boulder, where I joined a startup.

Kimberly: Which startup?  

Brian: It was Mocavo, a Foundry-backed, Techstars company. It was an amazing team to join. And through that experience is where I went from front-end development, to UX, to a product strategy role. And that is where I first started to learn about JTBD, and fell in love with the strategy side of things. But I also found that I just can’t give up the “maker” aspect of it all. So that is why this position now, where I do product-strategy consulting and also build MVPs (minimum viable product), is such a great fit for me.

Defining Your MVP

Kimberly: Before we go into Jobs to Be Done, there was something that you said at Rocky Mountain ProductCamp that I thought was really interesting and I wanted some feedback on it. We also had a listener question that was very similar to this, which is: how do you prioritize?

You said that product teams typically need to build much less than they think. When you work on an enterprise product, like I have for the past few years,  you have people above you saying, “This is your MVP,” when you know the MVP should really be cut in half or more. So how do you accomplish that? How do you whittle it down?

Brian: This will definitely be related to what we talk about later. But if the person assigning you that scope says, “Here is the MVP,” and if they have a true appreciation for what MVP (minimum viable product) means– which is, maximize learning while you minimize investment and minimize risk– then what you should do first is determine: what is the core problem that we’re attempting to solve here? And, what is the cheapest and fastest way that we can get to that?

So often I see the “MVP” is actually just the first tolerable version that the stakeholder can allow themself to release. If what you can help them answer is “What is the Core Journey?”, or, put another way, “What is the primary outcome that we’re going to get from this?”, then you can agree on that. And from there, you will be able to look with them at all the rest of the scope that has been defined, and determine from there what is not actually required.

Adam: Would you say that there needs to be a certain amount of “shame” about your product? Like, you should be a little bit ashamed of it because it is so minimal? [laughter]

Kimberly: We talked a few episodes ago about how you should be ashamed of the first version of your product, or else you’ve launched too late.

Brian: Yeah, totally – and they recently made a joke about just this on [the T.V. show] Silicon Valley! You might might kind of be embarrassed because you know that it’s not finished. You know this thing you’re releasing is not your whole grand vision. But that is always true. Software is never finished. You could spend a year building the perfect “cathedral” product, release it and what happens? You’re going to get customer requests. You’re going to start getting feedback. You’re going to change it.

So you might as well get to release faster.

The Different Types of MVP

Kimberly: Things become outdated so quickly, too, which is something I don’t think people understand. And competition catches up and software does become junk in a few years, unless you’re continually improving upon it.

Brian: Right, and you should be. There’s a great chapter in Cindy Alvarez’s book “Lean Customer Development,” where she he outlines about five or six different types of Minimum Viable Products. For example, there is the pre-order Minimum Viable Product, where you’re just putting up a fake thing. Another example is “The Wizard of Oz” Minimum Viable Product, where it looks automated, but there’s lots at work behind scenes keeping it running.

But one of the types she talks about is the “Single-Use Case Minimum Viable Product”. From what I know about Enterprise organizations and that style of approach, the product manager’s role is to be advocating for the customer’s outcome. You’re saying, “This is the thing that we think is going to matter the most. This is what’s going to have the biggest impact for them and, therefore, our business. So, can we refine it down to this single-use case?” And then nail that.  After you get that, you can go from there.

Kimberly: There you have it. That’s how you get your MVP winner.

Jobs to Be Done

Kimberly: All right. So let’s get into Jobs to Be Done. First off, you said that there’s a little bit of ridiculousness around Jobs to Be Done and how it started.

Brian: If people are learning about Jobs to Be Done for the first time right now, what I can almost guarantee is that they’re going to start following a couple of people on Twitter who are the big names. And then they will start seeing this really weird tension and rivalry, which is bizarre.

I originally heard about Jobs to Be Done through Jason Fried and Ryan Singer at Basecamp. They started talking about how they were using Jobs to Be Done on their product, and being a huge Basecamp fanboy, I started looking up everything I could about it.

Clayton Christensen on Jobs to Be Done

Brian: I found this YouTube video of Clayton Christensen, who is the author of “The Innovator’s Dilemma,” where he shares a story about him and his consulting partners working with a fast food chain. They had been brought in to help them improve their sales of milkshakes. The fast food restaurant had done all this market research, focus groups and everything, but nothing was working, which is why they brought in Clayton Christensen and his guys.

He and his partners sat in the fast food restaurant for about 12 hours. As people were walking out of the restaurant with actual milkshakes in their hands, they would stop them and say, “Pardon me, what job did you hire that milkshake to do?” And they actually phrased it more like, “Why did you buy that milkshake just now?”

And the pattern they observed was that in the morning people were “hiring” a milkshake to keep them occupied on their long, boring commute. A milkshake fits in your hand; it fits in the cup holder; it’s thick; it takes forever to drink; it gets your stomach full, so you don’t have mid-morning stomach grumbles.

Compare this to a donut, which is messy and gets all over your hands. Or compare it to  to a banana, which is clean, but it’s over in about six bites. So the milkshake gets that “job” done perfectly.

It’s through that story that I started to think through the framework of hiring a product to “do a job” in the way that a company hires an employee. The company starts to feel the pain of “We need another designer” or “We need another Product Manager.” When that happens, they put out a job posting and find the right fit. When you feel pain as a person in your everyday life, or you’re not making progress in an area of your life, you post a “Job to Be Done.”

Kimberly: That’s a great analogy. I hired [virtual-assistant device from Amazon] Alexa to play the correct playlist for me, except she doesn’t listen to me. So I think I should fire her and find somebody else to do that job, because it still needs to be done. Now we’re getting way off topic. [laughter] Okay, what is the new book by Clayton Christensen?

Brian: His newer book is Competing Against Luck.”

Theodore Levitt on Benefits vs. Features

Kimberly: Yes, Okay. So then, let’s talk about Jobs to Be Done and what it’s used for. And now we can go into the drill bits. Who is Levitt, by the way? This is Levitt’s quote.

Brian: Ted Levitt was a professor at Harvard in the early 1960’s, and that is when he said the famous quote: “People don’t want to buy a quarter-inch drill, they want a quarter-inch hole.

That gets to what we still talk about about, which is selling benefits instead of features. When you design a feature, its normal to want to Feature, Feature, Feature. And I’m guilty of this, too.

Kimberly: That mindset is really helpful. I heard a quote on a business podcast the other day – I can’t even remember where – but somebody was talking about the railroad industry a long time ago. The railroad companies didn’t get into airplanes and flights because they said, “No! We’re in the railroad industry.” And the guest corrected the host, and said, “No, they were in the moving-people-around-industry.”  I thought, “That’s a job to Be Done!” People don’t care that it’s a train; they hire the train to get them to where they need to go. And that’s kind of the same job that a plane does, just not in as effective of a way. But it’s jobs!

Brian: That is spot on!

Jobs to Be Done in Product Design

Kimberly: Can you walk us through any specific scenario or scenarios were Jobs to Be Done would be useful?

Brian: Sure! Jobs to Be Done is most useful in a setting where you’re trying to develop something new. For example, you may have the Job to Be Done right now of:

Help me produce a quality podcast.

What if we were to try to design a new product around servicing that job? Okay. There are about five things we would look at. They include:

  • the progress that you want to make
  • the context that you’re in
  • the obstacles that you’re currently facing
  • the hacks that you’re currently using to get that job done
  • and finally, how you might define quality.

Unfortunately, it’s like PCOHQ, so it makes a terrible acronym. [laughter]

So in our example, the progress you’re trying to make is “help me deliver a quality podcast.” The context that you’re in is that you, and many thousands of people, are now self-producing podcasts. You’re not in an official, formal studio. And that is your context.

The obstacles that you probably come up against probably include finding guests and everything associated with that. You have to find people to come on the show, prep them a little bit, and send them an outline. And also, when you do the recording, you have to edit out all of Adam’s swear words [laughter]. When you upload it, you have to worry about compression and stuff like that. So those are the obstacles that you come up against.

What are you hacking together currently? You’re using email, maybe using GarageBand to slice and dice things, maybe your phone to get some audio, and who knows what all else. You’re putting all these different things together and so finally, what would quality look like to you?

To answer that, you might say that what would be helpful is to have a system that managed the people you reach out to you, your schedule, people who are appearing on other podcasts on these topics, and just the different things to piece that together for you.  You would be able upload it, edit super easily and then distributes to all of the different places.

So through identifying those five things across 12 or 15 interviews with other podcast producers, you would start to be able to see if there’s enough energy here that people are willing to pay for a solution. You would either see that there’s a market for this and it’s worth putting some effort into building or that yes, people are all struggling with this, but not struggling enough.

The core thing that Jobs to Be Done tries to describe is, “How much struggle is there, for it to actually be a ‘Job to Be Done’?”

Want to Level Up Your Product Design Process?

Get free lifetime access to my personal Jobs to Be Done Knowledge Library and level-up your skills and resources in minutes!

Use the email scripts, interview templates, presentations, and book summaries I’ve created over the years to level-up your skills today.

Jobs to Be Done and the Forces of Progress

Kimberly: That was one of the things I remember most from your talk at ProductCamp was you had that visual, which I can put in the show notes, but it was that user have to struggle enough to make them make a change. I think you used the analogy of changing cell phone companies or something like that.

Brian: Yes. That’s the “Forces of Progress” diagram. Basically, the algorithm for change in customer behavior is Push + Pull across the top of the diagram, and that is over Anxiety + Habit. Imagine “push” is like something sucks, and you hate it. And “pull” is something looks great and new, so you’re being drawn to it.

Jobs to Be Done: Forces of Progress

Those two are over anxiety and habit on the diagram, and so “anxiety” is like saying: well, I may do that new thing or I could switch to that new thing, but then I have to learn it and what if I suck at that or what if they’re lying? And then “habit” is saying: well, I don’t love what I’m currently doing, but I at least know how to do it.

Push + Pull has to be greater than Anxiety + Habit in order for a new behavior to happen.

Kimberly: This is why we’re all using Jira at work. Habit. It’s habit! It’s like our anxiety with it isn’t quite high enough to pull us to something else. We can go into Jira rant at any time that anybody wishes we.

Brian: But the habit is probably so ingrained–

Kimberly:  It’s so ingrained, and even though we know that it’s just hacked together and we know that they just kind of throw out features to try and solve individual problems and it doesn’t really go with the overarching flow of software, we keep using it. I think it’s it’s a good idea. It’s a good example of something that everybody hates, but the anxiety just isn’t quite high enough to make everybody go to Rally.

Jobs to Be Done and Market Competition

Adam: I’m curious how you would quantify this. I know you’ve given a formula here, but how much anxiety does there really have to produce to create a change– and not just for Jira.

Kimberly: Like when I change from Android to an iPhone? It was causing a lot of anxiety. Also. I wanted to be cool. [laughter] So that was that. I’m trying to think of another example. Adam, what’s Shutterstock’s biggest competitor?  iStockphoto? Getty?

Adam: Yeah, they’re the same.

Kimberly: Do you ever have users switch over to Shutterstock from those competitors?

Adam: I don’t know numbers or percentages or anything like that, but it makes me  wonder. A lot of people know Shutterstock– it’s a multibillion-dollar company– but a lot of people don’t know it. I think that  they’ve seen stuff from Shutterstock and they just don’t make the association to where it came from; the brand doesn’t necessarily stick in their head. And I think it’s actually the same thing for Getty, where people see a lot of iStock’s and they don’t necessarily realize, “Oh, that’s from iStock,” even though it says “iStock” on the photo.

Kimberly: I would just be really curious to talk to your sales team or product managers to know what are the anxiety or the pain points that are going to make a user switch from Getty to Shutterstock. It would be interesting to see.

Brian: Relating it back to the milkshake example from earlier, where the milkshake is not competing against other breakfast products. It’s competing against a banana. I guess a bananas is somewhat of a breakfast product, but I think you get the meaning, and so I wonder if Shutterstock is competing against Getty, but is also competing against royalty-free images. As a freelancer, I’ve definitely purchased credits to Stockphoto services, but I’ve also used plenty of free services, like Pexels.

So, it’d be really interesting to find people who have just hired Shutterstock or people who have just fired it and talk to them. Like, talk to people who purchased some credits, use them all and didn’t repurchase again, or had a subscription and canceled.

Kimberly: You made a good point when we were talking back and forth about Jobs that you don’t necessarily have to innovate and build some fancy new technology that has never existed in the world. Sometimes, it’s just assembling various available technologies to do the job in an innovative way.

Jobs to Be Done and Innovation

Brian: Yes. That was what I was kind of mentioning a second ago, that the hacks that people are currently using could be the beginning of a new product. When you have somebody who is using Microsoft Excel and Trello and a notepad and something else, then you may have a product on your hands. A good example is when Intuit released  Snaptax, which was where you just take a picture of your taxes. It does all the Optical Character Recognition (OCR), reads everything for you and submits your taxes. They did not invent the camera phone or the internet or taxes or OCR.

Kimberly: Can you explain what OCR is?

Brian: Optical Character Recognition, which is where computers are able to read typed words.

And so they didn’t invent any of those things. They observed people struggling, so they assembled these different technologies together. Another example is Airbnb, who didn’t have to invent any of the things that are the are core to their business, including actual real estate. They have assembled those things in a way that makes them what would be the largest hotel chain in the world.

Kimberly: Yeah, that is crazy to think about. I think working in technology, I’m just constantly reading about what Google’s doing with AI and what Uber is doing with self-driving cars, and so on, and it is just a constant stream of new technology and new discovery. But really, a lot of these companies that are these big Tech Giants, they’re just assembling existing technology in a new way.

Adam: I’m glad you bring up Airbnb because I’ve noticed that they come up with really great design and UX Frameworks. They’re constantly making sure that they are the standard. And if you look at Airbnb and go through the website, you can see a lot of really clean design. Even Shutterstock applies some of their design standards. You know that certain things and flows are successful and you can see that reflected across the web in a bunch of different websites. It seems like being able to innovate to that degree is what can help you be successful.

Kimberly: Innovate from a design aspect, you’re saying?

Adam: Yeah, but also, they even have technology frameworks and stuff like that.

Kimberly: Yeah, they just do what they do so well. And now they have that “Experiences” feature that has just launched and it’s like what we’ve been talking about – they don’t own a tour company. It’s just allowing people to become tour guides where they live.

Brian: It’s kind of great what you’re just mentioning about how we hold Airbnb up as this really high standard of design because it totally ties back to what we were talking about with MVP (Minimum Viable Product) very early on. Have you seen the very first Airbnb page ever? It is a stinking pile!

It is horrific, but they proved through that simple, terrible design that there IS a need here, and over time they’ve iterated and iterated and iterated. Now, they are the standard.

Kimberly: Yeah, you’re totally right. I’m just thinking through more examples, and about the push-pull again. I’m thinking about Craigslist, which is still a stinking pile of crap. But people still use it because it’s their habit, and their anxiety with the terrible design of the website isn’t high enough to make them use Facebook [Marketplace].

Jobs to Be Done and Customer Personas

Kimberly: Let’s talk about product managers and how we can use Jobs to Be Done more effectively. You mentioned context is more important than personas.  

Brian: That is something that gets a little bit of heat out there.

Kimberly: Yes! We’re so used to making personas as product managers. Part of our existence and our identity is personas, personas, personas. When we’re talking about this, it seems like people are moving away from that a little bit.

Brian: The great thing about personas is that what it indicates is that the people who are designing software, developing software and trying to prioritize what we ought to build are trying to relate to the human beings on the other side of it. That is fantastic.

But when you define those people by attributes instead of their motivations or their desires or their job to be done, and don’t ask, “What are they actually hiring your product for?”, then unintentionally, there is a disconnect there.

I think that the way that Product Managers can use Jobs to Be Done to make better decisions and be better advocates for their users is not to focus on the age, income, education, and whatever else a Persona might be constructed of. Instead, they should know the context in which these users are are using our application and where they’re trying to go. By having a deeper understanding of that, you can be a better advocate up the chain to higher-ups who are insisting, “This is the thing you’re going to build.”

Jobs to Be Done will give you a better argument, and you’ll be able to say, “I understand why you might want to prioritize that, but I would suggest that instead we do this other thing, because what we’re observing and what we’re hearing from our users is that this is where they’re trying to get. This is the progress that they’re trying to make.”

Kimberly: It’s interesting to think about this from a marketing standpoint. I work on a Big Data marketing tool and I do a lot of competitive research. So, for example, I might look at what Facebook’s or AdWord’s advertising platform look like. And always when you’re targeting people for a product, it is always by gender, by age. When really, we should be targeting people by something bigger than that, like somehow looking for their motivation within their profile.

Jobs to Be Done and Non-consumption

Brian: There’s a big a big piece in Jobs to Be Done, if you start reading up on it, that’s all about non-consumption. There’s a large segment of your market that is currently not using an advertising network. So rather than looking only at what your competitors are doing, look at the people who are not hiring any of us. What are they hiring instead? What are they doing instead? And why? Is there a way that we can absorb that, design a solution around it, monetize it.

Kimberly: So this can kind of change the way that product managers do competitive research, too. Instead of just looking at what all my competitors are doing, we need to be going a lot deeper.

Brian: Right, and not defining your competitors by the other people in your industry, but by what do the non-consumers hire instead? There’s definitely a sense where you can abstract it too far. Disney has talked about this for forever, that Disneyworld does not compete against Universal Studios; they compete against camping and they compete against family nights at home. So they’re not saying anyone else ever that has offered a product is our competitor. It is looking at: what what are the functional, social and emotional jobs that people are hiring us to do, and what are the other alternatives out there that people choose outside of our industry?

Kimberly: This has been awesome. Is there any any other last words or any other ideas that we should know about for Jobs to Be Done?

Brian: I think we’ve I think we’ve covered Jobs to Be Done basics.

Adam: Thank you for this topic because I feel like it’s a very exciting idea, and deserves more exposure.

Kimberly: All right, that’s all we got. Thank you so much, Brian. I was so excited to record this podcast today. Thanks everybody. Thanks for listening to Product Popcorn.

Want to Level Up Your Product Design Process?

Get free lifetime access to my personal Jobs to Be Done Knowledge Library and level-up your skills and resources in minutes!

Use the email scripts, interview templates, presentations, and book summaries I’ve created over the years to level-up your skills today.

Jobs to Be Done Interview Guide

Conducting a JTBD Interview

Reading about how to conduct a Jobs to Be Done interview is like jogging about music.

There’s only so much to be learned by reading about, or even listening to someone else conduct them. You gotta get out there and put the theory into practice.

That said, you can definitely do some things to prepare yourself for success:

  1. Internalize your understanding of the Forces of Progress
  2. Come prepared with a few notes beforehand, including the tools and tips I describe below
  3. Listen to a handful of interviews available online and take notes as if you’re doing the interview, and finally:
  4. Start scheduling interviews

Internalize the Forces of Progress

Keep the Forces of Progress model top of mind as you’re conducting your interviews. If this Forces model is new to you, hop over here real quick and watch the short video I’ve provided.

It might even be helpful to draw a blank grid on a separate sheet of paper and note the points in the interview that surface each of these forces. I have typically done this during a post-interview debrief with my interview partner, but there’s no reason you can’t do it as you go along.

Tips and Tools

First, a couple of tips to keep in mind as you begin your interview, and then we’ll talk about the most important tool, The Timeline.

Tip One: Pretend the stakes are low. Even if they aren’t.

Open the interview by explaining that you’re in the very early stages of doing some low-stakes customer research on your service.

Even if you’re in the late stages of an extremely important initiative, its important that the interviewee not feel any pressure about their answers. They need to be relaxed and feel comfortable just sharing their story.

Make this clear: “The stakes are low, some details will end up being important, others won’t. What’s most important to me is to hear the story of how you ended up signing up for our ____.”

If it makes sense, let them know that you aren’t the creator of the product itself. If you’re selling software, let them know you aren’t the designer or developer (even if you’re both)!

Read more on keeping the stakes low »

Tip Two: Establish a documentary metaphor for how the interview will unfold.

Tell them to imagine that you’re shooting a documentary, so you want all the details around what lead them to make this decision. No detail is too small or silly, everything from the first time they thought about making the purchase to the weather outside when they bought. It’s all important.

Tip Three: Listen for, and follow the emotional energy in their story.

As the interview unfolds, the person will typically start to relax a little bit and will even begin to have fun. If you’re doing a good job of remaining engaged and genuinely interested in how all of this unfolded for them, they’ll really start to open up.

People generally love talking about themselves and you’re giving them your undivided attention! As that happens, you’ll notice that certain parts of the story cause them to really light up with excitement, annoyance, or any number of big emotions. Follow those threads, there are insights hidden along the way!

Tip Four: Play dumb.

Ask them to level you up or help you understand something.

Even if you’re pretty sure you know why they just said the thing they did, play dumb about it. “I’m sorry to ask you to repeat this, but can you help me understand that a little better? When you just said that one service was offering lawn aeration and the other wasn’t, what does that mean? What is aeration?”

Pretend you don’t know the first thing about your own product so that you aren’t bringing in any of your assumptions about why customers hire it and you’ll be more likely to discover the real reasons that people do.

Tip Five: Once or twice, retell a detail wrong on purpose.

Don’t overdo this, because you want the person to feel like you are hanging on their every word and paying close attention, but once or twice, when you summarize a “scene” from their story, get something wrong on purpose. Sometimes, in correcting you, it’ll jog another little detail or it’ll give you a natural segue to ask for a little more context on why that particular thing was important.

Start with those tips, and after a while, they’ll be so natural that you don’t even think about it. But at first, it’ll be good idea to have those discreetly hidden away on some notes.

As for what to ask after you’ve set up the documentary metaphor, my friend and interview partner, Jason and I walk in to each interview with just one question: “So tell me about how you came to purchase ___.” After that, let them talk, and start following the threads.

The Tool: Interview Timeline

As you follow those threads, you’re trying to fill in the gaps of this outline:

  • First Thought
    • Which triggers the customer into Passive Looking
  • Series of Events
    • Which trigger the customer into Active Looking
  • Series of Events
    • Which trigger the customer into Deciding
    • and eventually, either:
  • Purchase or Sticking with the Status Quo (non-consumption)

Most purchases tend to roughly follow this sequence of events. Something happens that causes someone to think, “Hm. You know, it might be time for a new pair of skis.”

That’s the First Thought and that prompts them in to what is called the Passive Looking phase. They aren’t deliberately visiting any outdoor retailers to look around, but if the sport comes up in conversation with a group of friends, maybe they’ll ask, “So, what type of ski are you on these days?”

Then something else significant happens that kicks them in to Active Looking. In the JTBD Timeline used by most practitioners, this is very unceremoniously referred to as, Event One, but it’s important to note that this is not literally one event. Your customer might note a number of events that occur during this phase of Active Looking, but typically there is a touchstone event during this series that triggers them from phase to phase.

In the Active Looking phase, they’ve pretty much settled upon the idea that they’re getting new skis and they’re out in the market with a very wide angle lens, looking at and taking in all that is available to them.

Another event comes along that we call, you guessed it, Event Two, and now the customer is in full on Deciding mode. They’ve narrowed their vision back down to a very limited set of options and one of these select few remaining choices is very, very likely to be the solution they choose to hire.

And so, this is what you’ll want to draw on a blank sheet of paper before you begin your interview.

Draw a line from the upper left to the lower right, put in four ticks along the way for First Thought, Event One, Event Two, and Purchase (or Non-consumption).

As you conduct your interview, you’ll uncover significant pieces of the story and can begin to attach them to the timeline. By the time you’re done, you should be able to retell their story in about thirty seconds, highlighting the first thought, event one, event two, and finally the moment of purchase.

Scattered along the way you should hear some moments signifying Push, Pull, Anxiety, and Habit; and buried within it all is the core job they’ve hired the product to do, the underlying progress they’re hoping to make in their life.

Do a Dry Run with Headphones

If you’re feeling a little nervous about doing your first interview with a customer, then just try this:

Take notes as if you’re conducting the interview. Listen closely to what the customer is sharing and consider what questions you might have asked if you were in the room. What energy do you hear and what insights might you have wanted to dig into a little further?

Do these dry runs a few times if you need. And, if you’re still feeling hesitant, ask a co-worker, friend, or your partner if you can interview them about a recent purchase of more than $50. Repeat purchases and low-dollar items aren’t a great place to begin because it’s less memorable and less meaningful. As you’re getting comfortable with this framework, you want to start with big purchases.

Ok. There you go. An overview, some tips, tools, and links to get you started. Get out there and Get to Know Your Customers!

Related Articles and Resources

Want to Learn More about Jobs to Be Done?

Get free lifetime access to my personal Jobs to Be Done Knowledge Library and level-up your skills and resources in minutes!

Use the email scripts, interview templates, presentations, and book summaries I’ve created over the years to level-up your skills today.

With Customer Interviews, Pretend the Stakes Are Low … Even If They Aren’t

When you’re kicking off customer interviews to collect feedback on a design or prototype, one of the most important things you should say is:

“None of the designers are on the call. You aren’t going to hurt anyone’s feelings.”


“We’re in the very early stages here, so please feel free to shoot down anything you see.”

Even if it isn’t true!

Nurture Honesty in Customer Interviews

People don’t like hurting other peoples’ feelings and your customers will lie to you to avoid the sense that they’ve delivered bad news.

You want to do everything you possibly can to relieve your customer of any sort of pressure or responsibility in the process.

It doesn’t matter if I’m the actual designer that created the screens they’re seeing and it’s my favorite work of all time, or if we’re one short sprint away from launching what they’re about to see, at the beginning of all the customer interviews, I will say:

“This is very low stakes because we’re still early on in this process.”

“We’re not at all invested in the specifics that you’re about to see. But we are invested in getting it right so it’s no big deal to us to blow this whole thing up.”

“Feel free to be blunt, this isn’t my baby. I’ve not put a lot of time into the prototype up to this point. My job is to poke some holes into what’s here now.”

To learn about my process for deciding what to build in the first place, check out my post on Jobs to Be Done & Unmet Customer Needs.

And Now … Believe Your Lie

That whole thing about being willing to start back from scratch? You need to mean it.

A lot of the time, customer research folks will argue that you shouldn’t show customers a prototype or a mock-up because it will prime their expectation and you’ll be refined to a local maximum.

That’s definitely true.

But in my experience, the greater risk is not that your customers will be primed or polluted by the prototype, but that you will!

Mock-ups are subject to the Lindy effect. Each time they’re posted to Slack, someone will become attached to a certain element or offer an anecdote for why a potentially meaningless feature is an absolute must-have.

The longer mock-ups exist prior to customer research, the more likely they are to exist regardless of the results of customer research.

You have to be willing to trash your favorite screen, your favorite micro-interaction, your favorite anything if what you learn is that, in fact, it’s not useful.

Neutrality is Easier When You’re Early

You’re going to get attached to your thing. Either because it becomes your Precious or because the inertia created by seeing it day-in-day-out lets you get used to it.

If you want to be able to mean it when you say, “Yeah, we’re in the early stages here so be honest. You’re not going to hurt any feelings,” then have those conversations when that’s actually true.

In building new things, the quote to always keep in mind is this gem by the founder of LinkedIn, Reid Hoffman:

“If you’re not embarrassed by the first version of your product, you’ve launched too late.”

Take that approach to your wireframes, mock-ups, prototypes, and your MVP.

What often happens is that founders and teams wait until they’ve fixed all the things that they think are wrong before showing it to anyone else. This puts you into diminishing returns way too early as you fine-tune all your own specific preferences, when in fact, there are massive gains to be made from just five customer interviews.

In short:

  • Talk to customers
  • Talk to them early
  • Let them know that they won’t hurt anyone’s feelings
  • Believe that to be true

Want to Level Up Your Product Design Process?

Get free lifetime access to my personal Jobs to Be Done Knowledge Library and level-up your skills and resources in minutes!

Use the email scripts, interview templates, presentations, and book summaries I’ve created over the years to level-up your skills today.

Is the 800lb Gorilla In Your Market Susceptible to Disruption?

Do you find yourself in a market with a long-standing, dominant player, and you’re wondering:

“Are these folks susceptible to disruption?”

Or, maybe you’re trying to get a handle on what all this disruptive innovation talk is even about.

What is disruptive innovation and what is just good old fashioned and perfectly noble “somewhat better than the thing we had before?”

There are two types of innovations: sustaining innovations and disruptive innovations. “Sustaining Innovations” by another name might be described as “Feature Creep.”

Company designs a thing. Releases the thing. Customers love the thing.


Then there are inevitable feature requests and well-paid VPs who need something to show for their year! So, they tack on a feature here, a doo-dad there, and before you know it you’ve got a five-bladed whisker removal device with a pivoting head, lubrication strip, and “microfins” to gently stretch your skin as you shave.

It isn’t that any one of those improvements was a bad thing. It’s just that it may not be entirely necessary or even noticed by the customer.

Interestingly, Mad Magazine predicted and poked a little fun at the over-implementation of shave tech back in 1979.

Anyway, those little additions are sustaining innovations moving the blue line a bit up and to the right as time moves along.

But then, something interesting happens. Someone comes along and captures market share, not by one-upping the dominant players, not by outdoing everyone else, but by under-doing the competition.

When Dollar Shave Club burst onto the scene, they didn’t say, “YO! SIX BLADES!”

Just the opposite in fact:

In what was one of the best marketing videos of its time and with some of the most memorable ad copy you can imagine, they said, “Stop paying for shave tech you don’t need.”

DSC’s contrarian and disruptive approach said:

  • You don’t need all those freakin’ bells and whistles.
  • The big guys are over-charging you.
  • For a couple bucks, we’ll ship your much simpler, but perfectly acceptable two-bladed razors to your door.

Dollar Shave Club is the red line, finding product-market fit with functionality well below what the incumbents are offering.

If you’re the little guy and you’re looking up at a dominant competitor, ask yourself:

“What are my competitors over-doing? What did they add to their flagship offering that they pitched as a monumental breakthrough, but their customers barely noticed?”

As the big guys start to see diminishing returns with each new product release and if their once elegant and simple offering is starting to resemble Microsoft Word’s menu bar … they might be ripe for disruption.

In another post, I describe the process for figuring out which of your customers’ needs are under-served. To discover if a disruptive strategy would work in your market, look for the opposite of what I describe in that post:

  • Interview your competitors’ customers.
  • Discover if there are outcomes that are less important and over-satisfied.
  • A large number of unimportant outcomes that are highly satisifed suggests an over-served market.

If you’re able to, meet those same needs at a lower cost with less features, less promises, and less complexity to win customers over-paying for tech they don’t need.

Want to Level Up Your Product Design Process?

Get free lifetime access to my personal Jobs to Be Done Knowledge Library and level-up your skills and resources in minutes!

Use the email scripts, interview templates, presentations, and book summaries I’ve created over the years to level-up your skills today.