Narrative architecture

People usually bring in narrative once there’s something to package. A website. A deck. A launch. A founder story. By then, a lot of the important decisions have already been made.

What I’ve found is that this work is often more useful earlier. Not because a company needs better-sounding language, but because early-stage teams need a clearer way to think. They need some shared understanding of what they’re building, why it matters, what kind of experience it’s supposed to create, and what should stay true as the company starts making decisions across product, design, sales, and everything else.

Most good products already have a real point of view inside them. There’s some belief about how this should feel to use, what should be easier than it is now, what kind of relationship a person should have with the tool. Usually the founder can feel it. The designer can too. Often the strongest engineer can feel it just as clearly. But that doesn’t mean the company has turned that instinct into something other people can actually use.

So the product may have a strong internal logic, while everything around it starts drifting. The website leans generic, the deck focuses on the wrong things, onboarding solves for something slightly different, and sales develops its own explanation. None of it looks disastrous on its own. Together, though, it creates drag. The company starts sounding less clear than it actually is.

That’s why I don’t think narrative is just about presentation. At an early-stage startup, it can be a practical tool for making decisions. It helps people answer the same questions as they keep showing up in different forms: what are we really building, what matters most here, what should this feel like to use, what should a customer understand quickly, and what are we not trying to be?

In practice, that usually means giving the team something they can actually use. A short narrative document, or a set of working principles. Not a manifesto. Just a clear articulation of the product’s logic and what should stay true as the company grows. Product can use it to pressure-test decisions. Design can use it to decide what to emphasize or simplify. Sales can use it to stay close to the real promise of the product instead of reaching for whatever pitch seems easiest in the moment. And the founder can use it to explain the company with more consistency, without sounding rehearsed.

When that logic is clear, it starts carrying more weight than people expect. It shapes the way the company talks about itself, but it also shapes the product itself. It affects what gets emphasized in the interface, how onboarding is structured, what a demo needs to prove, what sales reinforces in conversation, and which details make the product feel coherent instead of merely functional.

Take something like calm, or agency. Maybe the product is meant to make work feel less scattered. Maybe it’s meant to make the user feel more capable and more in control. If that idea is central, it shouldn’t stay in brand language. It should shape what the interface emphasizes, how quickly complexity is introduced, how suggestions are presented, how easy it is to override an output, and even what the company decides not to build.

Transparency is another good example. Not as a value pasted onto the site, but as a real product belief. If it matters, it should show up in onboarding, in how uncertainty is communicated, in the way outputs are explained, in what sales promises, and in the kinds of claims the company is willing to make publicly.

That matters because customers rarely experience a company in one clean, controlled moment. They get fragments instead: a sentence on the homepage, a product interaction, a sales call, an onboarding flow, a founder explaining what the company is trying to do. Trust builds from those fragments. Not because each one is perfect, but because together they add up to a sense that the company knows what it’s doing.

From the outside, this kind of work can look fairly simple. Sometimes it becomes a short document. Sometimes it’s a handful of clarified ideas. Sometimes it’s advisory work around language, product decisions, or both. But if it’s working, it’s doing more than improving expression. It’s reducing ambiguity. It’s giving the company a clearer center to build from.

Early-stage startups usually don’t need more language. What they need is stronger alignment between what they believe, what they’re building, and how that belief shows up in the actual experience of the company. That’s where narrative starts doing real work.