It doesn't happen all at once. A great idea comes out of a strategy session. Someone turns it into a PowerPoint. Another person summarizes that PowerPoint with AI. By the time it reaches the team building it, the sharp edges are gone and nobody quite remembers what made the idea worth pursuing in the first place.
Peter and Dave dig into a problem that's older than AI but getting harder to ignore. How does intent get lost as it travels through layers of people, tools, and artifacts? What does a shared context document do that a business case can't? And what can the architectural world teach the product world about keeping the thread from unraveling?
Key takeaways:
- Moving artifacts backwards and forwards through an organization strips out nuance at every step. A single central context document is a more honest way to carry intent from strategy to delivery.
- AI is being actively encouraged in most organizations right now, and in using it, teams may be quietly eroding the ideas behind what they're building without realizing it.
- If your outcomes don't match your original intent, the handoff chain is usually where things went wrong. That's worth looking at before blaming the team.
Try this: Trace one idea from your last strategy session all the way to what actually got built. See if you can find where it changed. Then come tell us what you found at feedback@definitelymaybeagile.com.
New episodes released every Thursday to challenge your thinking and inspire action.
Listen and subscribe:
Welcome And Why This Matters
Peter 0:05 Welcome to Definitely Maybe Agile, the podcast where Peter Maddison and Dave Sharrock discuss the complexities of adopting new ways of working at scale.
Dave 0:13 Peter, great to catch up with you. We're following on from a conversation we started a few weeks ago, sparked by something we found online.
The Broken Telephone Of Ideas
Peter 0:22 Yeah, there was an article that came through my LinkedIn feed and it caught my attention because of a conversation we'd had on the podcast about context engineering and how roles are shifting. This article was more about where some of the fundamental problems are with the system as it stands today. AI plays a part in that, but honestly, the underlying issue is older than AI. How do we articulate and capture ideas, and then hand them off to the person who's going to build them? That question applies to AI too.
Dave 1:04 And this touches on something we've seen play out in a lot of our work. The business has ideas, or whoever is close to the customer has ideas. There's a communication pathway, whether that's specs, BRDs, user stories, jobs to be done, or just working directly with a team. You start with an idea, figure out what you want to do with it, and get it to the people who build it. We've gone from tightly defined specs to much more fluid approaches, and we've had plenty of conversations about what works there. But as you accelerate ideas through that chain, you start hitting edge cases and real messiness. The article we're talking about describes a scenario where an idea gets generated, someone uses AI to turn it into a PowerPoint, that PowerPoint gets fed into another AI engine, it gets summarized again, and somewhere along the way you lose the essence of what you were originally trying to do.
Peter 2:28 Right, because AI naturally pulls things toward a common denominator. We've all seen enough examples of it. You end up with a boilerplate version of the thing, and whatever was special about the original intent gets diluted through the funnel. This is happening right at the point where you're trying to define something, before you've even written a proper spec. If the specification is being built from an intent that's passed through a chain of AI-generated summaries, you can end up with a classic broken telephone situation by the time it reaches the builder.
Dave 3:29 The best strategy sessions I've been part of have people in the room who have a very clear idea of where they're trying to get. They defend it, argue for it, make a case for it. And they constantly pull the conversation back from that tendency toward the diluted, normalized version of an idea. They hold the thread. That's the best case, not the typical case. But when someone really understands what they're trying to achieve and can articulate it well, you get something stronger out of the whole process. If you rely on AI to do that work instead, you might never narrow down to the sharp, specific intent that can actually get delivered. Would that be fair?
Peter 4:36 I think it depends on how AI is being used in that context. Always does, yes. But if it's being used to summarize and standardize, the nuance gets lost. You have a great strategy session, everyone's aligned, you've got a genuinely good idea, and then it goes into a PowerPoint, gets sent to someone, and they run it through AI to summarize it. Whatever made the idea interesting often doesn't survive that. And this isn't a new problem. This is basically how organizations have always operated.
Dave 5:28 It's how we end up with bland strategic vision statements that don't mean anything to anybody. The connection to the original intent just quietly disappears.
Peter 5:48 Or you tried to keep everyone happy in the room, and as a consequence, you ended up with nothing at all.
Dave 5:55 There are plenty of ways to arrive at that. And getting back to the article, the argument is essentially this: stop moving artifacts backwards and forwards. Don't pass PowerPoints and business cases through layers of people and tools. Capture the intent as a single, stable thing, and edit that. Not the PowerPoint. Not the business case. The context.
A Structured Model For Shared Context
Peter 6:39 Exactly. I have a good technical example of this, if you'll bear with me. There's a project within Finos, which is a financial open source organization. One of their open source initiatives is called CALM, the Common Architecture Language Model. What CALM gives you is a standardized language for defining a system and how its components and interfaces relate to each other. It's great material for an LLM, but more interestingly, it lets you define actors, interfaces, and flows in a single model. From that model, you can generate all the different views that different stakeholders need, without changing the underlying context. You can see how that connects to what we're talking about here.
Dave 7:51 Yeah.
Peter 7:52 So you use that language to come to a shared agreement about the shape of the thing you're trying to build. That's in the architectural space, but the principle holds more broadly.
Dave 8:05 It actually helps clarify something we were circling around before we started recording. In our last conversation, we talked about context engineering and the idea of capturing context in markdown files, things like where the business is trying to go, what they're trying to achieve, that kind of thing. These context documents become a stable foundation under which products get built. They're version-controlled and they don't change dramatically as the work progresses. And the article is making essentially the same argument. Don't create a PowerPoint. Don't write a business case. Create a single context that moves between the people contributing to it. Edit the context, not the artifacts you've generated from it. The challenge I keep coming back to is that in an architectural space, you have CALM giving you structure. I'm not sure we have an equivalent in the business context. Something well-formed enough that the next person who picks it up interprets it the same way you did.
Why Even Simple Stories Diverge
Peter 9:26 And that's actually what the article was pointing at. We have this kind of structured context in other domains, but not really in the product space. There's no shared taxonomy for intent. No way to have one source of truth that different people can look at from different angles without losing something. I find it interesting. There are various approaches, but the gap is real. And yes, I'm still trying to convince you that context engineering is a thing, so I'm hoping this is nudging you in that direction.
Dave 10:18 I think we're starting to agree that capturing and sharing context as a stable, underlying artifact is genuinely valuable. What it reminds me of is all those times we've written user stories, agreed we understood them, handed them off, and still come out the other end with two different interpretations of a simple feature. Not a complex strategic challenge. Just one feature that does X. Even then, people can read the same thing differently. So I'm not sure how you build the structure you're describing in CALM for a business context, in a way that is actually stable across multiple interpretations.
Peter 11:23 It's a real challenge. Maybe there are lessons to take from CALM. Maybe we should go away and try to build something that starts from that thinking. What are the attributes of language that actually describe intent? And can we use those deliberately?
Dave 11:40 If you think about something like banking or e-commerce, you could probably put together a pretty useful context structure fairly quickly. There would be edge cases it doesn't cover, but you could get something meaningful. That could be a good experiment.
Peter 12:06 Yeah. And I think there's something valuable in here for our listeners around how you create the context that drives the systems you're building, and how you manage the transfer of that context without it getting diluted along the way. The idea itself becomes something everyone contributes to, rather than a series of separate views that get generated for different audiences and slowly drift apart.
Dave 12:59 I really like the idea of a single artifact, a context document that holds the essential things. And you can absolutely use it to generate a PowerPoint for a particular audience when you need one. But the PowerPoint is a view, not the source. One thing you and I have talked about before is how quickly you shift from making a PowerPoint that communicates what you're trying to do, to making a PowerPoint that meets the expectations of the audience receiving it. Those are two different things. A single central artifact keeps you honest. You could argue this is what the project charter was supposed to be in traditional project management. And if you keep it current, it becomes the raw material for everything else. That consistency is actually quite powerful.
Three Takeaways And How To Reach Us
Peter 14:26 With that in mind, we should wrap up and go build it.
So what are the three takeaways from this conversation?
Dave 14:38 The first is recognizing that passing artifacts backwards and forwards, PowerPoints, business cases, summaries for different audiences, adds noise and loses information at every step. And seeing a single context document as the alternative is a meaningful shift. The second is watching closely how ideas actually move through your organization. People are busy, AI is being actively encouraged, and in using it, they may be quietly diluting the intent behind what they're building. That matters, because you might not end up with the outcomes you were aiming for.
Peter 15:24 Which leads to the third, which we don't quite have time for today: validation. Did I actually get the outcome I was expecting from the intent I started with? If your intent is being eroded through multiple summaries and handoffs, that might explain why the output doesn't match what you had in mind. That's a whole other conversation.
Dave 16:27 I think we've got three things there.
Peter 16:29 I think so. To all our listeners, don't forget to subscribe. And if you'd like to come on the show or just want to chat about any of this, reach out at feedback@definitelymaybeagile.com. Until next time.
Dave Until next time.
Peter You've been listening to Definitely Maybe Agile, the podcast where your hosts Peter Maddison and David Sharrock focus on the art and science of digital, agile, and DevOps at scale.