Your First Product Version Should Be A Proof of Concept
Validate your product concept without wasting time and money in an idea nobody wants.
Ideas are abstract and hard to visualize by others. What you have in your mind might not be easy to translate into words or it might not make sense to other people.
That’s why we use prototypes of all sorts to try to show our ideas to others so they can visualize it and even try it.
However, we tend to go directly to our solution and start creating a prototype or sample with all of the functionalities that we have imagined. We want the most realistic representation of our product idea.
This leads inventors and entrepreneurs to dedicate endless hours and to spend significant amounts of money building a product that might not be interesting to users.
Wait, but that is why you start by building a prototype and not a production product in the first place, right?
Well, the mistake here is that only because is called a prototype doesn’t mean that it’s easy to make or cheap. In fact, oftentimes a prototype is quite costly and it takes a considerable amount of time to design and fabricate and the prototype design might not even be usable for the production product at all.
A lot of people use prototypes as a way to get the first sample of their product, which they haven’t validated with the users, and then they believe they can go straight to production.
Prototypes sometimes only represent isolated parts or functionalities of your product and not a whole functional product. So, I prefer to use the term “product versions” instead because it brings a sense of being a functional version in continuous evolution.
So, the very first product version that I would encourage everyone to start with when developing their product ideas is a Proof of Concept.
Proof of Concept
The term Proof of Concept is widely used in product development and often with different meanings. I will explain my own view and how I understand what a POC should be used for.
A POC is a product version that is constructed using existing products and off-the-shelf parts to make a version of the intended product quick, cheap, and relatively simple to design and fabricate with the intention to get feedback, gauge interest, understand technical specifications, or even get funding.
Another way to understand what a POC is, it’s by describing what it’s NOT:
- It’s not a Pretotype. Although very similar in concept, pretotypes’ mantra is “faking it before making it”. With pretotypes you don’t necessarily have a physical product and the functionality could be simulated. However, a POC aims for a physical version of the product with actual functionality.
- It’s not an experimental or partial prototype. Instead, we are trying to build a complete working version but just with the most valuable feature(s) we need to evaluate.
- It’s not an MVP. Although a POC is intended to include the most valuable features (or minimum viable if you want), it is not a version ready to be sold to final users.
In most cases, it will look different from the final product since it is somehow “borrowing” the design and construction of existing products and it will not include all of the features and functionalities, but just the most important or the highest priority ones.
The POC needs to prove that the most important functionality or unique value of the product works and it is desirable to users.
Benefits
The main benefits of starting with a POC are:
You can build the first version pretty quick, days or weeks instead of months.
Since you are adapting existing products or off-the-shelf components you don’t require to design the product from scratch. So, you will drastically reduce the design time if any. At the same time, you will reduce the fabrication time and overall costs.
You will validate your idea early
Because this first version can be made quickly, you can also get quick feedback from users. This will let you define priorities for your product development that you might not know otherwise at the start.
You can more accurately define your product requirements
Since you will be exploring and researching existing products and technologies, you will get a better understanding of how the product should work. You will be able to assess the limitations of current products so you can define requirements that are more realistic for your application.
How to develop a POC?
Now that you know why a POC is the best option to start with your product idea, I will explain to you how to start developing yours. These are the main steps:
- Research existing technologies
The secret of a good POC is to use some existing product or technology that is the most similar to your idea. Look at what is used for different applications or industries, you can often find a close candidate as long as it can be easily adapted to your needs.
2. Reuse as much as possible of the existing product
Once you find a product that is suitable, you should evaluate how much of it you can reuse. Not only from internal components but also enclosures and other external parts since the aesthetics are likely not the unique value that you want to test first.
3. Design the minimum number of components to adapt it to your application
In other words, minimize the design of custom parts since this is the part that will take longer and cost more. Contain the urge to start designing your own idea, focus on delivering the main value feature first.
4. Build the product version
Fabricate the custom parts that you have designed (hopefully not many) and assemble the product together. If done smartly, most of the assembly of the product will not need much work and only a few adjustments and “quick and dirty” fixes might be required to fit the custom parts and make it all work together.
5. Describe and test your assumptions
Before you start building your POC you should have a clear goal of what you want to achieve with this version. You will likely have a few assumptions that you want to test. Define a list of simple tests and include measurable targets so you can evaluate the performance of the POC.
6. Show to potential users to get feedback
One of the most important things to do with the POC is to show it to potential users. This is when you will get real and valuable feedback to understand the user's needs and if there is an interest in the product at all.
Feedback about general aesthetics or performance at this point is not important (just keep it for future versions), the focus is on the main functionality. Are you building something that solves users' needs or problems? How well is doing that? What are other elements that will increase the unique value of the product?
7. Review user and technical feedback and elaborate your product requirements
Once you have performed the technical tests, you will have an idea of what are the limitations of the product and some other considerations for the product development. Use both the technical feedback from the POC tests and the users to elaborate your product requirements in more detail
Instead of just guessing, now you have real data that will help you create an accurate brief for your product development.
Build smartly
It is always a good strategy to go step by step, validating assumptions and readjusting when necessary. Don’t get blinded by trying to get the first perfect prototype of your idea. You will have to iterate a few times, believe me on this, so build smartly.
The quicker (and cheaper) you can build your product versions with the information you have at that point, the quicker you will know the direction for the next version.
Product versions or prototypes are a means not the goal.
(Start Building Your Physical Product With Our Free Email Course)
Abilista guides innovators to develop their product ideas from concept, prototyping and all the way to manufacturing following our own step by step framework. We are already helping many entrepreneurs and startups to build their ideas by giving them access to simple and agile tools and expertise on-demand.
If you want to read more stories like this one visit our publication page
