We tend to get blinded by our ideas, goals, and visions. We think we are infallible, or even omniscient. How to get out of this blindness "and do the other things not because they are easy (...)"? Let's start from being wrong. What? Yep. Being wrong is sometimes the best place to get started.
I invite you to the next article in the series about our software and hardware development process. This time I will describe in detail what is important in Phase 2. Proof of concept.
If you haven't read the previous articles in the series yet, I recommend starting with it to grab the context of our rapid prototyping approach and how does it look like Phase 1. Research:
All engines running. Fasten your seatbelts and liftoff!
Kathryn Shulz in her book "Being Wrong" talks about that. Like Coyote chasing the Road Runner in the cartoon, always at the end of the episode running off the cliff. All is good for him, and he's still running fine to the moment until he looks down.
We need to look often down to be sure we are not too far already. From the previous article, we know that we all have those amazing ideas. Ideas that keep us awake at night. Ideas that could be game-changers.
Once we explore them and have a basic understanding of how those potentially could be brought into life, we need to prove ourselves and our stakeholders or investors that it actually can be done.
Or otherwise, we wouldn't build a rocket if we didn't know that you could create an engine that could lift something into space. That engine is our “proof of concept” in the software and hardware development process.
Proof of concept is like the foundation of a house or a base for a rocket - if this is unstable, poorly calculated, all further construction may collapse. Proof of concept is a small sub-project and test that confirms the goal of the proposed project is viable. At this point, we examine whether it is possible to implement the most innovative part of our idea.
In the previous phase, we checked different ideas, we wondered in theory how something can be built, and we made a thesis. We are now starting technical tests and verifying what is feasible. This is the first engineering work on a hardware product, business or software testing on other solutions.
Testing is especially important when we are building a completely innovative solution that might be a game-changer on the market. The rapid prototyping process pays off.
If we are already working on a product, we do not implement the changes immediately, but first, we wonder if they make sense and how they fit into the current solution.
Proof of concept is often confused with a prototype, but they have a slightly different meaning and application. Proof of concept is used to check if something works and whether it can be technically created. A prototype is being built to help visualize how the entire product will work. Long story short, it’s "can be done" vs. "how it's done".
PoC is just a test to provide us with information, help refute or uphold some theses. Most likely, it will still not be used. A component may come in handy, but here the goal is to check that the idea itself works.
Proof of concept most likely will be completely scrapped and optimized. It doesn't have to be perfect, it’s good enough to show that the idea can be done and has the potential to keep on going in this direction.
At this phase, we collect information on how well the theoretical assumptions of Phase 1. Research can be implemented. We verify technical possibilities and solutions, e.g. if it was not possible to create the right pressure in a lactation pump such as Elvie Pump, and it would be necessary to pump 30 min for 1 ml of milk, then we know that this is not the most advantageous solution.
At Phase 2. Proof of Concept, we can have several ideas for checking theses and verification of solutions - we can then compare several proofs of concepts and choose the best one.
Proof of concept is finally used to quickly explore different approaches and possible solutions.
I can give some examples of a well-carried proof of concept process.
For some projects might be a research study on the accuracy of some market/phone available sensors or actuators.
After that phase you should have:
- - - - - - - - -
The next Phases:
- - - - - - - - - -
Thanks for reading so far and if you have any feedback or question, I will gladly answer them: bartek@untitledkingdom.com
Read more about our software & hardware prototyping process.