Context is the Product

You come back from a week away and everything is where you left it. The board is tidy, the tickets have acceptance criteria, the specs are linked, the roadmap view is current. On paper, nothing was lost while you were gone. And yet the first hour back is spent asking people what actually happened. Why did that story get dropped? What did the customer call change? Who decided to split the release, and what were they weighing when they did? The information is all there. The thing you actually needed was not.

That gap is the quiet failure this post is about. Teams pour enormous effort into producing artefacts, the tickets and specs and decks, and treat the surrounding context as overhead, something you catch up on in the hallway or infer from a Slack scroll. This quarter I am writing about seeing practice, and context neglect is one of the hardest problems to see, because the artefacts look complete right up until someone has to make a decision with them.

The mistake: the artefacts are the product

Ask most teams what they produce and they will point at the visible output. Features shipped. Tickets closed. A spec written, a roadmap maintained, a design handed over. Those things are real and they matter. But treating them as the product hides where the value actually lives.

Here is the distinction worth saying out loud. A ticket, a spec, an export, a roadmap slide: these carry information. Information is transferable. You can copy it, paste it, attach it, hand it to a stranger, and it says the same thing to everyone. That is exactly why it survives your week away untouched.

The reason you are building the thing, who it is for, what you already ruled out and why, what the last customer conversation quietly changed, what "good" would look like when it ships: that is not information. It is the shared understanding the team has been building and updating the whole time. It lives in people and in the conversations between them, and it does not export cleanly. When someone leaves, or a new engineer joins, or you take a week off, the information stays intact and the understanding is what goes missing. That is context neglect. The team optimised for the part that copies and neglected the part that decides.

Context is what makes the work make sense

Give a capable engineer a perfectly written ticket with no context and you get a feature-complete answer to a question nobody was asking. The acceptance criteria pass. The demo runs. And it misses the point, because the point was never in the ticket. The point was in everything around it that never got written down or shared.

This is why "we shipped it" and "it worked" are different sentences. A feature only becomes a product when it lands in a real situation, in the customer's actual moment, alongside whatever else they are trying to get done. Users never experience your feature list. They experience their own context, and your work is only valuable to the degree it fits into it. Plenty of well-built features quietly fail this test. They were shipped, they were correct, and they were never adopted, because the team understood the feature far better than the context it had to survive in.

So context is the product twice over. Inside the team, the real thing you produce is a shared, current understanding of the work, and the artefacts are the residue of that. Outside the team, value only appears when what you built meets the context it was built for. Neglect it in either direction and you get motion without meaning: busy teams, tidy boards, features that land with a thud.

Where context leaks

Context neglect rarely looks like neglect. It looks like efficiency. A few places it usually hides:

• The handoff that is "all in the ticket". The work moves from discovery to delivery, or from one person to another, and the transfer is a link. The what travels. The why, the trade-offs already considered, the things deliberately left out, stay behind in the head of whoever did the shaping.
• Discovery skipped for speed. The team knows what to build because someone senior said so, but nobody carries the reasoning. When reality pushes back mid-build, there is no shared understanding to reason from, so the team either freezes or guesses.
• Decisions made in the direct messages. A real call gets made in a two-person thread and never reaches the people who now have to act on it. The decision exists. The context that would let others use it does not.
• Context that lives in one person. One team member holds the whole picture in their head and everyone routes questions through them. It feels productive. It is a single point of failure wearing a cape, and it collapses the moment that person is on leave or moves on.

None of these show up as a missing artefact. The ticket is written, the decision was made, the expert is excellent. What is missing is the shared understanding around them, and shared understanding is the part no dashboard measures.

Building context on purpose

The fix is not more documentation. A wiki with four hundred pages can hold less usable context than one honest conversation, because volume is not the same as shared understanding. The fix is to treat context as a thing you deliberately build and hand over, not a by-product you hope accumulates.

A few habits that help:

Hand over the why, not just the what. When you pass work along, whether that is a shaped piece for a team to pick up or a decision for someone else to act on, write the short version of the reasoning: the problem, roughly how much this is worth, what you already ruled out, and where the known traps are. This is what a good pitch does. It carries bounded context a team can decide inside, rather than a spec that pre-answers questions the team should be closest to. It is also why some teams have moved from writing tickets to writing a page or two of narrative before a piece of work starts. The narrative carries context; a ticket carries a task.

Prefer holding context to storing it. Storing context is writing it down so it exists somewhere. Holding context is keeping a live, shared understanding current across the people who need it. Both matter, but if you only store, you end up with an accurate archive nobody reasons from. A ten-minute conversation that updates four people's mental model often does more than a flawless document that updates none.

Make the out-of-scope explicit. The most valuable context is usually what you decided not to do and why. It is also the first thing that gets lost, because "we considered X and ruled it out" almost never makes it into the ticket. Write it down once and it stops the team relitigating the same dead end three weeks later.

Onboard people into context, not just access. Giving a new person the logins and the doc links transfers information. Sitting with them and walking through why the product is shaped the way it is transfers understanding. The second one is slower and it is the one that actually sticks.

What to watch for

The first trap is mistaking documentation for context. Producing more artefacts can feel like closing the gap while the shared understanding stays exactly as thin as before. Ask not "is it written down" but "could someone act well on this without asking me".

The second is treating context as a one-time transfer. Understanding decays. What everyone agreed on a month ago has quietly drifted as the work and the customer changed. Context has to be kept current, not delivered once and filed.

And the last, the one worth naming plainly: the team member who holds all the context and never shares it can look like your most valuable person, right up until the day they are unavailable and the whole team stalls. Rewarding that, in the moment or in a performance review, teaches everyone to hoard context rather than spread it. The most useful people are the ones who make the context they hold usable by others.

Seeing practice through context

I keep coming back, this quarter, to the idea that product work goes wrong before the artefacts look wrong. This is the sharpest version of that. Your board can be immaculate, every ticket well formed, every spec current, while the understanding that would make any of it a good decision has quietly failed to travel.

The reframe to carry into the next planning meeting is simple. When the room reaches for another document to fix a problem, ask what the product actually is here: the artefact, or the shared understanding it is supposed to carry. Then build the understanding on purpose, and let the artefacts be the residue.

Your team's real deliverable is not the tickets it closes. It is whether the next person can pick up the work and know what it is for.