32 ms·

A medical device startup, based on a technology platform I invented in grad school. The startup part is what started me hanging out on HN, but I've found that t

A medical device startup, based on a technology platform I invented in grad school. The startup part is what started me hanging out on HN, but I've found that there is very little overlap between what I'm trying to do and what startups on HN do. Still, things are interesting enough here that I keep checking in. edit: I missed the "how's it working out?" part. Not great. Cash starved from day 1. Funding for medical devices is quite, quite different than software (i.e., bad but getting better recently). We don't fit the model for many VCs, so that limits potential sources, and being in medical devices means that we need to deal with sophisticated investors that can run proper DD on us, further limiting potential sources. Funding has been (and still is) a struggle! It's also a little bit "lonely": we run into a lot of problems unique to this industry, but often we can't talk about it in detail, and even when we can, there aren't many people around to talk to. Project management has been interesting. There's quite a number of consulting and industrial design groups out there, which helps to bring in expertise when needed and keep things lean overall. A big challenge has been in setting up the supply chain: it's not something I've done (or thought of) before, but consulting has helped out here as well. Basically, we'd be dead in the water without outside consultants. Regulatory affairs is a pain, but I appreciate why it's there and it's not onerous per se, just slows everything down (not necessarily a bad thing). It more or less distills down to documenting "say what you're doing, and do what you're saying". The technology side is a bit boring, honestly. We need to design things conservatively, unless we have a really, really good reason not to. We also need guaranteed years of availability for parts, which additionally tends to lead to conservative designs. Surprising lessons learned: cable management (i.e., in the device) is a nightmare, and packaging is anything but a simple problem to solve. Also, may have learned more in 6 mos. tilting at these windmills than my entire undergrad + graduate career.

HeyLaughingBoy 11y ago
What kind of consultants do you typically find yourself needing? I've been in the Medical Device field as a software engineer for almost 20 years and I'm beginning to look for other ways to leverage that experience. Most of my background in the field is in software/firmware development but I've managed to learn bits and pieces of Supply Chain, Regulatory, Manufacturing, Field Service and related subjects to get my job done. Cable management: yeah. Our previous instrument had over a mile of wire & cable in its first iteration.
- lambdaelite 11y ago
  Inexpensive ones. Kidding aside, as a startup, our needs and capabilities are quite different from a more established company. We can't afford to pay for consultants to fly business class, nor expensive per diems. We can't afford to implement heavyweight development processes, nor should we since being nimble is one of the few advantages we have as a startup. Software licensing costs is a concern at this stage, so we'd rather do a subscription for a (for example) CAD package even if it's not the industry standard over buying a license for the industry standard package. Also frustrating in general is that as a medical device, our volumes are never "large" in the consumer sense and so many common manufacturing processes (e.g., injection molding) are not practical, nor are companies excited to supply parts in our expected volumes—our consultants need to consider what are sometimes less common processes or smaller, "hungrier" suppliers. For many things, the budget is driving the bus, and it's within reason acceptable to need to spend more in the future if it means we can spend less now. It can be hard to find the a consultant at an experienced group (and domain expertise is what we need) that is willing to work with us. Our future business is not guaranteed (statistically we are likely to fail), the business we will be bringing is small, and we're pinching pennies on what we bring. What seems to have worked is to find a "hungry" associate-level consultant (keeps costs lower) at a larger group who can tap into the experience of senior/principal-level consultants on demand. We point out that, if successful, we'll be able to bring more business to the associate-level consultants, so we both will grow together. I'll give a specific example, stream of consciousness style partly out of laziness. We have a software component, and a portion will be safety-critical... crap, things just got more expensive. We know we need to develop the device under a risk-management plan (ISO 14971), so we don't need consultants to tell us that, but we may need them do to a design review because we don't have enough in-house experts (how many do we need?). We know that the software component must be developed under a SDLC (ISO 62304). Should we do it agile (as per AAMI TIR-45, not cowboy agile nonsense), or a more traditional V-model? Does CMMI or PSP apply to us? Should I listen to the nice people at IBM and use Harmony, or are they preying on a poor (emphasis on poor) innocent startup? It'd be nice to have a consultant advise us, based on their experience, that one or the other works better for a startup. Have we properly identified the safety-critical portions of our design? What should the development environment look like: is MISRA-C everywhere the right answer? Probably not. So MISRA-C for the safety-critical portion, and regular C everywhere else? Or should we do Java/RTSJ with a fancy JVM? Ada/SPARK? We could justify any of these, and probably others. What are the costs of tooling for each choice, licensing costs, how hard will it be to find employees/contractors (should we use contractors? how many will I need to hire?), and what will productivity look like? What about maintainability? Is QNX better than VxWorks? Is model-based systems engineering worthwhile, or is it an expensive buzzword? Those nice people at IBM said Rational is great, and it'll tie into DOORS! And they said DOORS is great! Maybe I should use Excel instead of DOORS, I heard from a guy on the internet that works just fine. And so on... So for much of this, we want an experienced consultant that can review case histories and show us that in the past, comparable companies were successful by doing X, and so it makes sense for us to go that route too. Many times we know we need to do something, and frequently how to do something at a larger company, but not the optimal way to do it at a startup. I can do a decision matrix, but without the case histories, there's too many gaps in the matrix to be useful. We also need to have external people for design reviews, and figure out when we need to pull in those external people, when we don't, and when we should. I need to be able to tell the regulators that our processes were based on industry best practices. I need to be able to tell board members the same, and be able to tell them that our processes and plans have a successful track record at comparable companies to justify the time/cost/etc. I want to be able to show shareholders that we're being good stewards with their investments, and we're doing that by making careful, informed choices.

HeyLaughingBoy 11y ago

What kind of consultants do you typically find yourself needing? I've been in the Medical Device field as a software engineer for almost 20 years and I'm beginning to look for other ways to leverage that experience. Most of my background in the field is in software/firmware development but I've managed to learn bits and pieces of Supply Chain, Regulatory, Manufacturing, Field Service and related subjects to get my job done. Cable management: yeah. Our previous instrument had over a mile of wire & cable in its first iteration.

lambdaelite 11y ago
Inexpensive ones. Kidding aside, as a startup, our needs and capabilities are quite different from a more established company. We can't afford to pay for consultants to fly business class, nor expensive per diems. We can't afford to implement heavyweight development processes, nor should we since being nimble is one of the few advantages we have as a startup. Software licensing costs is a concern at this stage, so we'd rather do a subscription for a (for example) CAD package even if it's not the industry standard over buying a license for the industry standard package. Also frustrating in general is that as a medical device, our volumes are never "large" in the consumer sense and so many common manufacturing processes (e.g., injection molding) are not practical, nor are companies excited to supply parts in our expected volumes—our consultants need to consider what are sometimes less common processes or smaller, "hungrier" suppliers. For many things, the budget is driving the bus, and it's within reason acceptable to need to spend more in the future if it means we can spend less now. It can be hard to find the a consultant at an experienced group (and domain expertise is what we need) that is willing to work with us. Our future business is not guaranteed (statistically we are likely to fail), the business we will be bringing is small, and we're pinching pennies on what we bring. What seems to have worked is to find a "hungry" associate-level consultant (keeps costs lower) at a larger group who can tap into the experience of senior/principal-level consultants on demand. We point out that, if successful, we'll be able to bring more business to the associate-level consultants, so we both will grow together. I'll give a specific example, stream of consciousness style partly out of laziness. We have a software component, and a portion will be safety-critical... crap, things just got more expensive. We know we need to develop the device under a risk-management plan (ISO 14971), so we don't need consultants to tell us that, but we may need them do to a design review because we don't have enough in-house experts (how many do we need?). We know that the software component must be developed under a SDLC (ISO 62304). Should we do it agile (as per AAMI TIR-45, not cowboy agile nonsense), or a more traditional V-model? Does CMMI or PSP apply to us? Should I listen to the nice people at IBM and use Harmony, or are they preying on a poor (emphasis on poor) innocent startup? It'd be nice to have a consultant advise us, based on their experience, that one or the other works better for a startup. Have we properly identified the safety-critical portions of our design? What should the development environment look like: is MISRA-C everywhere the right answer? Probably not. So MISRA-C for the safety-critical portion, and regular C everywhere else? Or should we do Java/RTSJ with a fancy JVM? Ada/SPARK? We could justify any of these, and probably others. What are the costs of tooling for each choice, licensing costs, how hard will it be to find employees/contractors (should we use contractors? how many will I need to hire?), and what will productivity look like? What about maintainability? Is QNX better than VxWorks? Is model-based systems engineering worthwhile, or is it an expensive buzzword? Those nice people at IBM said Rational is great, and it'll tie into DOORS! And they said DOORS is great! Maybe I should use Excel instead of DOORS, I heard from a guy on the internet that works just fine. And so on... So for much of this, we want an experienced consultant that can review case histories and show us that in the past, comparable companies were successful by doing X, and so it makes sense for us to go that route too. Many times we know we need to do something, and frequently how to do something at a larger company, but not the optimal way to do it at a startup. I can do a decision matrix, but without the case histories, there's too many gaps in the matrix to be useful. We also need to have external people for design reviews, and figure out when we need to pull in those external people, when we don't, and when we should. I need to be able to tell the regulators that our processes were based on industry best practices. I need to be able to tell board members the same, and be able to tell them that our processes and plans have a successful track record at comparable companies to justify the time/cost/etc. I want to be able to show shareholders that we're being good stewards with their investments, and we're doing that by making careful, informed choices.