For the sake of readability, I've split this article in two. Stay tuned next week for Pt 2.
It's easy to take for granted the things you know.
It's just as easy to forget that people don't know what you know.
Really, I shouldn't forget. It is my job after all to provide my skillset to those who do not have the capability or capacity themselves.
Probably half of all medtech founders come from clinical backgrounds, not engineering backgrounds. In the very early stages of founding a medical device company these clinical founders may be entirely without a technical partner. It is likely they do not have the requisite knowledge to progress an idea from a proof of concept. In support of those founders, this is for you.
Proof of Concept
This might be where you are right now.
Image courtesy of Matt Oldakowski
It's not pretty, but it works.
A proof of concept (POC) is the most rudimentary of prototypes. Likely cobbled together from other parts you could find at Bunnings, and held together with zip-ties. It works enough to show that it, well, works. Sufficiently so that it warrants further expanding, exploring and evaluating the idea. But how do you do that?
Here is how.
The Design Process: A Primer
Before we get into the specifics of taking a proof of concept forward. It's worth discussing the design process itself. This is the framework that designers use in all areas of design. The design process will be how we get from where you are now, to where you want to be next.
As you can see, the process is simple. But be warned that it is highly iterative. It is necessary to iterate many times to ultimately end up with a device on the market. Each sets out to define, develop, and test your ideas. And each will be approached differently, depending on the things learnt from the previous iterations and the objectives of the next.
In this article I'll specifically discuss our first lap through the process, as it may be the most critical in demonstrating viability of an idea.
The Objective
So you have your proof of concept, the next thing you'll need to do is create another prototype.
If you haven't gathered already, yes, it is prototypes all the way down.
Usually iterations will start out asking large, high-stakes questions with low-fidelity prototypes. With each successive prototype the questions become fewer and the form the device will become clearer, less nebulous. Ultimately working towards answering small questions with high-fidelity prototypes or even production samples. Finally you're pushing things around by a millimetre or two until it's [near] perfect. However at the point of POC, you still have many large questions.
The objective is to identify the largest, riskiest unknowns, and find answers to them.
Design Inputs
Design inputs is really too fancy a term here, but I'll use it to remain in line with the terms used in ISO 13485. This covers both empathising and defining as described in the design process above. In a very basic sense, your design inputs at this time will only be the most fundamental requirements you need to test your idea. It's important not to get overwhelmed with constraints that can be addressed in later iterations.
Put simply, the empathy part can be boiled down to thinking about who the users are and their needs. If you're a clinician with an idea within your field of specialisation, then this will be straight-forward. Just list out a few of the key needs you want to test. It will also be worth asking peers or colleagues for feedback too. This can provide greater diversity and clarity on these needs, and help keep your assumptions in check.
Some user needs to consider might be:
- What failure in clinical performance could kill the project.
- Workflow requirements. How is the device used?
- Any ergonomic requirements. How is the device held?
- Any other users who must interact with the device (don't forget patients).
By writing these needs down you've already started to define your inputs.
It is likely there are also some technical challenges that must be tested, so write these down too. Again, focus on the hardest, riskiest ones:
- What failures in technical function could kill the project.
- What other big 'million dollar' questions you don't have answers for.
- What you learnt from the POC that must be incorporated into the next design.
- Other fundamental technical requirements for minimum viable functionality.
- Integration into other systems.
Depending on your device, it is highly likely you won't be able to do any clinical testing with it, so you may need to consider what analogy you could use instead. This may mean you need to design both the prototype for testing, and a phantom on which you'll test it. At the very least you may need to know what performance measures you need to see to have clinical equivalence, and the sensors you need to measure them.
All up, 5-10 design inputs is more than enough. It's also fine that as you work through the design of the next prototype, you pare this list down in order to simplify the design to focus key requirements. If needed, you can also isolate specific requirements into separate prototypes to simplify conflicting or complex challenges. Prove out two challenges separately before integrating them.
With a few well defined design inputs, it's time to move onto ideation.
Ideation
Ideation, or concept development, is the process of exploring all possible ideas that address the requirements you've listed. There are many different techniques for doing this, but that's a whole article in itself. In its simplest and arguably most effective form, your ideation will just be some pencil sketches on paper. I would recommend a nice sharp pencil and some loose leaf A4 paper.
With your design inputs close to hand, sketch out some ideas. Your sketches don't have to be pretty. It is important to remember you're not trying to find the right answer yet, you're trying to cast a wide net. Don't judge your ideas until you've got them all down. From there you can test them against the inputs as you go, and combine and revise your ideas from there.
Keep sketching until your brain has nothing more to give.
Then set everything aside for a day or more. Your subconscious will keep working on ideas, even if your conscious isn't. It is likely you'll have new solutions pop into your head while you're in the shower or out jogging. If not, at the very least taking a look at your ideas with a fresh set of eyes will give you a new perspective on the ideas you've already generated.
It may also be worth engaging with an Industrial Designer at this time to help you work through the concepts and ensure that you've covered a broad gamut of ideas. They will have some additional tools for design exploration, and may be able to bring in concepts from adjacent and unrelated fields. Depending on your level of proficiency, they can also help all the subsequent steps.
Sanity Check Your Ideas
Take these sketches and show them to trusted peers or other potential users. Start opening the discussion with users as early as you can. Be open to changing your ideas based on their feedback, even this things you may not want to hear.
Stakeholders have a problem, and you're working on a solution. They want your solution to succeed, because it solves their problem. The sooner you engage them, the more successful your device will be.
Remember that the best time to make a change is while it's still on paper.
Next we'll cover taking those ideas through prototyping. Stay tuned.
If you've got any questions about your device, I'd love to chat about it with you. Book an intro call here.
