This is the first time I’ve written something in public, so a portion of my brain is shouting that I’m embarrassing myself.
This post is intended to take some common-sense ideas about foresight during project work, and make them more concretely actionable. It could definitely be improved.
Effort on a task is useful to to the extent that it either brings the task towards completion, or gives you information about the best path forward. I’ll call these making progress, and gaining assurance (the best word I’ve found for “justified confidence”). I like to think of them as walking and navigating.
Some effort gets lost doing neither.
Carefully proofreading a paragraph that you later cut.
Making a tool for someone that, by misunderstanding, doesn’t do what they want.
Creating a big exact plan that falls apart when the requirements change.
Giving up on a project before releasing it.
The effort is lost because they worked without enough assurance. They risked their work without enough evidence to back up the gamble. The overplanning example was trying to avoid against exactly this, with a comprehensive plan, but they didn’t have enough evidence to *plan* so far.
Gaining assurance is like improving form, making further efforts more efficient. Having more assurance improves the expected value of the work you produce.
Gaining Assurance:
For your project, identify the most important potential failures, looking first for large scale risks (no one wants this product, this idea is based on a flawed premise) and working down to small, local risks in whatever you’re doing.
Later in the project the risks should be much smaller, because the larger ones should have already been managed.
- Rush testing high-risk decisions to learn fast. (Related tangent, delay low-risk decisions for as long as is practical. They provide little assurance, and later on you’ll have more information to make a better decision.)
Find at least one way to decrease uncertainty around the risk, like experiments, prototypes/drafts/outlines, or contemplation.
Aim to maximize information, cutting the possibility space down aggressively.
Favor low fidelity. Avoid any polish that doesn’t efficiently increase the information you receive. A rough experiment can often tell you almost as much as a polished experiment. Scribble, if that’s all you need.
Do it.
If assurance is now sufficient, do progress work until more is needed. Else loop.
For small scale risks this is usually habitual workflow, like “write code, run tests, commit code.” If it’s insufficient, try changing the step size between gathering feedback.
Checking for larger risks is rarer and more context dependent, so it will need conscious attention.
When making progress, take small steps that keep within the space you’re reasonably confident in. Stop and gain more assurance when you reach the edge. Don’t outrun your headlights.
Depend on the firmest parts of the design. If part of the project has a 20% chance of being cut, then any polish there has a 20% of being wasted progress work. Probably not the best use of your time.
You can hedge your bets by doing your progress work in the shortest path towards a risk point. This is like making a prototype for the risk point, built out of production quality material. More costly than a rough prototype if it fails, but “free” if it succeeds. See Tracer Bullet.
I would like this to feel more concretely actionable, but this is the best I’ve got right now. The above is general purpose, but you’d probably want to adapt it into something tailored to your project.
Walking and Navigating
This is the first time I’ve written something in public, so a portion of my brain is shouting that I’m embarrassing myself.
This post is intended to take some common-sense ideas about foresight during project work, and make them more concretely actionable. It could definitely be improved.
Effort on a task is useful to to the extent that it either brings the task towards completion, or gives you information about the best path forward. I’ll call these making progress, and gaining assurance (the best word I’ve found for “justified confidence”). I like to think of them as walking and navigating.
Some effort gets lost doing neither.
Carefully proofreading a paragraph that you later cut.
Making a tool for someone that, by misunderstanding, doesn’t do what they want.
Creating a big exact plan that falls apart when the requirements change.
Giving up on a project before releasing it.
The effort is lost because they worked without enough assurance. They risked their work without enough evidence to back up the gamble.
The overplanning example was trying to avoid against exactly this, with a comprehensive plan, but they didn’t have enough evidence to *plan* so far.
Gaining assurance is like improving form, making further efforts more efficient. Having more assurance improves the expected value of the work you produce.
Gaining Assurance:
For your project, identify the most important potential failures, looking first for large scale risks (no one wants this product, this idea is based on a flawed premise) and working down to small, local risks in whatever you’re doing.
Try Pre-Postmortem. Think of the most important questions. What would you be concerned about if you were hearing someone else talk about this project?
Later in the project the risks should be much smaller, because the larger ones should have already been managed.
- Rush testing high-risk decisions to learn fast.
(Related tangent, delay low-risk decisions for as long as is practical. They provide little assurance, and later on you’ll have more information to make a better decision.)
Find at least one way to decrease uncertainty around the risk, like experiments, prototypes/drafts/outlines, or contemplation.
Aim to maximize information, cutting the possibility space down aggressively.
Favor low fidelity. Avoid any polish that doesn’t efficiently increase the information you receive. A rough experiment can often tell you almost as much as a polished experiment. Scribble, if that’s all you need.
Do it.
If assurance is now sufficient, do progress work until more is needed. Else loop.
For small scale risks this is usually habitual workflow, like “write code, run tests, commit code.” If it’s insufficient, try changing the step size between gathering feedback.
Checking for larger risks is rarer and more context dependent, so it will need conscious attention.
How to do progress work safely:
Be aware of uncertainty. Get a sense for what things go wrong, like illusions of transparency, or taking longer than expected.
Beware unmerited optimism. Take an outside view. Learn about relevant failure rates and avoid survivorship bias.
When making progress, take small steps that keep within the space you’re reasonably confident in. Stop and gain more assurance when you reach the edge. Don’t outrun your headlights.
Depend on the firmest parts of the design. If part of the project has a 20% chance of being cut, then any polish there has a 20% of being wasted progress work. Probably not the best use of your time.
You can hedge your bets by doing your progress work in the shortest path towards a risk point. This is like making a prototype for the risk point, built out of production quality material. More costly than a rough prototype if it fails, but “free” if it succeeds. See Tracer Bullet.
I would like this to feel more concretely actionable, but this is the best I’ve got right now. The above is general purpose, but you’d probably want to adapt it into something tailored to your project.