Most connected-device and drug-delivery companies build the product to survive an FDA review, then start thinking about commercialization once that review is behind them. For a connected device, one that talks to a phone or the cloud and generates a dosing history someone has to interpret, that sequence is backwards. The decisions that make a connected product commercially viable, who the customer actually is, how the device earns trust with that customer, and how its data gets governed, have to be made before clearance, not after it. By the time the clearance letter arrives, most of those decisions have already been made by default, usually badly, by an engineering team that was never asked to make them.
I learned this the hard way, or rather I learned it by watching other people learn it the hard way, while running device commercialization inside Sanofi. I worked on a connected glucose meter, on connected insulin pens, and on continuous glucose monitoring integration, at a point in my career when "connected device" still meant something genuinely new inside a pharma commercial organization. The device teams were extraordinary at getting through FDA review. Almost none of them had been asked, early enough, who the device's data actually belonged to, what a physician was supposed to do with a dosing pattern nobody had defined a threshold for, or what a patient was supposed to feel the first time the device told them something about themselves they did not expect to hear. Those are commercial questions. They got treated as regulatory afterthoughts, and the commercial team inherited the mess.
The argument is not that commercialization matters. Everyone in MedTech already agrees it does. It is narrower and more useful than that. For a connected device specifically, the commercial operating layer, the customer model, the channel, the measurement plan, and the security and data-lineage decisions, is not a parallel workstream to regulatory. It is regulatory. The company that treats it as a post-clearance problem is choosing to build its commercial foundation twice, once badly under engineering assumptions, and once properly, late, under a launch deadline it did not choose.
The macro-thesis everyone in MedTech now agrees with, and almost nobody executes
Some of this is not new. A board member reading it has already seen a version of the surface argument. "Build commercial in parallel with regulatory, not after it" is now standard doctrine across the MedTech consulting world. Veranex says it. NAMSA says it. The Matchstick Group says it. Every serious commercialization shop has converged on the same baseline claim, and they are right to.
The more useful fact is that agreeing with the doctrine and executing it are two different things, and almost every company still does the second one badly. The pattern is consistent across the industry: marketing gets brought in after 510(k) clearance, sometimes weeks before the actual launch date, to build from a standing start what should have been under construction for a year. The gap between what everyone says should happen and what actually happens is where companies stall quietly. Not with a dramatic failure. With a launch that slips, a sales team that has nothing coherent to say in month one, and a board that starts asking why clearance did not translate into revenue.
There is a specific piece of writing worth naming directly, because pretending it does not exist would be dishonest and because engaging with it sharpens the actual argument. On June 3, 2026, Denise Steinbring of Chief Outsiders and Linda Bernier of SmartTRAK published a piece making close to this exact case, naming an AI Commercial Operating System for lean MedTech teams and arguing commercial planning needs to start well before launch. It is a good piece, and it is right about the macro-thesis. I am not going to pretend I got there first, because the doctrine itself is now shared ground across the fractional-CMO and MedTech-advisory world, and any company doing diligence on who to hire should assume every credible advisor is saying some version of it.
What that piece does not do, and what almost nothing published on this topic does, is go anywhere near a connected device specifically. Its examples sit in orthopedics, wound care, and neuro, categories where the product is the product and the data trail mostly ends at the implant log. A connected device is a different animal. It generates a continuous data stream, it often ships alongside a drug, and it creates an ongoing relationship with the customer that a hip implant does not. The commercial architecture questions are different in kind, not just in degree. That is the gap I have actually operated inside, not studied from an advisory chair.
Why "connected" changes the commercialization problem
A standalone device has one customer relationship to design: the clinician who orders it or the patient who receives it once. A connected device, especially one paired with a drug, as in an insulin pen, a connected inhaler, or a glucose monitoring system, has at minimum three customer relationships running simultaneously, and most commercialization planning only accounts for one of them.
The prescriber is a customer, and needs a reason to trust a data stream they did not ask for and were not trained to interpret. The patient is a customer, and needs the device to build a habit, not just deliver a dose, because a connected device that gets abandoned after three weeks generates worse outcomes data than no device at all. And increasingly, the payer is a customer, because reimbursement conversations for connected and combination products are starting to ask what the data stream proves about adherence and outcomes, not just what the device does. A generic device go-to-market plan asks "who buys this." A connected device go-to-market plan has to ask "who buys this, who has to trust the data it produces, and who is going to be shown that data six months from now to justify continued coverage." Those are three different commercial designs, and building them after clearance means building them under a launch clock instead of with the time an actual customer relationship deserves.
This is also where the "device plus data plus often a drug" framing matters more than it sounds like it should. A combination product commercialization plan built the way generic device go-to-market frameworks describe it treats the drug and the device as one bundled thing with one customer story. In practice the drug has its own customer story, built over years of clinical experience, and the device is asking to be trusted as an extension of that story rather than as a separate gadget competing for attention. Getting that sequencing wrong, leading with the device instead of anchoring it inside the customer's existing relationship with the therapy, is one of the more common and more avoidable ways connected launches underperform. It is a commercial decision. It has nothing to do with whether the device cleared review.
Security-by-design and PCCP are commercial operating-layer decisions, not regulatory checkboxes
The existing MedTech commercialization discourse, including the Chief Outsiders piece, does not say this next part, because it is not written by people who have sat across from a physician explaining why a connected device is safe to trust with their patient's data.
The FDA finalized its medical device cybersecurity guidance in June 2025 and revised it in February 2026, and Section 524B of the FD&C Act now makes cybersecurity documentation a mandatory condition of clearance for connected devices that meet its "cyber device" definition. Security has to be designed in, not bolted on before submission. Read as a regulatory requirement, that is a compliance line item. Read as a commercial planner, it is something else entirely: it is the FDA telling every connected-device company, in writing, that the trust architecture of the product has to exist before the product exists. A physician who is going to recommend a connected insulin pen to a patient is being asked to vouch for a device that reports dosing behavior somewhere. If that physician cannot answer, in one sentence, where that data goes and who can see it, the device has a commercial problem no amount of sales training fixes later. Security-by-design is not something engineering delivers to commercial as a finished fact. It is a decision commercial leadership needs a seat in, early, because the answer to "where does the data go" is the first sentence of the sales story, not a footnote in the privacy policy.
The same logic applies to the Predetermined Change Control Plan, the FDA's mechanism, formalized in its December 2024 final guidance for AI-enabled devices, for pre-authorizing how an AI-enabled device is allowed to change after clearance without a new submission for every update. Companies are treating the PCCP as a regulatory strategy document, something legal and regulatory affairs author to keep future updates cheap. It is that. It is also a commercial promise. A PCCP defines what the product is allowed to become over its life, which means it defines what the sales and marketing team is allowed to promise a customer about where the product is headed. Roughly ten percent of AI/ML devices cleared via 510(k) in 2025 already used a PCCP, and that share is only going to climb as clearance velocity increases, with the median device now clearing in under five months. A commercial leader who is not in the room when the PCCP gets written is agreeing, in advance, to sell whatever regulatory and engineering decided the product could become, without having said a word about what a customer would actually value it becoming.
This is the connected-device-specific whitespace nobody else is standing in. Generic MedTech commercialization frameworks treat regulatory strategy and commercial strategy as adjacent workstreams that report to different people and meet at a milestone review. For a connected, AI-enabled, or drug-paired device, that separation does not hold. The regulatory decisions about data lineage, security architecture, and permitted change are commercial decisions wearing a regulatory jacket. Someone has to sit in both rooms, and that has to happen before clearance, because by the time the product clears, the data architecture is set and the sales story either was designed around it or is fighting against it.
The steelman: Pear Therapeutics had clearance and evidence, and it still collapsed
Pear Therapeutics had FDA clearance. It had clinical evidence. It had genuine innovation credibility, and it still filed for Chapter 11 in 2023. The postmortem is well documented, and my way of putting it is that reimbursement follows structure, not enthusiasm. Pear did not lack a good product or a good commercial team. It lacked a payer structure willing to pay for what it had built, at a price the product could sustain, and no amount of commercial groundwork built before or after clearance changes that math.
That is the real counterargument, and it deserves to be named without softening: building the commercial operating layer early does not manufacture a reimbursement pathway that does not exist. If the payment structure for a category is not there, or is not there at a viable price point, building customer models and data governance frameworks before clearance is capital spent well on a problem that was never the binding constraint. And there is a second, sharper version of this same objection worth naming directly: pre-clearance commercial spend competes for the same limited capital as the clearance process itself, for a device that has not yet cleared and, in a meaningful share of cases, never will. Spending commercial dollars early is not free optionality. It is survival capital redirected toward a bet that has not resolved yet.
Here is my answer, and it is not a dodge. The pre-clearance commercial build this piece is arguing for is not a substitute for solving the reimbursement problem. It is the work that solves it. Building the customer model early means defining, before clearance, who pays for a connected device and what they need to see to keep paying, which is precisely the question Pear's team needed answered years before its capital ran out, not discovered after launch. Building the data architecture early means the outcomes and adherence data the device produces is structured, from day one, in the form a payer's medical policy team will actually accept as evidence, rather than reconstructed after the fact from whatever the engineering team happened to log. This is also what a growing number of investors now look for in diligence. Commercial-intelligence advisors are beginning to describe a shift, with a defined reimbursement pathway, a budget-impact model, and early payer conversations expected as early as the Series A stage, not as a post-clearance scramble. That shift did not happen because investors got more patient. It happened because they watched enough companies discover their reimbursement problem after it was too late to fix cheaply.
So the honest version of the claim is narrower than "build the commercial layer early and success is guaranteed." It is this: the pre-clearance commercial build is the mechanism by which a company finds out, while it still has time and capital to act on the answer, whether its reimbursement problem is solvable. Companies that skip it do not avoid that reckoning. They just have it later, with less money and less room to change course, which is closer to what actually happened to Pear than "they didn't build enough commercial groundwork."
Why AI changes what a lean, pre-revenue team can actually build
None of the above is affordable in the way a growth-stage device company usually imagines commercial build. A ten or twenty person company that is still burning toward its first clearance cannot hire a VP of Marketing, a market research function, a data governance lead, and a commercial analytics team eighteen months before it knows whether the product will clear. That has always been the real objection to "start commercial earlier," and it is a legitimate one. Nobody disagrees that earlier is better. The constraint has always been headcount and cash.
What follows is my claim, not a market fact anyone else has validated. I have not found a single connected-device or digital-therapeutics company on record saying AI let them build the commercial layer without a full team, so I am not going to pretend that trend already exists. What I can say is what I have actually built.
At Novartis, I owned an international commercial content framework spanning multiple therapeutic areas and embedded AI into more than half of the steps I was responsible for, not to polish finished output, but at the judgment points earlier in the process: pressure-testing messaging against simulated customer response before formal research cycles, resolving cross-functional alignment conflicts that used to require someone senior breaking a tie, and running compliance checks on process and content that used to depend on one person's manual review across ten or more brands. That was not a productivity trick applied on top of an existing team. It changed how much commercial work a given number of people could actually own, and it produced a measured 20 percent reduction in operating cost against that scope. That is enterprise-scale proof that embedding AI at the right points in a commercial process changes the size of team a given scope requires.
The more relevant question is not the enterprise one. It is what a twelve-person device company can actually afford before it knows whether the product will clear. The answer is not to hire the team early. It is to build the operating layer so a lean team, or one fractional operator, can run what used to take a full team. AI is what makes that arithmetic work. Specifically, it is using large language models to pressure-test customer messaging before it goes to formal research, to draft and maintain the compliance-adjacent documentation a data governance decision requires, and to keep a measurement system running continuously instead of as a quarterly manual exercise. That is a specific set of mechanisms, not a vague claim that AI helps.
This has limits, and they matter more than a bigger promise would. AI does not replace the judgment call about what the customer model should be, what the security architecture needs to promise, or how to answer a payer's evidence question. Those are still decisions a person with operating experience in this exact domain has to make. What AI changes is how many people you need to execute once that judgment has been applied, and how early a small team can afford to start.
What this actually looks like before your clearance letter arrives
If you are running a growth-stage connected-device, drug-delivery, or SaMD company and you are not yet at the point of building a full commercial organization, the useful question is not "when do we start marketing." It is narrower and more specific than that, and it can be answered eighteen months before your anticipated launch, in parallel with your regulatory submission, by a fractional commercial lead rather than a hire you cannot yet justify.
Define your customer model in writing before the device exists in final form: who is the prescriber, who is the patient, who is the payer, and what does each of them need to see from the data this device produces to trust it. Put your data governance and security-by-design decisions in the same room as your commercial plan, because the FDA has already told you these are inception-stage decisions, and the sales story starts with the same answer the security architecture has to give. If your device is AI-enabled, treat your PCCP as a commercial document as much as a regulatory one, because it defines what you are and are not allowed to promise a customer about where the product goes next. And build your reimbursement and evidence plan as the thing that tells you, while you still have capital and time to act, whether the category's payment structure can actually sustain what you are building, not as a document you write once you already have a launch date.
None of this requires a commercial department. It requires someone who has done this exact motion before, for this exact category of product, working inside a small team and an AI-native operating layer instead of a headcount plan you cannot yet fund.
The concrete takeaway
The commercial operating layer for a connected device is not a workstream you pick up after clearance. It is the customer model, the data trust architecture, and the reimbursement thesis that your regulatory strategy is already quietly assuming, whether anyone has written it down or not. Write it down before clearance, with a lean team and an AI-native operating layer instead of a commercial department you cannot yet afford, and you find out early whether your reimbursement problem is solvable. Wait until after clearance, and you find out late, with less capital and less time to do anything about the answer.