The five steps discussed within this article identify what to expect, and how to respond as a team to move a well-designed device to volume production.

Originally posted on Med Device Online

Written by Jon Wenderoth, Lead Mechanical Engineer at Smithwise

Many new companies have a business model based on transitioning their product to high-volume manufacturing and distribution. Unfortunately, this is more complex than breaking out the parts from a working prototype and selecting a manufacturer. Mistakenly thinking the development is wrapped up at this point will cause schedule projections to be significantly off, and seed doubt in knowledgeable investors.

It is important to understand that these steps alone won’t fix the output from a broken development process; a house needs a solid foundation to remain standing. The entire evolution, from thoughtful design through prototypes and iteration, inherently becomes the footing for an efficient transition to manufacture. The five steps discussed within this article identify what to expect, and how to respond as a team to move a well-designed device to volume production.

1.  Prepare A Request For Quote Package

When it’s time to start shopping around for vendors, it is important to gather the necessary information into a concise Request for Quote (RFQ) package. Remember that everything is on the table at this point, so if a potential customer appears disorganized, unprepared, or generally unknowledgeable, it sends up a red flag that a project may involve significant hand-holding; prices will be adjusted accordingly. Having a complete, up-to-date database is in your best interest and will pay repeated dividends over the life of a product.

The RFQ package should start with an engineering Bill of Materials (BOM). This is the full parts list, including part descriptions, materials, proposed manufacturing processes for custom components, any secondary processes, quantities, file names, and revision tracking. For a contract manufacturer (CM), a complete BOM is a quick reference for the submitted parts that implies experience and attention to detail. If quoting at individual vendors for specific manufacturing capabilities, segment the data so they aren’t overwhelmed with extraneous information.


Above Image:  Zip-Stitch by ZSX Medical (

Vendors also will need part files to know what they are quoting.  Stay away from sending any native file formats; in addition to document reference headaches, outside parties are less likely to attempt to modify CAD data without design tree information. Instead, identify which file formats fit a vendor’s process. For instance, two-dimensional process manufacturers (stamping, die cutting, water jetting, etc.) can usually work with 3D part files, but many prefer flat pattern DXFs, as these can feed directly into their machine software. Three-dimensional process manufacturers (molding, casting, multi-axis machining, etc.) need 3D part files, like IGS or STP.

If your project is like most development efforts, time is on short supply and quoting is begun prior to design finalization. This typically is ok, as long as general size and features are included within your files. Ensure some form of revision control is used, so when it is time to hit “go,” the appropriate files can be referenced. To summarize:

  • Compile an appropriate, complete package for each vendor.
  • Use revision control (dated files, revision numbers, etc.) that can be easily referenced.
  • Send the entire package at one time. A barrage of emails to sort through is inconvenient for the recipient and increases the chance that things will be lost.
  • Special operations/secondaries can be specified in the BOM. If further granularity is required, 2D control drawings can be generated.

2. Construct A Realistic Timeline

One of the key outputs from the RFQ and vendor selection process is schedule. Formal quotes come with lead times, so be clear on what these lead times mean — when does the timer start, and what is the deliverable when it stops?

Using injection molding as an example, imagine it is May 2nd, and a vendor quoted a five-week timeframe to T1 sample parts. If a purchase order is sent today, the first parts will arrive in early June, giving just enough time for each part to be packaged and sent to representatives at the big east-coast medical design tradeshow later that month. (At this point, if you’ve done this before, you are questioning the validity of this article.)

Unfortunately, this is a common trap new developers fall into when doing the right thing and trying to project into the future. The intent is there, but the data is skewed. In this simplified example, the five weeks are for sample part molding, not including shipping time, and other steps in the process are not considered. A typical timeline for this example part might be as follows, with up to several months added on to the five weeks quoted:

  • Final file delivery
  • Moldability evaluation1-2 weeks
  • Discussion & part modification2-3 weeks
  • Final review & tool design approval1 week
  • Tool construction & T1 samples5 weeks
  • Part evaluation, testing, and file updates2-4 weeks
  • Tool grooming and texturing2-3 weeks
  • T2 samples delivered1 week

For multi-part assemblies, using varied manufacturing methods, schedules become increasingly complex. It can be helpful to fully understand all the steps in a process and work backwards from a set deliverable date. With this approach, as the project progresses, it is clear what the longest lead time items are, and which milestones need to be met, so they don’t become a gating item.

3.  Finalize The Documentation Package

After vendors are selected and the product design is finalized, the documentation process discussed in step one will need to be repeated at a more discrete level. In addition to CAD files, this should include complete engineering drawings in PDF format. If working with a CM, assembly drawings should be included, with all pertinent drawing views and instruction to enable a third party to assemble the product.

This documentation is the engineer’s chance to identify areas that need specific tolerances, with critical dimensions for functionality and inspection dimensions for the vendor to verify. In many cases, a vendor will inspect all drawing dimensions; at the least, values identified as “inspection” will highlight their importance to the physical outcome of a part.

Don’t forget to update and send your BOM with the final files in a complete package. It is critical that vendors have easy access to the most recent documentation to avoid mistakes, and it is wise to include revision numbers on individual file names that can be cross-referenced to the BOM.

4. Manage The Design For Manufacturing (DFM) Process

At this point, the vendors have been sent the information they need, but the job isn’t done yet. There should be some degree of feedback from all manufacturers, but we will continue to use injection molding as our example.

After a few weeks, the vendor will have reviewed the files and provided a moldability evaluation. If a knowledgeable engineer or reviewer has been involved in the development, there shouldn’t be any show-stoppers here. However, if the vendor discovers that a critical feature can’t be molded due to geometric constraints, there may be some late nights ahead. Luckily, the tools haven’t yet been cut and there is room to pivot. Still, a sales team pushing to be first to market won’t appreciate the compromised schedule.

Regardless, expect there to be some feedback to incorporate into the design. Maybe an internal rib is moved to allow for a more convenient gate location, or the draft added to a snap feature isn’t sufficient for appropriate shutoff. When resolving these details, keep in mind that the molder doesn’t know the design intent of your parts, and their first suggestion will likely be the easiest (but not necessarily the correct) solution.

To that end, communication, especially with overseas vendors, can be painful. A phone call to discuss changes directly is often the most productive way of handling this, but this isn’t always possible. Discussion often reverts to “Powerpoint engineering,” where issues are captured and suggestions given within a slide deck. For these situations, we suggest the following:

  • Be clear and concise, and don’t forget there may be a language barrier. Label and date all files, as well as all comments.
  • Pictures, arrows, & colors: The “1000 words” philosophy applies here, too, and simple sketches often can suffice, rather than investing time in an exploratory CAD change.
  • Consolidate. If schedule permits, gather all the DFM feedback together to review instead of assessing it piecemeal. This is more efficient, and makes it easier to track responses. Provide 2D and 3D file updates in the same way (don’t forget to update your BOM with revisions).

Besides design issues, the vendor will be looking for approval of process-specific features, such as gate and ejector pin locations in a mold. Ensure there is an understanding of what approvals are needed and how they are provided; it is frustrating to believe a vendor is spooling up when they are actually waiting for a well-defined approval.

5. Inspect, Evaluate, And Adjust

Regardless of what anyone says, no custom manufacturing parts are going to be perfect immediately — that takes additional work. For this reason, a good development timeline should always build in a period to assemble and evaluate the form, fit, and function of a design. This is the time to find and correct any issues that arose during manufacturing. If schedule is very tight, it is always helpful to have a representative on site for rapid evaluation. Remember that the vendor will need approval prior to any volume orders (or final tool details, like texture application on molded plastic), and it becomes more costly for budget and schedule if changes are requested later on.

  • Ask for inspection reports from vendors. For production parts, these should be available and provide direct measurement of critical dimensions identified on engineering drawings.
  • Get all parts in-hand (preferably multiple sets). This includes electronics, fasteners, samples from each cavity in family tooling, custom cables, everything. Long lead time parts need to be sourced appropriately so they are all available.
  • Assemble and test: Leverage sample parts and inspection reports to assess functionality.

Testing may start as fit checks — ensuring a sheet metal bend is at the correct angle or fastener holes align — and then may progress to a functional assessment. Eliminate variables where possible to focus on the area in question, and don’t be afraid to do some destructive analysis if supplies allow. This is a valid justification for allocating multiple parts to testing; if a problem can’t be seen or understood, it may not be fixed appropriately. Regardless of how many are available, never be cavalier with the approach to sample parts. Identify a plan, and then inspect, measure, and record until all learning opportunities from a part have been exhausted.

Ensure all members of the design team are aligned before implementing any modifications. As with earlier updates, communicate changes in a clear and concise manner, as the cost and risk of change (and therefore mistakes) increase exponentially after vendors have fully tooled up for high-volume production.

These steps should provide some high-level insight into the effort required to transfer a product to manufacturing. While this is by no means a complete list of the challenges involved, hopefully it can equip hardware developers with enough knowledge to avoid the common headaches and get their product into production.


Many factors need to be weighed when implementing 3D printing within an evaluation, clinical, or production device setting. Because 3D printing is as easy as a click of a mouse, additional responsibility falls on developers to properly design, assess risk, or account for quality.

Originally posted on Med Device Online

Written by David Schoon, Director of Mechanical Engineering at Smithwise’s Newton office

Medical device developers use 3D printers religiously, to develop prototypes and to iterate designs, in order to rapidly learn and improve upon a product idea. Traditionally, these tools are used during the early stages of development. After prototyping is complete and the behaviors of a product or part design are understood and tested, the design is manufactured by a more economically viable method, such as injection molding, extrusion, casting, or metal stamping, amongst others.

However, there are circumstances under which 3D printing is a perfectly reasonable production method. These can be instances where production volumes are low, product margins are high, or there is a need to uniquely customize each design. While these may not be common scenarios for, say, a smartphone or a coffee mug, these factors can translate well to certain types of medical devices. Still, device makers need to be aware that there are precautions and processes to consider as a result of the unique risks associated with 3D printing manufacturing.

It’s likely that many developers with 3D printing exposure or experience already are aware of some of the common traits and risk associated with the process — FDM hole sizes that are significantly undersized, in accordance with claimed machine tolerances; photopolymerization materials that creep and dimensionally change over time when exposed to loading conditions; and DMLS parts that are saggy, droopy, or out-of-specification from the outset, due to poor build orientation and support material layout. However, these examples of common difficulties merely scratch the surface of what needs to be understood, from a risk perspective, when implementing 3D printing into a medical device design.

One difficulty that developers have encountered to this point is the particular dichotomy that exists between 3D printing — which can be associated with fast and loose development — and the regulatory standards and rigor imposed by FDA upon devices developed within a quality system. The ease with which one is able to generate parts through 3D printing inherently introduces risk.

In May 2016, the FDA released a draft guidance titled Technical Considerations for Additive Manufactured Devices. Any manufacturer or organization considering 3D-printed components during the development of a medical device should refer to this document. The guidance goes into detail regarding risk and other considerations related to 3D printing, as well as how to employ 3D printing within device development. Some of the risks and considerations discussed include:

  • Development drawings with critical dimensions can be overlooked, and/or parts can be printed without files being saved and documented properly within a Device Master Record.
  • Material behavior can vary significantly from datasheet specifications due to environmental conditions, build orientations, print machine variables, and other unanticipated factors.
  • Software workflow, material controls, and post-processing are important considerations to achieve repeatable and quality parts, and proper documentation and manufacturing flow charts should be generated to capture these.
  • Compared to traditional manufacturing techniques, there are feature size limits, dimensional variation based on technique, environmental conditions factors, and many factors affected by build orientations.
  • Material behavior, with respect to cleaning and sterilization, can differ from that of parts manufactured using traditional methods.

The FDA has presented workflow guidance detailing what needs to be controlled for a successful device submission when utilizing 3D printed components. Developers should plan to include proper design documentation, software workflow, material controls, post-processing controls, and testing considerations.


The guidance should be consulted for finer granularity regarding each of these quality components. Additionally, manufacturers should heed these commonly overlooked considerations relevant to 3D-printed part production:

  • It is recommended that performance verification come from testing finished parts, or coupons that are produced using an identical process.
  • If possible, device files should be maintained and archived to an Additive Manufacturing File format, as described in ISO/AST 52915.
  • Workflows should be established to include part placement, layer thicknesses, printer accuracy, print speed, and the build layout within a print envelope.
  • Printer maintenance procedures should exist along with workflows to establish consistency between builds. These should be maintained within the Device Master Records (DMR).
  • All material information should be documented, including any process aids, like material support and crosslinkers.
  • Workflows should exist for any post-processing steps, such as the removal of support material. Depending on the use case, testing may be necessary to understand the effect this action may have on the finished part.
  • Process validation should be established. This can include monitoring and documenting the 3D printer’s environmental conditions to validate the machine process.

The FDA guidance is intended to induce a thoughtful approach that will yield a successful regulatory submission, and is catered towards the inclusion of 3D printed components within an end product. For a low-volume FDA evaluation or a clinical study, there may be economic factors that make 3D printing a desirable approach for component and prototyping purposes.  When weighing this approach, it should be understood that the burden is on the developer to establish sufficient rationale to claim equivalency between a prototype and a high-volume production method.

In certain instances, equivalencies can be rationalized fairly simply — for example, if a 3D-printed housing was used for a laparoscopic disposable within a human factors validation study.  However, if said device contained electrical or antenna components and was being used within a clinical trial or certification testing, there may be good reason to prototype with a production material.  Material differences could influence the EMC or antenna performance, and having to retest to IEC 60601 conformity could be costly and time-consuming.

In summary, many factors need to be weighed when implementing 3D printing within an evaluation, clinical, or production device setting. Because 3D printing is as easy as a click of a mouse, additional responsibility falls on developers to properly design, assess risk, or account for quality. As the FDA has only recently began to weigh in on 3D printing, developers and manufacturers would be wise to use pre-submissions when clarifications are needed.


In the deceptively simple words of one surgeon, “My job in the operating room is about minimizing stress, and I’ll change when the stress of staying the same outweighs the stress of changing.”

Originally posted on Med Device Online

Written by Eric Sugalski, Smithwise, and Wamis Singhatat, Active Protective

Bringing a novel technology to the market in the form of a new medical product introduces several challenges:  Will the technology work the way that it is intended?  Will it meet clinical objectives?  Will it achieve FDA’s safety and efficacy requirements?  While these challenges are important, there is another challenge that few companies sufficiently address during novel products’ development phases: Will people use it?

Startups often are advised to get feedback from their customers, and attempts to gain feedback typically take the form of a survey. The survey generally consists of several background information questions and some binary, “yes/no” questions to suggest whether customers would be receptive to a new solution. Surveys can be very effective when customer needs are explicit and users are considering alternatives, or incremental improvements, to products they may already be using.  But, when no existing product addresses a problem customers may have, adoption — and, presumably, regular use — of a new product requires behavior change, and attempting to address behavior change through a survey leads to highly unreliable data.

Behavior Changes And Switching Costs

Convincing humans to modify their existing behaviors, or to add new behaviors into their daily routines, is one of the most challenging parts of bringing a novel device to the market. In the deceptively simple words of one surgeon, “My job in the operating room is about minimizing stress, and I’ll change when the stress of staying the same outweighs the stress of changing.” What the surgeon really means is that the true upside of any new solution equals its advantages minus any “switching costs.” Beyond monetary costs, these can include any pain points associated with adoption, such as training, learning curve, new risks, etc. If the benefits are too small, they could be cancelled out by switching costs. The surgeon’s statement also reveals a critically important truth: most users are reluctant to change until presented with an extremely compelling reason to do so.

Case Study: Changing Behavior Of Elderly Adults

Philadelphia-based startup ActiveProtective aims to protect elderly adults against fall-related hip injury through a wearable airbag system. In collaboration with Smithwise, Key Safety Systems, and Inertial Labs, ActiveProtective has developed a system that can accurately detect the incidence of a serious hip-impacting fall, deploy airbags over the hip regions within 40 milliseconds, and send out an alert to caregivers.

Since the company’s inception, one of ActiveProtective’s critical questions has been, “will users wear it?”  Rather than immediately jumping into product architecture, ActiveProtective dove deep into understanding the psychology of various user groups, analyzing user painpoints, motivations, habits, and perceptions to the company’s product concept.  These are some of the key insights from that process:

1. Separate the needs from the product — All too often, developers make the mistake of framing their interviews around design improvements being contemplated for their new solution. In other words, interviews place a prototype on the table and “lead the witness” to the answers developers want to hear.  Before jumping into product mode, ActiveProtective visited target users in their environments to understand the challenges they faced on a daily basis. This process illuminated critical needs, some of which were apparent to users, and others that were more latent.

One critical need quickly revealed during this discovery process was mitigation of “fear.” Many of the elderly individuals interviewed were keenly aware of their risk of hip fracture, as well as the associated decrease in mobility and quality of life that occurs after such an event. This fear was explicit, captured by many vivid and emotional stories told about friends or loved ones who had experienced hip fractures and subsequently suffered often devastating consequences.

Other latent needs not directly articulated by users, but observed by the design team, included the challenge faced by many elderly people in putting on particular types of clothes. For instance, the research team observed many seniors struggling to insert a second arm into a jacket sleeve, due to lack of flexibility, or struggling to depress small buttons, due to arthritic hands and lost tactile sensation.

These insights were captured by separating the needs of the target user group from the ideas behind the product.  Going into discovery mode with a “solution-neutral” mindset can help a product team remain objective before becoming attached to particular design directions.

2. Create user segments — Among the qualitative data gleaned from ActiveProtective’s discovery research, a number of distinct user personalities emerged, differentiated by their specific painpoints, motivations, and habits. To put these various personalities into context, the development team created detailed “personas” for each user group. These personas described living situations, degrees of social engagement, levels of mobility, and the painpoints / motivators unique to each group.

These user personas provided the team with a specific vocabulary to reference regarding each segment. More importantly, these personas enabled the team to identify the segments considered to be primary targets for the product. As the saying goes in product development, “designing for everyone means designing for no one,” and the team was determined to focus on the user groups in which both need and likelihood of adoption were maximized.

3. Start with a story (not a demo) — Before extending too far down the design path, it is critical to obtain product-specific feedback. This feedback may relate to the overall product concept, or to specific product embodiments and feature sets. Often, startups want to start these conversations with a demonstration, perhaps in the form of a video or a live product demo. Starting with this type of demonstration generally is not a good idea. The viewer of this demo may realize the amount of time and energy the product team has invested into the creation of the demo prototype, and they will refrain from providing candid feedback due to their association of you and “your baby.”

A better way to start these conversations is through a simple storyboard, which allows an interviewer to provide some context and describe the solution in a low-tech, easy-to-comprehend manner.  The storyboard typically should be presented in a way that objectively illustrates what the product is intended to do. Details surrounding the technology should be avoided, unless there are technology limitations or constraints that could benefit from specific feedback.

Most importantly, take care to avoid biasing the user by “spoon-feeding” the product’s purported benefits and value proposition.  A common mistake when describing a product via storyboard or general verbal description is transitioning into “sales mode.” Inventors may rattle off a long list of the new product’s benefits, which only furthers the association between inventor and product.  It usually is more valuable for interviewers to learn concerns and questions about a new product, rather than receive validation.  The concerns are almost always out there — it’s just a matter of conducting the interview in a way that elicits them.

4. Share multiple models (not just one) — With many new-to-the-world products, there are numerous options related to product architecture.  ActiveProtective ruminated, should the product be a belt? Should it be an undergarment? Maybe a long jacket? Additionally, there often are questions about specific features. How should the product be activated? Should it be colorful and stylish, or muted in aesthetic?

To address key product architectures and functionalities, the ActiveProtective team created a series of use-case mockups and revisited potential users to gather feedback and preferences. These mockups represented the different usability modes identified by the design team. Note that these use-case mockups were non-functional, intended only as “props” used to describe how the product might be used. These mockups were presented to the interviewees to capture feedback on specific concepts and also specific feature sets.

After these concepts were reviewed in their entirety, the users were asked to rank each, from favorite to least favorite. This ranking exercise shifted the conversation to “why” — why was “Concept H” your favorite, or “Concept L” your least favorite? Often, this ranking process yields the most tangible data that can be used for advancing a design.

The alternative approach taken by most startups is to present a single demonstration unit, typically more functional in nature.  This “show-and-tell” generally will provide binary feedback – “I like it” or “I don’t like it.” Since there are no comparisons to reference, it is difficult to identify the rationale behind likes and dislikes.

5. Understand short-term and long-term reactions — User feedback and reactions generated by an in-person interview generally are based on snap judgements. While these initial reactions are informative, they may differ from the long-term response and adherence to a new product. ActiveProtective recognized this potential disparity and designed an extended-use case study, leveraging a group of 30 users to evaluate the longer-term perspectives.

During the study, individuals were asked to wear a non-functional belt mockup for 28 days, while keeping a daily journal to capture how the belt fit (or didn’t fit) within their daily activities and routines, as well as to record any suggestions for design and usability improvements. User perceptions of the product were captured in Day 1 and Day 28 interviews to measure changes over time. A sensor contained within the belt tracked when the belt was being used. The users were informed that the belt was non-functional, so the benefits that they would gain from participation in the study were minimal. Despite this caveat, a broad base of users was willing to participate, and valuable insights were gained that never would have been revealed in scripted, face-to-face engagements between users and developers.

6. Pricing – don’t go there — It is tempting to broach the subject of pricing during user feedback sessions.  While understanding pricing is critical for business viability, asking users about pricing thresholds related to a new product will almost always yield unreliable data. It is not uncommon for users to suggest high pricing levels during an interview session, only to respond very differently when it is time to make a purchase.

A better method to gauge price elasticity is to observe other products in a user’s environment that provide similar value. In the ActiveProtective case, it was reasonable for the product team to understand whether target user groups were investing in patient remote monitoring systems (e.g., Life Alert). Using existing systems with comparable benefits as a baseline, and adjusting price levels to account for advantages or differences in functionality, can be a reliable approach to assessing price levels early in development.

Gaining Reliable User Feedback Is A Science

As the methodology above suggests, reliable user feedback is born of a strong process. This process should be treated no differently than any other science:  Protocols should be developed, interviews should be conducted consistently, data should be captured, and the results should be analyzed thoroughly before conclusions are drawn.  This will arm you with the confidence to answer that all important question: “Will people use it?”

 Written by Eric Sugalski

Written by Eric Sugalski

Eric Sugalski is the founder and president of Archimedic, a contract medical device development firm with offices in Boston and Philadelphia. Sugalski has led the development of a novel pediatric life support system, cardiovascular implants, laparoscopic surgical devices, and an array of wearable diagnostics. In addition to his technical background, Eric provides companies with product development strategy that encompasses regulatory, reimbursement, and fundraising requirements. Eric obtained a B.S. in mechanical engineering from the University of Colorado Boulder and an MBA from the MIT Sloan School of Management.


What commonly happens with startups is that they laser focus on rapidly building the “thing,” rather than testing the value or benefit provided to a customer.

Originally posted on Med Device Online

Written by Eric Sugalski, Founder and President of Smithwise

Minimum viable product (MVP) is a strategy that has gained rapid and widespread acceptance among the startup community. Used effectively, it can be a compelling strategy to evaluate product-market fit, which often is the largest risk facing a new medical device company. The idea of MVP is to focus a product or service on the key value that it provides to a customer.

What commonly happens with startups is that they laser focus on rapidly building the “thing,” rather than testing the value or benefit provided to a customer. Consider the following example:

A new startup, CleanScrubs Inc., has seen a trend in the marketplace. Scrubs, the sterile clothes worn in operating rooms and other clinical environments, are commonly seen in subways, cafes, and grocery stores. CleanScrubs ponders that clinicians have come to think of scrubs more as a uniform than a sterile article of clothing that should be donned within a clinical environment. Meanwhile, hospital-based infectious disease runs rampant, drug-resistant bacteria are on the rise, and billions of dollars are being invested to control this problem. Moreover, hospitals have large staff and, consequently, large costs associated with cleaning these scrubs (when clinicians actually leave them at the hospital).

The founders of CleanScrubs, two bright young engineers freshly minted from top-tier universities, believe they have a compelling solution to this problem. They envision a system that receives dirty scrubs and then washes, sterilizes, presses, and packages them for bulk storage within the hospital. The process is fully automated, requiring only one person to toss the scrubs on the conveyor, reducing labor costs of the in-house medical laundry staff. The engineers dub their invention “ScrubBot.” They figure ScrubBot should be able to offset hospital costs and reduce hospital-acquired infections (HAIs).

The monetary benefits of ScrubBot are limitless. The engineers sketch out various embodiments of their system and file a provisional patent. Even though the provisional has been filed, first-to-market offers a big advantage, and secrecy will be maintained throughout development — CleanScrubs will operate under “stealth mode” for the foreseeable future.

Having heard about the Lean Startup movement and MVP strategy, the engineers aim to build a prototype, fast and cheap. Putting their skills to the test, they connect tubes, hoses, motors, and other hardware purchased primarily at Home Depot. After six months of hard work and ramen noodles, they finally have achieved their MVP. It isn’t pretty, but it works (occasionally); it’s about the size of a Honda Odyssey and it’s as loud as a jackhammer on concrete. Also, there is an odd burning odor after the system runs for a few minutes, but hey, this is MVP.

What’s up next is that it’s time to share ScrubBot with hospital administrators and venture capitalists (under a non-disclosure agreement, of course). Landing pre-orders and investment should be relatively straightforward now that their MVP is running, right?

A large number of startups take this approach. They use MVP as a license to focus their efforts on building something fast and cheap. They know that getting feedback from end customers is critical, but they think that deferring that feedback until the MVP is complete is the best strategy for reasons of confidentiality and speed. But as a rule, most of these startups fail miserably.

Why? MVP is not about the product itself. MVP is about the customer’s willingness to adopt and pay for the product. Figuring out whether organizations or individuals will pay for the product often is the largest challenge facing new companies. The goal of MVP is to test the adoption and payment assumptions as early as possible. Building up the ScrubBot from the beginning is the opposite of MVP.

Consider now this revised version of the example above:

Around the same time of CleanScrubs’ inception, SmartScrubs is launched. They have made similar observations regarding scrub usage, hospital infections, and the related costs.

The founders of SmartScrubs, a recent MBA grad and a microbiologist, want to tackle this problem and make a business out of it. They start by defining the basic problem that they are looking to solve: Clinicians wear scrubs outside of the hospital. Next, they ask, “What is the reason for this behavior?”  They speculate the following:

⋅ Clinicians think that scrubs are made of a special bacteria-resistant fabric.

⋅ Clinicians are busy people, and they can’t take time to swap their clothing multiple times per day at the hospital.

⋅ Scrub wearers want the public to know (or think) that they are doctors.

⋅ Scrubs are comfy.

SmartScrubs’ founders table these speculations and decide to get some feedback. They reach out to local academic and community-based hospitals, and they speak with a variety of administrators, doctors, and nurses. They gather a variety of opinions on the subject and they walk away with a key realization – the hospitals that were visited have grown rapidly in recent years, and the in-house medical laundry facilities have not been able to keep up the pace. As a result, clean scrubs are not readily available within the hospital, and many clinicians simply are taking home and washing their own scrubs. Additionally, the hospitals view in-house laundry facilities as low-value cost centers, and there is little interest in investing new capital to expand these facilities.

The SmartScrubs team digests this information, and they come up with an idea to replace the in-house medical laundry facilities with a system that automates the full cleaning, sterilization, and packing process. They also devise a reward system that incentivizes clinicians to deposit scrubs in designated hampers throughout the hospital. The system is fairly involved, requiring robotic washing systems, RFID tags on customized scrubs, sensor-equipped hampers to detect scrub deposits, and sophisticated software to manage the clinician reward system.

The SmartScrubs team considers its MVP strategy. They realize that their two underlying hypotheses are as follows: hospital administrators will pay for this service, and clinicians will be sufficiently incentivized to utilize this service. While robotics and software may be the long-term plan for SmartScrubs, they realize that they are a long way from achieving this status. They need a way to evaluate their baseline assumptions quickly and cost-effectively.

The team comes up with a strategy for manually delivering the bulk scrubs. They call the hospital administrators who were engaged during the feedback process, and they find two hospitals that are willing to participate in a three-month trial. The team then contracts an outside medical laundry service to provide the cleaning. Additionally, they purchase four large hampers for each hospital, and they hire temp workers to manage each of the hampers. They also provide clinicians with punch cards for their scrub return reward system. They then run this process for three months.

During that time, the SmartScrubs team collects quantitative data on the compliance rate of individual clinicians, while also collecting data on the economics of providing the cleaning service, and the administrators’ willingness to continue the paid service. In addition, the team collects qualitative data from administrators and clinicians on the system, its use, and potential areas for improvement. After reviewing this quantitative and qualitative data, the team begins to plan for its next-generation system, and they feel well-positioned to raise capital to achieve their next business milestone.

In the example above, SmartScrubs deploys a logical MVP approach. Note these key differences between SmartScrubs and CleanScrubs:

1) SmartScrubs realizes that they may not fully understand the problem. They conduct primary user and customer research to evaluate the problem, and to clarify any of their operating assumptions about the problem. CleanScrubs assumes that they fully understand the problem. They jump straight into solution building but miss the mark big time.

2) SmartScrubs focuses their solution on the end benefit to the customer, which is delivering clean scrubs. During their trial run, they use a manual process to achieve their milestone quickly and cost effectively. CleanScrubs focuses their solution on the product — a hacked-together robot that is too big, loud, and scary, and only occasionally functional. CleanScrubs thinks the robot is the product, but the product actually is clean scrubs.

3) SmartScrubs engages users and customers throughout their process. They engage these stakeholders as valuable parts of the conversation that are able to provide guidance and feedback. They are able to leverage these relationships during trial runs during the MVP testing phase. CleanScrubs stays in “stealth mode” and tries to sell their MVP to hospitals and investors. They secretly build the wrong product.

Again, MVP can be a powerful strategy for startups to leverage when testing business assumptions. However, common misinterpretations of MVP can send startups down the wrong path.

 Written by Eric Sugalski

Written by Eric Sugalski

Eric Sugalski is the founder and president of Archimedic, a contract medical device development firm with offices in Boston and Philadelphia. Sugalski has led the development of a novel pediatric life support system, cardiovascular implants, laparoscopic surgical devices, and an array of wearable diagnostics. In addition to his technical background, Eric provides companies with product development strategy that encompasses regulatory, reimbursement, and fundraising requirements. Eric obtained a B.S. in mechanical engineering from the University of Colorado Boulder and an MBA from the MIT Sloan School of Management.

Three Strategies To Achieve Big While Spending Small

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

Originally posted on Med Device Online

Written by Dave Perry, Director of Product Development Strategy at 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.


Boston Device Development is now Smithwise. The Boston-based company opened a University City office in January, and is gunning hard for the life sciences space.

Article reposted with permission from Philly

Written by Roberto Torres – Check him out on Twitter @TorresLuzardo


There’s another name change in the Philly tech scene, but this time it has nothing to do with pronunciation and more about reaching out to the city’s growing healthcare sector.

Boston Device Development — an 18-employee product design, engineering and manufacturing firm founded in 2009 in, yes, Boston — now goes by Smithwise. They threw a little party to celebrate.

This January, the company set up an 11-person operation out of One Drexel Plaza — a ten-fold expansion to its previous one-man operation in Malvern.

That one man was Eric Sugalski, the company’s founder and CEO. The Malvern-raised MIT grad was splitting his time between Boston, where he founded the organization, and the Philly ‘burbs since 2013.

According to Sugalski, the name change is a nod to the company’s expanding operations in Philly, where the health-tech scene is also burgeoning.

“We see huge opportunity in Philly,” Sugalski said. “We see a lot happening in local universities and the startup world. We’re helping some companies create laparoscopic surgical devices, pediatric devices, systems to improve medication, and more.”

The play for Philly’s growing life sciences space is evident. With $1.4 billion in National Institutes of Health funding, Pennsylvania’s major academic centers like the University of PennsylvaniaCHOP and Jefferson are a desirable target for any up-and-coming B2B tech company.

But what does Smithwise bring to the already crowded table of service providers for healthcare initiatives? Sugalski’s pitch can actually be found in how he breaks down the new name:

“The ‘Smith’ part is a recognition to builders and building, which is part of our core business,” he said. “And then the ‘wise’ part honors the fact that we use our team’s collective wisdom to focus our efforts in the right places. We can take ideas from the napkin sketch to functional medical devices.”


Read the original article here