How to build the "right" product

Why feature requests =/= demand

PSA: There’s a companion podcast! I go into WAY more detail on the “Physics of Startups” podcast - available on Spotify, YouTube, & Apple Podcasts.

Turns out, it is damn hard to build something people want… even when they literally tell you what they want.

This is my all-time favorite video about building products. It’s by Ryan Singer and Chris Spiek, who were leaders at Basecamp (the project management software company). In the video, they explain why “feature requests aren’t demand”.¹ It is a crime against humanity that this video has less than 7,000 views.

Their point is that there is supply - what we make - and there is demand - what the customer is trying to accomplish. When a customer requests a feature, they are requesting supply, not expressing demand. This is confusing because when someone says “I want X”, we think it means they have demand for X. And when we mistake “requesting supply” for “expressing demand”, we waste a ton of time building the wrong thing.

Here’s the example that finally made “demand vs. supply” click for me.

The Permissions Feature

Basecamp was getting a lot of requests for a permissions feature.

At face value, this request seems reasonable. There are a lot of teams who use Basecamp, so it makes sense that different people should be able to do different things in the product. Because we get a lot of requests for a permissions feature - some of them saying that if we don’t add a permissions feature, they will churn - it seems like there is real demand for a permissions feature.

But as we try to start designing the permissions feature, we don’t know what success looks like for customers. Is success, “there’s now a permissions feature?” No, that makes no sense. The permissions feature is just a tool on the supply side; they would use a permissions feature to accomplish something in their world. That something is what matters.

At this point, we don’t know what the customer is trying to accomplish. Going deeper on the supply side won’t help: We won’t understand demand by asking customers about their requirements or showing them mockups and saying, “What do you think?”

We also don’t want to know WHY they want this feature - they’ll say something like, “because it will save me time,” which is them justifying why they want supply, not them talking about demand.

Because we don’t know what’s on the demand side, we can’t even tell whether a permissions feature is the right supply to “fit” demand. And even if a permissions feature is the “right” thing, that’s a super broad feature - how do we scope it so it doesn’t take years to build?

We need to figure out what’s on the demand side, the project on their to-do list that caused this feature request. So we need to ask, “When did you need this? What happened in your world leading up to requesting this feature?”

Turns out, this was the customer’s story:

• There was an important project being managed in Basecamp

• A contractor was brought in to do a small part of the project

• When the contractor completed her small part of the project, she clicked “archive project,” thinking she was simply removing the project from her own dashboard

• The project was removed from everybody’s dashboard

• Everybody freaked out

• Someone put in a feature request for a “permissions feature” so this didn’t happen again

Ah, now we can see demand! The project on their to-do list was really: “I want to prevent one person from unknowingly archiving a project for everybody.”

The “permissions feature” concept emerged because the customer was trying to translate from demand language to supply language - probably thinking it would make Basecamp’s lives easier.

And here’s the fun part: Now that we know that demand is “I want to prevent one person from archiving a project for everybody,” we can decide what supply approach to take that fits this demand.² Here are two options:

Option 1: We could build a permissions page, which is a very complicated thing to build and would probably take months, touching many different parts of the product.

Option 2: We could put a warning when someone clicks the “archive project” button, saying, “are you sure you want to archive this project for everybody?”. This would take a few hours.

I estimate Option 2 would take ~100x less engineering work than Option 1. But Option 2 is not just less work, it is also a better “fit” for customer demand! No customer wants to click around a permissions page, or have to think about the difference between “admin” and “super-admin” permissions - they just want to prevent contractors from archiving projects for everybody!

In this case, when we understand demand, we wind up doing 100x less work while making a higher-quality product (where quality = fitting demand).

It is hard to understate how much this impacts your product: I’d bet good money that most startups spend at least 90% of their development hours building supply without really understanding demand. When doing this, it would be weird if what they built was a good “fit” for demand. This compounds, because now we have to maintain and build atop a broader surface area. In Basecamp’s example, if they’d built the permissions feature, they’d now need to think about permissions for every single feature they build in the future - a massive tax on their product for the rest of time.

Trust me: It sounds cool to have a big product with a lot of features, but when it’s all cobbled together and doesn’t really fit demand, it sucks, development grinds to a halt, and a few customers now rely on the permissions feature so you’ll have a hard time killing it.

Broader implications

Seven things to consider:

1. Everyone on your team - not just the “sales founder” - needs to know the difference between demand and supply. Understand demand, then figure out supply that “fits”. You can use the PULL framework for scoping out features, which enforces demand-first thinking.

2. Customers can’t speak supply language. It’s not their job to tell us what product or features to build. They are experts on the demand side - what’s happening in their world, what they’re trying to solve for - and they are axe-murderers on the supply side.

3. In sales calls, you’ll realize you’re going down supply-side rabbitholes when you really should be bringing it back onto the demand side. When you understand demand - and your supply “fits” demand - you should have a ~100% close rate.

4. In product/eng, most backlogs and roadmaps are just supply-side chaff that won’t actually help on the demand side. This leads to the (misnomer) “feature factory” where engineering is furiously building things that don’t matter. Nuke it all, focus on demand.

5. What, then, is a “good” or “high-quality” product? It is a product that fits demand well. This is why startups often grow super fast with happy customers despite their products being duct-taped together: The product fits demand such that buyers pull it out of their hands, even though the product frequently breaks or is technically inferior to others via some objective (but irrelevant) criteria.

6. When someone shows you that stupid trade-off triangle about product development - “speed, quality, cost” (trying to make the point that you need to slow down or spend more or whatever) - they don’t understand that this trade-off comes AFTER you have decided on supply, and that you can have all three if you understand demand.

7. Now you can see why many of the startups that work super hard don’t accomplish much - they are usually focused 100% on the supply side without really understanding demand, saying to themselves “we’re building the best product” without knowing what “best” means. Understand demand and you don’t have to work hard performatively. (But you still have to work hard.)

---

PS: I run a “product-market fit + sales” course & do 1:1 work with B2B founders to figure out 0-1 sales. Both are booked through September, so if you’d like to potentially work with me in Q4, reserve time on my Calendly for mid-late Sept HERE - more info about working with me is HERE.

PS: My startup, Waffle, has a few beta slots available for our new AI DevOps engineer (1-min explainer video HERE.) If your team wants access, I’m happy to include you in the beta (just email me at rob@reframeb2b.com).

1. This video kickstarted my induction into the cult of demand. There is such a thing as the cult of demand. We even have tee shirts.

2. For more context on shaping supply, I recommend reading Shape Up, particularly Chapter 2.