You Don't Build Traction Before Product—You Redefine What Product Means

The Pre-Product Traction Paradox

Every founder faces the same circular trap: investors want traction, customers want proof, and you need both to justify building. The question "how do you build traction before you have a product" seems reasonable until you realize it contains a false premise. The debate isn't whether you can build traction pre-product—it's about fundamentally redefining what "product" means in the first place.

This matters now more than ever. In an environment where capital efficiency determines survival, founders can't afford to spend twelve months building in a vacuum. But they also can't mistake social media buzz for actual validation. The path forward requires collapsing the distinction between traction and product development entirely.

What The Debate Revealed

The core tension emerged immediately: does traction require a functioning product, or can you build it through other means? But as the debate progressed, something more interesting surfaced—the participants weren't actually disagreeing about tactics. They were fighting over definitions.

The entrepreneurial perspective insisted that traction and product development are the same activity, not sequential phases. The argument: DoorDash's PDF menu and manual delivery service was their product, even though it couldn't scale. This view treats "product" as anything that exchanges value, regardless of how crude the mechanism.

The marketing perspective pushed back, arguing you can build traction around problem expertise before any solution exists. Superhuman's 180,000-person waitlist came from demonstrating deep understanding of email pain points, not from a working product. The claim: trust and audience-building are forms of traction that precede solutions.

The product perspective introduced a middle position: build traction with promises validated through manual delivery. Stripe's founders manually integrated payment processing before automating it. This view treats early traction as proof you can deliver an outcome, even if the mechanism is completely unscalable.

The operational perspective cut through the semantic debate with a sharp distinction: signals of intent (waitlists, buzz) versus real traction (usage, revenue). The challenge: if you can't get 10-50 people to commit money or reputation through direct conversation, you don't have validation—you have marketing theater.

"Promises get you meetings. Manual delivery of actual value gets you traction."

In the second turn, positions hardened around a crucial insight: the debate wasn't about whether to build something before seeking traction, but about what constitutes "building." The entrepreneurial view doubled down that a Dropbox video demonstrating core value was a product at that moment. The marketing perspective insisted that pre-sold audiences create leverage that makes launches explosive rather than starting from zero. The product view clarified that manual service isn't just validation—it's the first version of the product before automation.

The operational perspective remained skeptical of the romanticization, pointing out that Stripe's manual integration was a working product, just one held together with duct tape. The distinction matters because "promises" let founders procrastinate on actually solving problems.

The Framework: Three Paths To Early Validation

The debate reveals three legitimate approaches to building early traction, each appropriate for different situations:

The Concierge MVP: You are the product. Deliver the outcome manually, even if it requires your personal involvement in every transaction. This works when the value proposition is clear but the automation is complex. Stripe manually integrating payments, DoorDash founders delivering food themselves, or a recommendation engine powered by human analysts all follow this pattern. You're proving you can deliver the outcome before building what scales.

The Audience-First Approach: Build traction around problem expertise before offering solutions. This works when you're entering a space where the problem is widely felt but poorly understood. Create content that makes people say "this person gets it," document your research journey, and gather the people most desperate for a solution. When you launch, you're serving a crowd already gathered rather than starting from zero.

The Demo-as-Product: Create something that communicates the core value proposition so clearly that experiencing the demo is experiencing the product. Dropbox's video didn't let people store files, but it made the value so tangible that people had to have it. This works when the innovation is conceptual—when showing beats telling.

The key insight: all three approaches involve building something. The question isn't whether you need a product for traction—it's recognizing that a manual service, an audience, or a compelling demonstration are all forms of product in the early stages.

The Nuance: When Each Approach Works

The concierge MVP works best for B2B solutions where customers will pay for outcomes even if delivery is manual. It fails for consumer products requiring viral growth or network effects—you can't manually deliver Instagram.

The audience-first approach works when you have genuine expertise in a problem space and can articulate insights others can't. It fails when you're building in a well-understood market where the challenge is execution, not education. Nobody needs more content about productivity—they need tools that actually work.

The demo-as-product approach works when your innovation is conceptual and can be communicated clearly. It fails when the value only becomes apparent through actual usage over time. You can't demo your way to proving a marketplace has liquidity.

The operational perspective's warning holds regardless of approach: if you can't get real commitments—money, time, or reputation—through direct conversation, you don't have validation. A waitlist of strangers who clicked a button is worth less than ten customers who will take your calls.

Where To Start

• Redefine your product as the minimum viable exchange of value. Stop thinking about your product as the scalable platform and start thinking about it as whatever solves the problem, even if it's you doing it manually. Can you deliver the outcome with spreadsheets and elbow grease? That's your first product.
• Identify ten people experiencing the problem acutely right now. Not a thousand people mildly interested—ten people for whom this problem is urgent and expensive. Reach out directly. If you can't find ten people willing to have a conversation, you don't have a market.
• Charge money or get signed commitments before building anything scalable. Whether it's a pilot agreement, a design partner paying reduced fees, or customers prepaying for manual delivery, real traction requires real commitment. Anything less is a signal that might evaporate.
• Document and share your problem-space insights publicly. Even if you're pursuing a concierge MVP, build your credibility as someone who understands this problem deeply. The audience you build becomes your distribution channel when you're ready to scale.
• Set a deadline for transitioning from manual to scalable. Manual delivery validates the market but becomes a trap if you stay too long. Once you have ten customers whose problems you're solving manually, you know what to build. Don't get stuck being a service business when you meant to build a product.

The Real Question

The debate over building traction before having a product is really a debate over what we mean by "product" and "traction." The founders who win aren't the ones who wait to build traction until after they've built a product, nor are they the ones who try to generate buzz without solving real problems. They're the ones who recognize that in the earliest stages, the product is whatever creates traction—whether that's manual delivery, demonstrated expertise, or a compelling vision made tangible.

The question isn't whether you can build traction before you have a product. It's whether you're willing to deliver value in unscalable ways to prove your scalable vision is worth building.