Agility in hardware development
Minimum Viable Product (MVP) in manufacturing companies
Manufacturing companies are faced with a fundamental dilemma: agile methods promise faster learning, shorter development cycles and better products - but one of the central tools of agile product development, the minimum viable product (MVP), seems at first glance to be hardly compatible with the realities of mechanical engineering, electronics production or medical technology. However, the problem is not a contradiction in the method, but a misunderstanding of what an MVP means in the hardware context. Let us explain.
What is an MVP - and what isn't?
An MVP is not the first best, half-finished product. It is the smallest possible version of a product that is sufficient to test a specific hypothesis and generate real learning feedback.
In the software environment, the boundary is intuitive: an app can go live with just a few features. Different rules apply in the hardware and manufacturing world:
- Restrictive standards, approvals and safety requirements
- Production start-ups are expensive and time-consuming
- The customer often expects a "finished" product - not a test version
The decisive change of perspective: An MVP in this context is not a reduced product version, but a targeted learning tool - it can also be a process, a model or a simulation.
The MVP paradox in hardware development
The problem
In many industries such as mechanical engineering, medical technology, automotive and electronics:
- The product must be certified before it generates value
- Approvals (CE, TÜV, FDA, ISO) are time-consuming and costly
- A "half" product cannot be delivered.
The solution: MVP ≠ MVP of the end product
The MVP is shifting away from the product towards the learning process. Possible approaches:
- Feature MVP (reduced function): Only the core function is certified and delivered. Further modules/features follow in iterations. Prerequisite: modular product architecture.
- Market segment MVP: The full product is launched in a clearly defined, simpler market (less stringent requirements) before the main market is addressed.
- Service MVP: The product benefit is first provided as a manual service before the product exists. Goal: Validate willingness to pay and requirements.
- Simulation and digital MVP: Digital twins, CAD models or simulations are used to obtain customer feedback - long before the physical implementation.
- Wizard-of-Oz MVP: The product "works" from the customer's perspective, but is still operated internally manually or with tools. The degree of automation increases with the iterations.
MVP vs. prototype - what's the difference?
Both terms are often confused. The distinction between the two is particularly important for manufacturing companies:
MVP
An MVP is aimed at potential customers and users. The central question is not technical, but market-related: "Does anyone want it - and does it solve the actual problem?"
The result is market and user knowledge, which is why the MVP must make the core benefit clearly tangible, even if it is not yet technically mature.
→ An MVP proves to the market that something should be built
Prototype
A prototype differs from an MVP primarily in its purpose and target group . A prototype is used to test technical feasibility - it is aimed at internal engineers and answers the question: "Does it work?"
The result is technical knowledge, and the prototype can be very raw.
→ A prototype proves to the engineer that something can be built.
The customer does not accept an MVP - what now?
This is one of the most common challenges in the industrial environment. Industrial customers don't buy prototypes - they expect reliability, documentation and guarantees.
Understanding causes
- Risk aversion: one faulty component can bring an entire production line to a standstill
- Compliance: purchasing guidelines require certified suppliers
- Contract law: Warranty and liability issues
- Culture: "Never change a running system" mentality
Strategies for practice
1. identify partner customers (lead users)
Look specifically for customers who have an affinity for innovation and benefit from helping to shape it. Clear contract: special conditions in return for feedback.
2. test the MVP internally ;
If the market does not accept MVPs - test your own company as the first customer (pilot system, internal operation). Valid data from real operations, without external compliance risks.
3. change linguistic positioning ;
"MVP" is a concept internally - externally it means: pilot project, early access program, co-development partnership, research cooperation. The framework can change acceptance.
4. offer risk assumption ;
Free initial installation, a take-back guarantee or success-based pricing models significantly lower the customer's inhibition threshold.
5. expectation management right from the start ;
MVPs must be communicated as a process, not as a deficient product. What does the current version deliver? What will follow and when? Roadmap transparency creates trust.
Agile methods in the hardware context
Classic Scrum and Kanban are only suitable for physical products to a limited extent. The following approaches have proven successful:
Hardware sprints
Iterations are longer (4-12 weeks instead of 2), but the principle remains the same: At the end of each sprint there is a testable artifact - even if it is a functional model, a test setup or a validated simulation model.
Dual-Track Development
- Discovery track: validating hypotheses (cheap, fast, digital)
- Delivery track: Technical implementation (complex, relevant to certification)
Both tracks run in parallel - the discovery track is the "agile engine" that informs the expensive delivery phase.
Stage-Gate + Agile (Hybrid)
Stage gate processes remain in place for approvals and compliance. Work within the gates is agile. MVP thinking helps to filter out unnecessary features before a gate.
What exactly does an MVP in hardware development look like?
Example: New tool for assembly
- Step 1 - Paper MVP: sketches and a brief survey of the fitters → Which handle shape and weight are decisive?
- Step 2 - Foam model: A simple, non-functional model from the 3D printer or foam → Does the shape fit in the hand? Does the weight feel right?
- Step 3 - Functional prototype: First real model, tested internally in the workshop → Can it withstand the loads?
- Step 4 - Pilot deployment: 3-5 specimens go into real assembly operations for four weeks → How does the error rate and employee feedback change?
- Step 5 - Series production decision: Only now is a decision made on the basis of real usage data as to whether and how the tool will go into series production.
The special feature: At no point were unnecessary investments made in expensive materials or elaborate certifications - each stage only cost as much as was necessary to answer the next question.
Questions and answers about the MVP method
A Minimum Viable Product (MVP) is the smallest possible version of a product that is sufficient to test a hypothesis and enable real learning. An MVP in the production and hardware environment is a targeted learning tool - it can therefore also be a process, a model or a simulation.
The customer does not always have to be directly involved. An MVP can be tested internally (in-house production as a pilot environment), packaged as a service or as part of a clearly communicated co-development partnership. The decisive factor is the renaming and repositioning: away from "MVP" and towards "pilot project" or "research cooperation";
Each company decides for itself. An MVP is minimal enough if it makes exactly one clearly defined hypothesis testable - and no more. The question is not "What can we leave out?" but "What is the one thing we want to find out with this version?"
Yes - if you decouple them. Ideally, MVP iterations take place before or parallel to the certification phase, not afterwards. The aim is to go into the expensive certification with already validated requirements instead of certifying a product that has not yet been tested on the market.
An MVP that disproves a hypothesis is not a failure - it is the main purpose of the exercise. The early failure of an assumption prevents the wrong product from being developed further. Companies that have internalized this deliberately do not speak of "failure", but of "validated learning".
Agility in hardware development
Anyone developing physical products today is under massive time pressure. While European companies often have development cycles of several years, Asian competitors launch new products on the market at much shorter intervals. Agility in hardware development does not mean "copying software methods", but rather moving learning forward, reducing complexity and consistently aligning value streams with flow.
SAFe® for Hardware
Many organizations that develop hardware-dependent solutions face unique challenges when trying to implement Lean-Agile practices. while managing the complexity of large system designs.
Your contact partner:
Malte Foegen
