CtrlK
BlogDocsLog inGet started
Tessl Logo

ainativedev/latest-aidevcon-speakers-london-2026

AI Native DevCon 2026 London — all conference sessions as interactive skills

66

Quality

82%

Does it follow best practices?

Impact

No eval scenarios have been run

SecuritybySnyk

Risky

Do not use without reviewing

Overview
Quality
Evals
Security
Files

quotes.mdtalk-stoneham-product-brain/

Notable verbatim quotes

Note: All quotes are from Emma unless flagged otherwise.

On the thesis

  • [Coding-is-solved framing] "So coding is solved sort of, kind of a little bit at least. And PM is next." (Section: "Coding is solved, PM is next")

  • [PMs pulled down] "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..." (Section: "Coding is solved, PM is next")

  • [Goal of the product brain] "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." (Section: "What Resonant is + Emma's background")

  • [PM as agent orchestrator] "Where we need to go is towards what software engineers have become, which is agent orchestrators." (Section: "Coding is solved, PM is next")

On the autonomy ladder

  • [Three rungs] "Most PMs are here. They're using ChatGPT, etc. ... Then they're starting to actually orchestrate a set of skills... 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." (Section: "Coding is solved, PM is next")

  • [Cursor → Claude Code → open Claude analogy] "What Cursor did, it was very much like line by line assistance when it started out... 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." (Section: "Why PM automation is harder than coding")

On the four components

  • [Live ingestion] "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. ... if the system isn't up to date, you can't really run autonomous workflows." (Section: "The four-component product brain")

  • [Product frame definition] "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." (Section: "The four-component product brain")

  • [Workflows are taste] "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." (Section: "The four-component product brain")

  • [Human input is the most important] "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." (Section: "The four-component product brain")

  • [Human agent control plane] "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?" (Section: "Why PM automation is harder than coding")

On the agents

  • [Four agents] "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." (Section: "The four agents")

On the repo structure

  • [Inputs / sources / wiki] "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 ... and then technical context, which expresses our front end flows." (Section: "Demo — the GitHub repo structure")

  • [Product principles = taste] "Product principles, which is trying to express this higher level of how do you have taste and coherency in the system." (Section: "Demo — the GitHub repo structure")

On the demo outcome

  • [Two tickets, two outcomes] "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." (Section: "Demo — two Linear tickets, two outcomes")

  • [Story pointing is per-customer] "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." (Section: "Demo — two Linear tickets, two outcomes")

On adoption and the future

  • [Tickets become features] "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." (Section: "Q&A — abstracting PM tools away")

  • [PM role two directions] "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." (Section: "Q&A — PM/engineering role blur")

  • [An art, not yet a science] "It's for us it's an art right now that we want to turn into a science well codified science." (Section: "Q&A — rollout at scale / existing companies")

  • [Compliance via approval flows] "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." (Section: "Q&A — compliance and human ownership")

talk-stoneham-product-brain

README.md

tile.json