This week was my last week at Amplitude.

I joined last year when Amplitude acquired Inari, the startup that Eric and I started during YC’s Summer 2023 batch. We jokingly referred to Inari as an “AI PM” that analyzed customer feedback, support tickets, and sales calls then surfaced what customers actually cared about. I think the underlying thesis is even more relevant today: coding agents will continue to improve, so a bottleneck to building better products is identifying what problems are valuable to solve from your data, generating plans for how to solve those problems, then instructing background agents to execute and drive outcomes.

We had the right thesis but nowhere near enough data to act on it. Amplitude had the missing pieces: behavioral analytics, session replays, agent traces, past experiments, user surveys, and thousands of companies trying to figure out why users loved one product but ignored another. So we joined to help make self-improving products a reality.

The year that followed was the best operating education I’ve ever received. We launched Amplitude Agents, shipped a breakout MCP server, analyzed millions of pieces of VoC data, and are now reinventing Amplitude behind the movement of self-improving products with Wave. Along the way I acted as an internal founder, built several new products, argued strategy with people much smarter than me, demoed to hundreds of enterprises, and watched a public company rewire itself around AI in under a year.

I learned a ton, so I wanted to document my favorite lessons from my time @ Amplitude.

1. If the builders don’t love it themselves, customers won’t either.

The best products I saw at Amplitude had an author, instead of an owner. I don’t mean a PM or engineer whose name appeared next to the roadmap item. By “author”, I mean someone who genuinely cared about the thing. They used it hourly. They knew which details irked them. Their stomachs turned when things broke. They took the compliments lightly and the failures personally.

You can feel the difference as a user. An authored product has defaults that someone clearly chose and loved. A product assembled from customer requests has a setting for every possibility, because nobody cared enough to decide what great looks like.

It’s a subtle trap in enterprise product building. A customer asks for something, the team builds it, and everyone quietly outsources their judgment back to the customer. “Well, they asked for it.” But a customer asking for a feature only proves that a customer asked for a feature. It doesn’t prove the workflow makes sense or that anyone will still want to use it after bringing it up on a sales call. Someone on the team still has to imbue their taste, and taste only comes from using it religiously yourself.

Steve Yegge made this point recently: build something for yourself and love it so much that you know other people should work that way.

To be clear, building for yourself isn’t sufficient. Internal users know too much and forgive too much, and you still have to talk to customers. But if the people with the most context and motivation don’t want to use the product, an external beta is not going to arrive carrying a box of taste and conviction.

I watched this play out in both directions at Amplitude. Our best AI launches, like Global Agent and our MCP server, started as bottoms-up passion products. The people building them were also their heaviest users, so they got better every week, because every rough edge was somebody’s personal annoyance. Compare that to our Website Optimization Agent, which we built for a theoretical enterprise customer we hoped to win. Nobody on our teams was optimizing our own websites with it. Our hearts weren’t in it, and it showed: we never got it working, because no one felt the failures personally enough to chase them down.

TL;DR: Every day, the person building the product must use the thing on a real problem themselves. No staged demos, no explaining away the bad parts. Before shipping something to a customer, ask yourself: would I be proud of shipping this to my parents or partner? If I’m already pre-apologizing for it, it’s probably slop and should be refined.

2. The best builders own the last mile directly with customers.

Eric Carlson is one of the best 10x engineers I saw at Amplitude, and the multiplier has surprisingly little to do with technical ability (he’s kickass there too though). Plenty of engineers are technically competent, but few genuinely care about customer problems. The average engineer ships PRs and closes tickets, but only the best close the loop with customers on their own.

Turns out that the difference between a 1x and 10x engineer is whether they give a shit.

Eric spends an enormous amount of time with customers: he’s all up in the DMs, responding in Slack channels, meeting them in-person. When an issue comes up, he does things that don’t scale to unblock them. When he ships a fix, he circles back to every customer who flagged that issue until the value is actually realized. Then he spreads what he’s learned across the team, and parlays what he’s built for one customer into platform features for the rest. One customer’s pain becomes everyone’s capability. He’s a full contact operator, immersing himself in customer shoes, prototyping solutions, closing the loop, teaching the team, then scaling the platform.

We saw the same pattern when Amplitude spent time with the OG Statsig team. Their engineers led customer calls, resolved issues in Slack, made tutorial videos, and just solved customer issues proactively because shipping fixes took less time than holding meetings to get alignment. Every engineer had a “do things that don’t scale” instinct pointed at driving customer outcomes. It was the first thing we noticed about their culture, and it showed in the product.

The people who immersed themselves in customer problems - tried the weird workflow, asked one more question, stayed until it was actually solved — ran circles around equally skilled peers taking tickets, whether they were engineers, PMs, designers, or sellers. 1x engineers declare victory when something is “shipped.” 10x engineers are locked in until the solution drives change.

TL;DR: A fix isn’t done when the PR merges. It’s done when the customer who reported it says their problem was solved. Close the loop with every customer you built the feature for. And when you find someone who embeds with customers unprompted and gets shit done, promote them: that’s your 10x operator.

3. “What’s your drunkest idea that’ll help us 10x?”

Starting at Amplitude, I noticed a quiet malaise: smart teams going through the motions on backlogs they had low conviction in. It wasn’t a talent problem or an ambition problem. Something else was suppressing them.

I constantly poked teammates about what they were building and they gave reasonable answers: something achievable this quarter, staffed by their existing team, requested by a vocal enterprise customer, safe to say in front of their manager. It rarely felt like the idea they had the most conviction in. It was their best guess at what was defensible.

So we started asking each other a “joke” question over beers:

What’s your drunkest idea that you actuuuually think will get Amplitude to a $10B valuation?

Many answers were kooky, but some were fantastic: “We should build our own agent!” “We should fine-tune our own models!” “Our office faces the convention center… why don’t we put signage across our windows?” “We could orchestrate coding agents using our product context!” “We couuuld enable highly personalized ads!?” “We should go all in on engineers and bring in observability!”

The same people going through the motions during the day would light up with ideas they had real conviction in. The ambition was never missing. It was just waiting for an “unserious” question to shake people out of only voicing reasonable, incremental ideas.

A surprisingly large part of my job became asking that question in every corner of the org and giving people cover to chase the swings they already believed in. All I did was ask. Ampliteers did the building, and their joke ideas kept turning into real launches. “Why don’t we have an agent watch our session replays?” became exactly that—plus a second agent that evaluates and tunes the first. “What if our users don’t even need the Amplitude UI in the future?” became the MCP server. “What if we built our own end-to-end agent?” became our beloved Global Agent. “Maybe we could orchestrate coding agents using our product context” became Wave, our self-improving product agent. The kookiest ideas kept ending up in production.

The lesson isn’t that the best ideas only come from drinking beers. The majority of our drunk ideas were terrible. My takeaway is that bigger orgs tend to reward safe ideas — nobody gets dinged for proposing oft-requested projects. But your org’s most ambitious ideas are still there, trapped in your builders’ heads. All you have to do is make them safe to share, flesh out the nascent ones constructively, then take the best seriously.

TL;DR: Make taking big swings a normal part of the culture, not a hackathon week novelty. Ask the drunk question often, keep it fun, and build on people’s ideas before poking holes in them. You know it’s working when the ambitious version of an idea is the comfortable thing to say. Then pick and test the best bets.

4. You should build your own agent AND agent-native surfaces.

The internet is currently having a silly argument about agents. The indie hackers say building your own agent is “narcissistic” and you should only ship APIs, MCPs, and other tools to power the agents that live in Claude or Codex. The other camp points at companies like Cursor and Harvey training their own specialized agents and says every software company needs its own.

There is a right answer: do both. They serve completely different slices of your users and different jobs.

The case for building your own agent:

  • Most users will never configure an MCP server. Most SaaS users barely understand what an agent is, let alone how to connect one to a CLI. An agent inside the product they already use provides similar value with zero assembly required. Most software users outside of Twitter have lives outside of the AI bubble and providing a well-tuned agent in-product meets them where they are.
  • Own your product’s intelligence. You decide how your agent is constructed: what context it gets, how the harness works, which tools it uses. And because the traces are yours, you see every question, intent, success, and failure you need to improve your AI stack. Cursor/SpaceXAI have proven how critical it is to capture your own dataset and build your own models, passing performance improvements and cost reductions to their users.
  • A great agent is a new revenue stream. One of the biggest unlocks for AI winners has been riding the upside on token consumption. When your agent is good, customers will happily pay for usage that scales with the value it provides.

The case for also shipping agent-native surfaces (MCP, APIs, CLIs):

  • Meet users where the work already happens. An increasingly enormous amount of work now runs through Claude, Codex, Cursor, and Slack. Agent-native surfaces put your product inside those workflows, so users get your value without context-switching into your app, unlocking new distribution you wouldn’t get by improving your UI.
  • Agents are a new growth channel. AI-native builders evaluate products based on the quality of your headless surfaces, and agents are now picking new tools mid-task. Resend and Supabase saw growth explode because agents could sign up and start using them with no human in the loop. If your product requires a human to manually click around, you’re giving up free growth.
  • Your product compounds with the rest of the stack. Inside external AI clients, your app’s capabilities sit next to much more context now, including codebases, documents, tickets, and other sources. That proximity unlocks workflows you could never build alone, like enabling coding agents to check your analytics and issue trackers before opening up PRs autonomously.

Amplitude built both, and watching both compound for different reasons was the most interesting outcome from the last year. I underestimated how much existing users would love Global Agent, and everything we learned from it — the questions people asked, the places it failed — fed directly into better evals, tools, and overall AI performance. Meanwhile, the MCP server won over the AI-native crowd: customers we never expected became power users, bringing whatever clients and models they preferred and building automations on Amplitude data I’d never dreamt of.

5. Concentrated bets beat unlimited optionality.

For several years, Amplitude expanded the platform: session replay, experiments, guides and surveys, CDP, AI feedback, AI assistant, marketing tools, and more. The strategy worked as intended. Sales growth was steady and linear, multi-product customers became a large part of the business, and every new product gave sales another way into an account.

But I also got to see the two big costs, and they’re worth writing down for anyone running the same play.

The first is dilution of focus. Every product you launch is a years-long commitment: SDK support, permissions, docs, billing, reliability, on-call coverage, integrations, migrations, and a seller who has to explain how it fits with everything else. A small team can launch a new product line, but the whole company inherits the cost of maintaining it. Run enough of these in parallel and every team’s attention gets sliced thinner, quality gets harder to defend, and nobody gets to go deep enough on any single customer problem to solve it exceptionally well. Each product line is its own idea maze, and a builder exploring five mazes at once is unlikely to reach the end of any of them.

The second cost is subtler and, I think, bigger: it became increasingly hard to explain what Amplitude is and what the whole platform is for. When the story is “we have analytics, plus experimentation, plus replay, plus surveys, plus CDP, plus…”, each product makes sense on its own but the sum became muddled for customers deciding what to buy and for teams deciding what matters most. And because every product still orbited product analytics, a mature market, expanding breadth only added linear growth.

I think an investing analogy is useful here. Diversification protects a portfolio, but nobody ever compounded their way to greatness on hedges alone. At some point you need a concentrated bet on the future you actually believe in.

I find it genuinely encouraging that comparables in our industry are placing legible bets right now. PostHog is betting on the self-driving codebase: notice a problem, investigate it, open a PR, verify the fix worked. Optimizely bet its whole brand on AI tools for growth teams rather than staying an experimentation company. Amplitude has all the raw ingredients to enable self-improving products: behavioral data, experiments, session replays, qual feedback, and now agents. The only thing missing is tighter connection with the real source of truth: the codebase.

If I were to bet the farm, I’d bet on Amplitude becoming the infrastructure that enables self-improving products: measure everything that happens with users and digital products, surface what’s broken or missing, generate expert-level plans for how to tackle the problems, orchestrate and execute the changes using agents, verify the changes helped, then self-improve the full loop.

TL;DR: Commit to the select few futures you actually believe in, then concentrate the people and resources behind them. However, every new bet has to name its opportunity cost: what stops or shrinks to fund it, and who maintains it years from now. If adopting a strategy doesn’t cause you to stop doing anything, it’s not a strategy yet.

6. Velocity is a multiplier, not a destination.

Amplitude got dramatically faster during my year there, and it was impressive to watch. AI coding tools drove a 40% year-over-year increase in PR volume. Designers were shipping production code. Projects that used to take months took weeks. If you haven’t seen a 1,000-person engineering org adopt coding agents at scale, it’s a genuinely remarkable thing.

The catch is that speed multiplies direction. If you know what you’re building and who it’s for, faster is purely a gift. If you don’t, shipping faster just produces more output—it can’t tell you what to ship.

My honest critique, offered with love: we repeatedly misdiagnosed strategy problems as velocity problems. When growth felt slow, the instinct was to ship more, faster—more tools, more PRs, more launches—instead of asking whether we were pointed at the right things. Velocity was the comfortable diagnosis because it was measurable and fixable. The uncomfortable diagnosis was that we hadn’t chosen who we were building for, and no amount of faster engineering answers that question.

Speed at uneven quality also erodes the thing you actually need: trust. Customers don’t experience your ship rate; they experience whether the last three things you shipped worked. And coding agents have raised the bar here, not lowered it: when anyone can generate a working feature in a weekend, volume stops being impressive and craftsmanship becomes the differentiator. Linear built one of the most loved products in a crowded category almost entirely on that bar. Nobody wants to read or use slop. And if you want to become infrastructure for agents, the bar for quality shoots even higher.

TL;DR: Never let speed substitute for thoughtful strategy. Before optimizing how fast I ship, get clear on who I’m building for, whether the problem I’m solving is valuable, and the thesis I’m betting on. And when I do place a bet, hold an immense bar for quality. Moving fast at the expense of clarity and craft just means slop arrives to customers sooner.

7. Leaders can’t outsource product judgment.

I used to think “empowered teams” mostly meant executives should get out of the way. That’s true for a lot of decisions. The people building the product should talk to customers, find problems, propose ideas, and occasionally tell leadership that leadership has wandered off.

But a few questions can’t be delegated:

  • Who are we building for? (And who are we saying no to?)
  • What are we trying to be the best at?
  • Which changes in the world do we believe are real?
  • What are we willing to stop doing?

And in a market moving this fast, these questions don’t get answered once. They get re-asked constantly as models improve, competitors reposition, and customer expectations shift. That’s why the people making these calls have to be genuine experts on the space, the technology, and where both are heading. Leaders with personal understanding make sharp calls quickly. Leaders without it decide slowly — another week-long synthesis, another task force to performance manage — or decide poorly, because they’re choosing between options they can’t independently evaluate. I watched both at Amplitude: strategy debates that wandered for months, and the same debates resolving in hours once the executive team engaged with the details directly and made tradeoffs explicit.

That expertise comes from direct contact with the product and the technology. It’s why Creative Selection stuck with me: Apple’s leaders argued over real builds and how the product felt, because they’d actually touched it. It’s also why Sam Altman says Tobi Lütke stays months ahead of other CEOs — Tobi still writes software and spends his nights tinkering on frontier technology, which allows him to adjust product strategy and internal policies long before they’re consensus takes. And it’s why the best product decisions I saw at Amplitude came from leaders who tested the products themselves, tried out competitors and frontier technologies, and read failed sessions rather than just summary slides. Every time we dogfooded more, our strategy conversations got sharper immediately.

To be clear, hands-on doesn’t require micromanagement on everything. Nobody needs the CEO approving every pixel. It means staying close enough to the product and ecosystem to have conviction in whether the bets you’re placing will actually work.

TL;DR: You can delegate execution but not understanding. Stay an expert in order to make the right big calls: use your workflows, talk to customers, test competitors and comparables, and dig into the details. Ask “Should this exist?” and “Does it actually work for customers?” before rushing when it ships.

8. The paranoid see the future. Only the decisive survive it.

The big strategic shifts in the analytics market shared one strange property: none of them surprised us. Consolidation around the data warehouse… we saw it coming years ago and even shipped a warehouse-native product back in 2023. The entire industry reorganizing around AI… we saw that early too, shipping an AI assistant in 2023 and starting AI acquisitions in 2024. The radar was genuinely good. Almost every threat that mattered had been called, in writing, years ahead of time.

That taught me that seeing the future is the cheap half of the problem. You need to be BOTH paranoid enough to see the risks coming AND decisive enough to act on them forcefully. The second half is much harder — not because anyone is asleep at the wheel, but because defending what already exists is the natural physics of a successful company. Every forceful response to a threat competes with an existing roadmap and customers who are already paying. So the move that feels rational is spreading across many small, reversible bets and seeing if any of them stick. I did plenty of hedging, spreading focus too wide and operating too conservatively.

The companies that win platform shifts aren’t the ones that see them first. They’re the ones willing to reorganize around what they see coming, then execute relentlessly while it’s still contrarian to do so.

The paranoia part is a habit of questions:

  • What could make the current product irrelevant?
  • Which customer behavior is moving somewhere else?
  • What are tiny startups doing that our customers will expect from us in two years?
  • What are we dismissing mainly because believing it would be inconvenient?

Ask those regularly and you’ll see the future just fine. The harder part is acting on the answers. When the signals start emerging, be comfortable building the thing that disrupts your own product—even if it cannibalizes revenue, even if it upends your existing roadmap. That product is getting built either way. The only choice you get is whether it’s built by you or by someone else. Waiting until the threat is completely obvious just means constantly playing catch-up.

TL;DR: Continuously ask yourself “what could kill us?” Then take the answers seriously enough to reorganize and build them yourself. If a product could disrupt us, we should be the ones shipping it before anyone else does.

I’m enormously grateful for my time @ Amplitude. Amplitude gave Inari a bigger and more real place to grow than we ever could have built alone. I worked with incredible founders, engineers, designers, sellers, and customers who genuinely cared about making products better — and I got to watch a public company rebuild itself while the plane was flying.

When we started building agents, less than 1% of our weekly users touched AI. Today it’s nearly half. A shift like that only happens with people who are curious, eager to grow, and quick to learn from each other — and Ampliteers have all three in spades.

To everyone still building there: keep sharing the drunk ideas, keep challenging each other to go bigger, and don’t be strangers.

Time to go build again.