Brian Rhea Brian Rhea

Product Risk and Market Risk

Understanding the difference between these two types of risk should change how you approach customer research.

Consider two companies tackling very different problems:

  • The first, WoolyCo, is inventing a cure for baldness
  • The other, Vector & Mask, is creating a prototyping tool for designers

WoolyCo, obviously has a market. It should be fairly obvious that they don’t need to spend any time doing customer interviews to validate the problem. They aren’t going to hear anything that isn’t already well understood. The questions they face are figuring out if it’s actually possible and if it is, how are they going to divide up the billions of dollars they’re going to print on a daily basis.

Vector & Mask, on the other hand, don’t have to wonder if creating a desktop application with the ability to create, manipulate, and share design assets is possible. It definitely is. Their existential question is, “Are people going to be willing to use this instead of Sketch, Figma, or whatever Adobe is pushing these days?”

WoolyCo have a Product Risk. Can the product exist? Can this invention actually happen?

Vector & Mask have a Market Risk. Is there a market for this thing that we’ve built / are building?

Both are challenging in their own way.

Now, imagine having both of those problems.

A thread by Josh Pigford of Baremetrics had me thinking about that this recently.

A PEO is a Professional Employer Organization and they help small businesses with a lot of HR-related issues, including federal payroll taxes but not state and local taxes.

Unfortunately for Josh, he’s going to be writing some pretty big checks.Some of the comments and conversations around this thread, of course, lead to some suggestions that there’s a SaaS opportunity here.

And there probably is because remote-first companies aren’t going away any time soon. In fact, that’s where the puck is headed and many savvy entrepreneurs are already skating there.

But there are two risks here:

Product Risk: Is it possible to build a SaaS product that can navigate the federal, state, and local tax codes around the world at scale?

Market Risk: Will businesses trust a software tool to manage that burden or will they stick with the existing, conventional solutions?

There’s definitely a white-glove, services-model approach to solve the first risk. The PEO who already has Baremetrics’ business could explore adding that level of management as an add-on service.

That’s not the Product Risk.

It’s whether or not it can be automated and scaled as a software tool. Tax laws are constantly changing, and remote companies hire employees around the world. The implications and complexity multipliers there are massive.

And then there’s the question of Market Risk. Will there be enough companies willing to hire this tool and trust it with such a specialized, notoriously arcane domain as taxes? Or, will they prefer to tack on services with their PEO, or make an additional administrative hire to own and solve the problem internally?

You may have a different interpretation on the degree of each of those risks and I’m not saying that either or both are unsolvable.

What’s important is having an honest understanding of the type of risk you face and how you can address it.

Product Risks cannot be addressed with market research. Market Risks cannot be addressed with engineering.

Ask yourself:

  • Are we a “Product Risk” company?
  • Are we a “Market Risk” company?
  • Hoo boy. Are we both?

Getting the answer to these questions should change how you’re doing customer research.

If you’re a Product Risk company and you’re investing in customer research, pull back and focus on proving to yourself whether or not your idea can even exist.

If you’re a Market Risk company and you’ve got a giant engineering team and very little marketing and customer research expertise, rebalance your efforts to be sure that you aren’t fooling yourself. “If you build it, they will come” is one of the greatest movie scenes of all time, but it’s rarely true in business.

JTBD App Now in Beta!

I'm working on a JTBD app to help you build better products!

JTBD is an amazing tool, but it can be pretty confusing. I'm working on a product to help teams like yours conduct Jobs to Be Done research you can actually use.

Request early access today!

Related posts

If you're still reading, you'll probably like these.

Never Ask Your Customers: Would You Use This?

“Would you use this?” is probably the worst and most expensive question you could ask a customer.

You Need a Plan, Just Not a “Business Plan”

If you’re early stage and small, take advantage of those strengths with an equally small and nimble business plan.

Focus On the Problem

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

Don't Build a Vitamin, Build 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:

Customer Interview Tips & Tricks to Save Time & Money

If you haven’t heard this nugget of truth yet, you will soon: “You’ve got to get out of the building.”

Brian Rhea on UI Breakfast Podcast

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

Using JTBD to Increase Acquisition and Decrease Churn

When someone is deciding between sticking with their current solution or switching to a new offer, they find themselves weighing their decisions against the forces of Push, Pull, Anxiety, and Habit.

Jobs to Be Done Framework on the Product Popcorn Podcast

Hello and welcome to Product Popcorn- the podcast that explores topics related to product management

Jobs to Be Done Interview Guide

There's only so much to be learned by reading about or even listening to someone else conduct a Jobs to Be Done interview. You gotta get out there and put the theory into practice yourself.

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:

Is Your Market Leader Susceptible to Disruption?

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

Using a JTBD Survey to Quantify Unmet Customer Needs

In this post, I’ll show you step-by-step how I’ve used the approach described in Tony Ulwick’s book, "What Customers Want" to help my clients get a much better handle on what to build, what to improve, what to leave alone, and what to ignore.

How to Write Jobs to Be Done Example Statements

If you're trying to integrate Jobs to Be Done into your design process, you've probably found yourself looking for some concrete examples of Jobs to Be Done statements to be sure you're on the right track.

Start Over with Simplicity or Reduce Complexity?

I was having a conversation with a client recently and they’d more or less come to the conclusion that they needed to do a hard reset on the company and rebuild their application.

The 4 Reasons Someone Will Try Your Product

  • Save Time
  • Save Money
  • Make Money
  • Make Happy

Kano Model (Part 2): Creating Your Survey

Using a Kano-based survey, you can avoid false positives (“Oh, sure I'd totally use that!” ... never uses it) and identify the features your product actually needs to have to satisfy and delight your customers.

Ready to know what your customers actually want? Get in touch.