Outcomes Before Output

In plain words

In the hostel mess, everyone shouts 'get a food app' before anyone asks why students are going hungry. Teams do the same thing with software. An output is the thing you build; an outcome is the real change for a real person, with the limits that must hold. Write the outcome first in six short lines, then check that no solution has quietly sneaked into it.

How it flows

A tiny example

frame = {
    "user": "on-call engineer",
    "situation": "a 2 am production alert",
    "desired_outcome": "finds the failing service in two minutes",
    "constraints": ["diagnosis stays read-only"],
    "non_goals": ["no automatic fixing"],
}
for problem in check_for_leaked_solutions(frame):
    print(problem)

Notice the desired outcome names no app, bot or database — only what should get better.

What you will learn

• The difference between an outcome (what should get better) and an output (the thing you build).
• How to write a six-part outcome frame before you write any code.
• How to spot a solution sneaking into your goal statement.
• Why constraints and non-goals are part of the goal, not extra decoration.

The problem, simply

Think about your hostel mess. Students keep complaining. The mess secretary calls a meeting and everyone shouts one line: "Install a new food ordering app."

Now stop and ask. What is actually wrong? Maybe students reach at 9 pm and food is over. Maybe the menu changes without notice. An app does not fix an empty vessel.

Software teams do exactly this. Someone says "build an incident assistant" or "add a dashboard". That is a thing to build. It does not say who is suffering, what should improve, or what must stay safe.

This mattered less earlier because building took months, so you had time to notice the mistake. Now, with an agent, you can build that whole wrong dashboard on Tuesday afternoon. Speed is not free. Speed means you reach the wrong destination faster.

Warning

Warning: When implementation becomes cheap, choosing the wrong problem becomes the expensive part.

The idea

Outcome versus output

An output is an artifact. An app, a dashboard, a database, a script.

An outcome is an observable change in someone's real life, with the limits that must hold.

Compare these two.

Output: "Build an incident assistant."

Outcome: "When a production alert comes at 2 am, the on-call engineer finds the failing service and one safe next step within two minutes, and the whole diagnosis stays read-only."

See the difference? The second one can be satisfied by an agent, or a one-page runbook, or even fixing a badly named log field. It keeps you attached to the result, not to the first idea somebody imagined in a meeting.

The six-part frame

Before you build, write six lines.

1. User — who feels the pain directly?
2. Situation — when and where does it happen?
3. Current behaviour — what happens today, including the jugaad workarounds?
4. Desired outcome — what observable thing should get better?
5. Constraints — which safety, policy, cost or compatibility limits are fixed?
6. Non-goals — which tempting nearby work are you refusing this time?

A worked example

Suppose Priya is building for her college placement cell.

Someone tells her: "Build a WhatsApp bot for placement updates." That is an output.

Priya instead writes the frame.

• User: final-year student waiting for shortlist results.
• Situation: the evening a company releases its shortlist, around 300 students refreshing the notice page.
• Current behaviour: students refresh every two minutes, then ask seniors in a group, then someone screenshots a wrong list.
• Desired outcome: a shortlisted student knows within five minutes of the result being published, and knows it from a source they trust.
• Constraints: no phone numbers leave the college server; the placement officer must approve before anything goes out.
• Non-goals: no resume feedback, no interview scheduling, no analytics dashboard in this slice.

Now look. A WhatsApp bot is one possible answer. So is an email, an SMS, or just publishing the list in a fixed place at a fixed time. Priya kept her options open until she had evidence.

Solution leakage

Leakage is when a solution quietly hides inside your goal sentence.

• "Users receive a weekly AI summary" — leaks the summary and even the cadence.
• "Users understand account changes before they approve them" — clean, states the result.
• "Deploy a vector database" — leaks infrastructure.
• "Relevant policy evidence is available during review" — clean, states a capability.

Constraints are allowed to name technology, but only when compatibility genuinely fixes it. Then write down why it is fixed, so the next person does not treat your guess as gospel.

Tip

Tip: Read your desired outcome aloud. If it contains a noun you could put on a purchase order, you have probably leaked a solution.

Constraints and non-goals are part of the goal

Constraints are things like: no writes to production during diagnosis, answer inside the incident time budget, no new runtime dependency, screen-reader behaviour stays intact.

IMPRemember: if your build reaches the desired result by breaking a fixed constraint, it has not reached the outcome. It has failed.

Non-goals stop a small useful slice from swelling into a platform. Good non-goals are concrete enough to reject actual work: no automatic remediation, no new alert-routing system, no historical analytics this time.

Build it

Here is a tiny validator. It checks an outcome frame for missing parts and for leaked solution words.

"""Check an outcome frame before you start building."""

# Words that usually mean a solution has leaked into the goal.
LEAK_WORDS = ["app", "dashboard", "bot", "database", "chatbot", "portal", "api"]

REQUIRED = [
    "user", "situation", "current_behaviour",
    "desired_outcome", "constraints", "non_goals",
]

def check(frame):
    """Return a list of problems. Empty list means the frame is clean."""
    problems = []

    # 1. Every part must be present and non-empty.
    for part in REQUIRED:
        if not frame.get(part):
            problems.append("Missing part: " + part)

    # 2. The desired outcome must not name a thing you would build.
    outcome = str(frame.get("desired_outcome", "")).lower()
    for word in LEAK_WORDS:
        if word in outcome.split() or (word + "s") in outcome.split():
            problems.append("Solution leaked into outcome: '" + word + "'")

    # 3. Non-goals must be concrete enough to reject work.
    if len(frame.get("non_goals", [])) < 2:
        problems.append("Give at least two non-goals")

    return problems

good = {
    "user": "final-year student waiting for a shortlist",
    "situation": "the evening a company publishes its list",
    "current_behaviour": "refreshes the notice page, asks seniors, sees wrong screenshots",
    "desired_outcome": "a shortlisted student knows within five minutes, from a trusted source",
    "constraints": ["phone numbers stay on the college server"],
    "non_goals": ["no resume feedback", "no interview scheduling"],
}

leaky = dict(good)
leaky["desired_outcome"] = "students get updates in a whatsapp bot"
leaky["non_goals"] = ["no analytics"]

for name, frame in [("good", good), ("leaky", leaky)]:
    issues = check(frame)
    print(name, "->", "CLEAN" if not issues else "")
    for issue in issues:
        print("   -", issue)

Run it with python3 file.py. The first frame prints CLEAN. The second one reports two things: the word "bot" leaked into the desired outcome, and only one non-goal was given. Notice that the leaky frame is not badly written English — it just quietly decided the answer before anyone checked.

Where you will see this

• Product and design reviews at any company, where a PM is pushed to state the user problem before the feature.
• Coding agents like Claude Code and Cursor, where a vague task gives you a confident but useless patch, and a framed task gives you a usable one.
• Customer-support bots, where the real outcome is "the customer's issue is resolved", not "the bot replies".
• Swiggy or Zomato style assistants, where "show more offers" is an output and "the user picks a meal they are happy with in under a minute" is the outcome.
• Your own final-year project review, where the panel asks what problem you solved, not which libraries you imported.

Common mistakes

• Starting from the artifact. You say "let us build an app" and then reverse-engineer a problem to justify it. The build then cannot be judged, because there is nothing it was supposed to change.
• Vague outcomes. "Improve the user experience" cannot be checked by anyone. If you cannot say what you would observe, you cannot say whether you succeeded.
• Treating constraints as suggestions. Teams hit the target while quietly breaking the safety limit. That is a failure being reported as a win.
• Skipping non-goals. Without them, every review meeting adds one more "small" thing, and a two-week slice becomes a six-month platform.
• Never revisiting the frame. You learn things while building. A frame written once and never re-checked slowly becomes a lie you defend.

If they ask in an interview

Q: What is the difference between an outcome and an output?

A: An output is the artifact you build, like a dashboard or a bot. An outcome is the observable change for a real user, along with the limits that must hold. Many different outputs can satisfy one outcome, so stating the outcome first keeps your options open.

Q: AI tools let us build much faster. Does planning still matter?

A: It matters more. Faster building means you can commit to the wrong problem before anyone realises, and then you have working code defending a bad direction. The cost has shifted from typing the code to choosing what to build.

Q: How do you know a goal statement is well written?

A: It names the user and the situation, says what observable thing improves, and lists fixed constraints and explicit non-goals. It should not name a product form, framework or database unless a verified compatibility limit forces it, and then the reason is written down.

Try these

1. Take one feature request from your college project's backlog and rewrite it as the six-part frame. Do not let any product noun appear in the desired outcome.
2. Add one constraint to that frame that genuinely removes some possible solutions. Notice which ideas die.
3. Write three completely different outputs that would all satisfy your one outcome. At least one of them should involve no new code.
4. Extend the validator above with your own leak words, and run it on the frame you wrote in exercise 1.

Words, simply

Quick recap

• An output is what you build; an outcome is what gets better for a real person, under fixed limits.
• Write the six-part frame first, then check it for solution words that sneaked in.
• Constraints and non-goals are part of the goal — break one and you have not succeeded, you have failed loudly.