The Illusion of Product-Market Fit

Brad Feld published a very thought-provoking post about product-market fit (PMF) a few weeks ago:

The Illusion of Product-Market Fit for SaaS Companies

The piece that really resonated with me was the list of the 4 key myths about product-market fit:

  • Myth #1: Product market fit is always a discrete, big bang event
  • Myth #2: It’s patently obvious when you have product market fit
  • Myth #3: Once you achieve product market fit, you can’t lose it
  • Myth #4: Once you have product-market fit, you don’t have to sweat the competition

I believe we’re both in agreement on one other thing: companies tend to “claim victory” on finding product-market fit prematurely, but this is when Brad’s view and mine start to diverge.

Brad lays out a monthly-recurring-revenue(MRR)-based milestones, outlining when you only *think* you’ve found PMF, when you’ve actually found it, and when myths #3 and #4 start to kick-in.

Reflecting on the market the company I currently work for is in, automatically caused some red flags to pop up in my head.  In our industry, a single, “small” transaction may yield $50K in MRR. So 3-4 clients can easily get us to Brad’s “PMF sweet-spot” but I doubt it would have made sense to claim PMF victory then.  Granted our case is extreme, but it may shed some light on more industry-agnostic milestones. Looking at # of users, clearly takes us in the wrong direction, in ways far beyond the different-users-pay-for-different-product-plans argument that was discussed in the comments to Brad’s post. Perhaps a more generic way to define these milestones is as a percentage of the total-addressable-market (TAM) for that product. Without going into a lengthy debate about how to go about assessing it, I suspect this is what was implicitly set Brad’s MRR thresholds.

The part of the blog that really irked me was the discussion on valuations through a hyper-growth-centric lens. But I’ll leave opening the “growth obsession” pandora box for a different post and share some parting thoughts about PMF instead:

A good analogy for finding PMF comes from Physics: finding resonance with your customers and getting on the same wavelength as them. Note that this can be accomplished both by changing your product and by changing your customers (market pivot). Changing your wavelength is a gradual, continuous process (anti-myth #1), you know when you’re close to being on the same wavelength but it’s hard to tell if you’re exactly there (anti-myth #2). Since both your product and your customers constantly change (wavelength), it’s easy to get out of sync again (anti-myth #3) and it’s clear that your actions don’t prevent others from getting on the same wavelength (anti-myth #4).

Perhaps another good analogy from the same discipline is thinking about PMF as an unstable equilibrium often illustrated as a ball at the top of a hill (as opposed to a stable equilibrium illustrated as a ball at the bottom of a valley). You first need to roll the ball up the hill (find PMF), but then every little nudge can get easily get it rolling down the hill again.

The Illusion of Product-Market Fit

Fixing Fitness Apps

I’m taking a one-post break from org design to talk about behavior science instead.

About a months ago, Nir Eyal wrote a rather depressing on the ineffectiveness of fitness apps in helping people become more fit:

Your Fitness App is Making You Fat

I think Nir is absolutely right that fitness apps don’t drive the long term behavior change necessary to become physically fit; And that gamification, the only behavioral tactics used by many of these apps, is insufficient to driving such change.
I was disappointed, however, to see him making the bold, contrarian hypothesis that fitness apps are in fact making people fatter without supporting it with data. But the truth of the matter is that this doesn’t matter much. What matters is how we can fix them.
Nir looks at Twitter, Facebook, Pinterest, and the iPhone as products that were successful in changing user behavior. Specifically, enabling the users to form habits around using the apps by making the usage experience fun. He then draws the conclusion that fixing fitness apps will require them to make physical activity fun. I disagree with the conclusion since the analogy is far from perfect: If I’m using Facebook more, it does not mean that I have deeper social relationships. Using my fitness app more is not an indication that I’m getting more fit. Driving outcomes in the real-world is much more challenging, and measurement is not as straight forward. But it’s doable. Omada seems to be on the right track to getting it right.
Nonetheless, there is a lesson, that fitness apps should adopt from the various social networks – creating a real network effect in their business model. Chris Dixon put it beautifully in “come for the tool, stay for the network“. The few fitness apps that made some attempt to create such an effect, like MapMyRun, seem to have fared better than the rest.
Finally, the kind of behavior change we’re talking about here is much more complex. Getting healthier has an intrinsic level of discomfort: feeling hungry is unpleasant. So does physical strain. Making a phone call and tweeting, in comparison, are rather innocuous. We need to dig deeper into our behavior science trove in order to build up the necessary motivation needed to voluntarily undertake such experiences.
Fixing Fitness Apps

Building Badass Users

This is one of the better talks on product management, user experience and behavior science that I’ve seen recently. It was given by Kathy Sierra in the last Mind The Product conference:

Building Badass Users

It’s always hard to summarize content delivered by a great speaker. So much gets lost in translation. But my best attempt to do so, in this case, is below:

Kathy’s initial premise is that the key attributes of a successful product don’t live in the product – they live in its users.  People want to be amazing in what the tool enables them to do, not at using the tool. For example: people want to be amazing photographers, not amazing at using your camera.  So what really matters is the “post-ux ux”, what happens in the real world, after people have used your tool.

Furthermore, the things that prevent users from completing the user journey (becoming really good at the context they’re using the tool for) are derailers that live outside of your tool. Therefore, the solution, is not adding more motivation for using the tool, but reducing/minimizing the derailers. Those, in turn, tend to have a common root cause – a reduction in ability and/or willpower caused by cognitive leaks.

She then suggests six ways to reduce cognitive leaks:

  1. Delegating usability from your head to the real world. Often times the opposite happens as a result of trying to create “simple” or “streamlined” UIs.
  2. Creating defaults and smart filters. Making choices is cognitively expensive.
  3. Reducing the need for willpower. Turning actions into habits.
  4. Making it easier to focus. Using the brain’s “natural” attention grabbers: scary things, faces with strong emotional content, innocent/cute things, things that change (visually). And making sure that you’re not unintentionally using these things to draw attention in the wrong direction.
  5. Helping the brain let it go. Giving clear, clean feedback that the user can trust, on actions that the user have taken.
  6. Giving them faith that you know what it’s really like. We often act as if the actions we expect the users to take are simple and easy, when we should acknowledge that some things are hard. Examples: Wasabi’s “I’m freaking out” button, Kindle Fire’s “Mayday” button.
Building Badass Users

Getting to Yes

A really nice piece by Steve Blank about dealing with the friction between “innovation” and “corporate”:

Getting to Yes for Corporate Innovation

The problem:

A massive (+5,000 employees) corporation have set up a corporate incubator for horizon 3 innovations.  Despite executive support (including the CEO) the innovation team kept running into organization roadblocks, primarily in the form of policy constraints and lack of cooperation from corporate functions (HR, Legal, Finance, etc.).

The solution:

  • Every innovation team that wanted a policy/procedure changes can submit a “Getting to Yes” 1-pager to the department that owns the policy/procedure, outlining the requested change, the rationale and impact/risks to the core business.
  • The department has one week to ask questions, gather information and meet with the innovation team.
  • The department then could either approve / propose changes that the innovation team agreed with, or reject the proposal.
  • Rejected proposal were automatically escalated to the Chief Innovation Officer either overrule or ratify them.

What’s awesome about this solution:

  • The innovation teams are the ones proposing the new process, procedure, metric, etc. – they can’t just complain/argue that it’s someone else’s problem
  • There is a hard 1-week response time for the relevant department
  • “Yes” is the default answer, “No” required a detailed explanation
  • Appeals went straight to the Chief Innovation Officer to be acted on the next week. If no agreement was found it became a management team issue.

What’s really compelling about this approach, in my mind, that it can be applied beyond the realm of innovation. Everyone should be able to take part in continuous improvement of policies and processes, not just the departments who own them.


Getting to Yes