Column
Deciding what to build
Deciding what to build can go wrong in several places, in how the problem is framed, which ideas look good, the order of the work, when to commit, and how the result is judged. This column reads through them in that order.
It often starts with a request that is really a solution in disguise.
XY Problem
People ask for help with their attempted fix instead of the problem they actually have.Keep in mind: Look past the question to what the asker is trying to doSometimes asking for the real goal does not settle it, because the goal itself shifts as the work goes on.
Wicked Problems
For some problems, working out what the problem is and choosing a solution are the same act, so the requirements cannot be settled before the design starts and there is no point at which the problem is done.Keep in mind: When solving changes the problem, treat its statement as a draft, not a gateIf the problem statement can only be a draft, the cheapest draft to throw away is a page the customer would read.
Working Backwards
Teams that start from a solution often build things no customer needed; starting from the announcement exposes that early.Keep in mind: If you cannot say what the customer gets, you are not ready to buildA press release that survives the team's review has convinced the team. That is a different test from the one users run.
Most Ideas Fail
In online controlled experiments at large web companies, most ideas that survived the team's own pruning do nothing or make things worse once they are measured, and experts tend to be poor at telling in advance which ones.Keep in mind: Treat your favourite idea as a hypothesis that will probably failIf most ideas fail, a team has to try many of them with the same people, so which goes first becomes a decision of its own.
Cost of Delay
Work gets ordered by size, by gut feel or by whoever asks loudest, while what each item loses every week it waits goes uncounted, so the most valuable work often waits behind the merely visible.Keep in mind: Ask what a week of waiting costs before asking what it costs to buildOrdering the work is one decision. When to commit to each design choice inside it is another.
The Last Responsible Moment
Commit too early and a guess hardens into the design; wait too long and an option quietly expires, so the decision gets made by default without anyone making it.Keep in mind: Know when each decision expires, and decide before it doesDeciding before an option expires is half of it. The other half is hearing, before the work is under way, what the team privately doubts about the plan.
Pre-Mortem
People who doubt a plan the team has already committed to tend to keep quiet; asking them to explain a failure that has already happened draws the doubts out.Keep in mind: Assume the plan already failed, and make finding out why the clever moveA pre-mortem brings doubts out, and not every one gets resolved. When the work has to start, some people will still think the plan is wrong.
Disagree and Commit
Waiting for everyone to agree is often slower than committing and correcting course if the call turns out wrong.Keep in mind: Disagree once and fully, then commit, unless it cannot be undoneMost Ideas Fail asked for a metric before building. Once the result is in, that metric is also the easiest place to stop looking.
McNamara Fallacy
Decisions drift toward whatever can be counted, until what cannot be counted is treated as if it did not exist.Keep in mind: Name what you cannot count, and keep it beside the number
