What Y Combinator Taught Us About Product

Getting into Y Combinator changes the way you think about your company, but not in the ways I expected. I went in thinking I'd learn about fundraising, growth metrics, and how to pitch investors. Those things are there, but they're not the core of what YC teaches. What YC actually teaches — relentlessly, from every angle — is how to build something people genuinely want.

That sounds obvious. It isn't.

The Make Something People Want Problem#

The Y Combinator motto is "make something people want." In eleven words, it contains more product wisdom than most books on the subject. But it's easy to nod at the motto and continue building something people don't want, because the failure mode is subtle.

The failure mode is building something people say they want, or something you think they should want, rather than something they demonstrably, measurably, actually want. The gap between those things is where most startups die.

At DenchClaw, we started with a hypothesis: knowledge workers want a CRM that runs locally and is controlled by an AI agent. We had good reasons to believe this. We'd talked to potential users. We'd done interviews. We'd seen the HubSpot pricing complaints on Twitter. We believed in the thesis.

What YC forced us to do was test that belief against reality — not with surveys, but with working software and actual users.

The process is brutal in the best way. Every week, there's implicit pressure to show that more people are using your product. Not downloads — usage. Not sign-ups — people actually running the software, doing real things with it. And if that number isn't growing, you need to understand why.

The Right Kind of Uncomfortable#

The most useful thing YC does is make you uncomfortable in a productive way.

One of the YC partners told us early: "Talk to users more than you think you need to. You think you're talking to users enough. You're not." This is true. The instinct when you're building something technical is to go to the code when you're stuck. The code is knowable, controllable, solvable. Users are messy and say contradictory things and don't always know what they want.

But the code is not the product. The user's experience is the product. And you can only understand the user's experience by being in it with them.

We shifted to doing three to five user conversations per week. Not sales calls — genuine inquiry. "What are you actually doing with this? What's annoying? What's surprisingly good? What would make you tell a friend about it?" The answers are often uncomfortable. They surface blind spots you didn't know you had.

One pattern we kept hearing: people loved the idea of local-first, but they wanted it to be invisible. They didn't want to think about where the data lived. They wanted to think about their pipeline. The "local-first" feature is most valuable when you never have to think about it — when it just makes everything faster and more private without any additional cognitive load.

This insight shaped a lot of our product decisions. We stopped leading with the technical architecture in our messaging and started leading with the outcomes: "Your CRM responds instantly. Your data stays on your machine. You talk to it like a person."

Paul Graham's What to Build Heuristic#

There's a Paul Graham heuristic I've found genuinely useful: the best startup ideas are things the founders need themselves. Not "would use" — actually need. The reason is that if you need something and it doesn't exist, you have a direct line to the problem. You know when it's solved. You know when it's not. You're not guessing at what matters.

We needed DenchClaw. Mark and I were managing investor relationships, partner conversations, customer development calls — a hundred ongoing relationships with context that needed to stay organized. We'd tried every CRM. They were all slower than a terminal, more expensive than justified, and designed for a human operator rather than an AI agent.

So we built the thing we needed. When it started working for us — when our own CRM interactions changed from "let me open HubSpot and wait for it to load" to "let me just ask the agent" — we knew we had something.

The YC version of this heuristic: if you're embarrassed to use your own product for its intended purpose, that's a problem. If you've quietly switched back to the incumbents for your real work while "working on" your startup, that's a problem. If you'd use your product even if you weren't building it, you're probably onto something.

The Danger of Being Too Early#

One thing YC emphasizes that I found counterintuitive: being too early is functionally the same as being wrong. A product that's right but five years ahead of the market is a failed company. The market timing matters as much as the idea.

We had to think carefully about this for DenchClaw. Local-first software is having a moment right now, but five years ago it would have been a much harder sell. What changed?

Apple Silicon happened. The M-series chips made local AI inference practical on consumer hardware. DuckDB happened — it made embedded analytical databases viable for applications that previously would have needed a separate database server. The SaaS pricing backlash happened — multiple large companies did significant price increases or hostile pricing changes that burned their power users, creating a population actively looking for alternatives.

These changes happened simultaneously. They created a window. We're trying to build something real before the window closes or shifts.

Being at YC helped us articulate this market timing argument clearly. Not just "local-first is the right architecture" but "local-first is the right architecture AND the enabling technologies just matured AND the market is ready for it." Those three things together make a different case than any one of them alone.

The Hard Part They Don't Advertise#

Here's something about YC that isn't in the marketing materials: it's a test of execution under pressure.

The YC timeline is tight. Demo Day is a deadline. You ship or you don't. There's no "we're thinking about this" — either users are using your product or they aren't. The clarity is useful but exhausting.

You learn a lot about your company under those conditions. You learn which of your instincts to trust and which to ignore. You learn how you react when something isn't working. You learn how you prioritize when everything feels urgent.

For us, the biggest lesson was about scope. The instinct when you have a lot of ideas and limited time is to try to build everything at once, because you're afraid of being wrong about any one thing. YC's implicit lesson is: pick the thing that's most likely to matter and go deep on it. A product that does one thing exceptionally well is better than a product that does ten things adequately.

We cut features. We simplified the setup flow. We made the core CRM experience as smooth as we could rather than adding capabilities. And the result was that people who tried it were more likely to keep using it.

Less is more is such a cliché that it's hard to take seriously. YC makes you take it seriously by showing you what happens when you don't.

What Changed in How We Think About Product#

After YC, a few things changed fundamentally in how I think about product decisions.

The question is always "who is this for?" Not in a demographic sense, but specifically — what is the mental model of the person who will benefit from this feature? What do they care about? What's their workflow? If I can't answer that concretely, I'm not ready to build the feature.

Metrics are proxies, not truth. Engagement metrics, retention rates, NPS — these are useful signals but not the thing itself. The thing itself is whether real people are getting real value. I've seen products with good metrics that were slowly dying because the metrics were measuring something adjacent to the actual value. Talk to users. The metrics are guides, not answers.

Product quality compounds. A product that's 10% better than an alternative in every dimension isn't 10% better overall — it's dramatically better, because good products are a sum of interacting qualities. Speed, reliability, ease of use, feature completeness — they multiply, not add. This means small improvements in the right places have outsized effects.

Ship before you're ready. This is the one everyone knows and almost no one actually does. The version where you wait until it's polished enough to show people — that version never ships, because polished enough is a moving target. Ship rough, learn what to fix, fix it. The feedback from real users is worth more than any amount of internal polishing.

Frequently Asked Questions#

Do you have to be a YC company to get this kind of product feedback?#

No. The valuable part of YC isn't unique to YC — it's the discipline of talking to users regularly, shipping frequently, and measuring real usage rather than proxies. You can impose this discipline on yourself. It's just harder without external accountability.

What did YC teach you about pricing?#

That pricing is a product decision, not a finance decision. How you price signals what you are. Free open source signals trust and ecosystem-building. We chose that. There's a complementary cloud product that generates revenue. The pricing strategy serves the product strategy, not the other way around.

How do you balance user feedback with your own product vision?#

Users tell you what's wrong with the current product. They don't tell you what the product should be. Your job is to listen to what's broken while maintaining a vision of where it's going. The risk of over-indexing on feedback is building a product that solves only the problems users can articulate — which misses the problems they can't.

What's the most common mistake early-stage founders make in product?#

Building features instead of solving problems. A feature is a solution. A problem is a context in which users want different outcomes than they're getting. If you start with the feature, you might solve the wrong problem. If you start with the problem, the right feature often becomes obvious.

How has DenchClaw changed since YC?#

The core thesis (local-first AI CRM) hasn't changed. What's changed: the setup experience is dramatically simpler, the AI interface is more conversational and less form-based, the skill architecture is more extensible, and we've cut features that weren't being used to focus on the ones that matter.

Ready to try DenchClaw? Install in one command: npx denchclaw. Full setup guide →