🔀 Customers want things you shouldn't build

This week in The Pivot: just because our best customer wants a new feature doesn't mean we should build it.

Hey friends 👋

Every Monday in The Pivot, we share one anti-pattern we’re seeing from founders in the Traction Lab ecosystem, and the quick redirect that makes all the difference—in just 250 words.

Here’s this week’s:

The anti-pattern: feature requests as validation.

Most feature requests are mostly politeness.

We’re seeing founders get excited when a “big customer” asks for a feature—especially if it’s their only request—and immediately start planning 6-8 weeks of development.

The request feels legit because it came from a real customer who’s been “super happy” with the product, but there’s zero evidence they’ll actually pay for it, use it, or that anyone else wants it.

The fix: close the “say-do gap”.

Before you even write a single line of code.

Put a price on that feature and see if they’ll commit—not with enthusiasm, but with a contract or LOI.

If they won’t sign something that says “we’ll pay $X when you build Y,” you just saved yourself 6-8 weeks.

But that’s not enough.

Next, validate it’s not just one customer’s pet project—do 10 more customer conversations specifically about this problem. Are others experiencing it? Are they currently paying for workarounds?

If you can’t get concrete commitments from multiple customers, it’s scope creep disguised as customer development.

Use the Three-Signature test.

Before building any feature that takes more than 2 weeks, get three signed commitments (LOIs, contracts, or pre-orders) from customers who will pay for it.

If you can’t get three signatures, you don’t have a feature—you have a favor request.

And being nice isn’t a business model.

Until next week,

—jdm

---

PS: The Pivot is a new experiment in short-form, highly actionable content. Hit reply and let us know your thoughts. If you love it, please share it with a friend.