What We Look for in Founders (And What We Don't)_
What We Look for in Founders (And What We Don't)
Sequoia Capital famously asks four questions about every opportunity they evaluate. Don Vallentine, their founder, called them "the four terrifying questions" because most ideas can't survive all four:
- Is this big enough?
- Do people care?
- Does it change behavior?
- Will people pay?
These are good questions. They're necessary questions. But they're questions about the idea, not the founder. And after years of building and backing ventures, I've come to believe that the founder matters more than the idea — not because ideas don't matter, but because good founders transform mediocre ideas into great companies, while mediocre founders waste great ideas.
So we ask different questions. Three of them.
Question One: Can You Decide What to Build?
This is the question about taste.
Taste is the most undervalued quality in technology. We talk endlessly about technical skill, execution speed, fundraising ability, and "hustle." But taste — the ability to discern what matters from what doesn't, to make the thousand micro-decisions that determine whether a product is merely functional or genuinely great — is the quality that separates memorable products from forgettable ones.
Steve Jobs had taste. That's why the first iPhone had one button when every competitor had forty. It's not that he couldn't build forty buttons. It's that he knew one button was right. That decision — the willingness to be opinionated about what belongs and what doesn't — is taste.
When I evaluate a founder, I'm looking for this quality in everything they show me. Not just the product (though that's the most obvious artifact), but the pitch, the team composition, the market positioning, even the email that landed in my inbox.
A founder with taste sends a two-paragraph email that makes me want to learn more. A founder without taste sends a twelve-page deck that makes me want to learn less.
A founder with taste has a product that does three things well. A founder without taste has a product that does fifteen things adequately.
A founder with taste can explain their market positioning in one sentence. A founder without taste needs a quadrant chart with custom axes.
Taste isn't subjective. It feels subjective, but it's actually the result of deep pattern recognition — having consumed enough examples of good and bad that you develop an intuition for which decisions lead to elegance and which lead to bloat. Founders develop taste by caring deeply about the details of their domain for years, not by reading design blogs for weeks.
Question Two: Can You Decide What NOT to Build?
This is the question about judgment.
If taste is knowing what matters, judgment is knowing what doesn't. And in many ways, judgment is the harder skill.
Every startup faces a constant barrage of feature requests, market opportunities, partnership proposals, and investor suggestions. Each one, in isolation, seems reasonable. "You should add Slack integration." "Have you considered the healthcare vertical?" "What if you also did payments?" Each suggestion has a plausible business case. Each one, if pursued, would expand the product's surface area.
The founders who succeed are the ones who can look at a plausible opportunity and say "no" — not because they don't understand its potential, but because they understand its cost.
The cost isn't just engineering hours. It's cognitive load on the team. It's complexity in the codebase. It's ambiguity in the market positioning. It's dilution of the brand promise. Every feature you add is a feature you must maintain, document, support, and defend. Every market you enter is a market you must understand, serve, and compete in.
I've watched promising startups implode not because they built the wrong thing, but because they built too many right things. They pursued seven reasonable opportunities simultaneously and executed none of them well enough to win. Their product became a swiss army knife — technically capable of everything, genuinely good at nothing.
When I talk to a founder, I ask: "What have you explicitly decided not to build?" The answer tells me everything.
Weak founders struggle with this question. They'll say something like, "Well, we haven't gotten to payments yet, but it's on the roadmap." That's not a decision. That's a deferral.
Strong founders light up. They'll say, "We will never do X, because Y, and here's the pressure we've faced to add it, and here's why we resisted." They have a kill list — a set of features and markets they've actively rejected, with clear reasoning for each rejection. They can articulate the tradeoff they made and why the alternative path would have been wrong.
This is judgment. The ability to see a reasonable opportunity and choose not to pursue it because pursuing it would compromise something more important.
Question Three: Can You Make It Last?
This is the question about architecture.
I use "architecture" broadly here — not just software architecture (though that matters), but the architecture of the business itself. The revenue model, the team structure, the customer relationships, the competitive positioning — all of these are architectural decisions that determine whether a company can endure or whether it's built on a foundation that will crack under pressure.
The prototype-to-production gap is where most startups die. Building a demo that impresses investors is easy. Building a system that serves thousands of customers reliably, that handles edge cases gracefully, that scales without collapsing, that maintains data integrity under concurrent load — that's hard. And it's a different kind of hard than building the demo.
Founders who can navigate this gap think architecturally. They ask: "If this works, what breaks?" They design for the second year, not just the first sprint. They choose boring technology when boring technology is appropriate, not because they don't know about the shiny new thing, but because they understand that reliability is a feature.
Architectural thinking also applies to the business model. Can this company generate revenue that compounds? Are customer acquisition costs sustainable at scale? Is there a natural moat — switching costs, network effects, data advantages — that deepens over time? Or is this a business that works at seed scale but structurally can't work at Series B scale?
I've met founders who built beautiful products on business models that were structurally unsound. The product worked. The unit economics didn't. And by the time they realized it, they'd spent three years and millions of dollars building something that could never be profitable at scale.
Architecture is unglamorous. It's the foundation work that happens before the visible structure goes up. It's choosing the right database before writing the first feature. It's designing the pricing model before closing the first customer. It's building the team structure before hiring the tenth person.
Founders who think architecturally build companies that last. Founders who don't build companies that grow fast and break faster.
What We Don't Look For
Let me be explicit about what doesn't move the needle for us.
Pitch deck polish. I've seen world-class pitch decks from companies that failed within eighteen months and napkin sketches from founders who built enduring businesses. A well-designed deck tells me you're good at making decks. It tells me nothing about whether you can build a company.
Vanity metrics. Users, downloads, page views, social media followers — these are noise unless they translate to revenue or engagement that predicts revenue. A million downloads with 2% day-30 retention is worse than ten thousand downloads with 40% retention. I care about the metrics that matter, not the ones that impress.
"AI for AI's sake." If a founder's primary selling point is "we use AI," I'm immediately skeptical. AI is a capability, not a product. "We use AI to reduce construction loan underwriting from six weeks to three days" is compelling. "We're an AI company" is meaningless. The most dangerous founders are the ones who start with the technology and go looking for a problem. The best founders start with the problem and reach for whatever technology solves it — AI or otherwise.
Resume credentials from big tech. I don't care that you were at Google or Meta or Amazon. Those are great companies. Working there teaches you how large organizations operate. But startups are not large organizations. The skills that make you successful at a 50,000-person company — navigating bureaucracy, building consensus, operating within established systems — are often the opposite of what makes you successful at a 5-person startup.
What I do care about is whether you've operated in the messy, ambiguous, under-resourced environment where startups live. Have you built something from nothing? Have you shipped a product with no QA team, no DevOps team, no product manager? Have you closed a customer by yourself? Have you made a payroll decision that kept you up at night?
What Signals Conviction
The strongest signal I've found for founder quality is what I call domain scar tissue — the hard-won knowledge that comes from living inside a problem for years.
Founders with domain scar tissue have a particular quality in conversation. They don't pitch. They explain. They tell you about the seventeen things they tried that didn't work and why the eighteenth might. They describe the regulatory landscape not as an obstacle but as a map they've memorized. They know which customers will adopt early and which will wait, not from market research but from having been rejected by both.
When I ask a founder with scar tissue about competitive threats, they don't show me a quadrant chart. They tell me, "Company X tried this approach in 2019 and failed because of Y. Company Z is doing well in segment A but can't enter segment B because of regulation C. We're positioned at the intersection that neither can reach because we've spent four years building relationships with stakeholders D and E."
That's not research. That's lived experience. And it's irreplaceable.
Another signal: founders who can articulate what they won't build with the same clarity and conviction as what they will. The "anti-roadmap" is often more revealing than the roadmap itself. It shows that the founder has thought deeply about tradeoffs, has been pressured to expand scope, and has maintained discipline.
The weakest signal, in my experience, is confidence. Confident founders are everywhere. Conviction is different from confidence. Confidence says, "This will work." Conviction says, "This must exist, and I'll keep building it regardless of whether it works on the timeline investors want." Confidence is a personality trait. Conviction is a relationship with the problem.
Patterns That Predict
I'll share a few patterns I've observed, with the caveat that pattern recognition in venture is inherently noisy and these are tendencies, not laws:
Founders who've been thinking about the problem for years tend to outperform founders who discovered it recently. The depth of understanding compounds. A founder who has been obsessing about construction financing for a decade will see opportunities and risks that a founder who pivoted from adtech last quarter simply cannot.
Founders who can code (or who deeply understand technology) tend to build better products than those who can't, even if they're not writing code day-to-day. The ability to evaluate technical tradeoffs, to understand what's hard versus what's easy, to push back on engineering estimates with informed skepticism — this is a superpower at early stage.
Founders who've experienced failure are better than those who haven't. Not because failure teaches success (it often doesn't), but because it teaches resilience and humility. A founder who's been through a failed startup knows what 3am feels like when the server is down and the customer is angry. That knowledge is calming, not traumatizing.
Co-founder relationships that predate the startup tend to survive longer than those formed for the startup. The stress of building a company reveals every crack in a relationship. If the crack was already there before the company, it will open wider. If the relationship was forged over years of trust, it can bear more weight.
Honest Admission
I've been wrong. More than once. I've passed on founders who succeeded brilliantly and backed founders who failed despite having every quality I just described. Pattern recognition in venture is a noisy signal in a noisy environment.
What I've learned is to hold my patterns loosely. They're filters, not formulas. They help me ask better questions, not guarantee better answers.
The three questions — taste, judgment, architecture — aren't a scoring rubric. They're conversation starters. A founder who scores perfectly on all three but can't articulate why they care about the problem will lose to a founder who scores poorly on one but burns with conviction about why this specific thing must exist in the world.
In the end, what we look for is something hard to name and impossible to fake: the sense that this person and this problem were always going to find each other, and that the only variable is timing.
If you're that person, we want to talk.