The most expensive problem with an ambiguous AI request is not that it has too few features. It is that the team starts building before the problem and the acceptance boundary are clear. In this project, the most important first move was to withdraw an early Build decision and reduce the idea to a workflow that could be operated, fail clearly and be checked again.
This is Part 1 of the Content Workflow Platform project breakdown. It answers one question: how do you decide what is worth building? I split that decision into three layers: prove the problem, define a complete workflow and turn “usable” into an acceptance contract.
The project initially had a selected topic and a substantial set of existing documents. It looked as if the next step was simply to list features. But the documents could show that certain processes existed; they could not show that a user was actually blocked there. Choosing a direction did not prove that either the problem or the solution was valid.
I separated the three decisions:
Selected topic ≠ validated problem ≠ approved Build
When these decisions are mixed together, moving faster only adds cost to unvalidated assumptions.
Layer 1: Prove the problem without letting documents speak for the user
After restarting the project, I created an Evidence Register. It separated user-confirmed facts, document-supported material, assumptions that still needed validation and directions that the user had already corrected.
The point was not to create more paperwork. It was to stop evidence from being mixed. “The existing system has this process” describes the current state. “This may be useful later” belongs in the candidate set. Neither statement is automatically a current requirement.
Discovery made the problem more specific: sources were scattered; one source did not necessarily need every output; each output needed its own purpose and status; and the missing value was the next decision or the reason work was blocked, not another paragraph of generated text.
The product therefore moved from a vague “content tool” to a workflow that started with a source:
Source
→ Editorial Plan
→ Select the needed deliverables
→ Handle copy and assets separately
→ Human Review
→ Next action or waiting reason
That change mattered. The main design problem was no longer a Generate button. It was how data moved, how state changed and where the system had to stop for a human decision.
Layer 2: Define the MVP through one workflow that can reach the end
The project could have included source management, editorial plans, multiple outputs, assets, review, a calendar, AI, publishing and analytics. Building a little of every module would have produced a collection of plausible screens without a complete piece of work from start to finish.
I kept one path: a real source enters the system, becomes a plan and independent deliverables, receives the required asset work and reaches human review. That was the first MVP that could be accepted.
The first Lean PRD defined seven requirement groups. The number was not the point. Each group supported the same path: a Source had to persist; deliverables had to progress independently; missing assets had to be visible as a blocker; Review had to preserve revisions; and Today had to derive the next step from real state.
The first version explicitly excluded:
- public accounts and multi-user collaboration;
- social OAuth and automatic publishing;
- automatic scheduling and performance APIs;
- large media-file management; and
- dashboards that the core workflow did not yet require.
Non-goals were not an appendix. They protected the workflow from being pulled back into a feature list. Without those boundaries, every reasonable extension could expand the MVP again.
Layer 3: Turn “usable” into an acceptance contract
“Users can add a source” is not an acceptance condition. A more useful contract says that saving a source does not silently create a deliverable, that the source remains available after reload and that missing required fields produce a reason without leaving partial data behind.
“The product has review” is not enough either. Review needs to point to a specific revision. Approve, revise and hold need records. A new revision cannot erase the previous decision.
Writing the specification this way means engineering does not have to guess what “usable” means at the end. Automated tests, browser operations and UAT can all check the same conditions.
Priorities are not enough; decide when to stop
The implementation order followed risk rather than screen order: confirm domain rules and persistence first, build independent deliverables next and then connect Review, Today and recovery behavior.
The plan also defined stop conditions in advance. If Source or Plan could not survive a reload, UI expansion would stop. If media handling exceeded the metadata scope, it would be deferred rather than turning into an unplanned storage architecture.
Stop conditions turn scope control from a matter of willpower into a rule established before pressure arrives. The team does not have to renegotiate what to sacrifice, and data safety does not become the price of feature progress.
Passing Build is not the same as being ready to deliver
The project used a three-day timebox for the first core slice, but that was a project constraint, not the conclusion of the work. The remaining work included private-model integration, Job lifecycle fixes, topic-library and button corrections, UX revalidation and Windows packaging.
Build answered whether the design could be implemented. UAT and Release answered whether the user could restart the product and complete the work reliably. Mixing those questions creates the familiar gap between “the tests pass” and “the product still cannot be delivered.”
From Part 1 to Part 2: a defined workflow is still not an AI specification
These three layers answer “what should we build?” The problem has evidence, the MVP has a complete path and the PRD can be accepted. But once one step is handed to AI, new questions appear: which version of the source does the model read, what states can a Job enter, what remains after failure and when does a model result become a human-owned deliverable?
Those questions are not merely an extension of Discovery. They are product specifications for an AI system. Part 2 follows that gap through data, execution, responsibility and the boundary around the private Connector.
Before moving on, use these five questions to test whether the project is Build Ready:
- Is the problem grounded in a confirmed use case rather than a document or feature idea?
- What is the shortest end-to-end workflow?
- Which data, states and human decisions cannot be removed?
- How will each step be tested, reloaded and recovered?
- What conditions require the scope to stop expanding?
If these questions are still unclear, a longer feature list is only a more polished guess. Define what to build first; then define how AI should participate.
Next: Building an AI Content Workflow Platform, Part 2: Turning Model Integration into a System Specification