in   Software Development   Product Development   Prototyping   Software   Hardware

Phase 2. Proof of concept. Software & hardware development process

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

  1. 1. We choose to go to an MVP. 7 phases of the software and hardware development process inspired by NASA
  2. 2. Phase 1. Research. Software & hardware development process

All engines running. Fasten your seatbelts and liftoff!

nasa-OLlj17tUZnU-unsplash

Photo by NASA on Unsplash

Being wrong is right

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

What is proof of concept 

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. 

Theory vs. practice

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. 

Building or changing a product

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.

What is the effect of proof of concept 

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".

Proof of concept is all about going in the right direction

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.

Collecting data to move forward

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. 

The examples of proof of concept

I can give some examples of a well-carried proof of concept process.

  1. 1. Shazam music fingerprinting algorithm. By means of a short piece of music, the application is able to match that with a song in a database and provide the artist and title of the song he is currently hearing.
  2. 2. Elvie Pump is using a piezo air-pump for creating suction. The pump has been innovatively used, which is noiseless and can be pumped smoothly even at work.
  3. 3. Proof of concept for iPhone and iPad was a multitouch screen technology. Thanks to the construction of such a screen and the possibility of its use, work began on the rest of the device.

For some projects might be a research study on the accuracy of some market/phone available sensors or actuators.

What’s next 

After that phase you should have:

  1. - Technology feasibility, i.e. proof that we are technically able to meet the assumptions.
  2. - Testing report and data, i.e. no matter if the experiment was successful or not, we can collect data and use it at later stages and decide whether they are sufficient or need additional tests.
  3. - Physical proof (or model) or source code (or wireframe). After this phase, we remain with tangible proof whether it is a piece of code or hardware, something that can already be shown to an investor, for example.
  4. - Performance analysis. At this phase, you need to verify if the technical performance is sufficient (e.g. Shazam needs a few seconds to verify the song, but if it needed 3 minutes, it would not be so effective).
  5. - Key findings, depending on the project.

- - - - - - - - - 

In the next article, I’m going to write more about Phase 3. Prototype. 

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.

Read more about our Untitled Lab.

 
Bartek Hugo Trzciński

By

Head of Technology by day and software engineer by night. Recently solving more problems in business and mangement than in code - hard to tell which one is more fun. Local dev groups activist. Automotive enthusiast. Boosted Board shredding champ. The best companion to dance and to give you a ride.