Who Are You Building For? The Brand Question Behind Product Strategy

A couple years ago, we were out to dinner with a client who'd spent decades in product management. The kind of person who's seen every version of the startup story: the scrappy beginning, the first big customer, the messy middle where "just one more feature" quietly becomes the whole business. Over appetizers, we were complaining about something we see all the time: overeager founders promising new features to close deals. Not because they're foolish — because the pressure is real. The pipeline is lumpy. The runway is finite. And when a prospective customer says, "We'll sign if you just add X," it can feel like oxygen.

He listened, smiled, and offered us an axiom that we've held onto ever since: "Is this feature going to help you win the market, or just this customer?" Not "is it technically possible." Not "could we squeeze it in." Not "would they pay for it." Market. Or customer. That's the whole knife edge.

The reason that axiom stuck with us isn't just because it's good product discipline. It's because product decisions are brand decisions. Every time you say yes to a custom feature, you're not just adding complexity to your codebase — you're fragmenting your brand story. And in early-stage companies, that's often the thing that kills you before the technical debt ever does.

The custom feature trap isn't the code. It's what it does to your story.

In early-stage companies, custom functionality rarely shows up wearing a villain costume. It shows up as revenue: a deal, a logo, a case study, a warm intro to three more prospects. And sometimes you should take that deal. Early revenue is oxygen. The problem is what "custom" actually means over time. A custom feature isn't just technical debt — it's another exception you have to explain. Another "yes, but also..." that makes it harder for people to understand what you actually do. And when people can't understand what you do, they can't choose you. They can't refer you. They can't become champions for your work because the story doesn't stick.

Your brand is only as clear as your ability to say what you do in one sentence. Custom features make that sentence impossible. They turn "We help [specific customer] solve [specific problem]" into "Well, we do X, but we also do Y for this one customer, and we're building Z because someone asked, and..." By the time you finish, you've lost them.

"Win the market" doesn't mean "dominate an industry"

When we say "market," founders often hear something grand and abstract. That's not what I mean. Early on, "winning the market" usually means becoming the obvious choice for a specific kind of customer with a specific kind of problem. Not everyone. A someone. And the way you know you're finding that "someone" is repetition: the same pain described in different words, the same workflow with the same sharp edges, the same "I can't believe we're still doing this manually."

If a feature request comes from that repeating core, it's probably product. If it comes from one loud prospect with an idiosyncratic setup, it's probably custom work disguised as product. That doesn't make them wrong. It just means their problem might not be your product. And building it anyway doesn't just add code — it adds another branch to explain, another special case that makes your brand story fuzzier.

This is why the "market vs customer" axiom works so well. It forces you to ask: is this request part of the repeating pattern… or a one-off? Does this make my brand story clearer or more confusing?

Three questions before you commit

When a prospect asks for custom functionality, we run three questions before we say yes.

First: Would we build this if this customer didn't exist? If the answer is no, it's not product work — it's custom implementation. And custom work, even when it's paid, fragments your brand story. It's another branch you'll need to explain, another exception that makes "what do you do?" harder to answer. Sometimes the revenue is worth that cost. But be honest about the trade you're making.

Second: Have we heard this in at least three other conversations? Not "someone mentioned it once." Real repetition. Similar context. Similar motivation. Similar pain. Three isn't magic; it's just a useful speed bump that keeps you from overreacting to one deal.

Third: Does it strengthen the core… or add a branch? Core features deepen what you already are. They make your brand story tighter, not looser. Branches create new categories of complexity — new workflows, new edge cases, new "special" UI. And every branch is another thing you have to explain when someone asks what you do.

Sometimes the right answer is "no"

Saying no isn't about ego or purity. It's stewardship. If you say yes to every feature that could close a deal, you don't end up with a product — you end up with a collection of obligations. And you don't end up with a brand — you end up with a blurry promise that nobody can remember or repeat.

Here's the question I try to end these conversations with: If we say yes to this, what are we saying no to for the next 90 days? Because that's the real trade. It's the kind of thing that feels small when you build it…but the interest compounds over time. And it doesn't just compound in your codebase. It compounds in your story.