Force against the status quo

The physics of demand

---

PSAs:

1. My November product-market fit + sales bootcamp is coming up! It’s the last one I’ll be doing this year. Learn more and apply HERE.

2. Have you subscribed to the Physics of Startups podcast/YouTube yet? It’s the companion to this newsletter, where we dig super deep so you can apply stuff to your startup. Here’s the link to this episode:

---

Context

I was watching a startup’s sales calls. They were following the PULL framework and the potential customer was saying all the right things. It sounded like the potential customer had demand, and the startup’s product fit their demand.

But the calls didn’t feel right. It didn’t feel like the potential customers were leaning in.

I’ve also gotten quite a few questions in my office hours about the PULL framework - What exactly is a project? Is this something we can find just by looking at their actual to-do list? Do I need access to their Asana board?

So I figured I’d do a deep-dive into the mechanics of my demand model; you should have a strong intuition for demand after this post!

---

Why we need a demand model

The goal of the demand model is to predict whether a person will buy something. We can use this to determine whether a startup’s product will find traction.

The word predict is very important here: You’ll hear concepts like “pain points” and “problems” that make sense and sound right. When you look at successful startups, you can explain their success as “having solved a big problem.” But, as you’ve likely experienced, you can have someone complain about their big problems and pain points, who agree that your product would solve these pain points and problems, and then they don’t buy. In fact, this is the default outcome when we focus on pain points and problems: Life is a series of pain points and problems we mostly do nothing about. I spent two years hitting my head against this particular wall; the startup graveyard is full of examples of products that solved big problems yet found no traction.

In other words, “pain points” and “problems” are not predictive of purchases; they are explanatory models that work after-the-fact. From the sidelines, an explanatory model like “pain points” and “problems” is good enough. On the field, we need a predictive model for demand so we don’t waste our lives building something that solves a “big” problem… that nobody buys.

That said, here’s the predictive model:

Mechanics of the demand model

We can think of demand as, first and foremost, the measure of an individual person’s force against their status quo. They are trying to change; their force can be measured as strong or weak. If they are applying a weak force, they might say the right words but take little action. If they are applying a strong force, they run through obstacles to take action.

A person’s force against their status quo takes a particular shape, which I find easiest to conceptualize as a “project on their to-do list”: I can imagine a Trello board in everyone’s brain that reflects why they’re doing what they’re doing; I can see a huge backlog of projects competing for the #1 priority slot; I can see them refining the project on their Trello board as they consider exactly how to approach it.

But just because someone is exerting force against the status quo and prioritizes a specific project doesn’t mean they will buy our product to accomplish their project. Which is why I had to create the PULL framework, to describe (1) a project they can’t avoid, (2) with bad or unworkable options to accomplish their project. When this is the case, they would be weird not to buy our product.

The PULL framework represents a specific kind of force: A person who is applying strong force against their status quo, but their force is blocked because there aren’t good options available to them to accomplish what they’re trying to accomplish. Said differently: This person is exerting force against the status quo, but their existing options are exerting force in favor of the status quo. They are struggling with these opposing forces until we show up.

Let’s see examples of this “force against the status quo” concept:

Examples

A healthcare billing administrator’s job is, well, doing billing work. You watch her doing her job and notice how manual her processes are, how tedious her job seems. She, however, does not see it this way: This is her job, these are her responsibilities, and she has mastered them. She may complain about problems and pain points in her work, but she exerts no force against her status quo. If you show her what AI is capable of, she says “cool!” and gets back to doing work the exact way she was doing it before. She may see AI as a threat to her status quo and resist it. She has no demand.

Another healthcare billing administrator, right next door, views herself as above this tedious work. She wants to get promoted and make more money, but has been overlooked for years. She has, in fact, a more efficient process than her billing admin neighbor - as she has automated pieces of it in a futile attempt to get noticed and promoted. AI, therefore, will actually make less of a difference for her workflow, and she has fewer of the pain points and problems her neighbor might complain about. However, she is exerting force against her status quo - she is trying to get promoted! She believes that by demonstrating she’s using AI, she will get noticed. She has demand, which roughly fits into the PULL framework like this:

• Project on her to-do list = Stand out in order to get promoted.

• Unavoidable because = I feel like I deserve a promotion; this work is beneath me.

• List of options considered/attempted = All the process improvements I’ve done so far

• Limitations = They haven’t been visible enough or impressive enough to make me stand out.

• Supply I want = Something that helps me really stand out: AI is hot now, maybe that?

Can you see the force she’s applying against the status quo? We model it with the PULL framework, but what matters is the FORCE underneath it. We don’t get points for simply filling out the PULL framework; we get points for the force driving the PULL framework. This admin is desperately trying to get promoted; her force could be so strong that she will pull out her own credit card to buy and implement an AI product that gives her the chance of standing out and being promoted.

Now, these administrators have a boss, who is four years and thirty-seven days away from her retirement. She updates this metric daily, and her entire world revolves around not getting fired in the next four years and thirty-seven days. For her, the status quo must be preserved; any deviation from the status quo is unnecessary risk. She watches one of her billing admins - the pesky one - try to change things. She’s warned this admin before. And now this admin is buying AI on her personal credit card? This represents movement towards a new, unknown status quo. This movement must be neutralized. The boss now has demand that’s a force against the changing status quo.

• Project on her to-do list = Prevent admin from making noise

• Unavoidable because = I don’t want to stand out and risk being seen or getting fired

• List of options considered/tried = I’ve warned her before

• Limitations = She hasn’t learned her lesson

…so the boss fires the pesky AI-adopting billing admin, reporting upwards that the admin used unauthorized software after having been warned multiple times otherwise; HR and legal thank the boss for her commitment to the company’s reputation; the status quo is preserved.

---

I chose these examples, in part, because nobody would ever admit that this is what they were doing. The billing admin wouldn’t readily admit that adopting AI is a ploy to stand out and get promoted; the boss wouldn’t admit she is firing this employee to protect her retirement plans.

Which is why we have to infer demand and the PULL framework based on actions and attempted actions. The model starts with a hypothesis of a buyer’s force against the status quo - their actions and attempted actions reveal the truth, we have to interpret their force and shape it with the PULL framework. We inevitably must understand human nature; as we explore this, we find it human nature has its own peculiar logic that looks nothing like what’s in an economics textbook, and is often quite depressing to look at head-on.

This explains why you’ll hear people describe what’s on their to-do list, but you won’t perceive any force behind it. Perhaps it’s a weak force, perhaps they’re just pretending, perhaps they’re not admitting what the real force is. We need to observe their force, not just listen to what they say.

Zooming out

When startups grow fast, it is because they find intense, repeatable, blocked demand, and build supply that un-blocks that demand. In other words, they find a lot of people who are each individually applying a lot of similar forces against the status quo, with bad existing options to channel their force.

I like to lean on the example of Lovable, simply because we’ve all probably used their product.

There are a few kinds of forces applied against the status quo that Lovable is harnessing, from forces that are highly functional to those that are more in the “status-FOMO” realm:

• I am trying to make a website, and I am wrestling against traditional website editors.

• I want to make a website, but I know how annoying traditional website editors are, so I just don’t even bother.

• I want to make an app, but I am not an engineer, and learning to code seems tedious, and no-code tools also seem tedious.

• I have a demo coming up with a potential customer, and I want to mock up a feature we don’t have but could build for them, but designing it would take me hours I don’t have.

• I am trying to explain my product idea to these damn engineers, and they keep not getting it based on my requirements, and I want to show them something but can’t make a good clickable prototype.

• I am trying to gain followers and stand out versus other influencers, but level-headed assessments of new tech doesn’t stand out, so I frame Lovable as a way to make millions in software without coding

• I aspire to build a startup, but I don’t know how to code, and now feel FOMO based on all the influencers who seem to be making millions off of Lovable apps

All these forces are quite strong, and were largely blocked before Lovable. These forces pulled Lovable into the stratosphere. Yes, Lovable is a good product, but it is *only* a good product BECAUSE it fit this PULL really well!

So what?

In sales calls - and more broadly, in the early stage - we are looking for people who are applying force against the status quo.

• Discovery: Asking about their status quo works and their pain points provides SEEMINGLY useful, but ACTUALLY useless information: We are not learning about the force they’re applying against their status quo! Instead, ask about what they must accomplish and what they’re trying to change. See what they’ve done recently. For startup research, observe them in person (do their job with them!) to reverse-engineer where they are applying force against their status quo, and what that reveals about their to-do list.

• ICP: Design your ICP around who is actively applying force against the status quo, with bad options that are blocking from them from making progress - don’t design your ICP based on “who could benefit from our product.” People who are not actively applying force against their status quo would be weird to buy your product!

• Product: Because we don’t usually focus on the people who are applying force against their status quo, we tend to overbuild our product in hopes that “more features” will make potential customers apply force against their status quo. I don’t think this happens very often; basically every startup that works harnesses a force that already exists inside potential customers, that they are attempting to apply against their status quo, yet they are blocked from making progress by their existing options.

• Demand: The force people are applying against their status quo is rarely just functional - it’s often not about “ROI” or “additional revenue” or “reduced costs.” I will, I’m sure, come back to this point in the future.