Businesses as a Case Study Factory

Here I write about things that I'm trying to understand and let go of notions that I have to provide authoritative opinions. These are just my current understandings so these pieces may feature strikethroughs or entirely new versions as my thinking shifts. The prior versions will always be preserved to maintain the core idea that I am always trying to gain a better understanding.

Why I’m Chasing This

See Yet Another Startup Framework.

What I’m Learning So Far

The biggest instigator the this mindset was Rob's thorough emphasis on "nobody has ever gone out excited to buy B2B software". Everyone is trying to solve the projects on their plate for a given day and that's it. So if you can figure out what their big projects are, why they care about them, when they have to think about it, and what they are currently doing to solve it THEN you can hypothesize case studies. If you can figure out a way to make those projects go faster (or go away entirely) and do it in a way nobody else can, you've got a case study.

When is PULL?

I drift towards defining things by what they are, but PULL is inherently defined by when¹. Rob says,

The PULL framework uses “pull” as a noun: PULL is “the state of having demand.” When you find PULL, customers pull the product out of your hands.

He breaks it down into 4 pillars:

P = There is a Project their to-do list…

U = …that is Unavoidable right now…

L = … and the option (or options) they Look into…

L = … are Lacking for some critical reason(s)

So PULL describes a moment in time when a specific person will actually want to purchase a product (or alternative) to solve an unavoidable project on their plate because their current solutions are limited in some way.

Finding out who that person is, when that moment happens, what that project is, and how current solutions are limited defines your demand which you can build supply around.

Demand

Rob defines demand as,

"What buyers are trying to achieve."

and says you can think about it as a project on a Trello board. From the perspective of this person who has demand (a project) there are different types of projects with different priorities and frequencies. You MUST find something that is high priority for them to want to buy and should find something that is frequent enough across your customers to be recurring (depends on your business model, I presume). For example, SOC 2 can appear for enterprise startups and be high priority if it blocks vendor contracts, this would be intense demand at a specific moment in time. The more intense the demand, the more PULL the customer will demonstrate to rip that product out of your hands and we all want that.

Rob makes demand intensity a function of

1. How frequent that demand is
2. How much better your solution is than their current and alternatives²

However, I disagree with the phrasing of 2. I don't think this phrasing lines up with other core tenants of PULL. Rather than 'how much better your product is than the current/alternatives', I think 'how much worse their current solution is to alternatives (including doing nothing)'. That's because your customer does not care about your solution relative to other solutions until they are evaluating your product, but they always have demand. Demand exists absent of your product and can be intense if their current solutions are insufficient. Said differently, we care about 'how much of their solution is LACKING in solving their current demand'. The more someone is not being completely satisfied in their demand, the more intense demand exists to solve it better. It does not matter if your solution solves it 10% better than the current/alternatives solution if neither yours or the current/alternatives don't really solve the problem.

Frequency and Waves

How often someone has this project as a priority is largely project dependent, but there are moments (waves) where intensity can shift. Waves shift intensity in different ways and it's best to ride/pre-empty a wave if you're starting a VC backed business because that is effectively your critical insight that nobody else understands and competitive advantage.

Supply

Unlike demand, supply is everything that you control. Demand cannot be willed into existence, but supply can. This is where you can get creative and find a way to solve your customers demand.

Early on, supply does not need to be a self-service platform. It can be Google Sheets. Flintstone it! As an engineer who especially loves to nerd out about building, I have caught myself over-building and under-delivering for customers demand and had to course correct. I'd going to try out pre-selling a service as a bullet-proof way to not do that again. If you don't have demand, you don't have customers. If you don't have consistent demand, you can't build a service. If you don't have repeatable demand, you can't have a business. So to stave off all of this, make sure you have demand!

Rob believes the only way to do this is through a sale. Not a design partner, but a sale[^question-loi].

Early on, you can sell a service that is as scrappy as possible (on your end) because the customer does not give a shit how it's solved. They care that it is solved correctly and are paying a fair price (based on their demand, probably).

Follow these three steps to break supply down³:

1. You base your requirements around demand.
2. You design something to best fit those requirements.
3. You implement it as cheaply and fast as possible.

Then you sell this supply and repeatably unfold until you develop consistent and repeatable demand. That is something worth building. For reference, Rob said he scaled his business to some 6-figure ARR before migrating from semi-automated Google Sheets workflows.

Case Study Factory

Everything in the previous section was definition and local algorithms, now we get into Rob's framework for building a business: A case study factory⁴.

A Single Case Study

A case study is a container for a given customers story. In it we demonstrate their demand and our supply through the pull framework. I've broken Rob's work down⁵ with some alterations.

1. Demand (out of your control)

   a. Scenario

   • Frequency: When does this project occur and how often?*
   • Project: What was this person trying to accomplish?
   • Context: Why was this on the top of their plate?

   b. Catalyst

   • Disequilibrium: Why this person needed to change?*
   • Options: What solutions did this person consider? Why did your product stand out from the others?

   c. Outcome

   • Success: What key success indicators did they achieve?

2. Supply (within your control)

   a. Outcome ("How")

   • How did they complete their project?
   • How did your solution help them?

   b. Catalyst ("What")

   • What did they buy (packaging, positioning, pricing, offer, etc.)?

   c. Scenario ("When")

   • When did they know they were going to be successful?
   • How long did it take?

For example,

Every quarter John Doe dreads having to do X before the submission deadline. As Doe Headquarters scaled, John has had to spend all of his hours working on X. They looked a Y and Z, but found it lacking in A, B, C. That's when they found U which handled A, B, and C. We worked together and now John handles X in a day instead of weeks.

U allowed John automate S and P manual workflows while supervising semi-automatous R that runs in the background. This was all delivered with U's standard pricing package. Next quarter, John had time to do everything else on his plate and it only took a single 1:1 onboarding call with our founders.

I've adjust his model to introducing some easier to remember grouping and symmetry in story telling. I find it easier to put the story together in my head. He has a wonderful template created that integrates his 'case study' outline here⁶. I'm not so sure if my adjusted outline is better for creating stories or enumerating details to track while unfolding your case study so I may loosely stick to his outline. Whenever I make changes, it's because I'm really trying to remember the core principles and realize that his writing was done over years and some articles may not reflect the latest framing.

A Factory of Case Studies

Your job is to repeat this with increasing number of customers by creating a case study factory.

Your factory has three components⁷:

1. Pipeline: How people get into your sales process
2. Sales: How we turn them into customers
3. Delivery: How we turn customers into renewals/expansions

The more demand we have for the initial case study, the more our customers will pull our supply out of our hands; thus, we can more easily create case studies. Rob goes into more detail on how this factory work as it goes from just trying to get one case study to scaling in 'The Physics of the Case Study Factory'⁷. I'm going to stick to the already hard enough step of getting one case study off the ground.

Sales Pipeline

To start, use founder magic to do unscalable outbounds that work for you and unfold your case study hypothesis -- adjust to find demand. He recommends 5-10+ sales conversations per week.

Really love this small note where Rob says, "If [outbounds] do have demand, they make it sales call, no matter how the meeting was scheduled." It sums up the entire outbound ethos you should have. You are hypothesizing who has demand and when it happens. If you are correct, there's demand and it's a sales call.

After you've proven a repeatable case study, continue to use a semi-scalable toll booth approach. These should still be sufficiently crazy/bespoke to work and thus not fully scalable. Maybe this gets you to 100 customers?

His advice on outbounds, "2 cheat codes: what’s the message only you can send to only them? what’s in it for them"?⁸

Selling is a Team Sport with PULL

When there is pull, it would be weird for this customer not to be interested and willing to buy so you don't need to convince them of their problems or have any awkwardness around money. The only thing left is to line up on incentives. You do this by reading a similar companies case study and showing your service/product working.

They have a project that needs to get done and they are interested in seeing potential solutions. So you show them when (not how) your product has worked with other case studies. This when is much easier to resonate with and feel than any how. They don't give a shit how it is solved just that it is solved. At most, explain why this case study picked your product over competitors. This resonates much more than giving some complex technical demo on how it solves their problem. If their demand aligns with this story, then it's about pricing.

A key facet of this strategy is that you are not pushing some narrative or story on them. They hopefully have demand that aligns with your prior case studies and you can treat this as a team sport. You are extending a hand and offering a solution that can help them and if that makes sense you can discuss a fair exchange for that service/platform. If they have demand, they want to be there and hear you out. Don't think of this as zero-sum or winner-takes-all.

Rob has a wonderful slide deck that goes in depth on what this actually looks like and how early-stage sales looks⁹ as well as a template deck for you to fill¹⁰.

It is effectively three meetings (milestones)

1. Understand their pull to establish if they fit your demand profile
2. Deep-dive what signing up would look like
3. Decide of if it's a good deal and lock in deliverables

I like to think of these as milestones because this can happen over fewer (or more) than 3 meetings depending on the customer.

Keeping them Happy

In B2B sales the default behavior is to churn until they are not.¹¹

Onboarding is the time where you show your customer how to use the tool to solve their problems; such that, they are directly primed to trigger indications of retention.

Indications of retention are key feature usage, repeated success outcomes, or whatever you think shows that the customer will stay. So you may need to fiddle with this, but until you know you have the correct indicator and can measure it, you do not know if the user will churn.

Your job in this stage, is to figure out what is the right indicator, what is the right threshold, and use that the improve the product.

Bottlenecks

In this factory, there can only be one bottleneck at a time that is globally limiting your output. It is the worst one and must be solve with hyper focus. Solving a bunch of non-blocking bottlenecks won't increase the output of your factory.¹²

Don't Pivot, Unfold.

The previous section studied Rob's framework through a single branch of the multi-verse in which you succeed at every step and never need to pivot. Wouldn't that be nice! In reality, you will absolutely need to change course. It is one of the few guarantees in a startup so optimizing for fast iteration is a wonderful investment. Rob calls this 'unfolding'.

Your First Case Study

I explained what a case study looked like when you have one (or more) and how you can use one to get more, but didn't talk about what to do when you don't have any! Introducing the Sales Sprint¹³¹⁴.

1. Craft a pull/case study hypothesis of who would be weird not to buy.

2. Test you hypothesis with five sales conversations with people who fit your hypothesis. Execute those five sales conversations.

3. Analyze, reflect, and re-test

   • Summarize the best sources, conversations, or experiments you’ve explored.
   • Highlight the most surprising or conflicting insight from each.
   • Did anyone try to buy? How many? How badly did they want it?

When you consistently get 4/5 intense pulls, then you know you found the right people with demand and are offering the correct supply.

Rob believe you still much approach this as if it were a sale/pitch because that is how you get actual demand validation. Every other technique, we don't actually know if they are being nice or leading us on. So unless you can read minds, skip to the part that you'll have to do anyways and sell.

My Current Model

This is largely based on the following slide¹⁵.

Search Criteria in Sale Sprints

I'm searching for a moment in time when a specific person will actually want to purchase a product (or alternative) to solve an unavoidable project on their plate because their current solutions are limited in some way.

There must be high 'frequency' (of intense demand) across my customers.

Ideally, there is currently or going to be a wave to increase the intensity of that pull.

Within a single group of customers, I need to qualify WHEN their moment of disequilibrium occurs and show up there as much as possible.

Consecutive Sales Sprints

Bring this hypothesis to customers as a service and unfold.

This is work gets built into weekly sales sprints.

1. Craft a pull/case study hypothesis
2. Test you hypothesis
3. Analyze, reflect, and re-test

Once you develop consistent and repeatable demand, scale.

Tools to Checkout

https://www.granola.ai/

What I’m Testing Next

Pre-selling a Single Customer with Intense Demand

Observing Demand

Observe your domain by working for or doing the job of your customers. This can be by shadowing them, taking low wage jobs, or becoming the customer itself.

Once you've observed clear demand, fit supply to that demand to gauge pull.

If you can't directly observe demand, skip to the next step.

Form Pull Hypothesis

1. What am I building?
2. Who am I building for or what projects am I building for?
3. When do those people care or have these projects?
4. Why is it top of their list in those moments?
5. What solutions have they explored and how are they limited?
6. How much pull do they have?
7. Is anything in the market going to increase the intensity or frequency of demand?

Put this into a pull hypothesis dashboard.

Founder Magic for Consecutive Sale Sprints

1. Who do I know that might know these folks?
2. Cold outbounds?
3. Goblin mode on competition sites

Once I get 5+ sales calls a week, don't stop. Retro every week with 'Infinity - X' series.

Pre-sell to Intense Demand

Continue Sales Sprints until I know who to reach out to in order to pull 4/5 intense demand calls a week. Build your case study hypothesis out of this and pre-sell before you automate the workflow. Automate the service as you scale. Then use the case study sales deck to get more customers. Continue automating more of the service while you build out domain expertise and expand reach.

Retrospective

Track how these pre-sells use the service and how you can understand whether or not they will churn. Look at who buys fast and repeatedly and who is most happy post sale. Use this information to hypothesize pull again.

3 Customers

Leap Frog

Use the Case Study from top customer to get the 2nd, 3rd, etc.

1. Demand (out of your control)

   a. Scenario

   • Frequency: When does this project occur and how often?*
   • Project: What was this person trying to accomplish?
   • Context: Why was this on the top of their plate?

   b. Catalyst

   • Disequilibrium: Why this person needed to change?*
   • Options: What solutions did this person consider? Why did your product stand out from the others?

   c. Outcome

   • Success: What key success indicators did they achieve?

2. Supply (within your control)

   a. Outcome ("How")

   • How did they complete their project?
   • How did your solution help them?

   b. Catalyst ("What")

   • What did they buy (packaging, positioning, pricing, offer, etc.)?

   c. Scenario ("When")

   • When did they know they were going to be successful?
   • How long did it take?

Diagnose Bottlenecks in Case Study Factory

Solve each one at a time while targeting the biggest ones.

Retrospective

Figure out who your 'Hell Yes!' customer is from all the ones with intense demand. They are the one who buys fast, uses often, and renews/expands post-sale. That is your ICP moving forward.

Helpful Resources

• The Physics of Startups: Demand
• Why its so hard to see demand
• What demand looks like
• Demand is invisible
• Demand =/= "people who want to buy your product"
• Harvard Innovation Labs: The Path to PMF - What is Demand

Footnotes

1. When Not What ↩

2. Finding "Good" Demand ↩

3. The Physics of Startups: Supply ↩

4. The Physics of Startups: How Do Startups Work ↩

5. Harvard Innovation Labs: The Path to PMF - A Case Study is a Story in 6 Parts ↩

6. Harvard Innovation Labs: The Path to PMF - I-LAB: CASE STUDY ASSIGNMENT ↩

7. The Physics of Startups: Physics of the Case Study Factory ↩ ↩²

8. Harvard Innovation Labs: The Path to PMF - Outbound Cheat Codes ↩

9. Harvard Innovation Labs: The Path to PMF - The early-stage minimum viable sales process ↩

10. Harvard Innovation Labs: The Path to PMF - Sales Deck Template ↩

11. The Physics of Startups: Delivery + "Customer Success" ↩

12. Theory of Constraints <> Your Software Businesses ↩

13. _How to figure out 0-1 sales ↩

14. The Physics of Startups: How to Test a Hypothesis ↩

15. The Physics of Startups: The Path to Product-Market Fit & Hypergrowth ↩