Plan before prompting — Why AI projects need structure before tools
Why a strong prompt cannot replace missing project architecture — and how intention, research, requirements and concept become a robust AI project plan.

A prompt can produce an impressive answer in seconds. A project may need to remain coherent for weeks, months or years. Between the two lies a distinction that is easy to miss when working with artificial intelligence: an answer is not yet a structure, a draft is not yet a concept, and a concept is not yet a reliable plan.
Precisely because modern AI produces so quickly, it creates a new temptation. Execution begins before the team has fully understood what should actually be executed. The surface looks productive: text appears, tables fill up, features are proposed, code is written and task lists grow. Yet speed can hide a lack of orientation. Efficiently working on the wrong problem does not bring a project closer to its goal.
The central idea can therefore be stated simply: the better the planning, the better the realization. Planning does not mean fixing every detail in advance. It means transforming an abstract intention, step by step, into something realizable.
A prompt is not a project
A single prompt normally serves an immediate purpose: explain, compare, draft, summarize, research, structure or produce. A project, by contrast, has a history. It has a starting state, a target, prerequisites, dependencies, risks, decisions, intermediate results and criteria for deciding when something is good enough.
This distinction fundamentally changes how AI is used. Someone who merely prompts treats each answer as a possible new starting point. Someone who manages a project treats each answer as material inside a larger system.
At first this can sound like additional bureaucracy. In practice it is the opposite. A clear project structure prevents the same questions from being asked repeatedly, requirements from shifting unnoticed, or an AI developing a different interpretation of the goal in every new chat.
The decisive question is therefore not: "Which prompt do I need?" It is: "What state is my project in, and which decision needs to be prepared next?"
From the abstract to the realizable
Many projects do not begin with a task list. They begin with an intention. "I want to build a platform." "I want to professionalize my portfolio." "We want to use AI in the company." "I want to automate a process." These statements matter, but they are not yet plannable.
The first step is to translate the intention into a problem space. What should change because of the project? For whom? What is inadequate today? Which constraints already exist? Which parts are still unknown? What would count as a plausible outcome without prematurely fixing the solution?
The work then shifts from rapid solution production to orientation. This is exactly where AI can be especially valuable: not by deciding immediately, but by helping make the space of possible decisions visible.
A well-defined problem space prevents a common failure mode: the first attractive solution becomes confused with the actual objective. Someone who initially wants to "build an app" may discover during analysis that the real problem could be solved more effectively through a service, an automated workflow, an internal tool or even an organizational change.
Planning therefore does more than reduce implementation errors. It protects the project from committing too early to the wrong solution.
Research is not a prelude; it is part of the project architecture
In conventional workflows, research is often treated as a phase before the real work. In AI projects, that separation is too weak. The quality of the evidence base affects every later step: requirements, alternatives, risks, technical architecture, business strategy and evaluation.
Research should therefore do more than collect material. It should reduce uncertainty.
Good research does not only ask "What exists on this topic?" It asks questions such as:
• Which assumptions in my project are already supported?
• Which assumptions are only guesses?
• Which alternatives exist?
• Which real examples contradict my first idea?
• Which requirements follow from sources, practice and constraints?
• Which information is still missing before a responsible decision can be made?
Research then becomes a decision instrument.
This logic goes one step further: multiple research outputs can form a research pool, which can then be converted into a structured knowledge base. That is considerably stronger than a single deep-research report. A report is a document. A knowledge base is a working environment in which sources, claims, contradictions, examples and open questions can be reused deliberately.
Organize first, then compress
Between research and concept lies an often underestimated step: organization.
Many AI projects jump from a large collection of material directly to a proposed solution. The AI may then receive a great deal of context without knowing which distinctions actually matter. More context does not automatically create better orientation.
The methodological concept-development process therefore describes a chain:
Starting question → problem space → research → requirements → idea space → variant evaluation → architecture draft → plausibility check → concept
This chain is not linear. A plausibility check may send the team back to the architecture draft. A variant may reveal new requirements. Research may show that the problem space was framed incorrectly. That is not a failure of the plan. Those loops are the plan.
A good concept does not emerge because an AI generates as many ideas as possible. It emerges because options are generated, compared, rejected, combined and tested against requirements.
Requirements are the bridge between desire and decision
An idea describes what would be attractive. Requirements describe what must be true.
That is a major difference. Without requirements, an AI often evaluates alternatives according to what sounds interesting, modern or plausible. With requirements, alternatives can be tested against concrete conditions.
Requirements can be functional: What must the system be able to do? They can be organizational: Who must be able to work with it? They can be economic: Which costs or resources are acceptable? They can be temporal: What must be completed first? They can be qualitative: How do we recognize that an outcome is good enough? And they can express boundaries: What must explicitly not happen?
This creates a transition from creativity to decision.
At this stage, requirements should not yet be treated as immutable. They are hypotheses that may change through variant analysis and plausibility testing. But they provide a frame within which AI-generated proposals become comparable.
A concept is compressed decision preparation
The word "concept" is often used for anything between an idea and implementation. For AI projects, a more precise definition is useful.
A concept should explain:
• which problem is being addressed;
• who the outcome is for;
• which research findings are relevant;
• which requirements apply;
• which solution variants were examined;
• why one direction is preferred;
• which architecture or working method follows from it;
• which uncertainties remain open;
• which assumptions must be tested in project planning.
A concept is therefore not simply a polished text. It is compressed decision preparation.
Only after that compression has succeeded does it make sense to turn phases, tasks, resources and dependencies into a project plan. Otherwise the plan will merely describe, with great precision, how an unclear idea should be implemented.
A project plan is not a timetable
AI creates another trap here. Language models can generate extensive roadmaps, Gantt-like phases or hundreds of tasks in seconds. The result can look professional while creating false precision.
A project plan should not be judged by the number of tasks it contains. What matters is whether it makes decisions and dependencies visible.
Which work must happen before other work? Which outputs are prerequisites for the next stage? Where is human approval required? Which work can happen in parallel? Which assumption must be tested before further resources are committed? Which risks require buffers? Which elements explicitly do not belong in the current version?
A good plan therefore does not only reduce work into tasks. It reduces uncertainty into a meaningful sequence.
Agentic AI makes good planning more important
With browser-based AI, poor planning often remains visible because a person still has to trigger many individual steps. With agentic systems, the same ambiguity can scale much faster.
An agent that changes files, conducts research, distributes subtasks or executes entire chains of work needs more than a general instruction. The greater its room for action, the more important the goal definition, evidence base, boundaries, review points and acceptance criteria become.
Autonomy therefore does not replace project management. It increases the need for it.
The question is no longer only: "Can the AI perform this task?" It also becomes: "How does it know that it is working correctly, when must it stop, which decisions may it make itself, and what evidence must it provide before the next stage?"
Later articles in this series will examine agent roles, gates and human-in-the-loop design in detail. For now, one principle is enough: the more execution is automated, the more explicit the steering logic must become.
Methods outlive tools
There is another reason to work structurally: the AI market changes quickly. Interfaces, models and products come and go. If competence is tied to a particular tool, every change forces a partial restart.
Methods last longer.
Knowing how to define a problem space, assess sources, derive requirements, compare variants, limit scope, document risks and connect decisions to evidence remains useful even when the interface changes.
This attitude can be captured with a simple statement: we learn how to learn.
That is more than a teaching slogan. It is a professional strategy for a technology whose concrete tools change faster than the fundamental problems of good work.
Planning does not mean rigidity
A common misunderstanding treats planning as the opposite of agility. For AI projects, that is especially dangerous.
Good planning does not fix the future. It makes the current state of knowledge visible. It documents what we know, what we assume, what we intend to test and what we deliberately postpone.
When new evidence arrives, the plan may change. What matters is that the change is traceable.
That is what separates iteration from disorientation. In disorientation, direction changes because the next output sounds convincing. In iteration, direction changes because new evidence weakens an earlier assumption or reveals a better alternative.
Agility without structure becomes reaction. Structure without agility becomes rigidity. AI project management needs both: a stable frame and the ability to change it for a reason.
The planning chain for AI projects
For practical use, the method can be compressed into ten steps:
# AI PROJECT — PLANNING CHAIN
1. INTENTION
What should change because of this project?
2. PROBLEM SPACE
Which problem are we actually addressing — and which are we not?
3. RESEARCH
Which sources, examples and counterexamples reduce uncertainty?
4. REQUIREMENTS
What must be true for a solution to be viable?
5. VARIANTS
Which genuinely different solution paths are plausible?
6. EVALUATION
Which criteria will be used to compare those variants?
7. CONCEPT
Which direction do we choose, and why?
8. PROJECT PLAN
Which outcomes, dependencies, reviews and work packages follow?
9. AI USE PLAN
Which AI handles which tasks — with which sources, boundaries and gates?
10. ITERATION
Which new evidence would force us to change the problem space, concept or plan?This chain is deliberately independent of any specific software. It can be implemented in a chat, Obsidian, a project-management tool or an agentic development environment.
Do not answer faster; decide better
The greatest productivity gain from AI does not necessarily come from producing more output in less time. It may come from making better decisions earlier.
A poorly defined project can become larger faster with AI. A well-defined project can learn faster with AI.
That is the decisive difference.
Planning before prompting therefore does not mean working less with AI. It means using AI at the right points: first to understand, then to structure, then to compare, then to plan and only afterward to execute autonomously.
That is how a conversation becomes a project, many answers become a knowledge system, and speed becomes a controllable form of progress.
Worksheet: From idea to plannable AI project
1. Write the intention without the solution
In two sentences, state what should change. Avoid product names and specific tools.
2. Define the problem space
Write who experiences the problem, what is inadequate today and what explicitly lies outside the current project.
3. Build three research questions
One should clarify fundamentals, one should search for real examples, and one should deliberately seek counterexamples or reasons for failure.
4. Write five requirements
Include at least one functional, one qualitative, one organizational, one economic and one boundary or non-scope requirement.
5. Generate three variants
Ask the AI for three genuinely different solution paths. Prevent it from producing only variations of the first idea.
6. Define evaluation criteria
Decide how the variants will be compared before selecting one.
7. Write the concept in one page
Problem, relevant evidence, requirements, examined variants, chosen direction and open uncertainties.
8. Only now plan implementation
Create phases and work packages. Mark dependencies, review points and the first assumption that can be tested as cheaply as possible.
Reflection
The point at which I have previously started solving too early: __________________________________________
The decision I need to make explicit before the next AI execution: ______________________________________
All materials to download — the topic overview and the worksheet:
0 comments
● Loading comments…