Today, we're talking with Drew Dillon, CEO & Co-founder of Brief

Brief is a product Navigator for AI-native teams. It's automated product judgment and tightly-packaged context that gives the coding agents already in your stack, Cursor, Claude Code, Codex, the strategic direction they otherwise lack. Drew's own framing for the problem is the infinite monkeys version of development: shipping has gotten trivially easy, shipping the right thing is harder than ever. Give an agent an open-ended prompt and it will confidently build, just not always toward where your company is actually trying to go.

Brief fixes that by handing every agent the same institutional memory a great product leader carries in their head, packaged tightly enough to cost only a few percent of an agent's context window. Drew has been building products for fifteen years, starting as Yammer's sixtieth employee through its $1.2 billion acquisition by Microsoft, chief product officer at two more companies, then six years consulting for early-stage startups. Brief is the productized version of that consulting work, built around an insight Drew arrived at while vibe coding again last year for the first time in a decade.

Backed by a16z Speedrun, Brief sits on top of the tools teams already use, GitHub, Notion, Linear, Granola, and forms them into a living product graph that its roughly sixteen specialized agents reason over autonomously. It lives in Slack as a kind of coworker and plugs directly into Claude Code, Cursor, and Codex as an MCP or CLI. The open beta launched a few weeks ago, and they just went live on  Product Hunt today. 

In this conversation, Drew takes us through the path from advisor to founder, the pivot that became Brief, the dark factory experiment that took a coding agent's success rate from 46% to 95%, and where he thinks the role of the product builder is heading.

Let’s dive in ⚡️

Read time: 10 mins

Drew, welcome to Cerebral Valley! Give us a bit of background on yourself and the path that led you to found Brief.

I'm one of those people who's done every job. I started as a graphic designer, became an engineer, then a sales engineer carrying a bag alongside a sales team, and eventually moved into product, because if you average all of those things together you end up with a product manager. I was employee number sixty at Yammer, working directly for David Sacks, and stayed through the $1.2 billion acquisition by Microsoft about two years later, by which point we were 450 people. I never just led product teams though, it was always product, engineering, design, data, business development, support, everything. I did that as chief product officer at two more companies, then about six years ago I started working for myself, consulting for early-stage startups.

That consulting work is really where I formed the hypothesis behind Brief. Companies build things very differently, even from one project to the next, but the actual why behind their decisions is remarkably consistent. The companies that don't follow that end up firefighting constantly or chasing revenue and getting outmaneuvered. About a year ago I started hardcore vibe coding for the first time, having not really written code in anger in fifteen years, and I found I was bizarrely good at it. The reason was that I was walking the coding agent through my product thought process.

You've spent years as a product leader and advisor before this. When did you realize there was a company here, not just a better way to advise teams?

It goes back to that fractional chief product officer work. I always came into companies at one very specific moment, right around Series A, though it's happening earlier now with acceleration. The secret to navigating it is that it comes from who you are, not what you do. What's our culture? Who are our competitors? Why do customers like us? That becomes the grounding context for every future product decision, and with that framing you can correctly prioritize the strategic work against the hair-on-fire work.

Now extrapolate that to an agent making a thousand decisions a day. It needs the same grounding, because AI has its own preferences and will throw in random enterprise features that have nothing to do with your actual customers. When I started vibe coding, I found myself explaining all of this over and over, first copying it out of a Notion page, then keeping markdown files in the repo that were blowing out my context window. Eventually I put those files in their own repo and spun up two agents to talk to each other, a chief product officer agent and a CTO agent. Around then I got into a16z Speedrun. When I went interviewing the other companies, they kept stopping me to ask what I was doing. "Can I just purchase that? Is that a thing you can sell?" That was the lightbulb moment.

You pivoted into Brief. What were you building before, and what did you learn from it?

Before Brief, we were building Mocksi, AI-powered sales demos. The idea came from my experience as a sales engineer. Demoing complex enterprise products is hard, the data sets have to be very specific and very large, and putting one together can take weeks or months. I picked up vibe coding on Cursor to accelerate, dabbled with side projects, then applied it to the main product, and that's when I realized I was really good at this.

We had design partners giving us good signals and used them as references to get into Speedrun. We went and talked to sixty CROs, and the best response we got was, "this is really cool, come back next quarter." That's when it hit me: we don't have it. For a six-figure deal you need to be in the top three concerns of a C-level buyer, and while I could mumble my way toward how we related to a CRO's priorities, it wasn't clear enough. They'd say, "we'll just throw more sales engineers at it." So we decided to pivot about two weeks before the program started. The Speedrun partners' advice was to come anyway, work with the companies building the future, and figure out what they need.

For a founder or engineer hearing about Brief for the first time, how would you describe it in a sentence or two?

We call it a product Navigator. To put it more simply, it's me as an agent. It helps you figure out where to take the product. AI can generate an enormous amount of stuff, but that doesn't mean you're moving toward the goal you're trying to hit in the next three to six months. Another way to say it: Brief is almost like Claude Code for product management. It takes anyone and makes them a better product manager, and it takes an already-great product person and makes them ten times better, able to operate across the whole of product strategy at the same velocity as their coding agents.

You said Brief lets product people operate at the same velocity as their coding agents. How does it actually create that accelerated velocity?

Part of it is integration. We connect to your business systems, GitHub, Notion, Granola, Linear, and form them into the artifacts I would have built as a chief product officer. More importantly, we do it autonomously. Brief forms its own hypotheses about what you're trying to do and wraps them in tools so our agents can call them directly to advise you on what to build next. Then it connects wherever you work, most often Slack, where we treat it like a coworker. "Hey Brief, we're having a product discussion, what do you think?"

The last piece is connecting Brief as an MCP or CLI inside Claude Code, Cursor, Codex, and the rest. Your coding agent gets its own product agent through real agent-to-agent communication. If it has a question, it can ask Brief, and Brief gives it a grounded product-oriented response, the same way I would have.

So Brief isn't a coding agent and isn't a project management tool. Where does it sit, and what's the job it's doing that nothing else does?

We had a hypothesis back in October that the roles of engineer, product manager, and designer are blurring to the point where they stop being real definitions. You'll still see specialization around scale, databases, growth, specific things like mobile design, but most of the work is going to be done by generalists who sit across the entire stack.

Brief is built for that eventuality. Our bet is that the tools of product management are still valuable, but they need to be orchestrated by a single person running a coding agent, a product agent, and a design agent together. With all three working in concert, one individual can produce products at the velocity of a much larger team.

Walk us through the product graph. What's being captured, and why is a graph more useful than the documentation a team already has?

It comes down to a few things. AI loves tools, it's very good at calling them and it wants to call them. So you have two options. We hear this one a lot: "I hooked up my Notion MCP to my Claude Code." Sure, but every new session the agent has to rediscover all that context, crawling through the MCPs and chewing up tokens. Extrapolate that across five agents over a couple of hours and you're burning enormous effort just having your agents relearn how to use Notion and find your strategy documents. We call those dumb tokens, wasted effort that was completely unnecessary.

Brief takes that same data, calls it once, forms it into shapes, and wraps those shapes in tools. There's a user persona tool, so when an agent asks which personas we serve, here's the list. There's a storage decisions tool, same idea. Brief hands the agent a little book report that uses far fewer tokens and far more effectively, driving toward the choices our team has actually made.

Let's talk about what you're launching. What's live today, and what should our readers go try?

We launched our open beta a few weeks ago, and today, we're launching on Product Hunt with three months free for anyone who signs up through the page. Under the hood, Brief is that data shaping, formed by about sixteen agents so far, a user research agent, data analyst, scrum master, and more, with a chief product officer agent sitting across all of them. On top of that sits the Slack integration and the integrations into all the different coding agents.

A lot of our audience is already building with Cursor, Claude Code, and Windsurf. What changes for them once they plug Brief into the stack?

We ran our own experiments, coding agents with and without Brief. We built a dark factory, essentially a fully autonomous coding environment, and ran it both ways. With Brief, the coding agent arrived at the correct solution about 95% of the time. Without it, it got there roughly 46% of the time without continued back-and-forth prompting. So it's faster agents, lower token costs, better direction, and faster delivery of the right solution, rather than shipping a pile of stuff that has nothing to do with what your customers actually need.

That 46% to 95% jump is a striking number. How did you measure it, and what does the dark factory process look like in practice?

We gave it open-ended prompts, change this to that, build this new capability, shift the whole app to dark mode, and watched two parallel agents work, one with access to Brief and one without. Without Brief the agent weighted its prior understanding over what the user was asking for. You've probably seen this: AI loves Vercel, so it always steers you toward Next.js, Vercel, Supabase. Product strategy has the exact same problem. If you don't give it a bounding box, here's what we're building and why, it drifts toward that generic default.

This matters more as orchestrators become the fastest-emerging category. Openclaw and Hermes are generic open-ended ones, and coding-specific orchestrators are emerging that generate and execute large projects from very little input. I think Linear is moving in that direction. They can accomplish what they know technically, but not why we're doing it. As any former product manager knows, the spec is never perfect, and once engineering starts the questions keep coming. There has to be an ongoing conversation about what we're building and why. That's where we're positioning Brief: the product management suite of agents inside these dark factories and orchestrators.

Agents are taking over more of the building, so the bottleneck shifts from velocity to direction. How does Brief make sure teams ship faster and in the right direction?

That's exactly the infinite monkeys version of development. Yes, you can ship tons of stuff, but is it actually moving the needle? Each of Brief's agents has a different job. The user research agent turns your call notes and competitor activity into research signals. It's also looking at your product metrics through PostHog, Mixpanel, Amplitude, to understand what users are actually doing. All of this happens ambiently. You could hook up your own tooling and build automations every week, but Brief hands you that context in tight packages your AI can engage with immediately.

From there, you can ask Brief to write a PRD or generate your Linear tickets, then use a skill in Claude Code to connect everything to the ticket. My process for spinning up a new Claude Code instance is just "/onboard" plus a ticket number. Brief dumps out a little book report: the relevant decisions, features, personas, who requested it, who's paying and how much. By the time the coding agent starts, it has all of that in its head, taking up maybe 4% of the total context window per session.

With agents writing most of the code, and now accelerating product management too, where does human judgment actually live, and which roles survive?

I think the product builder role will exist, and then it'll bifurcate and split again into specializations. The unified role makes sense to start, but the taste and judgment required to build developer tools are very different from what's required to build consumer apps. You'll find more engineering-oriented product people, more product-oriented engineering people, more everything-oriented design people, each bringing their own perspective and needing different things from the agents that support them. I think we come back around to a specialized product builder for a specific type of product, but those lines will be emergent over the next few years.

Where is Brief headed over the next twelve months, and if I'm a founder getting excited about this, how do I get started today?

Over the next few months, we're cracking open all of those agents. You'll be able to customize nearly everything and start defining your own processes, say you want release notes delivered every Friday, or you want to graph a specific user chart and pin it somewhere in Brief for your team to share. We're also hitting the app stores and marketplaces for all these coding and agent platforms in the next couple of weeks, so you'll be able to use Brief headlessly from within your existing agent infrastructure. That should land in June.

Users can get started right away. It's free, with a model that's a mix of per-seat plus credits, and if you come in through the Product Hunt link you'll get three months on the pro or business plan. We recommend integrating as much as possible, but really, focus on getting it into your workflow in your coding environment and in Slack. That's where it clicks.

Stay up to date on the latest with Brief, follow them here.

Read our past few Deep Dives below:

If you would like us to ‘Deep Dive’ a founder, team or product launch, please reply to this email ([email protected]) or DM us on Twitter or LinkedIn.