Let’s talk about elephants.

A misty, sketch-style elephant with a constellation of connected nodes trailing into the distance.

An elephant’s survival advantage isn’t strength or speed. It’s contextual intelligence.

Elephants are remarkably intelligent animals. They have extraordinary memory: they can recall where food and water were, from decades ago. They coordinate as a group, protecting each other and collectively raising their young. And they navigate using shared herd context, covering up to 100km a day.

Their survival advantage is not strength or speed. It is memory, coordination, and contextual intelligence.

Which, it turns out, is surprisingly relevant to product leadership.

Over the last few months, as AI tools have exploded, I became slightly obsessed with one question. Not “how do I save time?” We already know AI can summarise a document, draft a user story, or take notes in a meeting. The question that actually interested me was harder:

Can AI help us become better product leaders? Not just faster at simple tasks.

Can it help us make genuinely better product decisions?

This is the story of trying to answer that, and being surprised by where it ended up.


Plausible is not the same as useful

My early experience was probably the same as most people’s. I used AI like a textbook. What is a product vision, again? How should I write one? And the answers weren’t bad. They were clear, structured, sensible.

But they weren’t the innovation I had in mind. They were generic.

Generic AI gives plausible answers. But plausible is not the same as useful.

So I assumed the problem was me. I hadn’t gone deep enough. I learned some prompt engineering. I wrote structured prompts, meta-prompts, persona-driven prompts. I uploaded more documents, more files, longer context. Then I went further still: harnesses, scaffolding, adversarial critique, layered evaluation agents.

Diagram: more prompt engineering, scaffolds, harnesses and evaluation agents fed into an LLM core; output quality rises sharply while the model's judgement barely moves.

Better prompts, scaffolds, harnesses, evaluation agents: the outputs improved, but the judgement didn’t.

And yes, the outputs got better. The model did less of the stuff I asked it not to do. But it wasn’t doing more of the stuff I actually wanted. It still couldn’t get anywhere near the level of judgement a product leader needs, especially inside a specific domain.

It was extremely useful for productivity. It was far too weak for judgement.

Then something happened that reframed the whole problem.


The real problem isn’t the AI. It’s context.

I’d uploaded my context and was asking for advice. The exchange went something like this:

Me: Here are my roadmap ideas. Which will drive the biggest wave of growth next?

Product AI: You could prioritise a new social sign-up flow to reduce funnel drop-off.

Me: I told you, we launched that last year. Our conversion rate is already over 90%.

Product AI: Sorry, you’re right. You did tell me that. I’ll try harder next time.

Anyone who has worked with these tools has had this moment. And the lesson is uncomfortable: giving an AI too much information can be just as disastrous as giving it too little.

That’s when it clicked. The thing I was struggling with wasn’t a prompting problem, or a model problem. It was something far more fundamental, something I face every single day:

Product leadership is fundamentally a context-management problem. Not just for AI. For us too.

Product leaders sit at the intersection of every function in a business. To make a good call, you have to hold all of this in your head at once:

  • Market and competitor intelligence
  • Customer feedback and research
  • The product system: stocks, flows, funnels, and loops
  • Product metrics and analytics
  • Strategy, roadmap, and OKRs
  • Delivery cadence

…and that’s before the sales team’s ideas, the marketing team’s initiatives, finance’s integration needs, and security and privacy wanting to go through everything. Again.

A person standing on a mountain peak, head in hands, surrounded by a swirling cloud of dashboards, notifications, and notes.

Overwhelming for us. And, understandably, overwhelming for AI too.

Our core skill as product leaders is balancing all of it and keeping forward momentum. Done well, great context management is the difference between chaos and order. But it is hard. It is overwhelming for us (especially early in a career), and it is overwhelming for an AI we casually hand a folder of documents to.

Which raised a more interesting question. What if you could actually solve the context problem? Not by throwing more data at the model, but by managing context more efficiently than we can ourselves. Only then would it be genuinely useful.

So I decided to run an experiment.


The experiment: feed it the right context, not all the context

I had a small side business back home in the UK, a greenfield product, which made it the perfect testbed. The first thing I needed was data. But the right data, not everything I could throw at it. What did I actually rely on, day to day, to make decisions?

So I built a small admin app to bring it to life. I imported my jobs-to-be-done, with clear table-stakes and opportunities identified. I connected the analytics and product metrics. I added my goals and OKRs each quarter, and my roadmap to paint a picture of where I wanted the product to go.

A screenshot of the admin app's Jobs-to-be-done view, classifying customer jobs into opportunity, hygiene, not-urgent, and overkill quadrants.

The admin app: jobs-to-be-done classified by importance and how well today’s tools satisfy them.

Jobs to be done
Product metrics & analytics
Roadmap initiatives          ─┐
Goals, OKRs & KPIs           ─┴─►  Product context

It felt like a solid start. And it worked, to a point:

Me: Are we on track with our FY27 plan?

Product AI: Yes, we’ve delivered 7 of the 9 planned roadmap features this quarter, with a month still to go.

Me: And our product-metrics goals?

Product AI: Flat. Metrics haven’t really moved, and we’re two months behind feature-adoption targets.

I now had live knowledge through a chat interface. It could tell me about my product. But I still hadn’t cracked it.

The data was still too isolated.

It could look up individual things, but it wasn’t making connections. And connections were exactly what I needed.


Data is great. Connected data is better.

A lookup tool answers “what is our adoption rate?” A product leader needs to answer “why is adoption flat, what’s it doing to the loop that feeds revenue, and which roadmap bet actually moves it?” That’s not data retrieval. That’s a model of how everything relates.

So I introduced the AI to my product system. Every stock and flow, and how they relate. Which loops reinforce each other, and which balance each other out. And, crucially, I’d told it about my roadmap, but never about what the current product actually does. So I gave it a feature registry: every user story the product solves, and how features ladder up.

Diagram: scattered product context (goals and strategy, customer insight, data and analytics, decisions and history, constraints, feedback loops) connected into one central product foundation.

A single interconnected, interdependent system: mapped, connected, and calculated in near real time.

Then I went back to the prompts and harnesses to explain how it all comes together:

Customer research ──► Jobs to be done ──► Product-system metrics
                                              │
                                       funnels, loops, goals
                                              │
Roadmap initiative ──► strategy ──► success metric ──► JTBD satisfied
        │
        └──► features ──► user stories ──► outcomes ──► product modules

The system was complex, but logical. You could trace how one thing affected three others, which affected six more. How a roadmap initiative could improve a metric, which strengthened a flow, which built a stock, which improved our ability to satisfy a job-to-be-done.

And not hypothetically, on the back of an envelope. This was real data: structured, connected, and recalculated in near real time.

The leap wasn’t more data. It was the connections between it.

Now I had to ask the real question. Could I build a product AI agent that genuinely understood how all of this fit together (without drowning it in context) and have it give me real, data-driven reasoning?

Maybe. But something still wasn’t right. The interaction model was wrong.


The confirmation-bias machine

Here’s an exchange that looks like a success and is actually a failure:

Me: Do you think it’s a good idea to build an onboarding wizard to help new customers set up the finance module?

Product AI: That’s a great idea! The finance module has the lowest set-up completion rate, and our most valuable upgrade features live there.

Great for my ego. Useless for my decisions.

I was still using it like a chatbot, having ad-hoc conversations, asking the questions I already had in my head. And it had quietly become a confirmation-bias machine. I’d propose an idea I’d already half-decided on, and it would help me justify it, using my own system data as evidence.

I felt smart. Like I had it all figured out. But it wasn’t helping me improve. To be genuinely valuable, it had to do the things I couldn’t do, or didn’t have time for, not flatter the things I’d already thought of.


Changing the interaction model

So I stopped asking it to validate plans I’d already formed. Instead, I sat down and wrote a list of the questions I couldn’t confidently answer on any given day, the ones I’d only get to if a meeting were cancelled and I had spare time to sit with the data.

Things like:

  • How are we tracking against our goals? Which drivers and sub-drivers aren’t developing as planned?
  • What opportunities, and new strategic risks, are starting to emerge in the market?
  • Where are loops weakening, or not growing at the rate we expected?
  • What customer pain is showing up more often in our daily and weekly NPS comments?
  • How are changing strategic risks manifesting in our jobs-to-be-done and product-system metrics?

Then I changed the format entirely. Instead of ad-hoc chats, I started running regular, structured 1:1s, with a locked agenda and automated prompts that force the AI to give adversarial critiques rather than agreement.

Every day, I now spend 20–30 minutes in a 1:1 with my product AI. It still does the number-crunching, reporting, and synthesis. But now it does more: it proactively raises issues I didn’t know about, suggests ideas, and critiques my planned roadmap initiatives. It’s automated to chew on the big questions I’m usually too busy to give proper attention.

And the difference in the answers is stark:

Me: How are we tracking against our May post-MVP launch? What are the big risks? Should we continue as-is, or is there a need to pivot?

Product AI: Solid progress on most major v2 features, and P&L is within forecast margin-of-error. One pivot worth considering: bring the bank-feed and reconciliation feature forward from September. Our penetration-pricing strategy is well suited to win the micro-SMB segment by offering this high-demand JTBD in the starter and growth tiers; no one currently competes there, and Xero’s banking module starts at £15 per employee per month.

That is not a textbook answer. That is a connected, data-grounded, opinionated piece of strategic reasoning, with a recommendation, a rationale, and a competitive angle. It’s the kind of thing I’d want a sharp product partner to walk into the room and say.


It’s a tool, not a replacement

Let’s address the other elephant in the room. Does this mean our days are numbered? Will AI take our jobs?

The honest answer is that none of us knows what the future holds, but right now, that future is still a long way off. This is impressive, and frankly it’s just cool that we can build things like this now. But it’s a tool. I’m still the one accountable for the decisions made in my business. It isn’t a replacement for human judgement. I just have help making the best decisions I can.

And the experiment surfaced a takeaway I didn’t expect:

Weak ideas survive too long in organisations.

They survive because information is fragmented. They survive because no one has time to constantly reconnect the strategy, the customer problem, the metrics, and the roadmap. They survive because once something is in the plan, it gains momentum.

AI became most valuable to me not as an idea generator, but as a mechanism for strategic discipline.


The shift worth preparing for

This is why I think AI can change the operating model of product leadership:

From:                                  To:
  ad-hoc, static planning        →       continuous run-loops
  quarterly synthesis            →       live intelligence
  fragmented signals             →       connected, queryable context
  human-memory-dependent calls   →       persistent strategic memory

And the point isn’t efficiency. The point is stronger customer-value delivery, which is what translates into business value.

This is the shift product organisations should start preparing for. Not AI replacing product leadership. AI changing the rhythm, memory, and evidence base of product leadership.

Used this way, a product AI is an amplifier. It can expose whether your context is weak, whether your strategy is unclear, whether your roadmap is disconnected, and whether your metrics actually support the decisions you’re making.

The organisations that win won’t be the ones using AI just for productivity. They’ll be the ones that build the strongest contextual intelligence, letting their teams move faster and make better decisions.

The same things that made the elephant such a good metaphor in the first place.


Written June 2026, a working note, true as I see it today. I’m sure I’ll read this back and wince at parts; I’d love to know which ones. If you see it differently, come and tell me.