Business Problem Statement to Future State: Documenting an AI POC End-to-End
What the full documentation chain actually looks like when you build it yourself, in order, for an AI feature
When I started documenting the AI-automated job posting POC, I kept looking for a reference — some example of what the full chain of BA artifacts should look like for an AI project specifically. Not a template with blank fields to fill in, but something that showed the thinking between one document and the next.
I never found one that fit. So I built the chain myself, one document at a time, and figured out the connective tissue as I went.
Here’s what that chain actually looked like, and what I’d tell someone doing this for the first time.
Start with the business problem statement — and resist the urge to make it sound impressive
It’s tempting to write a business problem statement that reads like a pitch. Mine went through a few drafts before I stripped it down to something plain: what’s broken, who feels it, what it costs us to leave it broken.
In our case, the problem wasn’t “we lack AI capability.” It was much more specific — the manual effort and turnaround time involved in getting job postings live, and where that effort was concentrated. AI was a possible answer, not the problem itself. Keeping that distinction clear in the statement mattered more than I expected, because it kept every document downstream honest about what we were actually solving for.
The stakeholder register is where you find out who actually has a stake
I wrote my stakeholder register almost right after the problem statement, and it was more useful than I gave it credit for going in.
Get SOUNDARYA SAINATHAN’s stories in your inbox
Join Medium for free to get updates from this writer.
It’s easy to treat this as a formality — list the names, list the roles, move on. What actually helped was going one layer deeper: what does each stakeholder need from this specific POC, not from the eventual full product. Someone might care deeply about final output quality and not at all about the technical mechanism. Someone else might care only about timeline. Writing that distinction down early saved me from assuming everyone wanted the same thing out of updates.
Mapping the as-is flow taught me more about the problem than the problem statement did
I expected the as-is flow to be a formality too — document what currently happens, check the box, move on. Instead it was where I found the actual friction points that the business problem statement had only gestured at.
Walking through the current manual process step by step surfaced things nobody had mentioned out loud: where handoffs happened, where delays crept in, which steps existed because of habit rather than necessity. Some of what looked like “the AI’s job to fix” in the original problem framing turned out to be process issues that had nothing to do with AI at all. That distinction matters a lot when you’re proposing an AI solution. Not everything slow is an AI problem. Some of it is just an unexamined process.
Future state documentation is where you have to commit to specifics
This is the document where vague language stops working. It’s one thing to say “AI will automate job posting.” It’s another to specify what the AI does versus what a human still reviews, what the handoff between them looks like, and where the process could still fail even with automation in place.
I found it useful to write the future state flow side by side with the as-is flow — same steps, same structure, so it was obvious exactly where the process changed and where it didn’t. That side-by-side made it much easier for stakeholders to see the actual delta, instead of reacting to “AI-powered” as a vague upgrade.
What connects all four documents
Looking back at the chain — problem statement, stakeholder register, as-is flow, future state — the thing that held it together wasn’t a template. It was going back to the problem statement every time I started the next document, to check that what I was writing still answered the original question.
It’s easy for documentation to drift. The future state doc starts describing an ideal system instead of a solution to the specific problem you defined three documents ago. Rereading the problem statement before starting each new artifact kept that drift in check.
If you’re building this chain for an AI project of your own, my honest advice: don’t skip the as-is flow because it feels like the least interesting document. It’s usually where you find out what you’re actually solving. Still working through scope and exit criteria for this one — more on how the full POC plays out once we’re further along.
