Six months after a discovery phase ends, somebody poses a question in a meeting, asking why a particular pain point made it onto a persona document. But nobody in the room can answer. The discovery team who built those artefacts have moved on, and with them, the conversations and research that produced the document have been forgotten.
For a long time, this was the nature of deliverables. You diverged in research, then you converged and produced an artefact or document - and you hoped it made sense once you’d left the project. No document could ever capture everything you’d learned, which often lead to the same work being done all over again a year later by a new team.
But tacit knowledge doesn’t have to walk out the door when a project finishes. Instead, insights should continue to grow, without becoming compressed.
The compression problem
Discovery has always been a compression exercise. You spend weeks gathering material from interviews, workshops, desk research, prior work, and stakeholder feedback. The volume builds and builds until it’s almost overwhelming. Towards the end of the phase, you have to compress all of it into a handful of artefacts, like a persona document, a journey map, an architecture diagram, or a roadmap.
Compression has always made sense. If you have an hour to socialise weeks of work to a wider audience in a simple to understand way, a single readable artefact is the best way to land it.
I speak from experience, having produced plenty of these artefacts myself. I have stood next to experience maps on walls and watched senior people nod at them. They were the right tool in the moment.
But the problem came afterwards. The compression was permanent, so all of the source material - the interviews, the throwaway comments that opened up new lines of enquiry, the three-hour workshops and hundreds of sticky-notes - was all effectively gone. What remained was the artefact itself, stripped of the reasoning that produced it.
Almost instantly, the document started to drift and lose relevance. Priorities would change and technology limitations surface, but the artefact stayed the same and the project kept moving without it.
The Spine
Any artefact or deliverable produced, used to be seen as something that should hold all the knowledge - and be simple to understand at-a-glance. But this belief needs to evolve so that instead, the artefact is seen simply as a moment-in-time view, communicating an aspect of the research - one that can be repeated as needed.
The knowledge should live elsewhere. Everything the project generates - from transcripts and interview notes, to records of decisions made and artefacts produced - should live in one place. This is what we call The Spine, and the deliverables you produce are drawn from it.
The Spine is a principle, not a tool. The tool used to build The Spine can be Notion, SharePoint, Confluence, or whatever your team already uses. What matters is that everything from the project goes into The Spine (transcripts, notes, desk-research, architecture diagrams…), and that an LLM can read it, write to it, and reason across it.
With the Spine in place, deliverables can be generated on demand. Claude can produce a persona document from the Spine, or a journey map, or a backlog, or a single slide for an exec audience, depending on what someone needs and how much time they have to look at it.
That changes the shape of the project and our relationship to project deliverables. They become fluid, customised, and live. If you have set deliverables in your statement-of-work these can start to grow from day one. You can set up empty templates at the start of the engagement for every deliverable you've agreed to produce. As the Spine fills, the templates fill alongside it. You can use your LLM connection to help you populate the deliverables, too; to interrogate what needs doing, what’s missing, what additional questions should be asked. You can even quickly create a dashboard to monitor the progress or ‘health’ of these deliverables to help the project teams keep track of the work.
If you haven’t agreed set deliverables but are more outcome-based or value-realisation measured, then this approach frees you up to create whatever artefacts or maps help you to communicate an idea or facilitate a conversation. You are not beholden to an industry best practice template but can instead create custom assets perfectly tailored for your audience’s needs.
Certain deliverables can also become important Spine context. An agreed North Star statement, for instance, can be drawn from the research, but can then be added to the Spine to inform ongoing work, creating a feedback loop of input to output to input and so on.
The loop in practice
Feedback loops are essential to ensuring the Spine and deliverables remain relevant.
This is where transcripts become your secret weapon. Record every meeting and point your LLM to each new transcript, asking “what needs to be updated?”. The LLM walks through the deliverables and flags what's changed - a pain point that should be added to a persona, for example, or a story that needs refining on the backlog. A person on the team approves or rejects each change, keeping the human in charge of every edit to the source.
The first time you describe this loop it sounds laborious. In practice it disappears into the rhythm of the project. You finish a session, point Claude at the recording, talk through the suggested updates, and move on.
There is a second use of the Spine that matters more than just updates. Claude can look across the whole Spine and tell you what is missing - the questions that need to be answered and interviews that should be scheduled - because it doesn’t forget the way a human would. This is critical for any project lead.
When you do need a line in the sand at the end of a phase, you take a snapshot. A locked persona document at the end of discovery, dated and circulated, gives you an auditable reference point, but the Spine carries on growing afterwards. In six or twelve months' time, when somebody walks in and asks why a particular pain point is on the persona, the answer is in the Spine, and you can render it.
Earlier this year, on a project for Newcastle University, we ran a version of this end to end. The team produced a full technical backlog in roughly a day. Comparable work months before by the same team had taken about ten working days. By the end of the first week, the team was confident the backlog was complete, accurate, and every loose end was either resolved or logged for follow-up. Claude wrote and refined the backlog, but the team made every decision about what stayed in, what came out, and what each line really meant.
What changes for the project lead
The Spine only works if it’s fed and maintained. That means transcripts go in after every session, decisions get logged as they happen, and templates fill out as the evidence arrives. The habit takes a few weeks to feel natural and might seem challenging to get used to at first, but without establishing this new routine, the Spine will only be half-populated and will produce unreliable views.
The bigger change is for whoever runs the project. You stop being the person who curates the final document and start being the person who keeps the Spine clean. Once the Spine is in good shape, the deliverables render themselves, and your attention moves upstream of the artefact.
Six months after the next project ends, somebody is going to ask in a meeting why a decision was made. The team will have moved on and the artefact on the wall will look the same as it did the day it was hung, but this time the Spine will still be there. Open it up, ask the question, and you have an answer.
The deliverable is a moment-in-time view - but the Spine is the whole project.
