Transcript — Build Your Own Product Brain

Speaker-label warning: This transcript has no per-speaker labels. The talk is given primarily by Emma (Resonant founder/CTO), with Simon Maple introducing her at the start, and unnamed audience members asking questions in the Q&A. When quoting, prefer "Emma said..." for the main talk and "an audience member asked..." for Q&A questions. Do not invent named attributions — none of the questioners are clearly named in the transcript. Some apparent names (e.g. "Anna", "Pia") are likely transcription artifacts. The word "Resonant" is occasionally garbled (e.g. "Persons"); preserve verbatim when quoting but you may parenthetically note the likely intent.

Participants (from metadata / inference): Simon Maple (host, Tessl), Emma (Resonant). Unnamed audience members in Q&A.

---

Intro (Simon hands over)

I got me the computer. I did. I generated it. I'm gonna start the last one. I had to check because the timer has changed and it sounds very exciting. So a little bit about Emma, as I mentioned, works at Resonant and she's been the CTO at Resonant in the UK. So I'll kind of hand over to her now. Thank you very much.

What Resonant is + Emma's background

All right, so I'm going to talk today about how to build your own product brain. So Resonant for a little bit of context is a product workspace for helping people write specs, PRDs, tasks, etc. And then we ship them very fast. But what we have realized in the process of building out this product is that PMs role fundamentally needs to change and accelerate even faster than the kind of tools that we have built already accommodate. So that's what we're going to talk about today is how you can build a reinforcement learning system that learns your product instinct. So that as a product manager, you can focus on the things that really matter, which is the strategy of your company and keep up with your engineers.

So a little bit about me before founding Resonant, as our host mentioned, I was at Stripe for four years running engineering in the UK. But I have always spent a bunch of time between basically product and engineering. I started my career as a PM at Google and then I ran product engineering and design at an e-commerce company. So have really enjoyed this kind of the last six months where things have changed dramatically in terms of the expectations of both engineers and PMs and thinking about where this is all going.

"Coding is solved, PM is next"

So coding is solved sort of, kind of a little bit at least. And PM is next. And what I mean by this is we have kind of really focused on this problem of how we can accelerate code with the process of agents, but nobody has really caught up from our product management perspective. And so if you speak to a bunch of kind of CTOs and CPOs, what tends to happen is product managers then get pulled down into the day to day. Their engineers are moving so much faster as a consequence of agent coding than how this core question of like, what do you build and how do you build it tastefully has become much more key. And at the moment where most PMs are is trying to just kind of do workflows, basic workflows that help them do their day-to-day job, you know, break this PRD down into tickets. Resonant also does all of these things very well for what it's worth. But I think where we need to go is towards what software engineers have become, which is agent orchestrators. So we identify the slices of product management work that can actually be done autonomously end to end. And in order to do that, you need a system that kind of lines and understands your product. So most PMs are here. They're using ChatGPT, etc. To help them do these workflows. Then they're starting to actually orchestrate a set of skills to help them run those workflows. And then where I think we need to get to is actually having agents that have a sense of taste, coherency, but also understand their own limitations.

Why PM automation is harder than coding

Software engineering from a product perspective has also already gone through this, right? If you think about where what Cursor did, it was very much like line by line assistance when it started out. Obviously, Persons would have more than that over time. Then we went really kind of deep on Claude Code and now there's the open Claude if you're brave enough from a kind of permissions perspective to run those agents end to end. But for PMs, the actual automation process is harder, right? You have a much less consistent set of work and training data to optimize this on. So you need to automate your process of gathering information from your customers, from your Slack conversations, from your emails. You need to work out what your human agent control plane is. How are you going to ensure that you have the right checks and balances between your agents and your PM so that they can work effectively?

The four-component product brain

And that we've built a kind of product frame to help us do that. We then deployed that with a number of design partners as well. And now we're trying to backport it into Resonant over time also. But it consists of a number of kind of key features. So I'm going to run through kind of how it works and then I'll give you a bit of a demo end to end.

So the first thing is live ingestion. So anytime you have a meeting with a customer, for example, in Granola, you should automatically be able to process that information and update your product understanding. GitHub itself is a valuable source of like, where is your product today? What does it do? Things like email, for example, Linear tickets, etc. All need to be ingested automatically because if the system isn't up to date, you can't really run autonomous workflows.

Then you have your actual product frame, which needs to synthesize all of these inputs into a form that can be quickly processed by any agents that are running autonomously.

And finally, you need to configure a bunch of workflows on top of it. Maybe when a customer ticket comes in, you want to be able to go back to the customer if their ticket is unclear. Equally, maybe if it is well specced, you want to be able to ship that end to end really quickly. All of this is very much a personal taste thing that companies need to grapple with and work out how they want to express their level of autonomy over time.

But finally, the most important piece is you need some kind of human input so that the system can reinforce its learning loop and get better over time and understanding how you think about product.

Okay, I think I probably actually removed this line ingestion as the process of input. We'll see that in a second.

The four agents

This is a kind of graph of our product brain. It builds a bunch of links between the different concepts being discussed at a bunch of different levels. And then we configure workflows on top of it, which are completely customized to our kind of end to end process.

And we have a set of agents to do this. The first is an action agent. It's pretty obvious. It runs the workflows. We have an input and a brain agent whose function is to process those inputs and reorganize them. And then we also have an organizational agent. So over time your wiki gets out of date. It needs to be reorganized. Also teams reorganize themselves as well. And so you need a way to kind of organize around company organizations, teams and construct. S as well.

Demo — the GitHub repo structure

Okay, let's kick over to a demo. So I'm going to start with a GitHub repo. So this is our Resonant product brain with some anonymization on top of that because it's kind of cool that it has customer data or conversations in it at least. So you can see here we've got a bunch of different forms of inputs. And we can see if we look at Linear, for example, we've got a bunch of Linear tickets. These are all the Linear tickets that were updated since its last run. It typically runs on a daily basis.

And the structure here is pretty simple. You've got inputs, that's processed daily, you've got sources, that is the raw data. We don't keep all the raw data because sometimes it can overwhelm the agent. And then you've got wiki. Which consists of customer insights, features, product principles, which is trying to express this higher level of how do you have taste and coherency in the system and then technical context, which expresses our front end flows.

So other things we've got in vert, we've got Granola session that we ran on Friday. And then you can also add a bunch of manual information. And lastly, we've got a bunch of GitHub in here as well, which are going to get processed by our system.

Now, because this takes a little bit of time to process probably longer than I have, unfortunately. I'll show you what it did so we can see here it's gone through all of those tickets. It's updated a bunch of the different kind of feature level context files that we've got, as well as this like technical content front end features which describes all of our front end flows end to end. And you can see the final process state is moved a ton of stuff out of inputs. That's its kind of input queue and then it has done things like we moved on OAuth authentication to no longer be team scoped, but OAuth scoped. It's understood that and expressed that in a way that can then be used by the agent going forward. And we can see it's done a bunch more kind of synthesis here across our front end features, which is our UX flows.

So that's the core is this kind of brain that can take inputs over time.

Demo — Resonant the product

But now I want to show you an end-to-end demo. So in order to do this, I need to just give you a tiny bit of context on Resonant itself. Resonant is a product workspace. This is our homepage. It allows you to create PRDs, specs, tickets and then ship them to coding agents very quickly. And we have this product charter feature here, which I'm going to write a ticket for in a second.

This is what our kind of main page looks like. So you can see here I've got a PRD about a new feature we're working on and a set of tasks that I can then send to coding agents. But our main product interface for agents and humans is actually Slack. So we try to avoid anybody having to go into these systems and that's very direct to the task that they're trying to accomplish.

Demo — two Linear tickets, two outcomes

So what I'm going to do here is I'm just going to kick off a new ticket. Let's imagine this was reported by the customer. And I'm just going to select my ticket context. So product charter confusion is the kind of feedback. And it says here, can everybody read that? Actually, it's a bit fuzzy. I've got. Much better. I'll try and explain it anyway. So it says users are confused about the product charter feature shown on the home page. They don't understand what it is and have no way to get to see it or understand it better. So I'm just going to submit this as our first ticket and the system will then operate on top of that.

Now I'm going to create a second Linear ticket here. And this one instead is going to be a bit more complicated. So the idea here is that people want to be able to estimate the size of the task before the agent actually gets started. And there's a description here of basically what that means. The process of story pointing essentially is a kind of common feature request that we've had within a Resonant. I'm just going to make sure this is labeled and kick this off.

So these tickets on the surface, they're both kind of feature requests. But what the agent should do if it understands my product brain correctly is different actions as a consequence.

And so what we can see over here in the Resonant chat. So I cheated a little bit on this first one just because I need something to show you on the kind of code of task six and a little bit of time is Resonant has pained me here with a question about the product charter confusion on the start page. So because it's understood a whole bunch of context here about our product and exactly how it works, it's made a recommendation and it thinks that this is well specified enough that it can actually go all the way through to implementation. So you can see it's presented me with two options. The first is ship a quick fix here and the second is fold it into the onboarding work that Rob is working on more generally. And it's asking me what do I want to do about that?

Right. So I responded here and I said, yeah, let's implement the narrow fix that you suggested. And then it has come back to me here and said that it's posted its recommendation on those comments. So let's click in here and have a look at that. And we can see here that it's got the recommendation to pursue the fix. Well documented, but it's actually created the task in Resonant and sent it to a coding agent. So it's really gone all the way through that, but made sure that it has solicited my opinion on how to do the kind of coherency and strategy within our product before going back. So we have a look at this. We can see here that we've got this product charter chip task and a PR associated with it. And that that has completed the work end to end. So obviously here you would then want an engineer to check it before it's submitted. But it's really trying to do a full autonomous PM workflow there.

Now the other thing that it can do is when it sees that there is a ticket, it will actually ping me with a different recommendation about this kind of second ticket that we were just looking at. So you can see here for the task complexity estimator, what it's done instead, if we have a look at its reply, is it has not recommended that this goes straight to agent coding. What it has recommended instead is that we write a PRD for this. And I've given him a bit of guidance here. So I said, yeah, let's do that. Here's what it said. Strategically it's a strong yes. But it also overlaps with some other work that we are doing and it wants to write a short PRD up before proceeding. And I've said you should do that. But the important thing to understand here is that when we talk about task complexity and story pointing, that is extremely individual per customer. And so you need a way to tackle that as a fundamental part of the work. So then it's again kind of gone through the same process here post visits recommendation and we can take a look at that.

Okay. So there's a PRD. And if we take a look at what it's done here, we can see why should we pursue. It reduces the ambiguity. A bunch of things that explains how it relates to our strategic work. Explains a bunch of kind of related work. And then also starts to try and understand this kind of piece of complexity understanding work that I had asked it to. So that's really kind of how a product brain can then really superpower a set of workflows.

Closing — feedback loop + GitHub backing

Now also what should of course happen is it should feed that work finally back to the product brain itself. So hopefully if we refresh here, we can see this product charter confusion work has populated an input session. That then the next time product brain will reindex that and it will improve the way it thinks about product work going forward. So you get a full cycle experience.

All right, so you can build this yourself. We critically use a GitHub repo to back this system because it means your engineers can also provide it with their own forms of input as well as the kind of inputs that we've shown today. Working with a bunch of companies as well to think about how to do this for different size of orcs. I think if folks are familiar with open Claude, open Claude has a lot of the same concepts. But actually configuring how you think about privacy, the different MCP connectors that you want, how you want to organize for teams, etc. And then how you want to tweak that over time is the expertise that we have built up with a number of our design partners.

All right. If you want to talk about this, this is a QR code. I respond to every email. We've also got a booth here that we can chat at. But yeah, we'd love to take any questions that you've got. I think I managed to actually go ahead of time. So can we get a mic? There's a couple of questions down the front here. Got one over here and then one over here.

Q&A — privacy / data / LLMs

Oh, thank you for your presentation. Talking about privacy, one thing that maybe is not managing a representation. What about when a client asks you where my data is going whenever you share with LLMs like a probate or ChatGPT, any models that you have behind. It?

Yeah, so the product brain repo that we have lists very much in customer's domain. It's not our repo. I mean, this is our repo, right? Because it's our company. But for the design partners we've got that lives in their repo. So from a privacy perspective, all the fundamental data there is stored there. In terms of like actually sending that conversation to LLMs for indexing, yes, you would have to reveal that as part of your kind of like third party processing. Agreement or do an anonymization system. So like if you look at our product frame, for example, that I've got here Normally going to show you all of our like customer data except that like it goes through an anonymization process before it gets here. Right. So if you've got that plus the mapping that only in your team can see then none of that system is actually sending data to Anthropic that they don't do. It.

Q&A — developer interaction with the repo

Okay, thanks for the presentation and demo. I'm Pia myself. You mentioned briefly that you use GitHub as a base so you can actually connect with the developers nicely. Could you elaborate on the ways how developers then use the outputs for the Git repo? Yes, how it's like from the lifecycle perspective how meshes the responsibilities between PM and delivery.

Yeah, so there's a couple of ways that developers can interact with this. The first is our inputs have a manual folder. Doesn't have anything in it right now because we have a process sensing manually. But if a developer wants to put something in manually, they can do so. But they can also just treat this like a normal GitHub repo, right? So they can pull it down from their GitHub org and then interact it using whatever coding agent of their choice to then ensure that they can move faster from recruiting perspective.

So I mean like you think of the Linear issue and it references the PRD documents within that culture look like from the developer standpoint.

Yeah, so it really depends on there is no kind of one size fits all with building the kind of system that allows flexibility for different workflows and different kind of ways of engaging with it. And so what we do with design partners is really trying to understand that what are the initial workflows that would add a ton of value but also getting towards this like spectrum of autonomy. And so the question kind of depends a bit on like how are they working? What are their core artifacts? And that kind of thing? So it's difficult to answer. Kind of in the abstract but hopefully that can see a bit of it. Yeah.

A good follow-up. Does it mean that ultimately you match product managers to put their documents into the GitHub instead of like Google Docs. So developers can actually access and like ground their agents to what they're building for.

Yes, yeah, that's that's kind of a core concept of Resonant is that there's a lot of context that's useful for coding agents that is currently kept in things like Google Docs which now are senua feel very backwards. But you know you could in theory, I don't think people have an MCP connector that's super easy to use. But yeah, you could ingest via MCP as well if you wanted. Thank you.

Q&A — refactoring inputs as understanding evolves

All the time like the input you're from your abuser story takes probably built on each other relate and so on. So which actually would require that you have to refector inputs like the current state of it. User stories with any ideas on how organ. Isms.

Yeah, so it does do that automatically. So everything that's in the wiki for example is very specific in terms of the underlying tickets that it referenced. Let me just see if I can find one here. So you can see here there's a bunch of like Linear references and as it goes through it will see it will basically do it the same way as you do a diff of the GitHub. You do a diff of the Linear to understand how stuff has progressed and then feed that into the wiki as a project.

Q&A — abstracting PM tools away

Hi Anna, can I start? I think every product manager has a love hate relationship with product management tools and have done for the best however many years. Do you see a world with Resonant where you're abstracting the need for them to interact with one of those tools? So it's largely through an agent or do you still see a UI interface of all them in terms of how they do their job.

Yeah. I think that for tooling that you will need going forward is more about like maintaining your strategy, maintaining your kind of product principles than necessarily like managing a lot of the tickets. And I think the transition that a lot of AI native teams have gone through already is that a ticket is basically a full feature now rather than something which is like broken out into your front end or your back end and that kind of thing. But yeah, I don't know. We'll see how far people push out.

Q&A — compliance and human ownership

Thank you for the overview. From the stuff that we work on, a lot of it is compliance related and regulatory and therefore we have to be very specific with what we do. How do you manage ownership of the DIDs or the workers performed by the agents and which ensuring that it is checked by a person so that you can later on say okay this has been checked by a person we made mistake versus the agent just came up with. It?

Yeah. I mean, I think that's why the workflows have to be vigorable and also why we think this like agent human interface is very important so that if you're running in a more regulatory domain, you can say like it's never the case for example that an agent can write the code without some kind of a documentation first for example and that you can also build an approval flows and that kind of thing which are actually documented. I mean in some ways it is an approval flow when there is a PRD forward to the next layer but obviously as to whether or not people have like really read the PRD. I mean. It depends really on the underlying company and how. Good people are at meeting their compliance. Goals. I guess.

Q&A — PM/engineering role blur

You presented this sort of evolution of the PM role and even though you had the agent automatically creating code off the back of it. So it seems like the line between PM and engineering blurring now and so when you sort of see that going actually.

Yeah I mean I think there's two directions that this seems to be heading one is that you end up with this kind of product builder role which is PMs moving down and then you are also ending up with PMs moving up which is then move into a much more of a focused kind of GM and strategy role. I don't think that necessarily companies will there'll be one winner. In the short term. I think from like a strike perspective and a Google perspective for example they've always run more as PM being GM type roles anyway and this will only kind of accentuate that. And so if I had a prediction it's probably more that way and you'll see engineers moving more into kind of the product builder type type roles. But I think a lot of experimentation is also happening. Right now.

Q&A — rollout at scale / existing companies

I can see how this be a great tool for the green field. Project. To be more. Company. But. How would an existing company. With millions of lines of code. Or. Have documents or something like that? How do you ingest that inclusion at scale? Wouldn't that be hugely pursuing?

Yeah so in terms of kind of the typical rollout so a company typically starts with like a team kind of seeing what this looks like. And one of the most important things about kind of I think deploying discipline product brain infrastructure into a company is understanding like okay how are their teams actually laid out and how are you going to ingest data over time in a way that kind of scales with the rate of change and really every product brain needs to look a little bit different for the company for the rate of change of data and then it needs to be managed to their cost parameters. So what we are aiming to do through the kind of design partnerships we've got is understand how much consistency there is so that you can actually have a system that helps to initialize a product brain without us having to spend a lot of time consulting on it essentially because there's a lot of different ways that companies are structured and that kind of thing. So yeah I think it's for us it's an art right now that we want to turn into a science well codified science.

Q&A — workflow output (where code goes)

Unit. Are there any further questions? Oh. In terms of the workflow does Resonant send this straight into the ATM just type coding or it goes straight to equal store human basically for co-inventional skills.

So the way that our product brain works is it uses the Resonant API to actually create those coding agent jobs and then that creates PRs on top of main which are then reviewed by a few. So that's how. That's how ours work.

Emma, thank you ever so much for contacting. Held over here and there are social book signing from the idea. So thank you all for that.