8 things you need to know about PoC (Proof of Concept)

In mechanical engineering, PoC (“Proof of Concept”) is a critical part of the design process. The premise is extremely simple: a part or assembly must perform a function, so a basic physical model is manufactured to prove that it can be done. It’s a quick, small, incomplete model, and depending on customer requirements, it might be created free of charge, or requiring a small payment from the customer. However, in all cases, the PoC doesn’t demonstrate the form of the final design form, and only represents limited functionalities of the product.

A 3D rendering of a PoC model demonstrating a critical function within an inkjet printing machine. It was developed to prove air wouldn’t escape an o-ring seal when the groove was on the manufacturing tolerance limit.

PoCs are often confused with prototypes or mock-ups. A PoC is not a prototype since it doesn’t contain all the design requirements, and it’s not a mock-up because it’s not a visual model. Instead, it’s a visual example of a mechanical solution the design team has come up with. The PoC can also be a useful sales tool: presales consultants can use it along with your explanations to convince a client that their need is not only answered, but that your department has the most effective or reliable solution.

Below are 8 essential guidelines you can follow while designing a PoC model:

1) Don’t waste time on the PoC!

As previously stated, the POC is often a useful sales tool. If a client approaches your company to discuss a potential design project, he might expect a fast answer. You shouldn’t waste a second developing anything too fancy. It can be tempting to add extra features to make the PoC more attractive, but this is not often feasible (or necessary) in a short timeframe. If you have any “extras” you would like to add, just make a note of them for now. Whilst demonstrating the PoC in a meeting with the client or the presales consultant, you can drop hints about the additional feature you can design.

2) Be sure the client understands the concept of PoC

When clients receive a PoC that’s been turned around extremely quickly, they often expect other deliverables (e.g. a fully functional prototype!) within an equally short timescale. In these situations, you should explain to them how far removed a PoC is from a prototype in the design process: a PoC comes before the initial design, and demonstrates only an aspect of the design that’s been radically simplified for demonstration only. A prototype is vastly more complex and detailed, representative of a complete design, and is developed in a much later design stage, somewhere between initial to final design.

3) Don’t raise expectations

This is the most challenging point with PoCs. Whilst the designer has indeed studied the feasibility of his solution, he can easily model it in such way that could give false expectations to the client, or cause them to make false assumptions. It is crucial that the PoC sticks to representing the solution without leaving space to the fantasy of a non-designer or implying some wonderful additional features. The limitations and scope of the project should be clearly defined during early meetings with the client, and this brings us to the next point…

4) Educate the client. Don’t leave them ignorant

If the client is able to do it, he should bring along a technical person from his own company to meetings. However, this is not always guaranteed. In addition to this, maybe your own company will have a non-technical sales person meet with the client. In all cases, the designer must turn into a teacher and explain his PoC to the presales consultant or the client. It is crucial that the client understands the concept of PoC and the solution you’re presenting. It’s also important that the presales consultant or designer fights the urge to say “yes” to anything the client suggests or wants. Such “addons” might seem harmless at first but they can turn into a complicated study and distraction from the more important project deliverables and essential requirements.

5) Don’t implement unnecessary features in the PoC

The only features that should be in included are the essential ones that illustrate the goal of the mechanical system. Those features must demonstrate that the basic function of the product can be fulfilled. Parts or features that are repetitive or trivial should be discarded. If an important feature is to be repeated on the finished design, illustrate it just once to prove the point.

6) Don’t hide the inner parts

If your PoC is a mechanical system, you might be tempted to conceal the inside of your model because you know how the motion will be achieved or what you will use as a method of transmission. Your client however doesn’t. Make sure the basic main assemblies are loosely presented, and make your enclosure transparent in strategic areas. Your client will be able to relate more to your solution because he can intuitively associate it with the mechanics he gets to see.

7) PoC are NOT prototypes

The client is not the only one who needs to understand this. We often find that designers are tempted to recycle their PoCs into a prototype. Mechanical design, by its nature, requires technical assessment/development on many possible levels: geometric, thermal, stress analysis, acoustic, vibration etc. Spending time trying to recycle a PoC can be a waste of precious design time, when there are so many other things that need to be done before a proper prototype can be developed.

8) Take the PoC as an opportunity to learn

Even though it might be designed within a short period, the PoC helps the designer get an initial perspective: the main problem areas, fitting/assembly problems, parts list, areas of risk etc. Therefore, taking quick notes whilst working with the PoC could save time during project meetings and design discussions.

About: Khadija Ouajjani

Since 2012. Mechanical Design Engineer in the aeronautics industry. Mainly dealing with CAD, FEA, simulation and analysis for turbo-engines. Writing for EC since 2014. Garlic, Color Pencils, Open Systems, Coffee, Herbert, Final Fantasy VII, Writing, Tolkien, Mechanics, Deutsch, Nihongo, Herbs, Aïkido, Tea, Cinnamon, Motion, Friends.

Leave a Reply

Skip to toolbar