Guest Column | August 12, 2016

3 Strategies To Achieve Big While Spending Small

How to limit cash burn and keep up with a persistent demand for progress.

By Dave Perry, Smithwise

Hardware-focused startups are expensive projects to get off the ground. Development cycles are inherently long, and prototypes cost even a technically savvy founder much more than time. Medical device startups, in particular, have the added hurdles of regulatory, clinical, and payer risks. Investors are well aware of this high-cost, high-risk proposition and — unsurprisingly — the competition between early-stage medical device ventures for available capital has become extremely competitive.

That’s not to say the well is dry. Plenty of investors still recognize the opportunities behind healthcare challenges. There’s something to be said for making a buck or two while making an empirically positive impact on patients’ lives. But, those willing to accept the risks and back a medtech venture expect a couple of really important things from their new investment: lean operating structures and rapid progress.

To be truly thrifty as a medtech startup, the choice to forgo an over-the-top office/playground isn’t enough. To strike the right balance between cash on the ledgers and forward progress, you need to keep your development team focused on core values, make good use of readily available (often free) technical resources, and be smart about how you build prototypes.

1. Keep Your Team Focused On What Makes You Valuable

What should you do internally and what, if anything, should be farmed out to a contract resource? Would you have somebody else build and optimize your core technology? What about designing your product around that technology? Who should handle regulatory strategy, clinical affairs, intellectual property management, manufacturing, and accounting.

Most start-up teams are incredibly resourceful and, given enough time, they could likely tackle all of these issues. Since the actual time afforded these teams is finite, though, they must decide where to focus.

Do It Yourself — Identify your primary source of competitive advantage. Is there a core technology that enables your medical device to improve healthcare outcomes and/or reduce healthcare costs? If so, the core internal team’s expertise may best be applied to concentrate its efforts on technology development. Does competitive advantage arise from industry alliances and/or distribution channels? If so, the internal team’s best use may be to focus on these customer/user experiences, key opinion leader (KOL) engagements, and industry partnerships.

Just Pay Somebody — Your product may be unique, but the right path through product development, manufacturing, and clinical affairs probably isn’t. These may be functions that could be best supported through external resources. However, this process takes a fair bit of cash, so make it part of your plan before you raise funding; plenty of investors will recognize smart outsourcing as a good investment.

Wherever a medtech or straight hardware startup decides to focus its internal team’s efforts, the key is to focus. Trying to do everything internally may be the most frugal route, but the pace of progress will undoubtedly suffer. Similarly, trying to outsource too much may burn through the available budget long before critical financing milestones have been reached. Planning this balance is critical, so be sure to get input early on from all the key players.

2.  Before You Take On A Difficult Question, See If Somebody Else Has The Answer

Too often, entrepreneurs spend time trying to solve problems that have already been solved.  A clever concept from a brainstorm session may lead the design team to invest hours or days in a custom solution. When faced with a non-obvious challenge, it often pays to look externally for some free stuff:

Free Design Input — Perhaps you need to make an economical friction hinge, and you’ve seen some devices use spiral-wound spring pins as a pivot to great effect, but getting that result isn’t as straightforward as sticking a pin through a hole. Call the people who make the spring pins (Spirol, in this case) and ask for an applications engineer. An email might get you a information packet or a catalog, but a phone call will get you somebody who’s happy to talk about best practices and offer suggestions for your specific design. Remember, ask stupid questions and you’ll get more complete answers.

Free Parts — Ask for free samples from manufacturers, and use them for early prototypes. Call the folks at Motion Mechanisms and have them send some miniature rotary dampers or hinges. Call up Vernay or Mini Valve, and get yourself some duckbill valves. Fill out a form on Bivar’s website and get that board component spacer that’s just right, but Digikey doesn’t keep in stock. This may not be the biggest money saver up-front, but a lot of these components are difficult or impossible to find — especially in prototype quantities — from the usual one-stop-shop suppliers. A young engineering team might stop there, assume there is no OTS part that suits their needs, and set out on the costly mission to design their own.

Free Advice — In many cases, service providers are willing to serve as a sounding board for concepts and strategies being considered by the entrepreneurial medtech team.  While these service providers and application engineers are unlikely to be able to provide detailed development work pro bono, entrepreneurs often need a few leads to pursue and can handle the leg work independently.

Free stuff is great, but eventually you’ll need the full attention of experienced resources to take ownership of tough problems.  Here, it can be a significant mistake to engage student labor or to attempt sweat equity arrangements with consultants. These routes typically are pursued in an attempt to conserve cash, but often result in poor quality and/or prolonged deliverables. In product development, there are times when procuring quick tips and free samples is the right strategy, and there are times when sharp, experienced development resources need to be deployed in order to gain the desired results.

3. Make Prototypes For The Right Reasons, Quickly, And Then Break Them

Many hardware startups view “prototyping” as a process where you put all your ideas into a quicker, cheaper version of the final product, and call it your “minimum viable product (MVP).” This approach really misses the point of MVP, per Eric Reis’ “Lean” methodology. Thinking about the MVP definitely has a place in hardware development, but for now, let’s focus on efficient prototyping:

Mockups And Models — Are you just looking to test a user’s reaction to a specific feature, early in the design process? This is what industrial design models are for; they communicate the intent of your product, are the same shape and size of the (planned) final iteration, and are composed of carved foam or 3D-printed parts. Functionality is simulated, if necessary. Real functionality takes a lot of effort to integrate, which kind of defeats the purpose of getting early, inexpensive feedback.

Breadboards — Are you looking to see if one feature or another will actually work? Isolate that feature from the rest of the product and build it. Say your product has a large body that houses key components, and one end of the body has a custom latching feature. It costs $800 to print the whole body, but printing just that latching mechanism costs $200. Don’t print the whole body just to test a new iteration of that feature; that’s a waste of $600. Worse, don’t wait to test that feature until you have a reason to print the whole body — that’s a waste of days!

Troubleshooting is the most important reason to build breadboards to test functionality. No design works right out of the gate. If you have a system with any level of complexity and it isn’t performing as expected, it’ll be nearly impossible to figure out why if you didn’t first confirm that each element worked independently.

Functional Prototype — This is the thing you wanted to jump straight into at the beginning, and that would be a mistake. A fully functional prototype that looks and works the way you want it to is incredibly expensive. This is a tool for confirming your product has been designed and engineered properly, and learning what adjustments need to be made before investing in tooling. If you jumped straight to this point early in development, in order to test users’ reactions, you won’t just be making adjustments moving forward; you’ll be throwing the device away and starting over.

It’s important to note that these costly prototypes are your last chance to identify weaknesses before investing even more money in tooling and manufacturing, so don’t coddle them. Treat your baby the way a real user will treat the final thing. And, rejoice in broken prototypes, for they have delivered valuable information.

Medtech entrepreneurs need to think like their investors and structure their operations accordingly. Excessive spending without achieving the critical milestones will not be tolerated; nor will an overly restricted cash burn that leaves a project limping forward. Building internal and external teams, focusing product development activities, and learning through a prototyping approach are critical operations that need to be considered in the medtech startup model. Throughout these and other operations, startup teams are wise to consider the continuous balance of being thrifty and moving a project forward.

About the Author:

Dave is a Director of Product Development Strategy at Smithwise. In his role, he helps companies map out development processes while fitting within the constraints of timelines and budgets. Dave has held several technical, program management, and business roles at Smithwise, which provides him a valuable perspective in defining development strategy for key projects. Some of his recent work involves motion control and automation, acoustics design, airbag systems, lab equipment design and fluid handling. Prior to joining Smithwise, David founded a company to further develop a novel water filtration system designed with fellow students at Rensselaer Polytechnic Institute. Through this work, he was named the Future Forward 2010 Game Changer of the Year and awarded a $100,000 prize in the 2010 MassChallenge competition. David holds a B.S. in Mechanical Engineering from Rensselaer Polytechnic Institute with a focus on the theoretical foundations of mechanical engineering.