From Idea to Working Result
The Four-Quadrant Method
Structure it. Understand it. Choose tools. Build it.
You might want to build an app, design a user interface, improve a workflow or run a scientific experiment. The method starts with the problem and the result you want. The choice of technology comes later.
The four quadrants are not a one-way checklist. The most important movement is:
Structure it <-> Understand it
You describe the problem, explore possible solutions, discover something and change your description. You repeat this until you have enough confidence to choose an approach and make the first useful version.
1. Structure it
Make the problem clear enough to explore.
Write a first description:
- Who is this for?
- What are they trying to do, and what gets in their way?
- What information, materials or resources do we have?
- What would a useful result look like?
- What would tell us that the problem is actually being solved?
Keep it short. A sketch, a few sentences or a simple process diagram can be enough.
For example, "We need an AI booking assistant" already assumes a solution. Start with the problem underneath it:
People cannot see which appointments are available. They exchange several messages before finding a time. We want them to see a suitable slot and book it.
Now you have something to investigate. An existing calendar might solve it. You might need a better interface. You might eventually need an agent. You do not have to decide yet.
Your first structure is a working draft, not a commitment.
2. Understand it
Explore the problem and the current ways of solving it.
Look at what people do today. Try relevant products. Examine working examples, documentation or research. Find out what is already possible and what has actually been shown to work.
This is your practical look at the state of the art:
- How is this problem currently solved?
- Which approaches work well, and where do they fall short?
- What can we reuse?
- Which assumptions in our own idea need checking?
- Could a simpler approach give us the result we need?
AI can help you explore, compare and ask better questions. Follow up important claims with an actual source, a working example or a small test.
Then return to Structure it. Change the question, narrow the goal, redraw the interface or remove an unnecessary feature.
For the booking problem, trying an existing calendar might reveal that the real difficulty is choosing the right appointment type. That changes the job: improve the choices and explanations before building an assistant.
Bounce between the two quadrants until you can explain what you will try, why it fits and how you will check it. You need enough confidence for the next small build, not certainty about the whole project.
3. Choose tools
Choose the simplest means that can deliver the result.
A tool or agent is a response to the problem you now understand. It is not the starting requirement.
This quadrant covers tools, agents and models. Choose a tool that fits the job, decide whether an agent adds value, and choose a model where the tool offers that choice. You do not need all three for every task.
Work down this short list:
- Can we use something that already exists?
- Would a small change to it be enough?
- Can a straightforward form, formula, script or workflow do the job?
- Where would AI assistance genuinely help?
- Does any part actually need an agent to act on our behalf?
An agent may help build an app without needing to become part of the finished app. AI-generated code does not mean every button needs an AI call.
OpenCode or Codex may help write and revise code. Base44 or Lovable may help create an interface or app. An existing spreadsheet, calendar or scientific tool may already cover the need. Choose according to the work, available access and the data involved.
If you use an agent, give it a specific assignment:
Here is the problem, our chosen approach and an example of the expected result. Build only the first useful version using what this project already has. Explain any additional tool you think is necessary before adding it.
Every added tool should solve a problem you can name. Start with one agent if one is useful; add more only for a clear reason.
4. Build it
Make the smallest useful version and put it to work.
Use the finish line you defined earlier:
| What you are making | A useful first result |
|---|---|
| An app | Someone can complete its main task. |
| A user interface | Someone can find and use the important controls without coaching. |
| A workflow | One real example moves from input to the correct output. |
| A scientific experiment | A pilot produces interpretable measurements that address the question. |
Try the result yourself. Let someone else try it where appropriate. Compare calculations with a known example, observe how people use the interface, or examine what the pilot measurements reveal.
When something fails, describe what happened and what should have happened. Fix the specific problem before adding features.
Building also teaches you about the problem. If the result exposes a wrong assumption, return to Structure it and Understand it. A better understanding may lead to a smaller solution or a different tool.
Keep what works. Remove what does not help. Add only what the next useful result needs.
Use the Quadrants Every Session
| Quadrant | Your question |
|---|---|
| Structure it | What problem are we solving, and for whom? |
| Understand it | What exists, what have we learned, and what should change? |
| Choose tools | What is the simplest suitable way to do this? |
| Build it | Does the result work, and what does trying it teach us? |
The quadrants do not need equal time. A new problem may need more exploration; a familiar one may move quickly into a small build.
At the end of the session, show what changed: your understanding, your plan or your working result. Explain the next useful step.
Understand the problem well enough to build less and achieve more.