Attachment 0

Ref.
Ares(2018)6161936 - 30/11/2018
Lean Hardware
D 2.4
November 2018
MERLIN
Methodologies for Researcher Led Innovations
Nº780.460. ICT-32-2017. EU H2020
Confidentiality Level: PU
Document Type Contract Deliverable
Document & WP No. D2.4 WP 2
Document Title Lean Hardware
Release date 30/11/2018
Executive summary
This document, D2.4 — Lean Hardware – (WP 2) is a deliverable of the MERLIN project, which is
funded by the European Union's Horizon 2020 under Grant Agreement #780460, and has been
prepared by taking into account the template of the "Guidelines on FAIR Data Management in Horizon
2020" and the "Fact Sheet: Open Access in Horizon 2020".
Merlin aims to foster and accelerate the transfer of knowledge from the projects funded in FP7 and
H2020, be it on the form of license agreement, patent or ideally, spinoff or startup to directly exploit
them, by organising practical hands-on workshops; meet ups with potential partners, customers and
investors; and by attending scientific conferences to reach a wider public. The programme will equip
participants with knowledge, skills and a network to generate market-led business models to unlock
potential and accelerate this journey.
th
The purpose of this deliverable is to provide the content of the 7 workshop – Lean Hardware that will
be used by all the members of the Consortium when conducting the workshop at their locations.
This project has received funding from the European

Union’s Horizon 2020 research and innovation
programme under grant agreement No 780.460
Copyright © MERLIN Consortium

https://merlin-ict.eu
PUBLIC Dxxx Lean Hardware
Document Control Page
Title Lean Hardware
Creator UPCT
Description Description of the content used in the workshops – Lean Hardware.
Review status Action Person/Partner Date
Completed by WP Leader
Approved by Peer Panel
Approved by QA
Distribution Confidential CO
Revision history
Version Date Modified by Comments
1.0 01/09/2018 Nieves Pavón Pulido First version of the deliverable.
2.0 30/11/2018 Nieves Pavón Pulido Final version of the deliverable.
Copyright © MERLIN Consortium Page 3 of 33

Table of Contents
1. Introduction ............................................................................................................................... 5
1.1. Audience .......................................................................................................................... 5
1.2. Structure .......................................................................................................................... 6
2. Workshop Lean Startup ............................................................................................................. 7
2.1. General information about the workshop ....................................................................... 7
2.2. Introduction to the workshop.......................................................................................... 7
2.3. Intro – waterfall paradigm vs Lean Hardware paradigm ................................................. 8
2.4. Considerations to take into account when creating hardware startups by using the Lean
method. .................................................................................................................................... 12
2.5. Financing hardware startups. ........................................................................................ 14
2.1. Playing a game to test how participants face the hardware development process ...... 14
2.1.1 How to moderate the game? .................................................................................... 16
2.1.2 How to play? .............................................................................................................. 27
2.2. Discussion. ..................................................................................................................... 29
2.2.1 Successes and failures in hardware startups and companies.................................... 30
2.2.2 CE Marking................................................................................................................. 31
2.2.3 Leading the discussion: considerations to take into account. ................................... 32
2.3. Conclusions .................................................................................................................... 32

1. Introduction
This deliverable (D2.4) — Lean Hardware content (hereinafter – LHC) – is a deliverable of the MERLIN project,
which is funded by the European Union's Horizon 2020 under Grant Agreement #780460 and has been
prepared by taking into account the template of the "Guidelines on FAIR Data Management in Horizon 2020"1
and the "Fact Sheet: Open Access in Horizon 2020"2. The purpose of LHC is to provide a description of the
material that all members of the Consortium will use when conducting the workshop at their locations and
the topics of which is the Lean Hardware concept.
Funding in ICT project under FP7 and H2020 totals over 11.000 million € by the end of the current work
programme. Stimulated and supported by these programs, many researchers in universities, institutes and
SMEs have worked hard on developing new ground-breaking technologies and disruptive services. But when
it comes to commercialize the results or create a company, these researchers are unsure on how to proceed.
MERLIN project, funded in the context of the EC initiative Innovation Radar, wants to start changing this
situation by organizing a set of activities aiming:
• To stimulate a greater interest in the scientific community to view their research results as potential
opportunities to be exploited with the correct business model.
• To equip researchers with modern, need-first and market-led methodologies that will help them to
shape their ideas and outputs into innovations to be ready for market validation and posterior
commercialization.
• To introduce the rich European entrepreneurship ecosystem and the opportunities it offers to create
and support startups on their journey.
Among the planned activities, it is worth highlighting the following:
• Organisation of 45 practical workshops covering state-of-the-art innovation and entrepreneurship

methodologies in 8 European cities.
• Organisation of 5 workshops in scientific conferences to reach more researchers and engage them
with the activities organized by MERLIN and other ICT-32 projects.
• Organisation of 8 meet ups with potential partners, customers and investors by the end of each year.
• Organisation of 4 webinars on SME growth and new business models for public-private partnership.
The LHC provides the description of the content used for the Lean Hardware workshop. It describes the
theory to be presented during the workshop as well as the practical exercises which are used to put the
theory to the test and ensure the participants develop the practical skills of applying the theory to their own
ideas.
1.1. Audience
The main intended audience for this document is the MERLIN project consortium and the European
Commission, but also workshop attendees and general public.
The target audience of the workshop are researchers and startups from the ICT field.
1
http://ec.europa.eu/research/participants/data/ref/h2020/grants_manual/hi/oa_pilot/h2020-hi-oa-data-mgt_en.pdf
2
https://ec.europa.eu/programmes/horizon2020/sites/horizon2020/files/FactSheet_Open_Access.pdf

1.2. Structure
The structure of the document is as follows:
• Section 2 presents the content of the Lean Hardware workshop.

• Section 2.1 and Section 2.2 provides general information about how the workshop is organized.
• Section 2.3 provides information about how Lean Hardware paradigm could offer advantages in
comparison to traditional approaches.
• Section 2.4 shows several considerations that it is necessary to take into account when hardware
startups are created.
• Section 2.5 explains the problems related to financing hardware startups.
• Section 2.6 describes a game that show to the participants how to face the process of creation,
development, manufacturing and retailing a hardware product.
• Section 2.7 shows how to conduct the discussion after playing the game, where participants should
discuss several issues related to Lean Hardware methodology.
• Section 2.8 presents the conclusions of the workshop and some interesting references for
participants.

2. Workshop “Lean Startup”
2.1. General information about the workshop

Name of the workshop: Lean Hardware
Name of the partner which is responsible for the content delivery: UPCT
Duration of the workshop: 4 hours
Optimal number of participants: from 20 to 30
Target groups: Junior and senior researchers, PhD students on their last years and post-doc with research
results
Target group needs identified: The target group lacks knowledge on how to design, develop and
commercialize hardware products according to the customer’s need and how to reduce the time, effort and
economical cost when prototyping such hardware products in the context of hardware startups.
Key skills to be acquired: Learn how to apply the Lean Hardware paradigm to develop hardware products,
with the purpose of reducing the development time and the economic cost during the prototyping stage.
The main goals of the workshop:
• To understand the main elements of Lean Hardware methodology.
• To learn how to apply Lean Hardware principled approach to new hardware product development
and its maintenance ensuring that the product get to the customers faster.
Learning methods to be applied: Kolb’s Learning Cycle3.
The main requirements for the venue: computer, projector, projector screen, able to seat 20-30 people.
Requirements for supplies needed: Pens, markers, large sheets of paper, stopwatch or a phone with
stopwatch, the graph of the proposed game for the moderator, fake money, game cards for participants,
several calendars and several copies of Lean canvas.
Trainers: Due to the workshop features, two instructors are needed for the development of the session. The
profiles for them are the following:
• Instructor 1 (Moderator): He or she should know the concepts of Lean Startup and the cycles involved
in the process.
• Instructor 2 (For supporting the moderator): He or she should have a technical profile: electronics,
hardware and software development for systems.
2.2. Introduction to the workshop

The Lean Hardware workshop starts with introducing the 4th basic rules for the workshop:
• The learning process is active (participation is absolutely required);
• No question is a silly question;
• What is said in the room stays in the room;
• Support and challenge each other.
3
Russ Vince, “Behind and Beyond Kolb's Learning Cycle”, Journal of Management Education, Vol 22, Issue 3, pp. 304 – 319, 1998,
DOI: 10.1177/105256299802200304

The main purpose of the introduction of the rules for the workshop is to encourage the participants to
participate in the workshop actively, inviting them to ask all the necessary questions by keeping the questions
asked in the room, and making easy to support and challenge each other.
The general information about the workshop is provided:

• Length of the workshop (4 hours);
• Coffee break (20 minutes);
• Slides will be shown to the participants during the workshop and it will be shared at the end.
After the participants are introduced with the workshop agenda and a specific ice-breaker game or a fast
presentation of each participant is done, the learning objectives of the Lean Hardware workshop are
presented, which include:
• Understand the key elements of Lean Hardware methodology;
• Learn how to apply Lean Hardware principled approach to a new hardware product development;
• Understand how using this methodology desired hardware product could get to the customer’s
hands faster and this would facilitate the maintenance process and the development of an improved
hardware product, according to the user experience.
Lean Hardware workshop content is divided into several distinctive parts:

• Intro – waterfall paradigm vs Lean Hardware paradigm;
• Considerations to take into account for hardware startups creation by using the Lean method;
• How to finance hardware startups;
• Playing a game to test how participants face the hardware development process: risk evaluation;
• Discussion about specific problems found in development process (and, in particular, when Lean
Hardware methodology is used), for a successful commercialization of the hardware product.
The following sections of the document describe the content of each part in detail.
2.3. Intro – waterfall paradigm vs Lean Hardware paradigm

At the beginning of the workshop, the participants are introduced with the general ideas that make up the
Lean Hardware methodology.
Lean Hardware is clearly related to Lean Startup concept4, since it is the paradigm that startups could use
when designing hardware following the Lean Startup methodology. Lean Hardware is also closely related to
Agile methods (frequently used in software development).
As it was shown in previous workshops, “Lean Startup is a methodology that aims to reduce product
development cycles by adopting a combination of business-hypothesis-driven experimentation and iterative
product releases, validating learning according to customer insights”.
Many hardware startups are born from makers that have experience in rapid prototyping by using well-
known development kits based on Arduino and similar tools, 3D printing and backend-as-a-service platforms.
However, even using these new tools, hardware development is still hard and, consequently, building a
4
Ries, E. The Lean Startup: How Constant Innovation Creates Radically Successful Businesses: How Relentless Change
Creates Radically Successful Businesses (Viking). 2011.

hardware startup is actually harder. While applying lean methods to software development is relatively easy,
because changes can be made over beta versions to obtain a new release in a short period, by generally only
consuming human resources, the application of this paradigm to hardware development is a little bit
complicated. In this case, not only human resources are required (even those needed for firmware or
additional software implementation), but material means are also necessary and, in general, the participation
of third parties is needed to produce the final device, which entails an additional cost in terms of time and
price.
Many developers still use the Waterfall method for modelling processes both in software and hardware
design. In fact, such method was the first process model to be introduced, and it is also referred to as a linear-
sequential life cycle model. The advantage is that it is very simple to understand and follow. It main feature
is that each stage should be successfully completed before starting the next one, so, there are not
overlapping between stages. However, subsequent modifications have introduced changes for allowing
developers to go back in the cycle (usually to the previous stage), for solving errors or including other
requirements before ending the complete cycle. The advantages of waterfall development are a better
departmentalization and control, and the possibility of defining a schedule with very well defined deadlines
for each stage of development. But this rigidity does not fit well with projects where requirements could
change fast and, then, risk and uncertainty is high. Given that a changing environment is usually present in
the process of startup creation and acceleration, Waterfall cycle could be not too suitable, since it is as
opposed to Lean methodology due to the rigidity that avoid entrepreneurs to easily pivot 5.
Therefore, applying the lean startup method to hardware development could be the best way to avoid
expensive errors, since making a mistake in the initial definition could be very hard to fix later, and this could
spend too much time and money. Then, to keep the process on the right path, it is necessary to go through
fast iterations of LEARN->BUILD->MEASURE, identifying the minimum effort that maximizes learning in each
iteration. Obviously, this is in opposition to the Waterfall method where stages are linear and sequential and
customer involvement is practically null, see Figure 1.
Figure 1. Comparing Agile and Waterfall methods
5
Palmquist, Steve & Ann Lapham, Mary & Garcia-Miller, Suzanne & Chick, Timothy & Ozkaya, Ipek. (2013). Parallel
Worlds: Agile and Waterfall Differences and Similarities.
Shah, Manan & Dhiman, Charusmita. (2016). Software Process Models Outline. IRACST - International Journal of
Computer Science and Information Technology & Security (IJCSITS). 6. 127-132.

In this case, the device is the consequence of a process where designers decide all about functionality, shape,
cost and design without considering the opinion of potential customers during all the cycle. In this case, the
odds of success are reduced and it is very difficult to fix the mistakes when the device has already been
commercialized, with the corresponding economic cost for the startup.
As it is well-known for the Lean methodology adopters is that the technology, in and of itself, is not
interesting. What is interesting is what people expect from the designed product. Therefore, it is necessary
to determine, what the product is for and who is willing to pay for such product. These questions should not
be answered by developers; they are questions that need to be answered by the customers themselves, so
the best option is directly to go to potential users for finding a response.
Designing and developing hardware products by following the Lean method involves to track a path
consisting of several stages:
Stage 1: Ask potential customers.
During this stage, iterations should be very fast, interviewing only the necessary amount of people at each
iteration. This allows developers to remove a lot of bias and maximize their learning.
However, the task of finding early adopters could be hard, mainly when entrepreneurs design hardware
products. Finding adopters for software prototypes is easier, since there are many channels for reaching
potential customers and the economic cost is considerably low, but finding hardware products adopters
is harder, mainly if the product is highly specialized. In this case, having a personal relation with interested
people that need the product to prototype, could be the best choice. Therefore, it is necessary to know
the market very well and to ask ourselves where to find people that would need our solution. Even better,
asking ourselves if our belief about customers’ needs is really true6.
Stage 2: Build a hardware minimum viable product (HMVP).
During this stage, developers should increase their knowledge in the learning process, not build the final
product. Consequently, it is not time to refine the look, but to get something that works.
Product development usually begins by considering three elements: cost, time and scope. It is also
necessary to define priorities: time-to-market, budget or a unique set of features. Obviously, taking
decisions while we are still learning is difficult. Moreover, we need to minimize errors during
development, and for doing this, we should not think about how to develop the final product, but what
the minimum number of elements is needed to solve the potential customers’ problems. Consequently,
first of all, it is necessary to define a Minimum Viable Product (MVP)7,8, that is, a basic collection of features
capable of satisfying a very first set of requirements that a potential customer, with a specific need. In the
case of HMVP we are talking about a tangible minimal product or prototype, that should work as fine as
possible. That means the prototype does not have to be perfect since it is not a final version. It is just a
6
David Roth, Early Adopters: Who Are the Right Cooks for Your Kitchen?
https://www.forbes.com/sites/davidroth/2012/06/15/early-adopters-who-are-the-right-cooks-for-your-
kitchen/#308b2637e0a3
7
Minimum Viable Product: a guide.
http://www.startuplessonslearned.com/2009/08/minimum-viable-product-guide.html
8
The Disciplined Agile (DA) Framework. Defining MVP, MMF, MMP, and MMR.
http://www.disciplinedagiledelivery.com/defining-mvp/

functional sketch that early adopters can evaluate and their feedback will be essential for improving such
minimum product or pivoting if necessary.
Nowadays, getting faster hardware prototypes is easier and cheaper, due to the cheapening of: (1) a great
variety of hardware development kits (many of them based on Arduino)9; and (2) the 3D printing
technology10.
Stage 3: Getting an alpha version.
In this stage, a functional prototype is available but it has not been throw it at the market yet. In this case,
it is necessary to make clear what the market is. Probably, a reduced group of early adopters should be
selected for starting the tests, since there is a high probability of failures; therefore, it is interesting to
warn customers about these mistakes and create a good relation with them, to get feedback. Testers are
a very important piece of the process since they can support the startup when it enters the market.
Stage 4: Getting a beta version.
After information from product and business sides, including the data provided by early adopters, has
been collected, more clients could be included in the process. In order to do this, the industrial design
procedure should start. Such procedure uses techniques of mass production for manufacturing designed
products. The main characteristic of industrial design is design and manufacture processes are separated,
since the creative act of determining the product’s shape and characteristics is made before making many
copies of such product by using repetitive and often automated techniques.
The use of rapid prototyping technologies to experiment with designs and do Alpha/Beta testing (just as
if it is done with software), is a good strategy for moving fast and iterate.
In this stage, the target market and customers should be clearly defined; ensuring beta users are the same
as target customers, because this is a key point to maximize the learning process.
During this phase, it could be appropriate to charge users for participating as beta testers, since this is a
signal for knowing if they are willing to pay for the final product.
Stage 5: Improving the product.
In this stage, the product should have real customers. Now, it is the moment to solve the problems of
real users. Not only problems but also new demands, new use cases and new ways to find mistakes in
the product. As problems will happen, it is necessary to be ready to face such problems by iterating the
following cycle:
• Reacting: As fast as possible, by understanding what happened, even considering but not
recriminating the erroneous actions made by the user.
• Fixing: As fast as possible too, solving the specific problems for the customers.
• Improving: The design should be reviewed and properly corrected to make sure known mistakes
will not happen anymore by applying a “try-catch” solution.
9
IoT Hardware Guide. https://www.postscapes.com/internet-of-things-hardware/
10
Bulent Yusuf. 3D Printing Technology Guide. All 10 Types of 3D Printing Technology in 2018.
https://all3dp.com/1/types-of-3d-printers-3d-printing-technology/

Providing an appropriate support to the customers is crucial to maintain a good relationship with them.
During this process, multiple iterations will be needed by repeatedly replacing old versions with new
ones. Although this may seem inefficient, this is what progress should be, because if the final product is
designed without considering previous multiple revisions, and thousands of it are manufactured, there
exists a great risk of finding out nobody cares enough to use it.
Stage 6: The final product.
After validating the designed prototype, the users and customers, now it is the moment to make the final
product, putting the final touches on the design and moving from small-scale to large-scale
manufacturing. In this stage, it is time to think about packaging and writing the user manual. It is also
important to take into account the unboxing experience, since it could be considered as a very important
part in the users’ life cycle and for brand building. Summarizing, the time to focus on all the little details
that were not previously considered because the goal was to get a functional and fitted product has
come.
See Figure 2 to understand how the evolution of a product is from the prototype to the final design.
2.4. Considerations to take into account when creating hardware startups by

using the Lean method.
When entrepreneurs use the Lean method, they can substitute the Business Model Canvas (BMC) with the
Lean Canvas (LC) (see Figure 3). This canvas is an adaptation of the BMC, proposed by Ash Maurya11, where
some parts of the canvas are modified or directly renamed:
• Customers Segment: In this case, it is more important to define who the early adopters will be. It is
considered very dangerous to go directly to mass market.
Figure 2. Example of evolution of a product from a prototype to a final consumer device.
11
Ash Maurya. Running Lean: Iterate from Plan A to a Plan That Works (Lean Series). Ed. O’Reilly. 2012.

Figure 3. Lean Canvas.
• The “Customers Relationships” are transformed into “Unfair Advantage”: In general, when a startup
is being born, there is no a relation with the final customers or with the mass market; therefore, it is
better to speak about what advantages we are providing with respect to the competitors. Obviously,
knowing such advantage is only possible if we know who the customers and the early adopters could
be, what their problems and pains are and what value proposition for satisfying their needs we could
design.
• The “Key Partners” are transformed into “Problem”: When the startup is starting it is not the moment
to think about partners but knowing why the customers would pay. It is necessary to know the profile
of early adopter.
• The “Key Activities” are transformed into “Solution”: The future activities that the company should
carry out are not relevant in this moment. It is more important to think about how to solve the early
adopters’ problems.
• The “Key Resources” are transformed into “Key Metrics”: It is not the moment to decide what
resources will be used, but to select the best indicators and metrics to measure if the idea and the
solution are good is really essential. This should allow us to decide about going on or pivoting.
The rest of sections are maintained, both in the BMC and in the LC.
When the startup or the future company is focused on developing hardware, using the LC and following the
Agile method could be more difficult, due to the special characteristics that hardware design entails. In
addition, there are different risks that Lean Hardware startups should face in each stage:
• When “asking potential customers”: It could be more difficult to get early adopters because a
hardware startup is proposing a physical device as idea. What customers really need could be very
difficult to physically develop. Showing the description of the product and its functionality to early
adopters could be also be a hard process, mainly if the solution does not exist yet, and no prototype
is available.
• When “building a hardware minimum viable product”: Creating a very initial prototype for providing
it to early adopters is more expensive than designing a software product for beta testing. It is

necessary to create something physical by using some kind of technology, such as 3D printing, or
electronic development kits, among others. When entrepreneurs are not economically solvents it is
necessary to search for funding and, during this stage, it is particularly difficult. For example,
crowdfunding is often used as financing method, but there exists a real risk of being plagiarized by
bigger companies with enough resources, and if funding is not obtained, even the very first prototype
could not be launched.
• When repeating the cycle of obtaining alpha and beta versions: Problems related to hardware
development and firmware implementation often happen. It is necessary to acquire physical
components; therefore, entrepreneurs are dependent on the companies that supplies such
components. If selected components are not properly working or have been erroneously selected,
the cycle could consume too much time and money. However, cycles in the Lean method should be
as short and cheap as possible. Moreover, pivoting is harder when hardware is developed.
• When “improving the product and getting the final product”: More bureaucratic aspects should be
considered, since depending on the region of the world, it is necessary to satisfy certain requirements
and to comply with current regulations.
Summarizing, risks for Lean Hardware startups are similar to those of other startups; however, working with
physical device adds more difficulties, mainly related to funding and complying regulation.
2.5. Financing hardware startups.

A hardware startup follows a set of differentiated set of steps during its lifecycle, see Figure 4, which usually
starts with the concept or idea. If the concept fails, everything fails, therefore, it is very important to track
the stages mentioned in Section 2.3 to get a successful result. But one of the main problems hardware
startups should face is related to financing. Capital could come from many sources12, but it is important to
note that the economic needs vary according to the stage, see Table 1, where MFP is Minimum Functional
Prototype, CFP is Complete Functional Prototype, DM is Design for Manufacture and FFR is First Factory Run.
2.1. Playing a game to test how participants face the hardware development
process
In order to encourage collaboration among the participants and test how they face the hardware
development process, a game is played.
The game starts with the participants splitting into teams with five people as maximum. Each team has 5
minutes to share personal information to each other and to define a name for the team. After this brief
introduction, the conductor of the workshop shows the game rules. Each team will play a sort of role game,
where a specific situation is explained. In particular, an idea about a possible hardware product will be
presented. For example, one idea could be related to the development of an automatic pet feeder. Such
feeder could be as complex as wanted. It could actually include a water tank and a ball thrower. Moreover,
the device could be connected to a smartphone in order to get different functionalities. The role game would
start with the first steps for developing the device. In particular, the scenario of having the idea about the
product could be considered as the first stage (stage 0), of the process of a hardware product development,
which could be coincident with the creation of a hardware startup. In this stage, there only exists the idea.
12
AMA Session with Jerry Yang. Startup Scaleup. https://youtu.be/gRAoviv5MIY

Figure 4. Lifecycle for a hardware startup.
Table 1. Summary of funding needs according to stages in the lifecycle for a hardware startup.
Stage What is it being done? Tools Financing needs Funding
Exploration of the idea Difficult. Investors
Interviews, surveys,
Concept feasibility and market Close to zero. needs to see
etc.
demand. something.
Moderately
3D printing,
difficult. Investors
Obtaining a very first version development kits,
MFP Depends on the product. could see the
of a functional prototype. mechanical
product as the final
components.
version.
Easier. Investors
could see a product
Modifying the MFP and Depends on the product. Now it is
A third-party for that looks well.
getting something that looks necessary to produce more than
CFP designing a better Angels investors.
more attractive: look and one. Cash is needed to face the
look. Family and friends.
ergonomics. production. (1)
Crowdfunding .
Grants. Awards.
Variable, but probably < 50k €.
A factory for doing a
It is necessary to buy components,
Growing from hardware minimum set of
3d printing, certifications, legal 13
DM maker to become a hardware copies of the product Crowdfunding .
costs, legal protection, patents and
entrepreneur. with a professional
utility models, factory selection,
appearance.
molds, etc.
A factory for
Crowdfunding. Pre-
replicating the
orders. Angel
Turning DFM prototype into prototype and getting Variable. Money to pay for tooling
FFR investors.
many identical products. a massive set of and first run.
Accelerators.
commercial units of
Venture capitalists.
the product.
Scaling. It is necessary to Third-party for
Investors. Venture
Retail demonstrate the demand of production and other Variable.
capital.
the product. tasks.
(1)
Crowdfunding could be a problematic financing method because developers are exposed to delays and competition, since the time
gap between the campaign and delivery is usually long.
From this step, the teams should take decisions about how to continue the story, according to different paths,
expressed through cards that represents different stages (see Figure 5). The person leading the workshop will
know the graph of the game. This means that he or she knows what happens and what could happen when
the participants select different options through the game and how to go from one stage to another, since,
13
AMA Session with Dan Maron. Startup Scaleup. https://youtu.be/u89_TX8V43Y

as the game progresses, teams will select different cards that conduct them to different scenarios or game
stages. Obviously, according to the particular current stage represented by the card and the game graph,
they will be only capable of selecting one of a reduced set of cards proposed by the conductor (which knows
such graph, as mentioned before). In addition, in a specific stage, each team will be able to use tools to solve
a specific problem that help them to choose the best option to go from one stage to another. Furthermore,
as the game evolves, participants will consume money and time. They will have an initial amount of money
available, and during the game, they will be also capable of getting more funding for going from one stage to
another. Evolving through the stages will also consume time. So each team could reach the goal (selling the
product), in different periods of time, earlier or later. However, consuming more or less time for reaching
such goal will not mean to get more or less success. If participants track the path with stages that follows the
lean hardware paradigm, it will be more probable to get a successful result, since as they go through the
stages in the graph, they will obtain points. Such points will be used at the end of the game, in the last stage,
so that if they get a higher number of points, the probability of getting a successful result will be also higher.
This fact will be discussed in section 2.2, where participants will be able to analyze the decisions taken during
the game and their consequences, since the purpose of this task is to see how teams are capable of solving
the problems that arise when a hardware prototype is developed, and to test if teams usually select steps
close to the Lean Hardware paradigm. After ending the game and discussing the results, they should think
about if the Lean Hardware methodology really drives to the success or not and to defend their opinions by
contributing logical arguments.
2.1.1 How to moderate the game?
As mentioned before, the moderator or conductor of the workshop is responsible to take the teams from
one stage to another. Figure 6 shows the complete graph proposed for the game that is only completely
known by the moderator. He or she is responsible of knowing how many points are assigned when the
participants go from one stage to another, how much time using a tool consumes, how much carrying out a
specific task with a specific tool costs and how to calculate the probability of a random result, according to
certain parameters related to the path tracked by the participants. For doing this, the moderator has a set of
resources: (1) the complete graph in Figure 6; (2) the list of tools with their cost (see Table 2); (3) the different
financing methods and how to calculate if funding is obtained or not; (4) the annotations about how much
time and money are consumed and points are obtained when going through the stages of the graph (see
Figure 7 and Figure 8); and (5) a pair of dices that could be thrown for calculating the result of a random
operation. Several lists will describe how to assign a final result according to the random result obtained, the
current stage and the path tracked by the team through the graph (see Table 3, Table 4 and Table 5).
Each stage is numbered and it will be represented by a card that defines the scenario, the possible tools that
participants could use and if it is allowed to get funding by using the appropriate means (see Figure 5). The
general shape of a card is explained in Figure 9. Note that, there are fixed elements in all the cards: (i) a section
for writing down data about the team and its progress during the game; (ii) a section with the title of the
stage; (iii) a section with the description of the stage; and (iv) the number of the stage. In addition, it is
possible to find optional elements: (i) the tools that it is possible to use; (ii) if it is possible to get external
funding during this stage; and (iii) the next stage to go to (in this case, there are three kind of cards: those
that does not specify the next number, because the gamers should decide the next stage according the
choices provided by the moderator; those that specify a result of a random operation –throwing the dices–,
if true go to V stage, otherwise, go to F stage; and, finally, those that specify the number of the next stage,
because it is not possible to choose).

Figure 5. Collection of cards defining the game.

Figure 5. (Continue).
When the game progresses from one stage to another, the moderator will take into account the path that
the participants have followed through the graph and he or she will provide to each team a set of possible
cards (representing stages), that they can select. As aforementioned, the selected choices will be an influence
for spending money and time, getting funding or modifying the result (according to a probability that depends
on the situation of each team in the game), when a random operation is performed.
The random processes and operations in the game will be solved by throwing a pair of dices. They are the
following:
• Validating actions: The result of the operations could be “False” or “True”. When a validation action
involves to repeat a cycle in the graph, the number of repetitions will be bounded to 3. As number
of cycle is higher, the probability of getting a “True” result will be also higher. Defined annotations in
a list will show to the moderator how to interpret the result of throwing the dices in each case, by
considering the path tracked by each team through the graph of the game.
• Calculating the cost of using a tool: The cost will be in an interval [min, max]. When throwing the
dices, the result will allow the moderator to select the cost in the interval according to a set of defined
annotations in a list only known by the moderator.
• Obtaining funding: The result of the operation will depend on the type of funding method and the
stage in the graph. Defined annotations in a list will help the moderator to interpret the result.

Figure 6. Graph that defines the stages of the game that is only known by the moderator.

Figure 6 (Continue).

Figure 7. Points assignment.


Figure 8. Money and time assignment.


Figure 9. General shape of the cards.
Table 2. List of values for calculating the cost of using a tool or staying in a stage.
Tool Stage Random result from the pair of dices. Spent money
2 1000
2000
All 𝑣 = [3,11] 1000 + 𝑣 ∗
11
12 3000
2 0
100
All 𝑣 = [3,11] 𝑣∗
11
12 100
2 50
450
All 𝑣 = [3,11] 50 + 𝑣 ∗
11
12 500
2 5000
5000
All 𝑣 = [3,11] 5000 + 𝑣 ∗
11
12 10000
2 5000
50000
All 𝑣 = [3,11] 5000 + 𝑣 ∗
11
12 50000
2 0
20000
All 𝑣 = [3,11] 𝑣∗
11
12 20000
2 50
950
18 𝑣 = [3,11] 50 + 𝑣 ∗
11
12 1000

Table 3. List of assignments for applying a result when validation is needed for going from one stage to another.
Time Result obtained after throwing the pair of dices. Result to apply
First one Odd numbers False
Second one V>8 False
Third one Never False
First one Even numbers True
Second one V <=8 True
Third one Always True
Table 4. Points assignment and its relation with random result obtained from throwing the dices at the end of the
game, for deciding if product is or not successful.
Points Result obtained after throwing the pair of dices. Result to apply
<150 <3 Success
[150-169) <4 Success
[170-189) <5 Success
[190-199) <6 Success
[200-299) <7 Success
[300-329) <8 Success
[330-349) <9 Success
[350-379) <10 Success
[380-399) <11 Success
>=400 <12 Success
Table 5. Annotations about if funding is or not earned according to the result obtained after throwing the dices and
the current stage.
Stage Result obtained after throwing the pair of dices. Kind of funding Success
<4 Crowdfunding Yes
<4 Business angels Yes
2
<9 Bank Yes
<4 Accelerator Yes
<4 Crowdfunding Yes
3
<9 Bank Yes
<4 Accelerator Yes
<5 Crowdfunding Yes
4
<10 Bank Yes
<9 Accelerator Yes
6 <8 Crowdfunding Yes
<12 Bank Yes
<8 Accelerator Yes
>=8 <10 Crowdfunding Yes
Always Bank Yes
<10 Accelerator Yes

2.1.2 How to play?
Participants will play the game with the purpose of showing their skills in a simulation of creating a hardware
startup that tries to reach the market with a novel hardware product; therefore, they will assume the role of
the entrepreneurs that work in the creation of the mentioned startup through the development of the
product, from having the idea until massively manufacturing the product.
In this section, the instructions that participants should follow for playing the game are shown.
• Organization (5 minutes):
ü Participants should form teams with 5 members as maximum.

ü Each team will be named at the beginning, and one of the participants will be chosen as spokesman
in the group.
• Materials: Each team has a collection of tools to play:

ü Money: At the beginning, it is assumed that 50000 € are available for starting the process.
ü Calendar: Years 2018, 2019 and 2020 are available. The maximum time for manufacturing the
product in the game will be 3 years.
• Rules:
The moderator is responsible of telling the game dynamic. Each team is considered as a group of
entrepreneurs who want to develop a new hardware product. In particular, a novel pet feeder that
incorporates some extra features in addition to allow a pet to be automatically fed. Such features include:
water tank and font to allow the pet to drink clean and fresh water and a device to store a ball that could be
automatically thrown to get the pet playing. The device should be connected to Internet using a Wi-Fi
connection and an application in a smartphone should allow the owner to remotely control the device.
Playing the game is navigating through a story with different stages that are represented by cards. Such cards
are given to each team during the game, and the collection of them defines a specific story for each team
about what steps they have followed in order to manufacture the product from the idea.
The game is organized as a set of rounds, where each team should go from one stage to another by selecting
a new card that defines a new stage. The number of cards that should be selected in each round depends on
the previously chosen cards. Therefore, as different paths could drive the participants from the beginning to
the end of the game, different stories will be generated.
During the game, as teams move from one stage to another, money and time is consumed and points are
earned. The number of points is calculated according to the selected card, and only the moderator knows, a
priori, how many points will be obtained by selecting a specific card that allows the team to go to a new
stage. According to this, the story, which could be different for each team, depending on the path followed
through the set of stages, will define the number of points obtained when the final stage is reached
represented by the card showing that the entrepreneurs are massively manufacturing the product.
Points are very important, since the more points obtained, the lower the possibility of failure at the end of
the game. When all the cards have been chosen, and all the teams have built their stories, the moderator will
calculate if the result is successful or not using a pair of dices, whose result will depend on the amount of
accumulated points. This means that the result of the game depends on not only the luck, but the good
choices selected during the game.
Summarizing:

• Each team starts in stage 0.
• The game is based on playing rounds. During each round:
ü Teams have to select a new card (in general, between several cards), that will drive them to another
stage represented by such card. Selectable cards are provided by the moderator. Each team should
analyze during a short time (2 or 3 minutes), what card will be chosen and, once it is selected, the
spokesman will briefly explain the reason why they have done such selection to the audience.
ü Teams could decide to obtain funding (only they can do it a limited number of times, in particular, 3
times for all the rounds). If they lose too much money, they could access to Bank or Friends & Fool &
Family funding. In this case, the number of times is not bounded. The financing methods will be
properly explained by the moderator. If a team needs funding, the spokesman should briefly explain
the reason why they need it to the audience (during 2 minutes as maximum).
ü Teams should use tools in each round for solving problems. For example, if they are in a stage, where
the product is being prototyped, they could need to use a prototyping kit. Then. they should pay
money for using the tool. The amount of money earned is obtained after the moderator throwing a
pair of dices. The result is interpreted by the moderator according to the obtained number, the
selected tool and a set of internal rules that only the moderator knows. Again, the spokesman should
briefly explain why they select a specific tool (during 2 minutes as maximum).
ü The number of points and the time and money consumed are published by the moderator, and the
team’s spokesman is responsible of annotating such information.
Example of two rounds of the game for two teams.
Assume that two teams (A and B) are in the stages 1 and 2, respectively, after playing the first round, because
the A team decided to choose the card 2 and the B team decided to select the card 1 while they were in the
initial stage 0.
ü What the A team has to do:
They have to explain why they have selected such choice, and they have to explain how they would define
the requirements. Furthermore, they would also decide if they want to get funding (or not). If they
choose to get funding, the moderator will throw the pair of dices and he or she will apply the result of
Table, according the type of funding selected. Going through this stage consumes time and money. In
particular, it consumes 0 euros, and 20 days. Moreover, the team earns 10 points as the consequence of
having selected this option.
ü What the B team has to do:
As previously explained, they have to explain the taken decision. In this case, they have to ask possible
customers, so, they have to explain how to do it. In particular, they can use the tools (a) and (b), that is,
interviews and forms in Internet. According to the used tools, they will consume time and money. For
example, if they decide to use the tool (a) (interviews), they will spend 10 days and the cost will be
randomly calculated by the moderator by assigning an amount of money between 1000 and 3000 euros,
according to the result of throwing a pair of dices, and matching the obtained number with the amount
of money by using Table. Moreover, as this stage involves a result related to the opinion of the potential
customers, the moderator will calculate the result of this query by throwing a pair of dices, whose result
will be interpreted by considering Table. A False result involves going back to stage 0. This means that
the idea should be reviewed. A True result involves going to the next stage numbered as 3. During this

process the team consumes time and money and earns points. For the false result, the moderator will
ask the gamers if they want to ask again or they prefer to continue with the next stage 3. If the
participants decide to ask again, the procedure is repeated. The maximum number of times that a cycle
would be repeated is 3. In this example, the team asks for a second time, consuming time and money
again, and when the moderator throws the dices again, the result is true. Therefore, the time consumed
is 20 days and the spent money is 2000. Note that, the second time that the moderator throws the dices,
the probability of obtaining a positive result is greater according to Table.
During the second round, A team goes to stage 4, and B team goes to stage 3.
ü What the A team has to do:
They have to explain how they would define the architecture of the system by considering all the initial
requirements (the pet feeder has all the proposed features). It is also necessary to select what
components it is necessary to include. In this case, they should use the tool (c), that means, a
development kit. The team should also explain what they know about development kits, and what they
think about which developer tools are more suitable in this stage. The time consumed is 20 days and they
could spend between 50 and 500 euros if they buy a development kit. The price is calculated by the
moderator after throwing a pair of dices and matching the obtained result with the annotations in Table.
After this stage, the A team has consumed 40 days in total, and 450 euros, for example.
ü What the B team has to do:

They have to define the minimum requirements of the system and explain why the decide to select such
requirements. For example, they decide to design a simple pet feeder (without any other functionality),
but controlled by a smartphone application. Here, the team could ask for funding. In particular, they
decide to use the crowdfunding method. The moderator throws the pair of dice for determining if the
crowdfunding process has been successful and how much money they have obtained in this stage. The
procedure is matching the number obtained with the annotations in Table. For example, the result of the
crowdfunding process is 1000 euros earned. Moreover, the time consumed is 10 days in this particular
stage. Therefore, the total days consumed are 30 and they have earned 550 euros in total.
2.2. Discussion.
This section proposes a participative discussion where each participant will expose an opinion about the
result of the game (both, as member of a team, and personally) and later, everyone will tell what has learned
about the lean hardware methodology, and if this method would be considered suitable for solving an own
specific problem.
Moreover, in this section, several issues will be addressed. In particular, those related with the analysis of
existing startups or companies that have or have not been succeeded. In addition, other important aspects
related to hardware development will be also taken into account, for example, CE marking or patents, among
others.
These issues are explained in the following subsections.

2.2.1 Successes and failures in hardware startups and companies.
In this subsection, Table 6 shows several examples about hardware startups and companies that have and
have not been succeeded.
Table 6. List of companies and startups.

Name Startup or company History Lean?
Primesense Startup It developed the first RGBd camera. It got No information
patents. It will be bought by Apple.
Apple Big company The first personal computer. Many other It could be probably
novel devices. considered as yes with
some recent products.
Habana Labs Startup A fabless semiconductor company Probably yes.
located in Tel-Aviv, Israel and San Jose,
California, employing over 120 people
worldwide. The company set out to
develop AI processors from the ground
up, optimized for the specific needs of
training deep neural networks and for
inference deployment in production
environments
Drone Hopper Startup Design, manufacture and operation of Probably yes. Obtained
(Madrid, Spain) heavy-duty, multi-rotor unmanned funding from ENISA for
drones. Applications on aerial support for young entrepreneurs.
fighting wildfires, pest control and crop H2020 SME Instrument
management. Phase I Champion.
Currently, Flight stability
tests for early Wild Hopper
prototype.
DecaWave Startup Working within the IoT sector, DecaWave Probably yes. It was
creates wireless devices – which now deemed worthy of a €2.5m
total more than 1m – that can be located investment from
indoors to an accuracy of 10cm. STMicroelectronics in April
2017. Having raised €30m
in funding to date, the
start-up now has offices in
France, China and South
Korea.
STAYmyway Startup Access control and management system Yes. The startup was
(Lockup) for hotels and touristic apartments. initially incubated in Cloud
Murcia, Spain. Incubator Hub in Murcia,
Spain.
Pebble Startup It was dedicated to the development of No information. The most
Technology the Pebble smartwatch. The company successful crowdfunding.
Corporation. under its former name, Allerta, failed to On May 10, 2012. Maybe it
attract traditional investors. Then, the suffered a lack of interest
company (now named Pebble), pursued after initial crowdfund.
crowdfunding in April 2012.
Jawbone Startup Wearable device maker. Due to many No information.
problems in its devices, Jawbone had to
offer refunds to customers, and delays
were common in next realeses.
Its slow slide drove the company to its
failure, and it is a case study of how even
the most promising leaders in consumer
hardware can ultimately lose the long
game.

2.2.2 CE Marking.
CE Marking could be defined as a conformity scheme that allows for the free flow of products between
countries in the European Economic Area. Manufacturers are responsible of demonstrating compliance with
whatever rules applying to their product in Europe. CE Marking shows that the manufacturer has correctly
carried out the procedure and the product is compliant14.
CE Marking applies to the following products, among others:
• Electrical and electronic products (household appliances, lighting equipment, information

technology equipment, etc.).
• Machines (drilling machine, jigsaw, milling machine, tunnelling machine, etc.).
• Healthcare products (patient monitoring monitor, tomography system, orthopaedics, etc.).
• Products that use gas as fuel (gas stoves, gas boilers, etc.).
• Toys.
In the field of IoTs, three directives15 are good candidates to be analyzed over a specific product. These
directives are shown in Table 7.
These directives include many tests that they should be applied over the product under test. Specifically, the
following stages should be carried out for obtaining the CE Marking16:
• Identify applicable directives17.

• Check requirements according to European Regulation and standards.
• Identify if you need Notified organization.
• Test product and verify compliance.
• Establish technical documentation.
• Put CE marking issue by an EU Declaration of Conformity.
Table 7. New European directives for CE Marking.
New European directives Previous directive New directive Publication date Commencement date
Electromagnetic compatibility 2004/108/EU 2004/30/EU 2014/02/26 2016/04/20
Low Voltage Directive 2006/95/CE 2014/35/EU 2014/02/26 2016/04/20
Radio electric devices 1995/5/CE (R&TTE) 2014/53/EU 2014/02/26 2016/06/13
Exposure of workers to the risks

2004/40/CE 2013/35/EU 2013/06/26 2016/07/01
derived from magnetic fields
14
The 'Blue Guide' on the implementation of EU product rules 2016.
https://ec.europa.eu/docsroom/documents/18027/attachments/1/translations/en/renditions/native
15
Exporting to Europe and CE Marking. http://www.ce-mark.com/cedoc.pdf
16
Instructions for manufactures (1):
https://ec.europa.eu/growth/single-market/goods/building-blocks/conformity-assessment_en
17
Instructions for manufacturers (2): https://ec.europa.eu/growth/single-market/ce-marking/manufacturers_en

2.2.3 Leading the discussion: considerations to take into account.
The moderator is responsible of leading the discussion stage of the workshop and dispersion of ideas should
be avoided. Therefore, some crucial aspects should be defined:
• Participants should reflect on the decisions they made during the game, and give their opinion about
if the obtained result was the expected one. The time to this will not exceed 15 minutes. Everyone
could spend 1 minute.
• Each participant should reflect about how to introduce the lean hardware methodology in him/her
business model. Everyone could spend 2 minutes for telling what product is developing or wants to
develop, and other 2 minutes to speak about how to use the lean hardware paradigm for designing
or modifying the product.
• Participants will be invited to give pieces of advice to the rest about how they think it is possible to
apply Lean Hardware methods to their business. Everyone could spend 2 minutes in each round to
discuss about it.
• Participants will explain how they think they could include CE marking, patents, etc., during the lean
hardware process for their own products and if it is necessary for such products. Everyone could
spend 3 minutes as maximum in each round.
• Participants will give their opinion about what they think about the success or failure of known
companies, and if they think that Lean Hardware methodology was used or not.
Summarizing, they should answer the following questions:
• If they think that they will use the Lean Hardware methodology in their own businesses: Advantages
and drawbacks.
• If the Lean Hardware methodology could match well for designing their products. Are they currently
using the traditional paradigm?
• If they know how to get funding according to the design stage. Do they agree with the information
about when to get funding proposed in the workshop?
• If they need to include CE marking, patents or other bureaucratic procedures while they are
developing or improving their own products.
Answering these important questions is aligned with the main goal of this workshop, since it is desired
participants to learn about the main aspects of Lean Hardware paradigm, but such learning process should
be carried out with critical spirit and open mind.
2.3. Conclusions
The workshop ends with the conclusions, which are:
The Lean Hardware paradigm could improve the hardware development process for hardware startups. In
fact, during the workshop, the Lean Hardware methodology has been explained. Advantages and drawbacks
have been shown and a comparison with the traditional design paradigm has been done. Participants should
have learned about the agile cycle (see Figure 1), and how to apply it in hardware design, by considering the
advantages, drawbacks and risks.
Participants have tested their knowledge about Lean hardware paradigm by playing a game. In fact, the
participants have investigated how to carry out an assumption of design and development of a product
through such game, where they assume the role of entrepreneurs of a startup that want to manufacture a

smart pet feeder. The more relevant question here is discussing the results of the game: the participants
critically have been able to analyze the results obtained during the game and explain if they agree with such
results.
Several issues related to hardware development have been taken into account, such as, those aspects related
to bureaucratic procedures, CE marked or funding.
Different tools for solving problems related to hardware design and funding methods have been also
explained.
Summarizing, the Lean Hardware method is based on the Lean methodology for creating startups, and it
could be suitable for hardware development. In particular, customer-focused, cycle-shortening, error/waste-
reducing techniques will help hardware developers, by substituting the traditional waterfall approach with a
set of fast attempts (named sprints), with the four sequential stages: Discover, Design, Develop, Test, where
the feedback of potential customers is in the heart of the process.
The participants are also introduced with the upcoming events in their cities. This concludes the Lean
Hardware workshop.
Internet resources for additional learning:
• List of resources
ü https://techcrunch.com/tag/lean-hardware/
ü https://hax.co/lean-hardware/financing-lean-hardware/
ü http://www.berkeleysg.com/3-best-practices-for-lean-hardware-development/
ü http://tech.eu/features/385/lean-hardware-startups-europe/ (The 50 most exciting lean
hardware startups in Europe)
ü https://www.researchgate.net/profile/Laanti_Maarit/publication/308869388_Piloting_Lea
n-Agile_Hardware_Development/links/5a79d8e3aca2722e4df4e521/Piloting-Lean-Agile-
Hardware-Development.pdf?origin=publication_detail (Paper: Piloting Lean-Agile Hardware
Development)
ü https://www.agilealliance.org/resources/sessions/experiences-from-lean-agile-hardware-
development/
ü https://es.slideshare.net/haxco/building-leanhardwarestartups
ü https://hennyportman.wordpress.com/2016/09/21/book-review-the-lean-machine/
(Analysing “The lean machine. How Harley-Davidson drove top-line growth and profitability
with revolutionary lean product development” by Dantar P. Oosterwal).
ü https://www.cytalytic.com/single-post/2018/03/03/Agile-or-Lean-for-hardware-
development-part-1-of-2
ü https://dspace.mit.edu/bitstream/handle/1721.1/1661/95_01.pdf?sequence=1 REPORT --
LEAN 95-01 Toward Lean Hardware/Software System Development: Evaluation of Selected
Complex Electronic System Development Methodologies. 1995.
ü https://www.altitudeinc.com/mvp-hardware/
ü https://www.quora.com/What-is-the-best-way-to-apply-Lean-Startup-principles-to-
hardware-development
ü https://dtusciencepark.dk/can-hardware-startups-be-lean/
ü https://gigaom.com/2013/04/05/how-apple-makes-gadgets/

Attachment 0

Uploaded by

Copyright:

Available Formats

Attachment 0

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Attachment 0

Uploaded by

Copyright:

Available Formats

Ref.

Document Type Contract Deliverable

Document & WP No. D2.4 WP 2

Document Title Lean Hardware

Release date 30/11/2018

This project has received funding from the European

Copyright © MERLIN Consortium

Document Control Page

Title Lean Hardware

Description Description of the content used in the workshops – Lean Hardware.

Review status Action Person/Partner Date

Approved by Peer Panel

Version Date Modified by Comments

1.0 01/09/2018 Nieves Pavón Pulido First version of the deliverable.

2.0 30/11/2018 Nieves Pavón Pulido Final version of the deliverable.

Copyright © MERLIN Consortium Page 3 of 33

Copyright © MERLIN Consortium Page 4 of 33

Among the planned activities, it is worth highlighting the following:

• Organisation of 45 practical workshops covering state-of-the-art innovation and entrepreneurship

Copyright © MERLIN Consortium Page 5 of 33

• Section 2 presents the content of the Lean Hardware workshop.

Copyright © MERLIN Consortium Page 6 of 33

2. Workshop “Lean Startup”

2.1. General information about the workshop

2.2. Introduction to the workshop

Copyright © MERLIN Consortium Page 7 of 33

The general information about the workshop is provided:

Lean Hardware workshop content is divided into several distinctive parts:

2.3. Intro – waterfall paradigm vs Lean Hardware paradigm

Copyright © MERLIN Consortium Page 8 of 33

Figure 1. Comparing Agile and Waterfall methods

Copyright © MERLIN Consortium Page 9 of 33

Stage 1: Ask potential customers.

Stage 2: Build a hardware minimum viable product (HMVP).

Copyright © MERLIN Consortium Page 10 of 33

Stage 3: Getting an alpha version.

Stage 4: Getting a beta version.

Stage 5: Improving the product.

Copyright © MERLIN Consortium Page 11 of 33

Stage 6: The final product.

2.4. Considerations to take into account when creating hardware startups by

Copyright © MERLIN Consortium Page 12 of 33

Copyright © MERLIN Consortium Page 13 of 33

2.5. Financing hardware startups.

Copyright © MERLIN Consortium Page 14 of 33

Copyright © MERLIN Consortium Page 15 of 33

2.1.1 How to moderate the game?

Copyright © MERLIN Consortium Page 16 of 33

Copyright © MERLIN Consortium Page 17 of 33

Copyright © MERLIN Consortium Page 18 of 33

Copyright © MERLIN Consortium Page 19 of 33

Copyright © MERLIN Consortium Page 20 of 33

Copyright © MERLIN Consortium Page 21 of 33

Copyright © MERLIN Consortium Page 22 of 33

Copyright © MERLIN Consortium Page 23 of 33

Copyright © MERLIN Consortium Page 24 of 33

Copyright © MERLIN Consortium Page 25 of 33

Copyright © MERLIN Consortium Page 26 of 33

2.1.2 How to play?