Proof of Concept, Prototype, MVP, and MMP in embedded software development
Increasingly, Lean and Agile processes, methods and tools are being adopted in the development of embedded devices and their software. Using these approaches puts an emphasis on continuous learning and applying it to projects.
Notions around Proof of Concept (PoC) and Prototypes have been in traditional approaches to embedded device development for some time. But the concepts of Minimum Viable Product (MVP) and Minimum Marketable Product (MMP) are newer.
The differences between these techniques can seem confusing at first. Their definitions are still evolving. The good news is that any of these techniques are useful if you want to build an embedded product that best meets the needs of its users and that you want to prove that it does so through testing and data gathering.
Agree definitions
If you and your design and development teams are going to use any of these techniques, it’s a good idea to agree on definitions which everyone understands. To help you, here’s what the teams here at Bluefruit treat as Proof of Concept, Prototype, MVP and MMP in their work on embedded products:
| Technique | What question are we trying to answer? | What this potentially looks like in embedded |
| Proof of Concept (PoC) | Can we solve a technical/operational challenge with this combination of hardware and software? | They are typically built using off-the-shelf hardware and software components.
Following a throwaway approach: build fast and cheap to answer the feasibility question with little regard for product fidelity or quality. The audience is internal: product design and delivery teams. A PoC is unlikely to be shared with broader product/project stakeholders and end users. |
| Prototype | Can we design and build a feature to meet user needs? | Normally built to test that the implementation of one or a small number of vertical product feature slices, intended for end users, are usable and meet end user needs.
Depending on the feature(s) being tested, the prototype may have a combination of rapidly assembled off-the-shelf hardware and software libraries, alongside more carefully designed and built bespoke components. Prototypes come with a level of fidelity that is sufficient to present prototyped feature(s) to:
|
| Minimum Viable Product (MVP) | Can we design and build a set of features to meet user needs and prove it with data? | Building MVPs is part of a Lean product development approach. As such, the ability to test product design and implementation by setting hypothesis around value delivered to users and using metrics to validate or invalidate these hypotheses is a vital aspect of the creation of an MVP.
Design and deliver the minimum amount of functionality, implemented at the minimum level of fidelity required to test a hypothesis around providing user value. Since we’re moving towards a released product, the build is largely made up of custom, bespoke hardware and software components. As with prototypes, the level of fidelity presented in the MVP should support presentation to project and product stakeholders and testing with end users. |
| Minimum Marketable Product (MMP) | Will users invest money and/or time in our product to meet their needs? | An MMP is a version of a product which is considered ready to market and sell to users. Here, the key hypothesis being tested is that users will invest time and/or money in the product to meet their user needs. The metric used to test this will generally be the number of conversions which could be in the form of product purchases, downloads, activations, updates, and so on.
Where an MVP may still be considered throwaway, an MMP is likely to be the first iteration of a product that is expected to be adopted and evolved in future versions. Product build quality and fidelity are enough that users will invest time and/or money. At this stage, hardware and software components are typically bespoke and designed and built with quality and maintainability in mind. |
These definitions are not definitive
To reiterate: none of the techniques described above are definitive. Neither are they stages in a process: you can pick and choose and adapt them to meet the needs of your product and your teams. What’s certain is the fact that both the users of your product and your teams will benefit from using some of these techniques in your approach. And that can reap financial rewards through happier users, better sales and reduced product development costs.
Quality and users first
Would you like to talk about taking a different approach to embedded software development? One that puts quality and users first? Bluefruit Software has the knowledge and skills you need to make this happen.
Did you know that we have a monthly newsletter?
If you’d like insights into software development, Lean-Agile practices, advances in technology and more to your inbox once a month—sign up today!
Find out more