§PARPA

You can create a program design discipline that enables better research and development

The distinction between areas, programs, and projects

Treating Science Fiction as case studies from a future history

Program design could be thought of as creating a causal graph of blockers and hypotheses about how to mitigate those blockers

Program design is a coordination tool

The value of planning is inversely proportional to the cost of experimenting

Program design is like creating the lego instruction book

Instead of planning not working as well as people in the past thought, as a society we’ve become worse at technological planning

How does money work in PARPA?

Physical experiments are expensive

Workshops could be a way to start small building a private ARPA

How do you measure real progress in research?

What role does scenario planning have in technological program design?

Maps help you figure out possibilities

Top of mind

There was a high return to technological roadmapping compared to not roadmapping in the past

fuEnablingMissionImpact2021

Efficiency biases systems towards false negatives

An ontology around peoples attitudes competency and roles is important for program design

Explaining things like I’m five helps avoid the Einstellung Effect

The tech tree model suggests that explicitly drawing out tech trees is important

An ARPA-like program could be the first step towards making general-purpose telerobotics inevitable

Funding is path dependent and funding curves matter

A predictably successful idea is composed of known unknowns that that a team can execute against

The crux question of program design is when to commit

Planning to Start vs Planning to Finish

Say ‘X is more important than Y’ instead of ‘X is important’

What are the different kinds of bottlenecks?

zwickyNewMethodsThought1967

What does a modified PARPA Heilmeier catachism look like?

There are two kinds of program design conversations — expansive and focused

Betting markets for research ideas could circumvent expert review killing ideas

The role of a visionary is to bootstrap the new from the old

Is there a way that python collab notebooks could be integrated into program design and roadmapping?

What is PARPA’s edge?

Roadmapping is related to the ability to create leading metrics for success

How do you think about the risk profile of PARPA programs?

Jim Matheson and Joshua Krieger conversation 14 Jul 2021

Hunting vs Farming Ideas

Work backwards with questions and work forward with answers

Joe Rollin conversation 10 May 2021

Precisely listing entrenched beliefs could be an important part of bottleneck analysis

Abstractly you want a good way of visualizing a bunch of chained vectors

Block Diagrams need to be in easily editable format

Geoff Anders conversation 7 Jun 2021

Geoff Anders conversation 9 Jun 2021

Getting people to talk about speculative research extensions is hard

Josh Greenberg Conversation 18 May 2021

Program design as a recursive response to the Heilmeier catechism

Roadmaps should have statements like “if we gain the ability to do X then we should do Y”

What are the pieces of a roadmapping architecture?

# §Program Design
- [[What are the goals of the program design process?]]]::needs work::
- [[Program design is like creating the lego instruction book]]
- [[Program design could be thought of as creating a causal graph of blockers and hypotheses about how to mitigate those blockers]]
- [[The crux question of program design is when to commit]]::needs work::

### Hypotheses
- [[The first step of roadmapping is frontier mapping]]
- [[A roadmapping framework may make the ARPA model more effective]]
- [[Talking to experts can expose bad equilibria, the moves necessary to get out of them, and considerations for doing them like cost constraints]]
- [[You can create a framework for talking to people that makes it easier to generate a roadmap]]
- [[You could build tools to make program design more efficacious]] 

### What are roadmaps
- [[What are the properties of maps?]]
- [[Roadmaps have two pieces - the map and the path]]
-  [[Roadmaps are a theoretical construct to escape inadequate equilibria]]
- [[List of Roadmapping Examples]]
-  [[Most roadmaps suck]]
	- [[Most roadmaps are not execution oriented]]

### Why Roadmapping
- [[Instead of planning not working as well as people in the past thought, as a society we’ve become worse at technological planning]]
- [[Roadmapping could be thought of as backwards-chaining together a series of conception-only heuretics]]
- [[Roadmaps can enable faster progress than blind exploration]]
- [[Technological roadmapping can give an idea of where technological evolution can go and how to get there]]
- [[A roadmapping framework may make the ARPA model more effective]]
- [[Program design is like performance debugging a vision]]
And of course we need to look at the possibility that this is all BS
- [[The roadmapping process is heavily context dependent and there may not be a generalized roadmapping process at all]]

### Building better roadmaps
- [[Design for roadmapping system]]
-  [[Person targeted questions for roadmapping]]
- [[What are the eight steps of Wigmore analysis translated to science?]]
- [[Technical Planning Principles]]
- [[Good roadmaps work backwards from a goal]]
- [[Good Simulations could be the ‘why now’ of roadmapping tools]]

### Glossary
- [[The distinction between areas, programs, and projects]]
- Bottlenecks -> Roadmap -> Execution
- Language
	- Binding Constraints
	- Affordances
	- Dependencies 
	- Project
	- Program
	- Area
	- Causal graph of blockers
- Steps
	- Frontier Mapping
	- Finding the right people
	- Comparing different paths
	- Goal setting
	- Finding serious contexts of use
	- Different institutional ‘moves’
	- Respectability cascades
	- Spending curves

### References
- [[And Suddenly the Inventor Appeared]]
- [[Wigmore Guide - Paper]]
- [[vincentTradeoffCentralConcept2017]]
- [[zwickyNewMethodsThought1967]]



[Web URL for this note](http://notes.benjaminreinhardt.com/§Program_Design)

[Comment on this note](http://via.hypothes.is/http://notes.benjaminreinhardt.com/§Program_Design)




Progress frontiers are geographically fractal

The tech tree is fractal

What are the properties of maps?

There are two levels of institution

Scientific inquiry is an abstracting process while engineering design is a narrowing process

Technological and scientific paradigms are each based around exploiting a specific phenomenon

The creation of a heuretic has two steps - conception and implementation

Phenomena are things that happen without a human consciously making them happen

Maps are multi-scale

The difference between specialists and generalists is fractal in nature

olsonManagingModesEffort2020

How can you describe the difference between learning by doing and idea sex?

Each node on the tech tree can recursively be decomposed into more nodes

Conservatism and Progressivism both have good and bad sides

Identity categories are fractal

# Every time you zoom in on a fractal, it presents the same pattern on a different scale
Fractals are Multi- Scale patters
## Questions
## Related
* [[Progress frontiers are geographically fractal]]
## References


[Web URL for this note](http://notes.benjaminreinhardt.com/Every_time_you_zoom_in_on_a_fractal,_it_presents_the_same_pattern_on_a_different_scale)

[Comment on this note](http://via.hypothes.is/http://notes.benjaminreinhardt.com/Every_time_you_zoom_in_on_a_fractal,_it_presents_the_same_pattern_on_a_different_scale)




Most roadmaps suck

Maps help you understand the state of something

Technical Planning Principles

# Maps are multi-scale
You can get some information just by glancing at a map and then more and different information by zooming in.  Fractals were literally discovered by someone mapping coastlines.[[Every time you zoom in on a fractal, it presents the same pattern on a different scale]]. 

 If a map doesn’t give you something useful on first glance, it’s not doing its job. Most pure-text roadmaps fail on this point - it’s very hard to get something useful on first glance from pure text unless it has a well crafted outline. If you can’t get different useful things when you investigate a map more closely it’s not doing its job.

If you can’t get different useful things when you investigate a map more closely it’s not doing its job. Digital maps are wonderful in this way because they can actually load scale-dependent information. Good paper maps did this by being obscenely detailed - cartographers ‘[entire professional life is spent at the magnification level of a postage stamp](https://eyeondesign.aiga.org/for-decades-cartographers-have-been-hiding-covert-illustrations-inside-of-switzerlands-official-maps/).’

### Related
- [[Maps help you figure out possibilities]]
- [[Maps help you understand the state of something]]
- [[What are the properties of maps?]]



[Web URL for this note](http://notes.benjaminreinhardt.com/Maps_are_multi-scale)

[Comment on this note](http://via.hypothes.is/http://notes.benjaminreinhardt.com/Maps_are_multi-scale)




Roadmaps need to be coupled to people

# Maps help you figure out possibilities
Even the medieval T-O map let you know that you could get to Africa from Europe by crossing the mediterranean.  Star maps help you figure out which constellations you could draw or where you could look in the night sky. 

If you can’t figure out possible (and unallowable moves) from a map, it’s not doing its job. Many ‘competitive’ landscapes fail on this front. 

A good map makes you aware of the tradeoffs between different possible moves.  Google Maps also helps you figure out possibilities by showing alternate possibilities and making you aware of the time and distance between those possibilities. The parameters of these tradeoffs vary drastically between maps - on a hiking map, elevation is important while on a driving map it is almost irrelevant. On a research map, cost is important while on a star map the concept of cost doesn’t even make sense. 

[[The Map is not the Territory]] - a good map will capture the information that you need to make decisions and exclude information that is distracted. 

*Roadmaps* ([[§Program Design]]) explicitly point out those possibilities in an opinionated way.  The difference between a map and a roadmap is the difference between google maps and the directions the map gives you to a location. 

![](../BearImages/57FE1074-F3ED-4A30-A4EB-C75575380032-456-00003424E76F85DB/9F042C35-37C6-4A14-8DCC-2066389EFB4E.png)
(Wardley)
![](../BearImages/D46F1E2D-1AC7-43B6-B703-46E7BA120E26-456-0000343CA6138B63/A9DE43E5-B06E-442A-8C30-4ED7643D2317.png)

### Related
- [[The less shared context you have the higher the coordination costs]]
- [[Context is important and underrated for knowledge transfer]]
- [[Maps are multi-scale]]
- [[Maps help you understand the state of something]]
- Wardley points out how useless a strengths/weaknesses/opportunities/threats analysis would be for a battle [On being lost - wardleymaps - Medium](https://medium.com/wardleymaps/on-being-lost-2ef5f05eb1ec)
	- [[Wardley Maps]]

[Web URL for this note](http://notes.benjaminreinhardt.com/Maps_help_you_figure_out_possibilities)

[Comment on this note](http://via.hypothes.is/http://notes.benjaminreinhardt.com/Maps_help_you_figure_out_possibilities)






# Maps help you understand the state of something
If you don’t understand the state of something better after looking at a map, it’s not doing its job.

Maps are always an abstraction ([[The Map is not the Territory]]) so there is always something about the state of the thing being mapped that the map will not capture. However, this is not always a bad thing! You can think of a map as compressing and structuring knowledge similar to how [[Jargon is a mechanism for compressing information]]. 

The compression mechanism means that a map is always going to be opinionated about what is signal and what is noise. Therefore, the design of a map should never be independent of its audience. [[More context can decrease the signal to noise ratio of communication for people who already have that context]].

A [[Stock and Flow Models]] *can* be a map, if it reflects the state of reality, but is not necessarily a map. 

### Related
- [[Structuring knowledge is expensive]]
- [[Maps are multi-scale]]
- [[Maps help you figure out possibilities]]



[Web URL for this note](http://notes.benjaminreinhardt.com/Maps_help_you_understand_the_state_of_something)

[Comment on this note](http://via.hypothes.is/http://notes.benjaminreinhardt.com/Maps_help_you_understand_the_state_of_something)




§Program Design

Most predictions suck

List of Roadmapping Examples

Good roadmaps work backwards from a goal

Technical language should be treated like an actual other language

Jordan Blashek conversation 23 Feb 2023

Playbook for Writing a Roadmap

People often confuse whether they are or should be creating prescriptive vs descriptive work

Program design creates Schelling points for purpose maintenance

Engineering Biology Roadmap -ERBC

What is SpecTechs Edge?

Andy Matuschak Conversation 30 Aug 2020

Michael Filler Converstation 2 Sep 2020

# Most roadmaps suck
As the name suggests, roadmaps should have the properties of a map ([[What are the properties of maps?]]) [[Maps are multi-scale]], [[Maps help you understand the state of something]], [[Maps help you figure out possibilities]] and explicitly point out those possibilities and associated tradeoffs. 

Most roadmaps do a poor job on many of these points. Instead, they feel like a mush of keywords and key phrases that someone evaluating a grant could check against and say “aha! This grant is legitimate because they’re trying to do this this thing that’s mentioned in the roadmap.” 

Of course, it’s possible that creating a good roadmap is an impossible task. It may be impossible to create a roadmap that actually enables coordination and progress that would not happen otherwise. However, the assertion that most roadmaps suck is based on a list of points that are very possible to fix.  

- Most roadmaps are primarily text, which makes it hard for them to be multi-scale. You should be able to glance at a roadmap at at least get a sense of what you need to do. For most of these roadmaps you need to do a deep reading to actually get a full picture. The only thing you can get at a glance from a full-text roadmap is an isolated chunk of whatever you’re looking at. 
- None of the roadmaps I’ve seen talk about either who is most suited for a task and who is going to do it.  This people/organizational decoupling might work on for the semiconductor industry, where everything is highly modularized, interfaces are standardized, and each organization has a clear responsibility. For less mature industries this isn’t the case and there’s still no pointers from jobs to be done to people or organizations. [[Roadmaps need to be coupled to people]].
- Most roadmaps don’t have precise ideas of what would enable a capability step change. All aspects of a technology can be improved, but improving some metrics can actually make the difference between a tool being almost useless and super useful [[Continuous changes can lead to discrete differences]]. Sometimes these changes are going to be improved metrics, but I’m being careful not to over-focused on metrics because often the key blocker keeping a technology from being useful is more fuzzy. At the same time, sometimes numbers are necessary to enforce precision. 
- Most roadmaps don’t go into the precision needed to actually decide whether a project is on a critical path towards enabling something important. Following on the previous point, most of the intermediate steps in roadmaps are incredibly fuzzy “Step 5: build improved planning algorithms.” What does it mean to improve a planning? Calculating paths faster? Being able to recalculate smoothly on the fly? etc.
- Most roadmaps don’t precisely present the state of an area. A question I have constantly in response to “In five years, we hope to be able to X, Y, Z” is  “Ok, so why can’t we do those things today?” I suspect the way to answer that question is to work backwards from where you hope to be to where you are today. ie. [[Good roadmaps work backwards from a goal]].  In order to do that you need a clear idea of where you are on the things that matter.
- Most roadmaps don’t make it clear which constraints are major blockers and which are nice-to-haves from an application perspective. For example, do we need robots to have five fingered hands that are as dextrous as a human’s in order to take care of older adults? Probably not! Do they need to be able to locomote over carpet? Absolutely. 
- Most roadmaps don’t make it clear which metrics matter and which metrics don’t matter. Different metrics are important to different applications. 
- All the roadmaps I’ve looked at don’t distinguish between exogenous changes that they’re counting on and endogenous changes in the field that someone reading the roadmap needs to go do. Instead, the roadmaps just use the blanket statement “X should be possible or true in five years.” The litmus test is whether X would still happen if everybody reading the roadmap went and drank mai tais on the beach for five years. In the context of robotics, for example, Moore’s Law chugging away or shifts in the ratio of older adults to working-age people are exogenous changes. Faster path-panning algorithms are endogenous. It’s important to distinguish between endogenous and exogenous predictions because exogenous predictions can be core assumptions, while endogenous predictions need to be broken down into “X will happen in five years IF A, B, and C” so that if A is behind schedule you can update your expectations for X. 
- Most roadmaps don’t talk about different scenarios. It’s absurd to think that there will simultaneously be no exogenous changes in the world *and* you are absolutely right about each step of the plan. [[Plans can change in a definite worldview]]. I would hope to see statements like “The primary path to success looks like A -> B -> C, but if B fails to achieve X, an alternative path looks like E -> F -> G.” This sort of thinking allows you to assign some sort of weight to the chance that different scenarios would play out and spend effort effectively. Scenario planning has been a discipline since at least the 1970’s, so there isn’t much excuse. [[What role does scenario planning have in technological program design?]]
- Most roadmaps don’t break down why a timeline is what it is. Most timelines are in the form of “in the next five years, we could expect to get to this point.”  That sort of estimate doesn’t give you any room to come to your own conclusion. A bulk time estimate also doesn’t let you 
- [[Most roadmaps are not execution oriented]]. Concretely, most roadmaps don’t address jobs to be done. There’s a description of applications (like elder care) and ‘tools’ (like path planning)  ::need a better word here:: but not “these are the challenges in path planning that need to be done in order to enable elder care.” 
- Most roadmaps are dead documents. [[Make living documents]] is almost universally true but is doubly so for roadmaps. The whole point is to try to shift the frontier, so hopefully within a few months something is different about the world than when the roadmap was created - whether it’s an exogenous assumption, an endogenous capability, or even just different information about the requirements on a subsystem thanks to a failed experiment. 
- Most roadmaps do not acknowledge that [[Program design is a coordination tool]]. 

### Examples
[THIS IS NOT A ROADMAP](https://home.cern/news/opinion/physics/roadmap-future)
[The Rejuvenation Roadmap | Lifespan.io](https://www.lifespan.io/road-maps/the-rejuvenation-roadmap/) - reasonable
This can’t help you make any decision https://nowandnext.com/PDF/Mega%20Trends%20and%20Technologies%202017-2050%20(Web).png

### Examples of roadmaps that don’t suck
The [[International Roadmap for Devices and Systems]] is actually useful for guiding the semiconductor industry. I suspect this is because there are well-defined interfaces, most progress will be incremental, entities are fairly fungible, and there’s strong incentive for new entities to take on different pieces of the roadmap (like in the semiconductor industry .

### Related
- [[The returns to good technical planning have decreased]]
- [[Instead of planning not working as well as people in the past thought as a society we’ve become worse at technological planning]]
- [[List of Roadmapping Examples]]
- [[Most predictions suck]]
- [[What are the properties of maps?]]



[Web URL for this note](http://notes.benjaminreinhardt.com/Most_roadmaps_suck)

[Comment on this note](http://via.hypothes.is/http://notes.benjaminreinhardt.com/Most_roadmaps_suck)




Uncertainty always involves risk but risk does not always involve uncertainty

Floating Term

Research has many orthogonal and non orthogonal classification axes

When ‘talent’ isn’t code for ‘specialized training’ it means the role or industry has not been systematized

Naming things is Powerful

The dependence of DARPA on high quality program managers mirrors the obsession with “talent” in other disciplines

As a platonic ideal, research is an unscheduled quest for new knowledge and inventions with hard-to-predict outcomes

Alignment requires existential threats

Bullshit Ideas

Overlapping institutional constraints rule out several classes of creative work

Classical liberalism arose in an environment that no longer exists

Hashtags don’t work

Precise visions are more likely to happen

The possible upsides of a healthy program design discipline seem like they could be huge

Education is no longer tied to national greatness

Good connectors nurture the connections

The term moonshot is romantic bullshit

Visions of ARPA

Nanotechnology is a suitcase-handle word

Working general purpose telerobotics is a system that enables a person to seamlessly interact with the world using a machine

Innovation ecosystem and innovation org are terrible but useful terms

Glossary

PARPA needs to enable smooth project ramping with high ceilings

Roadmapping Workshop Overview

The NSF could partner with philanthropy to unlock new general purpose technology

Vague language only works when dealing with competent people

# Suitcase Handle Word
Originally from [[Creativity Inc.]]:  
`Imagine an old, heavy suitcase whose well-worn handles are hanging by a few threads. The handle is “Trust the Process” or “Story Is King”—a pithy statement that seems, on the face of it, to stand for so much more. The suitcase represents all that has gone into the formation of the phrase: the experience, the deep wisdom, the truths that emerge from struggle. Too often, we grab the handle and—without realizing it—walk off without the suitcase. What’s more, we don’t even think about what we’ve left behind. After all, the handle is so much easier to carry around than the suitcase.`
`Managers scour books and magazines looking for greater understanding but settle instead for adopting a new terminology, thinking that using fresh words will bring them closer to their goals. When someone comes up with a phrase that sticks, it becomes a meme, which migrates around even as it disconnects from its original meaning.`
`To ensure quality, then, excellence must be an earned word, attributed by others to us, not proclaimed by us about ourselves. It is the responsibility of good leaders to make sure that words remain attached to the meanings and ideals they represent.`
- 
Very similar to [[Floating Term]]

## Related
- [[List of Suitcase Words and Phrases]]

## References
- [[Creativity Inc.]]

[Web URL for this note](http://notes.benjaminreinhardt.com/Suitcase_Handle_Word)

[Comment on this note](http://via.hypothes.is/http://notes.benjaminreinhardt.com/Suitcase_Handle_Word)






# Technical Planning Principles
Each of these principles must reference one or more of the idealized properties of [[What does good technical planning look like?]]
 
Since we’ve established that good technical plans resemble roadmaps, what happens if we invert why [[Most roadmaps suck]]?
- ***State a precise, realistic, but ambitious vision*** What does winning look like?
	- 1, 8.1, 8.4, 8.8, 15
-  **Make living documents**  “No plan survives first contact with the enemy.”  It takes work, but living plans are powerful coordination tools that helped us get to the Moon. Computers make living documents easier to create but the liveness needs to be designed in from the beginning - ways to keep track of what was changed when, what depends on what, etc.
	- 1, 2, 3, 5, 6, 7, 9, 15
- **Graphical information should be a first class citizen** Text is great for explaining, making arguments, and creating a narrative, but it is terrible at creating a holistic overview.  [[Maps are multi-scale]] and it is hard to achieve that with text. 
	- 3, 4, 14
- **Talk about who could work on what.** More detail is better, from precise skillsets down to specific people or groups.  The latter is especially important for work on the knowledge frontier because [[There are many pieces of equipment or tacit knowledge that only exist  in one or two places in the world]]. 
	- 1, 2, 10, 11, 12
- **Prioritize problems to go attack.*** It’s hard but critical to identify ‘need to haves’ vs ‘nice to haves’ to make a vision a reality.  
	- 1, 2, 8.1, 8.4, 8.5, 11, 15
- **Make it clear what has been tried before and why it didn’t work.*** Most visions are not new and the people who tried to achieve them weren’t stupid. These two facts mean that you’re likely to try something that someone else has tried before. Doing this is not *necessarily* bad - the world can change, but the burden of proof is on you to explain what those changes are and why they will make the difference between success and failure.  
	- 8.2, 8.3, 9, 13
- **Explain both technically and politically why the vision isn’t a reality today** Technical projects don’t exist in a vacuum. Sometimes the real reason a vision doesn’t exist is because of regulation, cost, or institutional bias. It’s not a party-killer if the primary blocker on a technology isn’t sheer technical capacity but it does change how to think about it and the work that needs to be done to make it a reality.  [[You can transform between technology constraints, regulatory constraints, and cultural constraints]]. Non-technical reasons don’t have to be broad macro explanations either - it could be that professor A and professor B hate each other so they never integrated their technologies. 
	- 7, 8.2, 8.3, 11, 13
- ***Use numbers but no more than necessary*** Numbers are great because they are the most unambiguous way to compare two things, set targets, and see improvement. However, [[Metrics can cause paradigm lock-in]],  the [[Streetlight Effect]], and they can give a false sense of progress (ie. going from 50% to 75% is unambiguously a 50% improvement but is actually worthless if the same methods won’t get you to 99.9% and nothing useful will happen until get there.)  If there are one or more numbers that people are trying to hit, even the most diligent person will focus on the number instead of the high level goal. The upshot is that numbers are powerful, in both good and bad ways so be judicious about their use. Numbers are just one way to represent constraints and goals - there are other low-ambiguity markers of success and progress: precisely articulated scenarios, reactions of people using a thing to do a real job, etc. 
	- 1, 2, 3, 4, 7, 8.1, 8.8, 11, 14
- **Draw a clear line between the parameters that matter in a given context and those that don’t.** Both technologies and scientific theories have many operating parameters. One difference between the two is that while a scientific theory wants to explain as many phenomena and be applicable in as many situations as possible, a technology just needs to work in a set of specific contexts. A technical plan should make it clear which parameters matter for the contexts a technology is intended for. (ie. Weight really matters for a technology meant to be used on a spacecraft but doesn’t matter at all for one meant to be used on a boat.)  
	- 2, 8.4, 9, 11, 12
- **Address multiple development scenarios.** Anybody who has does technical development work knows that the first thing you try often doesn’t work. Resorting to alternatives is not a bad thing, but not calling out what they might be (and the failure modes that might lead to them) means that the plan doesn’t reflect reality from the start.  Good statements look like like “The primary path to success looks like A -> B -> C, but if B fails to achieve X, an alternative path looks like E -> F -> G.” Additionally, external circumstances might change - funding could increase or decrease or external technologies could be invented. Acknowledging this and providing multiple “tracks” the project could follow make it more likely to succeed.
	- 1, 2, 7, 8.5, 9, 11, 12, 
- **Explain timelines and budgets in as much detail as possible but no more.** Demystifying timelines and budgets open the possibility that someone else can help figure out ways to decrease them “oh, you need to buy that machine? A friend has a spare” etc.  At the same time, be honest - if you don’t know, you don’t know. Pulling timelines and budgets out of thin air is far too common and doesn’t help anybody. 
	- 2, 3, 7, 8.6, 8,7, 12
- **Be execution-oriented.** Unless there is a great reason to believe that some work will happen exogenously to the scope of the plan, everything needs to be done by a real human. Focus on specifically what those experiments, build projects, and other actions are. 
	- 2, 3, 8.6, 8.7, 10, 12

We can do even better than  just inverting the things that suck, but by embracing [[What are the properties of maps?]] 

- **Make the plan useful at multiple levels of detail starting with just a glance.** You should be able to get some information about the plan just by glancing at it and then more and different information by engaging further. Even the people who care about minute details appreciate an easily digestible overview. This principle is one of the reasons that images should be first class - it’s very hard to get information from glancing at pure text. 
	- 3, 4, 5, 8.1, 14
- **Help people come to their own conclusions.**  Giving a reader the power to disagree forces you to show  them that your plan is the best plan instead of asserting it. Room for disagreement enables much stronger buy-in in the long run. How do you help people come to their own conclusions? …
	- 1, 2, 3, 5, 7, 9, 11, 15
- **Lay out constraints, assumptions, and affordances** Constraints look like “this technique doesn’t doesn’t work in temperatures about 5K.” A lot of technological development is about relaxing or finding ways around constraints. Affordances look like “this tool is great at doing X and Y” - they’re kind of the mirror of constraints. A lot of technological development is about expanding or finding clever uses for affordances. Assumptions look like “we’re assuming that we’ll be able to run everything on off the shelf parts.” Explicitly calling out constraints, assumptions, and affordances helps people understand tradeoffs. 
	- 1, 2, 7, 9, 11, 13
- **Draw lines between the exogenous and endogenous.** Exogenous changes are things you expect to happen external to the plan - for example, it’s a good bet that there will be better GPUs in two years. Exogenous are fine to incorporate into the plan as assumptions. However, it’s important to call them out and ideal to outline different scenarios for if they fail to happen. It’s important to draw a bright line between exogenous and endogenous changes because endogenous changes fall under the responsibility of whoever is executing on the plan while exogenous changes do not. 
	- 2, 7, 13, 15 

### Related
- [[There are scientific and technological problems that make other technology advances irrelevant by altering the environment]]



[Web URL for this note](http://notes.benjaminreinhardt.com/Technical_Planning_Principles)

[Comment on this note](http://via.hypothes.is/http://notes.benjaminreinhardt.com/Technical_Planning_Principles)




Design for roadmapping system

Adam Marblestone feedback on design

Frameworks for Systematic Creation

# Wardley Maps
- Create a graph - value to customer on Y axis, Commoditization on X axis, pieces connected by needs?
[Wardley map - Wikipedia](https://en.wikipedia.org/wiki/Wardley_map#cite_note-4)

![](../BearImages/0E4F8E2B-648B-4E16-9D3E-573A264B3445-456-000034545EA1513F/AC3FE050-B592-461E-ABA0-5BDF1D42262C.png)
![](../BearImages/6A7CC996-AA12-4F81-B358-A5B285FA3ECE-456-0000345BB715D357/93CD8E28-BD74-4213-AFA7-EB3BA05133C8.png)
![](../BearImages/BA5C7283-530D-4D5E-8D68-A653D1D7DD46-456-0000346F05DD73A5/26CACE12-8EA6-42A9-BC9F-FE6108A7AC5C.png)
![](../BearImages/68B28246-2C53-44D3-9F06-4CA991ECDDF7-456-000034A44CC9C27B/9CF93955-17D5-40F4-943A-D883A36C570A.png)
![](../BearImages/B623BAE0-F291-457C-B69E-8D02EAA708C1-456-000034CB550AA28B/C6E432DC-DDD0-4E99-A639-0CF18D1E9A0E.png)
![](../BearImages/A6674401-BB16-4771-A64B-DF5258146F45-456-000035232931EDD2/D687EA60-56AC-4514-BBD8-4DE4A55229E6.png)
![](../BearImages/D74CF346-AFAC-4CBD-8922-FCAF5A16E998-456-0000352AEFF99984/FA48A2D8-7308-4E39-B3BA-0D879664B4E0.png)
![](../BearImages/5DB04B58-156C-49AE-A0F0-CB99D811133C-456-000035603268593D/860BFD68-11BF-4847-9C76-DA04B8C5628B.png)
![](../BearImages/2220059A-5A4D-4C58-9A2C-13607CEF4793-456-0000357DBACC56B0/3F586EE8-88BF-4E9B-893A-BB36B3D1524B.png)

![](../BearImages/6AE2FC83-9416-4ED6-8774-697AD61EF2F7-456-00003590915A8968/8045921B-4956-4053-ABAF-4F59A7E682D6.png)
![](../BearImages/336130EB-34D5-48D6-BC3A-A2168C53E093-456-000035B777AE0EE8/BD2EB1A1-CB6B-49CA-99A4-3519BA38329E.png)
![](../BearImages/88C16A0D-950D-4C19-BD99-B11EB14D1D45-456-000035BF02769FF5/71878849-FA09-4912-B862-ABE7F0ED6497.png)
![](../BearImages/69B32270-7A3B-4DEE-93DA-D450011B12F9-456-000035CFCD4407B1/B74ADB1B-90F3-4073-9417-7003BBA2F2D6.png)
![](../BearImages/7B19C32D-7E67-4947-9842-4D86F715C684-456-00004089128A96BF/77B15668-DD84-4F5C-8B64-2B254915EF61.png)
![](../BearImages/D1E80098-577E-47DE-BE14-4545136154F9-456-000041001A3E3D69/B628E990-7B6C-4B4A-831A-C8CF9C56100B.png)

Customer is anchor
`As I’ve mentioned before, a program is nothing more than a high level function which often calls many other functions.`
![](../BearImages/B01737C2-DC6E-4D04-9A7B-5E78071508BE-456-00008BDF609CCA17/3FFF3829-FDD8-4224-AF2A-97B16162F83B.png)
`We first start with the appearance of this novel thing, its genesis. The component is highly uncertain, of potential future value and risky. We don’t know who will introduce it, whether it will go anywhere or what it will transform into. But, it’s a potential source of **Wonder**. It may well disappear into the bin of history along with refrigeration blankets or become a soaring success. We just don’t know. If it does find a use then supply and demand competition will start to cause its evolution. We will see custom built examples in other companies and eventually products introduced when the act becomes ubiquitous enough and well defined enough to support this.`

`will cause mass unemployment often lessens because the new industries built upon the new activities we could not have predicted will form. That doesn’t stop authors writing books prophesying calamity whether *Nehemiah Hawkin’s “New Catechism of Electricity”, 1896*or*Donald Michael’s “Cybernation, the silent conquest”, 1962*or the endless stream of books on machine intelligence. “*This time it’s different”*is one of those phrases I frequently hear shortly before we discover it isn’t.`
![](../BearImages/6B71FC7B-21F1-40A6-A569-D1932E4D1574-456-00008EF6E2A7D0AC/78E88720-CAA0-4920-BCDF-5033199BB15B.png)
`cowardly custard predictions of the kind *“the ball that was thrown will fall to the ground”*`
![](../BearImages/63E067FD-5D77-4AE5-966F-EE4EB25669C3-456-00008F959E0AD2CE/8634C795-EF89-492F-9FE8-7F3C38738BE7.png)
At the end of the day all of these things stemmed from people’s needs to share moments
![](../BearImages/4EB3E0C6-86D9-402E-A4D6-F3EE6A33BEC2-456-00008FAF70707509/9728B122-87FE-4CFC-BE0F-686B342CCA25.png)
![](../BearImages/B322BC7F-710C-4322-99DA-40600BBFB77E-456-00008FD3713E79AB/DCD4B5BB-B42D-4A05-9CB1-56494CEA461B.png)
`Carlotta Perez’s marvellous book — *Technological Revolutions and Financial Capital*. Perez has characterised these K-Waves around technological and economic paradigm shifts.`
![](../BearImages/65B664E0-7FD8-4020-B3DC-49661660D5F8-456-00008FF33463F5D2/F112793C-8A58-4725-BE64-7B1063899ED4.png)
![](../BearImages/BE12A586-E394-4C81-A9CC-59C70750322B-456-0000900519DAC906/945016C7-851B-4E35-A5C4-8AD7E6E84D24.png)
![](../BearImages/52AD620A-6940-456B-ABAF-7287C4C67877-456-0000900772D82AE9/D98C1691-79B9-47DE-97E3-CCADF725B55D.png)
`On the 1st May, 1840 a revolution in industry was started by the introduction of the Penny Black. This simple postage stamp caused a dramatic explosion in communication from 76 million letters sent in 1839 to 350 million by 1850. It wasn’t a case that postal services didn’t exist before but the Penny Black turned the act of posting a letter into a more standard, well defined and ultimately ubiquitous activity.`
![](../BearImages/CED9FAE9-A829-4954-BC9A-69A7BE80620F-456-00009078EB56058A/CD0F1BBE-B9C8-4B73-A8F2-0E8D0DD8D184.png)
`The problem for a CEO of a hardware company at that time was the market comes to expect a certain level of profit, revenue, growth and return. There is only so much you can do to blame a change on general economic factors (e.g. a downturn) as the market expects you to return to norm and most executives are rewarded on short term measures based upon this. `

`Eliot Sivowitch’s law of First — *“whenever you discover who was first, the harder you look you’ll find someone who was more first” —*and hence the first electric lightbulb was Joseph Wilson Swan, the person who actually flew a kite into the night which was hit by lightning was Thomas-François Dalibard and when it comes to the telephone, bar shenanigans with patent clerks then we owe a debt to Elisha Gray. `
![](../BearImages/A57C1CF0-6F73-4202-B9A9-3CAB065DF9D7-456-000120251D4D3855/0BAED7E2-907F-4B20-A80E-2DCC147CE94C.png)
![](../BearImages/5F8433FF-51A2-4C8A-830B-6D618709B45A-456-00017191DE2C431A/940AE4CB-3FDA-4471-B80E-E6A75B20E889.png)
![](../BearImages/41941F1A-58A3-41B8-B9D7-117040544D67-456-00017197262A4060/74CF879F-69F2-4568-9573-1556CFB805C5.png)
![](../BearImages/5C324DEB-D950-4945-AB91-00E791CE82EE-456-0001719A7A56A58B/9221D127-5BA1-4B13-92C5-7E4F39776D6D.png)
![](../BearImages/8FAC2F63-606D-425C-9E0E-C9C106800ADF-456-0001719E14384731/41081414-8FC1-4C9D-9F87-9C13F41C4531.png)
![](../BearImages/828C68F5-F3BD-4C88-BF01-626DA19F6429-456-000171A7D42A60F1/48AD1808-873C-45E7-B4E0-C12359839684.png)
This could possibly used to illustrate inadequate equilibrium?
![](../BearImages/B1FA6A3E-F3D7-499C-BC00-9C0D840EB2D9-456-000171CAF5A01039/DEE0FD40-B247-4C7C-82BD-5CB1EB003417.png)
![](../BearImages/6E9A340B-0E2D-4911-B2B0-067449968315-456-000171D14517FAD4/5B5E994A-C466-4154-AD65-CED4C26B6633.png)
![](../BearImages/2F43581C-876A-49FB-962B-3AC4F6DE3591-456-000171DB7F66D4BD/344FD83B-2241-440E-9B03-98080079DD00.png)
![](../BearImages/4EDE1B76-503D-41A7-B885-EC7547ACF551-456-000171E189B86DF0/A91B381E-AD45-4F51-8666-ECD6730A4153.png)
![](../BearImages/BBFF9BCE-F45B-4E22-B9CC-B133B44B8A67-456-00017246CD66E7E0/25896E9C-C1F2-452D-9B92-776D009291FA.png)
Constraints!
![](../BearImages/57F49200-B730-4CF4-A255-2DA834E92458-456-00017328EEBA209F/159AD772-7D4F-4703-A86F-03EC26A3E4C5.png)
`Be warned, this path won’t win you many friends. I’ve been in conferences where I’ve got into raging arguments with people trying to explain to me that agile works everywhere. This is often followed by other conferences and raging arguments with people trying to explain that six sigma works everywhere. In both cases, they’ll often explain failure as “not doing it in the right way”`
![](../BearImages/002C0BD4-5B34-477B-9F08-22984860CCE6-456-000173EF4458E8A4/17F30324-B1ED-4953-A1DA-25391ECDEB0C.png)
![](../BearImages/87D8E9D3-3C27-4164-B300-8DE3C4CEA3F3-456-000173F1B040B9A5/B8B101BC-7EC0-4CD6-8B74-F5571879830C.png)
![](../BearImages/B3EC9D93-7FC7-47DD-AA44-5C531C9913C2-456-00017402475D8C26/F8B4ED40-2D4F-42D1-92DA-F77F52CBE5CC.png)
![](../BearImages/5A18774F-E226-46E6-9023-5ED11FEC1610-456-00017532D1619896/535D0DBE-72DB-41EA-9D10-FC016408118B.png)
`The problem with figure 246 is we always look back from the perspective of today and highlight the path by which success was achieved. There were other ideas such as phones integrated with projectors, printers, firearms, umbrellas, clothing and even into a tooth that have all been, gone and quickly forgotten.`
### Thoughts
- Areas could be used to show possible realm of improvement/limits/requirements
- Could repurpose X axis to normalized key attribute?
- Different overlays on the same map
	- Satellite view/topo view/road view
- Could you even think of there as being forces along a spring or string if things are too far to one side?

### Related
- [[The Idea Maze]]
- [[TRIZ is a framework for creating inventions]]
- [[Wigmore Guide - Paper]]
- [[List of Roadmapping Examples]]



[Web URL for this note](http://notes.benjaminreinhardt.com/Wardley_Maps)

[Comment on this note](http://via.hypothes.is/http://notes.benjaminreinhardt.com/Wardley_Maps)




Most roadmaps are not execution oriented

# What are the properties of maps?
# What are the properties of maps
“Maps”, “Mapping”, and “Roadmaps” feel like [[Suitcase Handle Word]]s but  there is a nugget of desire in using them. What are we really yearning for from a map?

- [[Maps are multi-scale]]. You can get some information just by glancing at a map and then more and different information by zooming in.  Fractals were literally discovered by someone mapping coastlines.[[Every time you zoom in on a fractal, it presents the same pattern on a different scale]]. 
	- If a map doesn’t give you something useful on first glance, it’s not doing its job.
		- Most pure-text roadmaps fail on this point - it’s very hard to get something useful on first glance from pure text unless it has a well crafted outline. 
	- If you can’t get different useful things when you investigate a map more closely it’s not doing its job. 
-  [[Maps help you understand the state of something]].
	- If you don’t understand the state of something better after looking at a map, it’s not doing its job. 
- [[Maps help you figure out possibilities]]. Even the medieval T-O map let you know that you could get to Africa from Europe by crossing the mediterranean.  
	- *Roadmaps* explicitly point out those possibilities in an opinionated way. 
	- If you can’t figure out possible (and unallowable moves) from a map, it’s not doing its job.

![](BearImages/A1F27DD7-DF6B-467B-96E4-599D26CC393D-32352-00023ECE922974A5/DEE0FD40-B247-4C7C-82BD-5CB1EB003417.png)

### Types of maps
- Conceptual 

### Related
- [[Wardley Maps]]



[Web URL for this note](http://notes.benjaminreinhardt.com/What_are_the_properties_of_maps)

[Comment on this note](http://via.hypothes.is/http://notes.benjaminreinhardt.com/What_are_the_properties_of_maps)




Benʼs working notes

What are the properties of maps?

What are the properties of maps

Types of maps

Related

Links to this note