From Idea to Working Result: The Four-Quadrant Method

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.

In this book, you will take one small part of a project through to something usable. The worked example produces a ready-to-review appointment request. You can follow it with a new note in a text editor you already use; no terminal, account connection or installation is required. The finished note will contain an actual request, not just a plan for making one.

Booking is an optional example. Bring your own app, workflow or scientific question if that is more useful. Keep the method and change the project. Your result might be one working calculation, a clearer interface someone can use, or an interpretable pilot measurement.

If you already use OpenCode Desktop, its project conversation can support your exploration or later implementation. That is the local application, not the curriculum website. You do not need to open it to follow the manual example, and nothing in this method requires an AI conversation. First understand what you want the work to accomplish.

Learning objectives

By the end of this book, you should be able to:

• Describe a useful outcome without prematurely requiring an app, model or agent.
• Use Structure it <-> Understand it to uncover an assumption and improve the problem description.
• Choose the simplest suitable means, explaining what it can deliver and what remains outside its reach.
• Make a first useful result, inspect a concrete ambiguity or failure, and improve it.
• Apply the four quadrants to your own project and explain the next useful step from the result you made.

Core concepts

Structure it. Understand it. Choose tools. Build it.

The four quadrants name different kinds of work. They are not a one-way checklist, and they do not need equal time. A familiar problem may move quickly into a small build. A new problem may need several rounds of exploration before the right first result becomes clear.

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. Building then gives you more information, which can send you back around the loop.

Structure it

Make the problem clear enough to explore.

“We need an AI booking assistant” already assumes a solution. It tells us very little about the person who needs help, what is difficult today, or what would count as an improvement. 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.

This is a useful first description because it gives us something to investigate. It is not yet a promise that we can deliver booking. An existing calendar might solve the problem. We might need better explanations of appointment types. We might eventually need an app. We do not have to decide yet.

To structure your own problem, ask who it is for, what they are trying to do, and what gets in their way. Then name the information, materials or resources you have. Finally, describe what a useful result would look like and what would tell you that the problem is actually being solved. A sketch, a few sentences or a simple process diagram can be enough.

Here is the starting situation for our worked example. All people, contact details and appointment preferences in this example are synthetic. Alex wants a 20-minute project discussion on 18 September 2026 at 14:00, with the time zone supplied as Europe/Berlin. The contact is alex@example.test. These are Alex's preferences. They are not evidence that anyone is available, and they do not describe a confirmed meeting.

We have enough information to describe what Alex wants. Do we have enough to book it? That question takes us into the next quadrant.

Your first structure is a working draft, not a commitment.

Understand it

Explore the problem and the current ways of solving it.

Understanding is practical work. Look at what people do today. Examine a relevant example, documentation or research. Try an existing product where you have appropriate access. Find out what is already possible, what has actually been shown to work, and which parts of your idea are still assumptions. This is your practical look at the state of the art: current ways of solving the problem, including ordinary ones.

For the booking example, follow the information rather than the imagined interface. A person chooses a preferred time. Someone responsible for the appointment must know whether that time is available. Someone must also have authority to accept the request. A screen showing “14:00” cannot supply either fact by itself.

Our supplied example has a preference but no availability authority: no authorised schedule or responsible person's answer that establishes a free slot. It also has no way to reserve a slot. Writing an app would not make those missing things appear.

That discovery changes the job. Return to Structure it and rewrite the outcome:

Alex needs to prepare a clear request for a 20-minute project discussion. The request should state the preferred date, time, time zone and contact so that the recipient can assess it and reply. This first version prepares the request; it does not book the appointment.

The smaller outcome is useful. A recipient can respond to a precise request more readily than to “Can we meet sometime?” We have removed a claim we cannot support while keeping a real piece of work that helps someone.

Notice what changed and what did not. We still want to reduce the difficulty of arranging a discussion. We changed the first deliverable because we learned that availability and acceptance are outside the information we have. That is the Structure/Understand loop doing its job.

In another setting, the same investigation might reveal that an authorised calendar already handles booking, but people keep choosing the wrong appointment type. Then the useful first change might be clearer choices and explanations, rather than a new request tool. Investigation can change the problem in different directions; the point is to follow what you learn.

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. A suggested integration is not proof that you have access to it, just as a fluent request is not proof of an available appointment.

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. Here we can proceed: the facts support a useful request, and we can inspect whether the request preserves them without implying confirmation.

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, but you do not need all three for every task. A tool provides a capability. An AI model can help generate or interpret material. An agent can use tools to carry out assigned work. Each is useful only if it helps with the job in front of you.

Consider the actual choice for our request:

For this first synthetic request, a text editor is enough. An existing calendar would be worth using if it already met the real need; there is no reason to replace a working route just to practise writing software. Conversely, a manual request is not automatically the best long-term answer if many people repeatedly need help entering the same information. Choose for the present outcome, then let use reveal whether more is needed.

Work down the original method's 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?

AI might help write clearer wording, but this request does not require it. If you later use an agent to help build an app, the agent need not become part of the finished app. AI-generated code does not mean every button needs an AI call. Choose according to the work, available access and the data involved; choose a model only where your selected tool calls for one.

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. For now, we can name no problem that requires an agent, a database or a new service to produce this single request.

Build it

Make the smallest useful version and put it to work.

“Smallest” does not mean leaving out the detail that makes the result usable. It means completing a narrow task. For our example, a paragraph that someone can review and respond to is more useful than an elaborate diagram of a future booking system.

In a new note in your text editor, a first attempt might read:

I'd like to request a 20-minute project discussion on 18 September 2026 at 14:00. Please let me know whether that works. Alex — alex@example.test (opens in a new tab)

It has a purpose, duration, date, time and contact. It asks rather than announces. Yet a recipient in another time zone still cannot tell which 14:00 Alex means. The request is readable but ambiguous.

That is a specific failure you can repair. The expected result is a request whose proposed time is unambiguous; the observed problem in this written example is that the time zone is absent. There is no need to redesign the workflow or add automatic time conversion. Return to the facts. The supplied synthetic preference includes Europe/Berlin, so put that beside the time.

If the time zone had not been supplied, it would remain unknown. Ask the requester which time zone they mean. Do not infer it from the computer's settings, an email address or where you think the person lives. A request with an unresolved time zone can remain a working draft, but it is not yet ready for the finish line we chose.

Here is the revised, complete result:

Synthetic practice request — ready for review; not sent or confirmed

Subject: Request for a 20-minute project discussion — 18 September 2026

Hello,

I'd like to request a 20-minute project discussion on 18 September 2026 at 14:00, time zone Europe/Berlin.

This is my preferred time. Please let me know whether it is available. If it is not, could you suggest another time?

Thank you, Alex Contact: alex@example.test (opens in a new tab)

The request now carries the information a recipient needs to assess the preference. It also gives a useful recovery path if the time is unavailable: suggest another time. It does not need to invent a recipient's name, a meeting link or a confirmation number.

For practice, keep this synthetic result in your note; do not send it to the example address. In real use, review the actual facts and intended recipient before sending through an appropriate existing channel. Sending would still be a request, not acceptance.

Building also teaches you about the problem. If a 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. If someone reviewing this request asks what kind of project discussion is intended, clarify that purpose with the requester rather than inventing an agenda. Improve the particular missing detail before adding features.

Keep what works. Remove what does not help. Add only what the next useful result needs.

Runnable exercise

Set up one place to work

Use paper or an editor you already have. For the booking route, create a new note named First useful request; do not replace an existing document. Keep the supplied synthetic facts visible beside it. You need no live calendar, AI account or software project.

Alternatively, choose one small result from your own project that you can make with your present tools and permitted materials. Do not switch to booking just because it is the worked example. If you use an existing project, create a separate working note or copy for this first attempt so that experimentation does not overwrite valuable work.

1. Describe the job before the solution

Write a short Structure it paragraph naming the person, the difficulty and the useful result. For booking, begin with Alex's need to arrange a discussion; avoid making “build an assistant” the requirement. For your own project, describe what someone should be able to do after your work that they cannot readily do now.

Give the first result a finish line. “A ready-to-review request containing the supplied preferences” is something you can make and inspect. “Better scheduling” is a direction, not a finish line.

2. Investigate one consequential assumption

Under Understand it, identify the fact your initial idea depends on most. Use the information or current process available to you to decide whether that fact is established.

For booking, ask where availability and permission to reserve a time would come from. The supplied facts establish neither. Revise your paragraph to preparing a request, as in the worked example. Do not invent a calendar connection to preserve the larger plan.

For your own project, the assumption might concern an available input, a calculation's units, a user's task or a measurement method. Investigate enough to choose the next small action. If essential information is missing, ask for it or narrow the first result to something the known information supports. Record the change in your description so that you build the revised job rather than the old one.

3. Choose a means you can use now

Under Choose tools, name the simplest available route and give its reason in a sentence. For booking: “I will write a manual request because the immediate job is one clear message, and I have the preference details.” Compare it with the tempting alternative: an app would not resolve the missing availability authority.

For your project, first consider the tool or process already in use. A spreadsheet may be enough for one calculation; a change to an existing screen may be enough for one interface problem. Use AI if it helps with a specific part, but do not make obtaining AI access a prerequisite for work you can already do.

4. Make the result

Under Build it, do the task. For booking, write the actual request using the synthetic facts: a 20-minute project discussion, 18 September 2026 at 14:00, Europe/Berlin, Alex, alex@example.test. Label it synthetic and keep it unsent. Make it a request the recipient could answer, rather than notes about what a future request ought to contain.

For your own project, the result must likewise do something useful. The following are possible finish lines, not compulsory project choices:

Choose a slice small enough to complete. A list of intended features, a tool comparison or a blank experiment plan does not yet meet these finish lines.

5. Inspect, improve and explain

Read the booking request as its recipient. Can you identify the proposed date, duration and time zone? Can you tell that acceptance is still needed? Compare the text with the supplied facts. If it says “Your meeting is confirmed,” change that claim to a request. If it omits Europe/Berlin, add the supplied time zone. If your first draft already contains it, compare it with the ambiguous first attempt above and explain why those extra words matter; you do not need to damage a correct draft to demonstrate iteration.

For your own project, try the result in the way that matters to its purpose. Compare a calculation with a known example, observe use of the important controls, or examine whether pilot measurements address the question. If something fails, describe what happened and what should have happened. Repair that specific problem where possible. If the failure reveals a wrong assumption, revisit the problem description before building more.

Keep your improved result. Beside it, write a short next-step explanation grounded in what happened. For booking, this could be:

I made a complete request and resolved the missing time zone. It is ready for review, but availability remains unknown. In real use, the next step would be to review the recipient and facts, then ask through the existing channel and wait for an answer. A reusable form would become worth considering if preparing these requests became repetitive.

For your project, name the comparable next action. “Add more features” is less useful than explaining which observed need the next change would address.

Exit check

Show one inspectable working result with a short next-step explanation. The note containing the revised request and explanation is the complete artifact for the booking route; a separate planning sheet is unnecessary.

The booking result passes when it:

• Contains the supplied purpose, 20-minute duration, 18 September 2026 date, 14:00 time, Europe/Berlin time zone, Alex and alex@example.test accurately.
• Is clearly labelled synthetic, remains unsent, and presents the time as a preference requiring a response, not as available or confirmed.
• Includes wording a recipient could act on, including what to do if the proposed time does not work.
• Is accompanied by a short explanation of the ambiguity resolved and the next useful step.

A request missing its time zone, inventing acceptance or stopping at “we should make a booking app” does not pass. Repair the missing detail or unsupported claim using the known facts. If essential facts are genuinely unavailable, identify the question that must be answered and keep the result marked unfinished rather than pretending it works.

For your own project, show the result against the finish line you chose. Explain how trying it informed your understanding, why the tool fits, and what should happen next. A working narrow result can pass even when the larger project remains unfinished. A plan alone cannot.

Use the quadrants again next session:

You now have something to show, plus a reason for the next step. Understand the problem well enough to build less and achieve more.

Source notes

• Source book: From Idea to Working Result: The Four-Quadrant Method (opens in a new tab), permanent ID T01-L01. This revision used the coordinator-supplied authoritative current-book snapshot, with supplied base body SHA-256 dcdf7008041952d2a356ab4d309135b9bcb8b9d9b9ff946b1dd4ce998f44132d; it did not independently fetch or re-hash the live page.
• The existing book supplies the four quadrant names, the Structure/Understand loop, the problem-first booking opening, exploration and reuse questions, tool/agent/model distinctions, the useful-first-result examples, failure recovery and session questions. Useful original wording is retained alongside the expanded worked teaching. The supplied source does not identify its original human or model contributors; their identities remain unknown, and the revision author does not claim original authorship of that material.
• The approved example-led pilot brief, version 1, supplies the synthetic booking facts and the request-only boundary. Alex, alex@example.test, the discussion and all timing preferences are invented teaching material, not observations of an actual booking service. The optional booking design context is not a shipped app or an availability source.
• Editorial guidance used: STYLE.md, LEARNINGS.md version 7 and book-template.md version 1. No external booking repository was needed to establish this conceptual method or the manual request example.

Unknowns and limitations

The example establishes neither availability nor a reservation, recipient identity, meeting location or meeting link. It creates no account, storage service, calendar connection or confirmation. A manual note is a valid first result for the chosen request-writing task; it is not a booking system.

The method helps you choose and learn from a small build. It does not establish that every problem is solvable with the tools or information at hand. Scientific results still depend on an appropriate measurement method and interpretation; a successful pilot does not by itself establish a wider scientific claim.

No current product interface, external application execution, licence terms or downloadable bundle is asserted here. There are no screenshots or simulated screenshots. The worked drafts are authored illustrations, not captured user sessions. Independent reader comprehension, classroom outcomes and real-world reduction in scheduling messages have not been observed for this revision.

How this book was made

Coordinator update, 11 September 2026: The manuscript passed its format and live-baseline checks and was accepted by an independent Terra reader. The authoring-stage account below records what was known at that earlier handoff. Learner execution and classroom outcomes remain unobserved.

One writer, OpenAI gpt-6-astra (runtime model ID openai/gpt-6-astra), prepared this example-led revision on 11 September 2026 in a fresh context and the assigned isolated worktree. The author field identifies this revision's writer. Original contributor identities were not present in the supplied baseline, so retained source material is attributed to the existing T01-L01 book rather than assigned to an inferred author.

The coordinator's handoff provided the authoritative book snapshot, its baseline hash, the approved brief and the boundaries between the three pilot books. This writer retained the original method and added the completed synthetic request, the availability-authority discovery, tool comparison, time-zone correction and learner-chosen exercise. The output is this single manuscript. No additional agents participated in this writing session.

The production lesson mirrors the method: retain a useful foundation, clarify the outcome, and complete the smallest substantive result. Here the new example stops at a useful request because neither supplied preferences nor new software would establish availability. It leaves delegation and repeated-form construction to their own lessons.

This is a completed draft for coordinator integration, not a published or independently verified edition. Source reading and manuscript writing were performed; tests, lint, typecheck, browser checks and manuscript validation were not run in this author session. One coordinator-led consolidated verification is pending. External execution evidence, screenshot evidence, classroom evidence, exact elapsed time and input/output/cache/reasoning token counters are unknown, not zero; no cost or automated budget-enforcement claim is made.