§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)




Most roadmaps suck

What are the properties of maps?

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)




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)




Legible games enable people outside of an institution to control it

People who have done a thing should be in charge of a thing

Creating legible interfaces is expensive

The tech tree is fractal

Fair games are self-limiting

Undiscovered Public Knowledge (Paper)

Explicit rules are a substitution for learned pattern matching

Every simulation is an engineering approximation

Ontologies should be context dependent

‘Have your cake and eat it too’ life-games have led to a toxic society

Good quotes

# The Map is not the Territory



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

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




Fully open online discussions are low quality because of trust and context

Research tends to work best when it can be done by small teams

Joel Chan Podcast Feb 2 2020

Shared context is a core variable for human relationships

# The less shared context you have the higher the coordination costs
This is why [[Learning a new thing you want to both learn the jargon and explain it like you are five]] - the jargon reduces the coordination costs. 

[[Explain it like I’m Five]] is a way to make context more explicit

### Related
- [[More context can decrease the signal to noise ratio of communication for people who already have that context]]
- [[Conversations are better at demystifying than written material]]
- [[Jargon is mystifying to people without the relevant context]]
- [[Demystification involves a lot of context]]



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

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




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

Maps help you figure out possibilities

Related

Links to this note