Shots fired, shots fired! Actually, this topic is a common misconception with some clients that we have to navigate around so let’s delve into the differences between a Minimally Viable Product (MVP) and a production-ready product.
What is a Minimally Viable Product (MVP)?
A Minimally Viable Product (as defined by Wikipedia!) is a version of a product with just enough features to be usable by early customers who can then provide feedback for future product development. We think some clients overly focus on early customers, and not enough on future product development.
One more distinction we should make is the difference between software product development, and hardware product development. The processes in both developments may have the same nomenclature, but the approaches to that development can be pretty different.
One of the things that really makes us nervous is when we get an email that says ‘We already have an MVP (or worse yet, Proof-of-Concept), we just need a little help to get it into production’. At this point, alarm bells are ringing, the red lights are flashing and all of us are ducking under our desks.
Other than the rapid decent into hyperbole, we do want our clients to be fully educated about the process and it may or may not be something they were prepared for. We understand that they’ve spent time and money to build an MVP and think that ‘this is almost ready for production’. Spoiler alert, it’s probably not.
What do you mean it’s not ready?
Design-for-Manufacturability is one of our biggest value-added services to our clients. We’ve had numerous projects come through that require a lot of redesign and re-engineering to get to a production-ready database.
CAD Database: The database is not built parametrically, or with top down design in mind. Our engineering process builds all our databases using top down principles because we design with change in mind. If (or rather, when) features in a product changes, our database will update accordingly so we don’t need to manually propagate those changes on every part. This is a huge time (and cost) saver.
Tolerances: Tolerances that are so tight that they can’t be held in production. Tolerances that are so loose that parts don’t fit together well. Parts that are designed line-to-line. Interferences between parts in an assembly.
Hardware: Not consolidating hardware throughout the product drives us crazy. Please don’t use 10 different screw sizes when you can accomplish the same with 2 screw sizes!
Manufacturability: How many setups does this machined part have? How do you reduce the number of actions needed in the mold for this plastic part? Can we use 1 sheet metal bracket to accomplish the work of 3 brackets? How do we make these parts symmetrical so you don’t need a left and right version in production?
Assembly: We design with the production line team in mind. How easily/quickly does someone attach this PCB to this housing? Can we make this assembly process more efficient? Could this part be accidentally installed backwards/upside down, and if so, how do we avoid that? Can you fit a hand or screwdriver in there to attached that part??
How can Clandestine help?
The above are some of the questions we take into consideration during the development process. Unlike software development, we can’t release hardware in beta, the design has to be as close to perfect as possible. To modify or retool production parts is a very expensive process so we take a conservative approach before deeming something is ‘ready for production’.
We work to ensure that our process, and work required, is fully transparent to all our clients. The process may take longer and be more expensive than they had initially anticipated/budgeted for, so we hope this article will help better understand our approach.
If you are interested in solving some of your production design issues, please reach out to us at [email protected].
