From topic to problem space — How to turn an idea into a workable project question

Why good AI projects do not begin with a solution, but with a problem space that is broad enough to understand and narrow enough to work on.

Many projects begin with a sentence that already sounds directional: "I want to build an app." "We want to use AI in the company." "I need an automated system." "I want to rebuild my portfolio." Such sentences matter because they create momentum. They are still not enough for robust project work.

An idea can contain three very different things at once: a perceived problem, a desired future state, and an already preferred solution. That mixture is risky. If the solution is fixed too early, later research easily becomes confirmation of what you already wanted to do. If the problem is framed too broadly, the project disappears into possibilities. If it is framed too narrowly, relevant alternatives are excluded before they have even been seen.

A proven methodology therefore places a distinct step before concept and project plan: an initial question is first expanded into a problem space. Only then come research, requirements, idea space, variant evaluation, architecture design, plausibility testing and, finally, the concept.

The problem space is not an academic interlude. It is where you decide which part of reality the project will actually examine.

A topic is not yet a project question

"AI in customer service" is a topic. "A local AI for customer service" is already a solution direction. "How can our support team handle recurring enquiries faster without unnecessarily sending sensitive customer data to external systems?" is a workable project question.

The difference is not length. It is structure.

A topic names a field. An idea often adds an intention. A project question describes a concrete change, a context and a need for investigation. It keeps several solutions open while being precise enough to guide information gathering.

This matters especially with AI. Language models respond very well to solution constraints. Ask for "an AI app for X" and you will quickly receive an architecture for an AI app. Ask for "an agent for Y" and you will get an agent design. That can be useful — but only after you have established whether an app or an agent is the right form in the first place.

A workable project question therefore protects against a common failure: the form of the first idea is not automatically treated as the actual problem.

The problem space is larger than the first solution

A problem space contains the conditions, tensions and open questions that may matter to the decision. It is deliberately broader than the eventual solution.

Suppose someone wants "an AI agent for social media." Premature project planning could immediately create tasks: connect platforms, build a posting schedule, create a prompt library, automate approvals. But the real problem space might look very different:

• The issue may not be lack of content, but unclear positioning.

• The issue may not be lack of automation, but unreliable quality control.

• The issue may not be lack of speed, but inconsistent sources.

• The issue may not be lack of ideas, but the absence of a workflow that turns raw material into brand-consistent posts.

• There may be legal, organisational or reputational boundaries that rule out full automation.

Only when those differences are visible does the meaningful question emerge: What exactly should improve, for whom, under which conditions, and how will we later recognise that the improvement has happened?

The problem space does not suppress creativity. It gives creativity direction.

The initial question: the first useful cut

The concept chain begins with an initial question. It does not have to be perfect. Its first job is to prevent the project from being described only as a product wish.

A good initial question contains as little solution as possible and as much observation as possible. Instead of "How do I build an AI agent for my company?", a stronger opening is: "Which recurring workflows currently consume substantial time, and which of them could be partly automated at an acceptable level of risk?"

The second version opens more meaningful paths. Perhaps an agent later turns out to be the best option. Perhaps a small automation is sufficient. Perhaps the real issue is data quality. Perhaps a process change matters more than new software.

The purpose of the initial question is not to name the right path immediately. It is to start the right investigation.

From a sentence to a problem space

An initial question becomes a problem space only when it is broken down across several perspectives. Five dimensions are especially useful.

1. People affected

Who experiences the problem in practice? Who will work with the outcome? Who has to approve it? Who suffers the consequences if the solution fails?

The person commissioning a project is not necessarily the person experiencing the problem every day. That difference often changes the requirements fundamentally.

2. Current state

What happens today, concretely? Where do delays, errors, friction, cost or uncertainty occur? Which workarounds already exist?

The current state should be describable without mentioning AI. That is a useful test. If the problem can only be explained through the desired technology, it is usually not yet framed cleanly.

3. Desired change

What should be different after the project? Faster? Cheaper? Safer? Easier to understand? More consistent? More scalable? More creative? Less dependent on individual people?

A desired change is not a solution. It describes a direction that several variants may be able to achieve.

4. Constraints

Which resources, deadlines, systems, skills, data sets, responsibilities and dependencies already exist?

Constraints are not irritating obstacles. They make the project real.

5. Boundaries

What is explicitly not part of the problem? What should not be solved in this project stage? Which decisions are deliberately postponed?

Without boundaries, a problem space easily expands into a description of the entire world. With boundaries, it becomes workable.

Good questions open and constrain at the same time

That sounds contradictory. A good project question should be open enough that the first solution is not already fixed. At the same time, it must be narrow enough that research and planning do not become arbitrary.

This requires two movements.

The first is divergence: open the topic. What other causes might explain the observed problem? Which stakeholders see it differently? Which alternatives exist? Which assumptions are hidden in the first idea?

The second is convergence: narrow the field. Which sub-question is decisive for this project? Which perspectives matter? Which conditions are non-negotiable? What will deliberately be excluded?

A problem space is strong when both movements have occurred. Opening without narrowing produces endless analysis. Narrowing without opening produces tunnel vision.

Hypotheses instead of hidden certainties

Many project ideas contain assumptions that are phrased as if they were facts.

"Our customers want a chatbot."

"Employees lose too much time on manual research."

"A local model would be cheaper."

"Automation will improve our quality."

Any of those statements may be true. Until they are tested, however, they should be treated as hypotheses.

This is an important methodological shift. A hypothesis is allowed to turn out to be wrong. A hidden certainty, by contrast, steers the entire project toward confirmation.

A small hypothesis list is therefore useful when defining the problem space:

# HYPOTHESES

H1: The observed problem occurs often enough to justify a project.
H2: The suspected cause is actually relevant.
H3: The affected people experience the problem in a similar way.
H4: A technical intervention can improve the situation.
H5: The improvement can be measured or at least evaluated in a traceable way.

This is not meant to turn project work into a scientific study. It simply exposes which statements still need checking.

Separate assumptions, knowledge and open questions

One especially effective step is to split the problem space into three columns:

We know: things already supported by observation, data or reliable sources.

We assume: things that appear plausible but have not yet been checked.

We need to find out: information missing from a later decision.

This separation prevents a long AI output from being mistaken for established knowledge. It also prepares the transition to Article 3 in this series: Deep Research is no longer used as a generic "research everything" command, but as a targeted response to specific knowledge gaps.

That creates an important sequence: the problem space defines the questions that research must answer. Research should not retroactively define which problem you wanted to have.

Focus is created by exclusions

A project becomes clearer not only through what it includes, but especially through what it deliberately leaves out.

A non-scope might say:

• no complete automation of the company;

• no migration of all legacy systems;

• no autonomous publication without approval;

• no new brand strategy;

• no custom technical development in the first prototype;

• no final vendor decision during the concept phase.

Such exclusions are not a weakness. They protect the learning value of the project.

If too many problems are solved at once, it becomes difficult later to understand why something worked or failed. A clear scope makes cause and effect easier to see.

From problem formulation to project question

At the end of this work, the problem space should be condensed into a question with five properties.

It is context-bound

It states the environment in which the change should happen.

It is solution-open

The sentence does not force you into an app, agent, model, platform or vendor.

It contains a desired change

It is clear what should improve.

It is testable

Later, you can reasonably judge whether a variant answers the question convincingly.

It is bounded

The question has a scope that can be worked on within the available project.

A practical formula is:

How can we change [observed state / problem]
for [people affected / usage context]
so that [desired effect],
under the conditions [important constraints],
without [critical non-scope / undesired effect]?

The formula is not mandatory. It is a test. If you cannot fill in the elements, the problem space is probably not clear enough yet.

Example: from "I want an AI app" to a project question

Take the starting idea:

"I want to build an AI app for my customers."

The idea already contains the solution "app," but says almost nothing about the problem.

Step 1: Observation

Customers frequently ask similar questions and wait for answers when the team is unavailable.

Step 2: People affected

Customers, the support team and, where relevant, specialist departments handling complex cases.

Step 3: Goal

Simple questions should be answered faster without reducing the quality of complex advice.

Step 4: Assumptions

We assume that a meaningful share of enquiries is repetitive and that reliable answer material can be made available.

Step 5: Boundaries

No autonomous decisions about individual contracts; no replacement of personal advice in complex cases.

Condensed project question

"How can we answer recurring customer enquiries outside direct support hours more quickly without removing complex cases or individual decisions from human advice?"

The app is now only one possible variant. That is exactly the methodological advantage.

AI can expand the problem space — but it should not own it

Generative AI is excellent at exposing blind spots. It can simulate stakeholder perspectives, generate counter-questions, suggest alternative causes or challenge a problem statement that is too narrow.

But the AI does not own the problem space. It has no direct access to the organisation, tacit experience or the consequences of a decision. Its role is therefore not to define the problem conclusively, but to help people make the problem visible.

Useful prompts include:

Which assumptions are hidden in my project idea?

What three alternative causes could explain the observed problem?

Which stakeholders would probably formulate my problem differently?

Which solution am I already assuming in my wording?

Which boundaries are missing for this question to be workable within four to eight weeks?

Which information would I need before deciding between three solution variants?

These questions use AI as a perspective engine, not as an oracle.

The problem space is a living work object

A common mistake is to write a problem definition once and never look at it again. In the concept logic used here, loops are explicitly part of the method.

Research may show that a suspected cause is unimportant. Requirements may reveal a conflict. A variant may expose that the scope is too broad. A plausibility check may change the initial question.

That does not mean the project has no direction. It means changes become explainable.

A useful problem space therefore has versions. For example:

• v0.1: first problem hypothesis;

• v0.2: after stakeholder perspectives;

• v0.3: after foundation research;

• v0.4: after requirements and non-scope;

• v1.0: stable enough for concept and variant work.

This turns "we changed our mind" into a traceable learning movement.

When is the problem space good enough?

It will never be perfect. The goal is workability.

A problem space is mature enough when you can answer the following questions:

• What are we observing, concretely?

• Who is affected?

• What should change?

• Which causes are only hypotheses?

• What do we already know?

• Which knowledge gaps matter to the decision?

• Which boundaries apply?

• What is explicitly outside the project?

• Which project question should guide the next research step?

• How would we later recognise that the question has been answered convincingly?

When these points are clear, Deep Research can begin in a targeted way. Before that, more research often just creates more material.

Clarity before depth

AI tempts us to go very deep very quickly. In minutes, we can generate long market analyses, technical architectures or project plans. But depth applied to the wrong question is not progress.

The problem space is therefore a filter for attention. It decides which questions matter and which only sound interesting.

The real productivity gain does not come from researching every imaginable perspective. It comes from a project first knowing which uncertainty it needs to reduce.

That is exactly where the next article begins: Deep Research is then no longer a button or a long report, but a chain of targeted questions, sources, intermediate results and follow-up research.

Worksheet: From a topic to a workable project question

1. Write your topic in one sentence

Do not explain a solution yet. Name only the field and the perceived need for change.

2. Write down the first solution that comes to mind

Keep it deliberately separate. It may return later, but it should not dominate the problem space.

3. Describe the current state

What happens today, concretely? Use observable situations instead of broad judgements.

4. Identify people affected and perspectives

Who experiences the problem, who decides, who uses the result and who carries risk?

5. Separate knowledge, assumptions and open questions

Create three columns. Mark assumptions that have previously been treated like facts.

6. Formulate three hypotheses

Which assumptions need to be sufficiently true for the project to remain worthwhile?

7. Set scope and non-scope

What should this project solve? What explicitly should it not solve?

8. Write two alternative project questions

Make one slightly broader and one narrower. Compare which one would produce better research and better decisions.

9. Select a working question

Use the formula if helpful:

How can we change [observed state / problem]
for [people affected / usage context]
so that [desired effect],
under the conditions [important constraints],
without [critical non-scope / undesired effect]?

10. Define the first knowledge gap

Which one question must be researched next before further planning becomes sensible?

Reflection

The solution I have been assuming too early: ___________________________________________________________

The most important assumption I need to test: _________________________________________________________

The boundary that finally makes my project workable: __________________________________________________

All materials to download — the topic overview and the worksheet: