Building Brand Before Building Product
The counterintuitive case for knowing who you are before you build anything
The standard advice is ship first, brand later.
Get a working product. Find users. Iterate based on feedback. Once you have something real, then worry about what it looks like and what it’s called. Brand is polish. Polish comes after substance.
This advice is wrong more often than it’s right.
In crypto especially, brand isn’t polish. It’s foundation. The teams that figure out who they are before they write code often build better products than teams that figure it out after.
The ship first fallacy
Ship first sounds pragmatic. Don’t waste time on logos when you could be building. Don’t debate names when you could be shipping features. Substance over style.
But here’s what actually happens.
You ship something. It works. Users show up. Now you need a name. You pick something fast because you’re busy building. The name is fine. Not great. Fine.
You need a website. You throw something together. It looks like every other crypto project because you used the same template everyone uses. Fine. Not distinctive. Fine.
You need to explain what you do. You write copy in an afternoon. It’s generic because you haven’t thought deeply about positioning. It describes features. It doesn’t capture why anyone should care.
Now you have users. And a name that’s fine. And a website that’s generic. And positioning that’s fuzzy. And everything you build from here inherits these foundations.
Changing a name after launch is painful. Changing positioning after you’ve attracted users who came for something else is painful. Rebuilding brand equity from scratch is expensive.
The time you saved by skipping brand work upfront gets paid back with interest later.
What brand before product actually means
This isn’t about spending six months on logo design before writing code. That’s obviously stupid.
Brand before product means answering fundamental questions before you build.
Who is this for. Not everyone. Specifically who. What do they care about. What language do they use. Where do they hang out. What do they believe.
What problem are we solving. Not features. The actual problem in someone’s life that we address. Why does this problem matter. Why hasn’t it been solved already.
Why us. What makes us the team to solve this. What perspective do we have that others don’t. What are we willing to do that others won’t.
How should this feel. When someone uses this product, what’s the emotional experience. Confident. Playful. Powerful. Calm. The feeling shapes every design decision.
What do we believe. What’s our point of view on the space we’re entering. What do we think others get wrong. What hill would we die on.
These questions take days to answer well, not months. But most teams never answer them at all. They just start building and hope clarity emerges.
Sometimes it does. Usually it doesn’t.
Why crypto makes this more important
In traditional software, you can hide behind functionality for a while. If your product works better, people will tolerate generic brand.
Crypto is different.
You’re asking for trust before you’ve earned it. Users are putting money into something new. They’re evaluating not just whether it works but whether they believe in it. Brand carries that belief.
You’re building in public. Your Discord exists before your product. Your Twitter presence matters from day one. Community forms around the idea before the implementation. That community needs something to form around.
You’re competing with forks. Your code isn’t defensible. Your brand is. If you don’t establish strong positioning early, a fork with better marketing can capture the narrative.
You’re often fundraising before shipping. Investors are betting on vision as much as execution. A clear brand makes the vision legible. A fuzzy brand makes it hard to understand what you’re even building.
Everything moves faster. In web2, you might have years to figure out brand. In crypto, narratives form in weeks. If you don’t define yourself, others will define you.
What this looks like in practice
Before you write code, spend one week on brand foundations.
Day one and two. Audience definition. Who specifically are you building for. Write a description of your ideal user. Give them a name. Describe their day. Understand their problems.
Day three. Positioning. What’s your one sentence description. How are you different from alternatives. What’s the tradeoff you’re making that others won’t. Write a positioning statement.
Day four. Principles. What do you believe about your space. What would you argue for publicly. What decisions does this make easy. Write three to five principles.
Day five. Voice. How do you sound. Formal or casual. Technical or accessible. What words do you use. What words do you avoid. Write sample copy.
Day six and seven. Visual direction. What’s the feeling. Find references. Define the aesthetic territory. You’re not designing a logo. You’re establishing the world the logo will live in.
One week. Five to seven days of focused work. Not instead of building. Before building.
The output is a short document. Maybe ten pages. It guides everything that follows.
The products that did this well
Phantom had brand clarity from day one. They knew they were building for Solana users who wanted something better than existing options. The name communicated speed and smoothness. The visual design was clean and confident. The voice was friendly but not childish.
This wasn’t luck. They thought about it before shipping.
Blur knew they were building for professional NFT traders. The dark interface, the dense information display, the aggressive branding. Everything signaled “this is for serious people.” The brand attracted exactly the users they wanted.
Base had Coinbase’s design resources but they didn’t just inherit the Coinbase brand. They developed a distinct identity. Optimistic. Builder-focused. The visual language was deliberately different. The positioning was clear.
In each case, brand work happened early. Not after product-market fit. Before.
The risks of brand first
This approach has failure modes.
Over-investing too early. Spending three months on brand before validating anyone wants what you’re building is dumb. Brand foundations should take a week, not a quarter.
Falling in love with positioning that’s wrong. You might define an audience that doesn’t exist. You might position against competitors that don’t matter. Brand hypotheses need validation like product hypotheses.
Letting brand constrain product. If your principles say one thing but user feedback says another, listen to users. Brand should guide decisions, not override evidence.
Confusing brand with marketing. Brand foundations aren’t launch campaigns. They’re internal clarity that makes external communication possible.
The goal isn’t perfect brand before building. It’s clear enough brand that building goes faster and better.
The real output
Teams that do brand work early build more coherently.
When you know who you’re building for, feature decisions get easier. Does this serve our user? Yes or no.
When you know your positioning, you can evaluate opportunities. Does this reinforce where we want to be? Yes or no.
When you know your principles, hard calls have frameworks. What would someone who believes what we believe do?
When you know your voice, writing gets faster. You’re not figuring out how to sound with every tweet.
Brand before product isn’t about marketing. It’s about building with intention instead of building and hoping meaning emerges.
Some teams ship first and figure it out. Some of them succeed. Many end up with products that work but brands that don’t. Features nobody remembers attached to names nobody recalls.
The week you spend on brand before building is the cheapest investment in coherence you’ll ever make.
Probably worth the time.
Thank you :)
If your project needs design, brand, product, strategy, and leadership,
let’s talk, hi@dragoon [dot] xyz | Follow: 0xDragoon