Why methods, and not answers.

The answer is already in the room

Nobody else knows why your band misses practice. No search engine knows what a good answer to your subject choice would have to do. Toyota’s fifth why has to come out of the head of the person who was standing at the machine, and Shell’s scenarios were only useful because the people who had to act on them had built them. Every method on this site works the same way. It doesn’t supply content. It supplies the shape that gets the content out of you.

That is why the methods are old, and why none of them were invented here. A method that has been used on factory floors and in boardrooms for fifty years has had every shortcut tried and every lazy version found out. What survives is a short list of questions in a particular order, and the order is usually the whole thing. Write the criteria before the options. State the failure as a fact before you list the causes. Ask why of the answer, not of the problem. Get the order wrong and the method quietly becomes a way of justifying what you already thought.

A method is a set of questions in an order that stops you lying to yourself. The answers were always yours.

The opposite direction

The default now is to ask a machine for the answer. That works well when the answer exists outside you: a date, a formula, how to fix a fence post. It works badly, and sometimes harmfully, when it doesn’t. A plan for your own life written by something that has never met you is a plausible-sounding plan for someone else. It will be fluent, tidy, and wrong in ways you can’t see, because the wrongness is in the assumptions it made about you, and you never got to look at those.

Greggle takes a side here, and the side shows in how it’s built. Pick a method and it proposes a cut of your board, and then it adds nothing until you have looked at every step and ticked or unticked it. It shows the counts, three of eleven, rather than a percentage, because a percentage flatters a plan and a count doesn’t. And it holds nothing on a server, because there isn’t one. Those aren’t privacy features bolted on afterwards. They are what a tool looks like when it believes the knowledge is in the user.

What about an assistant?

Honest answer: the app is built so that one could be added later, and there isn’t one in this version. There is no network code in it at all, and no place to put a key. But the boundary an assistant would sit behind already exists, and it says a lot about what an assistant would be for. It would be asked the same two questions the method library is asked today: propose a cut of this step, and read this branch back and say what is missing. Its suggestions would arrive on the same review screen a method’s do, one at a time, to accept, edit or reject. And the settings screen already shows, word for word, what it would be told about a step, so you could read that before every call instead of trusting a promise.

That is a different job from writing your answer. It’s the job of a good colleague who asks "what would have to be true?" and then shuts up. If an assistant is ever switched on, that’s the job it gets.

Where this goes

If the belief is that the knowledge is in the person, the app is one expression of it and not the only one. The wider thing is a set of tools, methods and systems for people who want to solve problems, finish things and plan what they’re going to do, using what they already know. Most of the first steps are now built, and they went in the order the idea suggested.

The library. This site. A page that lets someone run a pre-mortem on paper, with no app at all, is already a tool. The fourteen are here.

Cards. Each method as a single printable page: the steps, the questions, a blank grid where one is needed. Pen and paper is the most offline the work can get, and a card on a kitchen table is how a method gets used by a family rather than by whoever owns the laptop. Every method page has one.

More kinds of thing. Seven kinds was a good start and the gaps were obvious: a habit to build or break, a skill to learn, a conversation you’re dreading, a document that has to persuade. Each brings its own questions and its own natural methods, and none of those were invented here either: Gabriele Oettingen’s WOOP for a habit, Chris Argyris’s ladder of inference for a conversation. The four are in the app, two methods each, and the eight methods are cards too.

The knowledge audit. Every method assumes you know things, and most people have never been asked to write down what they know about their own situation. So there is a method for that, to run before any other: what do I know for certain, what do I believe, what am I assuming, what would I need to find out and from whom. Donna Ogle’s KWL chart from 1986 is the classroom version. It’s a card, and a framework in the app, offered first whatever the kind, and it’s the one that most sharply separates a tool built on the user’s knowledge from one built on retrieval.

The review loop. Greggle can already read a board back and say what’s missing. The next thing to read back is the past. The decision journal records what you decided, what you expected and how sure you were, and then, months later, what actually happened. Over a year it teaches a person where their own judgement is reliable and where it isn’t, which is knowledge nobody else can give them. It’s a card, and a framework in the app that closes the list for a Decision and won’t accept an entry without a review date. Reading finished boards back as the raw material is the step after that.

Fading. The most interesting version of the tool is one that plans its own obsolescence, and the app now does. The first time someone runs a pre-mortem, it walks them through every question. Once they have laid the same method out four times, the guidance folds away to a single line, one click from open, and the help under each question steps back. By the tenth, the aim is that they run it in their head in a meeting and don’t open anything. Teachers call this cognitive apprenticeship: model, coach, then fade the scaffolding. The count comes from the person’s own boards, Settings shows it, and anyone who wants the questions spelled out every time can say so. A tool that measures its success by how little people need it is unusual. It’s also exactly what a tool built on the user’s own knowledge ought to want.

The rule

The thread through all of these is the rule the app already follows. If a proposed feature breaks one of these, it belongs to a different product.