The Shift in Where Value Lives
Producing a First Draft Went Cheap
Across commerce and knowledge work, producing a plausible first draft: a memo, a query, a design, a slide deck, a block of code: costs almost nothing now. Automated systems generate confident output on demand. What they cannot do is decide whether the output answers the right question.
That shift moves a professional''s leverage upstream. The scarce skill is no longer typing the first version. It is framing the problem, writing the spec, decomposing the work, asking a precise question, and judging the result that comes back.
This lesson drills four disciplines that compound:
- Problem definition: separating the presenting symptom from the real problem.
- Specification: turning a fuzzy ask into precise, testable success criteria and constraints.
- Decomposition: structuring a large problem into independent, verifiable sub-problems.
- Asking the right question: of a stakeholder, a dataset, or an automated system, where the precision of the question sets a ceiling on the value of the answer.
A confident answer to the wrong question is worse than no answer, because it looks finished and it gets shipped. The professional''s job is to make sure the question was worth answering before anyone answers it.
The Executive Ask
Separate the Symptom From the Problem
A presenting symptom is what someone reports. The real problem is the underlying condition that produced it. Solving a symptom well can leave the real problem untouched, and confident delivery hides that failure until it surfaces expensively later.
A VP walks up and says: "Our sales dashboard is too slow. Build us a faster dashboard by end of quarter." That is a symptom framed as a solution. The instruction already names a technology (dashboard) and a fix (faster), which quietly forecloses better options.
The cost of solving the wrong problem well is the trap. A team can ship a beautifully fast dashboard, hit the deadline, earn praise, and still fail, because the VP actually needed to spot churn risk in time to act, and never looked at the dashboard daily in the first place.
From Fuzzy Ask to Testable Criteria
A Spec Turns Opinion Into a Test
A fuzzy ask ("make onboarding better", "clean up the data", "add search") cannot be delivered or verified, because nobody can say when it is done. A specification replaces adjectives with tests. It states the success criteria in terms someone could measure, and the constraints the solution must respect.
Two ingredients make a spec real:
- Testable success criteria: a condition you can check pass or fail without arguing. "Fast" is an opinion; "p95 response under 400 ms at 200 requests per second" is a test. "Better onboarding" is an opinion; "80% of new users complete step 3 within their first session" is a test.
- Explicit constraints: the boundaries the solution must live inside: budget, deadline, data it may not touch, systems it must not change, regulations it must satisfy. Constraints are not obstacles; they are half the definition of a correct answer.
A useful discipline. For every adjective in the ask, write down the measurement that would settle it, and the constraint that bounds it. If you cannot write the test, you do not yet understand the request well enough to start.
When the first draft is cheap to generate, the spec is what tells you whether the draft is any good. A precise spec is a reusable judgment. It grades every candidate answer the same way.
Independent, Verifiable Sub-Problems
Break the Boulder Into Checkable Stones
A large problem resists judgment because you cannot tell which part is wrong. Decomposition structures it into sub-problems that are each small enough to verify on their own. Good decomposition has two properties.
- Independence: sub-problems overlap as little as possible, so a change in one does not silently break another. When parts are independent, they can be worked, tested, and even automated in parallel, and a failure localizes instead of spreading.
- Verifiability: each sub-problem carries its own success test, so you can confirm it is solved before assembling the whole. A part you cannot check is a part you cannot trust.
A well-decomposed problem also tells you where to aim scarce human judgment. Most sub-problems are routine and can be handed to an automated system or a junior hand and checked against their test. One or two are the crux, the high-uncertainty, high-consequence, easy to get confidently wrong. Those keep the expert''s attention.
Watch for a false decomposition: parts that only look separable but share a hidden dependency, so "finished" pieces do not compose into a working whole. The test of a decomposition is whether solving every part, each verified, actually solves the original problem.
The Question Sets the Ceiling on the Answer
Garbage Question In, Confident Garbage Out
Whether you query a stakeholder, a dataset, or an automated system, the precision of your question sets a ceiling on the value of the answer. A vague question does not fail loudly. It returns a fluent, confident, plausible answer to a question you did not mean to ask, and that answer looks finished.
Consider an ambiguous data request: "Pull me our best customers." Every load-bearing word is undefined. Best by what: total revenue, margin, retention, growth rate, referrals? Over what window: lifetime, trailing twelve months, this quarter? Which customers count: active only, including churned, including trials? A dataset will happily answer whichever version the query happens to encode, and the requester will act on it as if it meant the one in their head.
A precise question pins down four things: the exact quantity or entity, the population it ranges over, the time window, and the tie-breakers or thresholds. The same discipline applies to a person ("when you say best, do you mean most profitable this year, or most likely to renew?") and to an automated system, where an underspecified prompt yields a confident answer to the wrong question.
The professional skill is to notice the ambiguity BEFORE the answer arrives, because a confident wrong answer is expensive to detect after the fact. Precision in the question is cheaper than correction after the fact.
Where Your Leverage Now Lives
A First Draft Is Cheap; Framing and Judgment Are Not
Pull the threads together. When a plausible first version of almost anything can be produced on demand, the work that carries value is the work an automated system cannot do for you: deciding what problem is worth solving, specifying what "correct" means, splitting the problem so it can be checked, asking the question precisely, and judging whether the returned answer actually meets the spec.
Carry this framing checklist into any ambiguous task, before generating a single draft:
- Problem: What is the presenting symptom, and what is the underlying problem? What does solving the wrong one cost?
- Success: What are the testable criteria for "done and correct"? Could two people disagree about whether each is met? If so, sharpen it.
- Constraints: What boundaries must the solution respect: budget, deadline, data, systems, rules?
- Scope: What is deliberately out of scope?
- Decomposition: What independent, individually verifiable sub-problems does this split into? Which one is the crux for human judgment?
- Question: For any query to a person, dataset, or system, is the metric, population, window, and tie-breaker pinned down? What ambiguity could return a confident wrong answer?
- Judgment: When the answer arrives, what test tells me it is right rather than merely fluent?
The professional of this era is not the fastest producer of first drafts. It is the person who frames the problem so well that a good answer becomes checkable, and a wrong one becomes visible.
What You Carry Forward
Two Sentences to Keep
You practiced separating symptom from problem, writing testable success criteria with explicit constraints, decomposing a problem into independent verifiable parts, and sharpening a question so it cannot return a confident wrong answer. Those four moves are one skill, framing.
Solving the wrong problem well is the most expensive mistake in knowledge work, because it looks like success. And the precision of your question sets the ceiling on the value of any answer, from a person, a dataset, or an automated system.
Producing a first draft is now cheap and getting cheaper. Framing the problem, writing the spec, and judging the result is where a professional''s leverage lives. Carry the checklist. Ask the sharper question. Define done before you start.