Throughout the development of a product there are technology-related project risks that have the potential to negatively impact budget and timeline. At StarFish, our development process defines medical device proof-of-concept (POC) prototypes to mitigate these risks, either by resolving the uncertainty one way or the other, or by testing the use of a new or different technology.
So what are POC prototypes then? POC prototypes are pretty much defined solely by their purpose: To prove a concept. Sometimes they are a simple bench-top setup, sometimes they take person-years to perfect.
For example, I might wonder if I can save cost or increase accuracy by switching from an optical position-sensing technique to a capacitive one. In that case I might do a quick experiment in the lab to see if the new idea has legs. That’s a POC.
I might want to use a spring loaded connector in a dynamic way, like a slip ring. This sounds plausible but I would definitely want to test this technique before designing my whole product around it. That’s also a POC.
Just to blur the definition a bit more, there is another reason to build POCs and I call these Platform POCs. These prototypes are essentially development test-beds. For instance, if there are novel firmware algorithms that must be developed, we often will design a PCB with all the subcircuits that we know are needed. Sometimes these boards contain all the same circuits that will be in the final product, but getting these down on a board without all the size, cost and other constraints allows the software developers to design and prove out their mojo well in advance. Not only does this give them a headstart on the timeline, but it also allows problems to be caught and resolved significantly earlier, when corrections cost less. Essentially a platform POC brings together a number of technologies in order to reduce dependent risks.
So why shouldn’t I just go ahead with an alpha? You’ve probably already seen the answer to this one, either in what I’ve said or in your own experience. As long as there are significant technological project risks, there’s a good chance I’ll run into trouble later in the design process. There’s a ton of effort that goes into all sorts of mundane, low-risk areas during alpha development. Often time is better spent tackling those specific, risky areas and putting off the handle-cranking until later. To do all that work too soon is to risk doing it again.
Speaking of which, I also try not to over-design my POCs. I believe that the value in a POC is the learning I get from it, not the POC itself. In many cases a POC is too fragile or hacked and kluged to do much more with than was originally intended. I figure that if I’ve squeezed every drop of goodness from it, all I have left is pulp. Certainly there are situations when a POC is able to deliver further value after additional modifications or testing, but to assume that a POC will definitely be such a source of goodness leads to extra time and budget and thereby delays the important and specific project de-risking for which it was originally conceived.
How do I choose what to POC? At StarFish we develop and maintain a project risk registry which works well for prioritizing POC development. Ideally I choose the technologies that either are least known, or have greatest potential to upset the project and do them first. That’s not to say that prioritizing is easy. I try to get as much input from as many experts as I can. Fortunately, here at StarFish we have plenty of domain experts and they all love to share knowledge on their pet subjects.
Finally, how do I know when to stop POCing and get going on the alpha? That’s up to me and the rest of the project stakeholders. It depends on how risk averse everyone is, but bear in mind that spending too long in POC-land (or Phase 0 as we call it at StarFish) is itself inherently risky because it can delays the product launch. In other words, there’s always going to be a natural tension here. If possible, I try to find a way to limit the impact of every technological risk but at least POC those all-or-nothing risks that could make the whole program fall flat on its face.
At that point, we’re good to go ahead with alpha prototype development, but that’s a subject of another blog.