The Context Lake Is Product Management's New Core Artifact

Article 7 of 9 in the series.

Picture a Product Owner and a Developer, together in an afternoon Teams call, reviewing a story that was researched, drafted, and designed by their Refinement Agent in the morning. The item is well-written. Acceptance criteria are tight. Dependencies are flagged. It would sail through a normal refinement.

The problem is one nobody in the room can see. The item does not fit the product strategy. Not obviously wrong, just subtly wrong. A feature aimed at a segment the team deprioritized six months ago. An acceptance criterion that quietly conflicts with a compliance guardrail documented in a Slack thread nobody searched. A value assumption that was already tested, and failed, during a pilot the previous Product Owner ran.

The agent did not know any of that. It could not have. It only knows about the data it was trained on, and the additional information (context) that was provided by the team. The missing context was never captured anywhere for an agent (or a new team member for that matter) to find.

This is the quietest failure mode of AI-powered product teams, and one of the most expensive. The code is right. The refinement is clean. The Definition of Done is met. The work is disconnected from the product, because the product context never made it to the place the agent reads from.

In the first six articles of this series, I proposed a Definition of Value, argued that accountability concentrates as agents enter the team, reframed refinement as option framing, raised the Increment bar to require adoption, replaced the demo-style Sprint Review with an Evidence Review, and named the Tacit Knowledge Tax AI-powered teams pay. All six rest on an assumption I have not yet made explicit: what the team knows, the agents can use. That assumption, today, is wrong on most teams. This article is about what changes when you fix it.

This is a visionary piece, not a predictive one. I cannot tell you exactly what Product Management will look like in five years. I can share how a room full of experienced Professional Scrum Trainers thinks the center of gravity is shifting, and why the next core artifact your team needs to build is not another backlog, a roadmap, or a dashboard. The full list of contributors from the Amsterdam Face-to-Face Event sits at the foot of the article. The arguments here are mine. The thinking is ours.

The Shift Product Management Has Been Quietly Making

For thirty years, the Product Owner’s job has been described, in most teams, as curating a Product Backlog. Refine items. Order them. Decide what ships when. The Scrum Guide asked for more: maximize value, clarify Product Goals, and communicate and align people around product direction. But the daily reality of most Product Owners is to manage the backlog, attend meetings, and listen to stakeholders’ needs.

AI is reducing the importance of backlog management. Agents draft items faster than humans can read them. Prioritization heuristics can be applied at scale. Given enough (strategic) context, data, and insights, prioritization becomes a simple job. The ‘mechanical parts’ of the Product Owner role are becoming cheaper, simpler, and less dominant.

What is not becoming cheap is the upstream work. What should the team even be considering? Which customer segments matter now? What have we already tried and learned? Which research, data, and insights are and aren’t valuable for the problem we want to solve for the intended audience? What are the non-negotiable guardrails, legal, technical, brand, and ethical, that bound our decisions? Why is a feature there? Why is a feature not there? Which insights from which research inform which bets?

Make no mistake; Product Owners were already the ones accountable to clarify and communicate this context. For thirty years however, that context lived mostly in the Product Owner’s head, supplemented by a patchwork of wikis, roadmaps, and Slack threads. That was tolerable when the Product Owner was the primary audience for their own context. It is no longer tolerable when agents are reading, writing, and influencing (almost) everything the team produces.

The Context Lake

I want to propose a new name, a new artifact, and a new core responsibility for the Product Owner. We can call the artifact the Context Lake, and the responsibility Context Management.

A Context Lake is the curated, versioned, and prioritized body of product context that the Scrum Team, the Product Owner, the stakeholders, and the agents all work from. It includes the product vision and strategy. It includes the Definition of Value. It includes customer segments, personas, and the research that defined them. It includes the guardrails, legal, technical, ethical, brand. It includes the decision log: why features exist, why features do not exist, why bets were won, and why bets were lost. It includes the context of the context: which insights came from where, how recent they are, and how much weight they should carry.

It is a lake, not a warehouse, because the signal in it is not uniform; some of it is polished strategy, some of it is raw customer quotes, some of it is half-formed hypotheses, and all of it is accessible, traceable, and prioritized inside one shared space.

The Product Owner is (or becomes) accountable for the Context Lake. The Developers contribute to it. The Scrum Master protects the discipline of maintaining it. The stakeholders contribute to it and use it as a knowledge base, asking questions and proposing new ideas to it. Agents read from it and, when permitted, write drafts back into it for human review. It is not a static document, and it is not a wiki; it is a living, evolving artifact, the place the team and its agents go to know why.

From Product Wall to Context Lake

The concept of a Context Lake may sound familiar, as there are some parallels with a Data Lake. In addition, there are also some parallels to the idea of a ‘Product Wall’ or ‘(Product) Obeya’. Both are physical or digital spaces where the team posts everything that matters about the product in one visible place: the vision, the strategy, the OKRs, the roadmap, customer interviews, competitor analyses, features in flight, open problems to explore, success metrics, new ideas, connected people and teams, and the dependencies between them all. Everything relevant, on one wall, legible to anyone who walks in.

Make no mistake; Product Walls and (Product) Obeyas are excellent practices and valuable ideas. The Context Lake is not a rejection of them. It is an extension (or evolution) of them for a team that now has agents walking in alongside humans. A wall designed for people to read in a room is not automatically a wall an agent can read from an API. The Context Lake is what a Product Wall becomes when you make it legible, traceable, and queryable for every member of the team, human or not.

For senior product teams already running a Product Wall or an Obeya, the move is small(er). You already have much of the content. You need three shifts: make the content machine-readable as well as human-readable, add explicit decision logs alongside the artifacts, and mark the confidence and provenance on every claim. For teams that have not yet built a wall, the Context Lake is the modern form to build toward from day one.

What Goes In, and What Does Not

At least the following topics belong in the Context Lake. Everything else is noise, or belongs somewhere else.

Direction. Vision, strategy, OKRs, Product Goal, Definition of Value, roadmap, and the current Option Frame bets from Article 3. The why-we-exist, where-we-are-going, and what-we-are-betting-on layer.

Constraints. Guardrails, legal, regulatory, technical, brand, ethical. Connected people, teams, products, and the dependencies between them. The non-negotiables and the system-context a competent team member, human or agent, must honor without explicit escalation.

Learnings and Insights. Customer interviews, user research, research papers, competitor analyses, success metrics, decision logs (what was decided, by whom, when, on what evidence), pilot outcomes, adoption data, failed bets, and the open problems and ideas to explore next. The I-tried-this-last-quarter and we-should-investigate-this-next layer that normally dies in a Slack thread.

Everything else, task-level detail, Sprint-specific implementation notes, operational documentation, does not necessarily belong in the Context Lake. Those live in the tools they always have. The Context Lake is for the layer that is product, not project.

Decision Logging Is the Unsexy Discipline That Makes the Rest Work

One habit, above all others, keeps a Context Lake alive. Write down the why when you decide.

Not the what. Not the who. The why. Why did we kill that feature? Why did we pick this cohort for the pilot? Why did we reject the vendor? Why did we accept the higher latency in exchange for simpler deploy? A decision log, kept in whatever tool the team already uses, and fed into the Context Lake weekly, is the single highest-leverage habit the Product Owner can adopt in an AI-powered team.

The reason it matters is simple. Agents, and new humans, can reproduce your conclusions if they see your reasoning. They cannot reproduce your intuition if all they see is the outcome. A decision log is how the team’s judgment becomes portable.

Traceability and the Prioritization of Insights

Not every piece of research is equally valuable. Not every stakeholder opinion carries equal weight. Not every customer quote is equally informative. A Context Lake without traceability and prioritization is a swamp.

Traceability means every claim in the lake can be traced to its source, its date, and its confidence level. A quote from a customer interview in March is not treated as equivalent to a one-liner from a stakeholder in passing. A pilot outcome with n=50 is not treated as equivalent to a gut feeling.

Get Robbin Schuurman’s stories in your inbox
Join Medium for free to get updates from this writer.

Enter your email
Subscribe

Remember me for faster sign in

Prioritization means the team has an explicit ordering of which insights carry weight on which questions. The Product Owner curates, the team debates, the agents honor the ordering when reasoning. An insight with stale data and low confidence is used with care, not dropped, but flagged.

Where This Lives Inside Scrum

The Context Lake does not replace anything in the Scrum Guide. It extends the existing artifacts.

The Product Goal, the Sprint Goal, and the Product Backlog all become sharper when the Context Lake behind them is sharper. The Option Frame from Article 3 reads directly from the lake: the Outcome row points at the Definition of Value, the Options draw on constraints, the Bet is weighed against prior learning, the Evidence plan is informed by what the team already knows works. The Evidence Review from Article 5 feeds back into the lake: every adoption outcome, every bet that moved or did not, every stakeholder pressure-test gets written back. The lake is the persistent memory between Sprints. The Sprint is where the lake is consulted and updated.

Small Teams, Large Teams, and the Lake

The Context Lake weighs differently depending on the team. A small team of one to three people building a simple product can, sometimes, keep much of this in one shared head. The lake stays lightweight. The decision log still matters, but the surface area is small. A larger team in a complex environment, multiple products, cross-team dependencies, regulated industry, must invest in the lake proportionally. The cost of not investing compounds faster the larger and more complex the product gets.

A practical test. If a new Product Owner joining your team next Monday could not, from reading your Context Lake, explain in one meeting why the last three major product decisions were made, the lake is not yet doing its job.

What This Looks Like in Practice

Return to the SaaS onboarding team that has run through the earlier articles. In a pre-Context-Lake world, the team makes a decision in refinement to kill a proposed social-login feature. The decision is correct. Six months later, an agent drafts a Product Backlog item proposing the same feature again, because the agent has no access to the reasoning. A Developer spots it. Twenty minutes of refinement are spent rediscovering the argument.

In a Context-Lake world, the decision is logged on the day it is made. “Social login deprioritized, March 2026. Reason: pilot on a comparable SMB cohort in Q3 2025 showed no activation lift and a measurable drop in trust scores. Revisit only if the enterprise cohort signal changes.” When the agent drafts an item, it reads the lake first, flags the prior decision, and proposes a different angle. Refinement moves faster. Human judgment is not rediscovered every quarter. It is extended.

Multiply this pattern by the number of decisions a product team makes in a year. That is the value of the Context Lake.

What Product Management Becomes

Inside three to five years, I expect the defining skill of a senior Product Owner or Product Manager to shift visibly. Less time on backlog mechanics. More time on Context Lake curation. Less time optimizing refinement throughput. More time curating the evidence, constraints, and history that everything downstream reads from. Product Management becomes, to a meaningful degree, context engineering for the product.

That is a harder, more exposed, and more consequential job than the one most Product Owners are doing today. It is also the one worth doing.

Four Things You Can Do in Your Next Sprint

The Turn

For thirty years, the Product Owner’s most visible artifact has been the Product Backlog. In an AI-powered world, that is no longer the artifact that distinguishes the team. Everybody has a backlog. Agents can draft one overnight. What distinguishes the team, in five years, is going to be the quality, traceability, and living discipline of the context the team and its agents reason from.

The Context Lake is not a new tool you need to buy. It is a new artifact you need to start owning. The sooner Product Management treats it as its core craft, the sooner the team’s agents stop producing well-written outputs disconnected from the product, and start producing well-written outputs that actually move it.

Over to You

Run a thought experiment this week. If a senior agent joined your team tomorrow, and could only read what your team has already written down, how well would it reason about your product? If the answer is “not very well,” the gap is not in the agent. It is in what your team has chosen to make explicit.

The next article goes somewhere more uncomfortable. If the Context Lake is what the team and its agents read from, how do you keep the Scrum pillar of transparency alive when the data, the reasoning, and more and more of the decisions themselves start to live inside the AI? And what does that do to the five Scrum Values, when the most active member of the team is also, measurably, a biased one? See you there.

Contributors

This article was created based on the Scrum.org PST Face-to-Face Event #137 in Amsterdam. It would not have been possible without the discussions with: Dave West, Merel van de Wiel-Riedeman, Tommi Kemppi, Sjoerd Nijland, Jesse Houwing, Robbin Schuurman, Martijn Magermans, Guus Verweij, Steven Deneir, Gregor Stuhldreier, Paul Kuijten, Mehdi Hoseini, Simon Kneafsy, Vivien Colas, Jeroen de Jong, Kate Hobler, Olivier Ledru, Roderick Schoon, Stephan Vlieland, Tiffanie Newton, and Karel Smutný. The arguments here are mine. The thinking is ours.

< Read the previous article

Sources

The Scrum Guide, Schwaber and Sutherland

The Knowledge-Creating Company, Ikujiro Nonaka and Hirotaka Takeuchi

Evidence-Based Management, Scrum.org

From Velocity to “Agent Efficiency”: Evidence-Based Management for the AI Era, Scrum.org

The Definition of Value Takes Center Stage, Article 1 of this series

You Can’t Delegate Accountability to an Agent, Article 2 of this series

Refinement Is Not Solution Design, Article 3 of this series

The Sprint Review Is Broken, Article 5 of this series

The Knowledge Your Team Is Losing, Article 6 of this series

Transparency and the Biased Teammate, Article 8 of this series

Scrum Was Written for the Average Team. It Is Time to Aim Higher, Article 9 of this series