The concept of a Product Brain is so seductive because it solves so many of the challenges product people face. The challenges we’ve had to deal with involve finding up-to-date information about our customers, about our competitors, about changes to the market that we operate in. Sometimes when we can’t find the information, we have to spend valuable time recreating it. We don’t often know what our colleague in product has worked on, and therefore cannot call upon it to inform our work.
As Taufiq Khan (affectionately known to us as TK) put it:
“When I was doing product management, say two years ago, I would rely on my sales team for maybe quarterly things on what customers really want, what the top ten requests are from around the business. These days I’m going into the transcripts of every single customer conversation they have. I’m going into what the themes are in those transcripts, in the exact emotion they were described in. So it’s a whole different depth of data we can get now, and a different timeliness of data. It’s daily, not quarterly.”
So the Product Brain contains all of this information. We don’t have to search for it, and we don’t even have to ask for it, because it can surface new opportunities on its own. The Product Brain can even take it a step further and turn the opportunity into a product requirements document. Which is why the concept of a Product Brain is so appealing and resonated so much with the community.
In this AI era, everything is accelerating, especially delivery, and the product manager is piggy in the middle, so we now have to accelerate our work as well. Sure, we will still have to decide what to build and judge the quality of the AI output, but we now have a tool that can help us with the heavy lift.
TK described the bind we’re all in like this:
“People are shipping things faster than ever, and the team is hungry for really good, synthesized context, insights, and analytics to build the right thing. So product managers are kind of stuck between these two accelerating forces. That’s where we, at Ordermentum at least, are trying to experiment with some of these new tools that have come out.”
TK used a tool called Superpowers by Obra to build his Product Brain:
“What I like about Superpowers is that Claude doesn’t get overconfident, it doesn’t just ship the first thing you say. It puts Claude into a mode where it asks you a bunch of questions, and then you get to really specify what the direction of the product is. It then goes into a more structured, spec-driven development flow, if that makes sense.”
How to actually build one
I pushed TK for the mechanics, because it’s easy to talk about a Product Brain in the abstract and quite another thing to know what to do on a Monday morning. Here’s roughly how he described it.
Start by shipping something small yourself. TK’s first move wasn’t to build the brain; it was to get product managers building things directly with Claude. Not because PMs should be shipping to production, but because they need to feel the ergonomics of working with these tools before they can set anyone else up to use them well.
Notice what you keep repeating, and write it down. Once you’re building a few things, you’ll find yourself answering the same questions every time you open the tool up. What kind of customer is this for? How do we monetise it? Who are we competing with? Each of those repeated questions is a signal that you need a document. TK’s team ended up with a backlog file, a competitive intel file, and a customer research file, each one answering a question they were tired of answering from scratch.
Turn the documents into skills. Writing down today’s competitive landscape doesn’t help you in three months, because it will have changed. So the next layer is a set of skills that keep the documents current. TK built a competitive researcher that runs every week, scans everything their competitors and overseas equivalents have launched, and updates the intel file itself.
Wire in an alert, and let the thread become the context. TK’s team set up a weekly run every Monday morning that scans the competition and posts into a Slack channel whenever something changes. That alert sparks a discussion, and “the thing that does the competitive research actually looks at that thread and uses it as context for the next round of competitive research.” As TK put it, “Slack is basically the OS for this.”
Let the brain be a doer, not just a summariser, in the prototyping phase. Once a PM has a strong signal from a customer interview or a support theme, they can ask the brain what it would do, get several options back, and apply judgement to choose one. In the early prototyping phase at Ordermentum, the PM can then say “create a PR for this” in Slack, review it, and approve it themselves. Tools like Vercel let them send a working preview link to one customer before it ever reaches anyone else.
Expect the first build to take about a week, and every one after that four to eight hours. That first project is where you build the connectors into wherever your data actually lives: behavioural data from something like Mixpanel or Amplitude, interviews, sales calls from Gong or Grain. Once those connections exist, standing up the next brain for the next product is a much smaller lift.
Where it falls over
TK was refreshingly honest about where this doesn’t work yet, and I think the pitfalls matter as much as the promise.
It’s built for one person, not a team. TK was blunt about this: “A lot of how Claude and Codex are set up is very much for single-player mode, not multiplayer.” There’s no easy way to share everything the brain knows across a whole product team. His workaround has been to keep the documents in the code repo, or sync them through Google Drive, but it’s still a patch rather than a solution.
Every product manager builds a different brain. Because there’s no shared structure yet, whoever owns a product ends up with their own mental model baked into their documents. Picking up someone else’s product isn’t as easy as it used to be. TK’s approach for now is to let PMs build it however makes sense to them, and rely on a short handover conversation when someone moves on.
Designers and engineers are mostly still outside it. At Ordermentum, the brain is largely a PM tool today. The handover from PM to designer to engineer still happens the old way. TK sees this as a real opportunity, but it’s not solved yet.
It’s about 80% right, and the 20% matters. When someone asked whether the brain comes up with genuinely new ideas or just remixes what it’s been trained on, TK’s answer was: “I reckon it’s 80% right. But the 20% is important.” Judgement doesn’t disappear; it moves later in the process.
Tech debt doesn’t disappear; it is contained. Someone asked TK directly whether all this fast building creates a wave of technical debt. His answer: yes, there will be a lot of slop, and some of it will land in production. His way of managing it is to keep the slop contained to the prototyping phase, get real confidence from five or ten happy customers, and only then have the re-architecture conversation.
Everything you build now will be outdated in three to six months. TK said this more than once, almost as a warning. The specific documents, the specific tools, the specific structure, none of it is fixed. What he thinks will last is the underlying discipline: organising your product context deliberately, and having a repeatable way to harness it for decisions.
The cost conversation is a red herring, but the headcount conversation isn’t. TK said he’s “never been able to run up heavy token costs,” and can’t seem to spend more than “about 50 bucks a week,” even putting the brain through hackathons. The real question the room kept circling back to wasn’t the token bill; it was whether this means fewer product managers. TK didn’t pretend to have that answer, and honestly, neither do I yet.
What I’d take from this if you’re starting Monday
Don’t try to build the whole brain at once. Start by using Claude yourself on something small, notice the questions you keep re-answering, and turn those into your first documents. Expect the first one to take about a week. Expect it to feel shiny and then, in a few months, oddly outdated, and be okay with that, because the discipline and the capability underneath it are more important than perhaps the tool itself.
