diff --git a/start-as-experiment.md b/start-as-experiment.md
new file mode 100644
index 000000000..6551d5c3e
--- /dev/null
+++ b/start-as-experiment.md
@@ -0,0 +1,114 @@
+# Title
+
+Start as an Experiment
+
+# Patlet
+
+
+# Problem
+
+An InnerSource initiative is considered but not started because management is 
+unsure about its outcome and, as a result, is not willing to commit to an 
+investment.
+
+# Context
+
+The company is considering to leverage InnerSource to increase the efficiency
+of collaboration on software projects. However, most managers are not familiar
+with the Open Source working model and are instead accustomed to hierarchical,
+top-down control style management. The idea of InnerSource is very popular with
+software developers in the company, not the least because many developers use
+or are actively developing Open Source software.
+
+# Forces
+
+- Managers will want to validate the claims of improved collaboration through
+  InnerSource before making a long term investment. This usually involves
+  measuring the improvements.
+- If the InnerSource initiative will likely have a huge uptake among developers
+  and if many projects are likely to rely on it, a decision to shut it down
+  will be very unpopular and therefore hard to make. The perceived resulting
+  loss of control might deter some managers to even start with InnerSource.
+- Implementing InnerSource style working models are often a radically departure
+  from previously practiced working models. It is therefore likely, that
+  existing, mandatory processes are no longer applicable and that appropriate
+  governing processes are missing. The result might be that one has to operate
+  in a regulatory, sometimes legal no-mans land. Examples are tax and export
+  control related regulations in large corporations with multiple legal
+  entities in multiple countries.
+
+# Solution
+
+Declare the InnerSource initiative as a time limited experiment. Define and
+communicate the criteria for projects to join the InnerSource experiment. The
+criteria should be chosen such that they maximize the chances of building a 
+healthy InnerSource community around the selected InnerSource projects. They
+should also help to ensure that the setting of the projects is such that they 
+can later be used to gain externally valid insights into the effects of 
+applying InnerSource. Examples for such criteria are
+
+- Sufficient geographical distribution of developers
+- Sufficient departmental mix of developers,
+- Openness of communication within community,
+- Career path based on merit within community,
+- Democratic decision making within community.
+
+Consider designating the end of the experiment a _pivot_, _change_ or _pause_
+point to re-evaluate. Also consider establishing a [Review
+Committee](review-committee.md) to increase the chances of management buy-in
+through participation. Depending on company culture, it might be helpful to
+accompany the experiment with appropriate metrics [First Steps With
+Metrics](introducing-metrics-in-innersource.md). If the projects in the
+experiment don't provide a direct impact on the companies revenue, consider
+introducing [Cross Team Valuation](crossteam-project-valuation.md) to highlight
+their value contributions.
+
+# Resulting Context
+
+Managers are able to kick start InnerSource for the following reasons:
+
+- The experimental setup eases the need of managers to scrutinize the
+  InnerSource program numbers in the same way that they would for typical
+  projects.
+- The possibility of failure of the experiment is understood and accepted. The
+  personal risk for the supporting managers is minimized.
+- Even in case of a failure, the setup ensures that the company will learn from
+  the experiment.
+- In case of success, the data gathered during the experiment will allow
+  managers to make a longer lasting commitment to InnerSource. 
+
+Participants in the InnerSource experiment are now conscious of the fact that
+they have to prove to management that InnerSource yields the promised benefits.
+It will therefore help to focus work on those activites which provide the most
+demonstrable value thus increasing the chances of success.
+
+Finally, starting as an experiment makes it much easier to sidestep regulations
+and forces such as tool and process policies which could decrease the chances
+of success.
+
+# Related Patterns
+
+- _Trial Run_ (from the book [_Fearless
+  Change_](http://www.fearlesschangepatterns.com/))
+
+# Known Instances
+
+- Robert Bosch GmbH (globally distributed software development)
+
+# Author
+
+- Georg Grütter (Robert Bosch GmbH)
+
+# Status
+
+Proven Pattern
+
+# Acknowledgements
+
+- Jason Zink (Robert Bosch GmbH)
+- Diogo Fregonese (Robert Bosch GmbH)
+- Robert Hansel (Robert Bosch GmbH)
+- Hans Malte Kern (Robert Bosch GmbH)
+- Russ Rutledge (Nike)
+- Tim Yao (Nokia)
+- Clint Cain (Optum)