Clayton Christensen's company made a ceramic engine part in the 1980s, and it worked. It was lighter than the metal it replaced, the lighter part changed the balance of the engine, and the automaker cancelled the program rather than redesign an engine around a supplier's component. Nobody made a mistake. When he told me that story on a flight years later, I heard what he had heard: the boundary is real.
What I have spent the years since on is how to work across those boundaries. Build the engine part and you still sell to an engine program. Build the cell and there is still a pack, a UPS and an operator's power architecture above it. For a pure material the chain is longer and more complex: a cathode powder passes through a cell maker, a pack maker, a system integrator and an operator before anyone runs a data center on it, and every step is a boundary with its own owner, its own requirements and its own clock. Unless you integrate all the way to the final user, there is always at least one boundary you do not own, and the work of a materials company is building a bridge across it to the people who do, without giving away the one thing that makes you worth the trouble. The bridge is where the work is. The moat is what lets you afford to build it.
As a mentor at Greentown Labs, the largest climatetech startup incubator in North America, I teach a session called The Moat and the Bridge. Every company's situation is different, and the same few mistakes keep deciding the outcome, which is why I keep teaching it. And every time, when the room empties or the Zoom call ends, a founder hangs back. There is a term sheet, or a JDA they already signed, or a proof of concept that ran start to finish on the partner's line. They do not ask me whether the deal is good. They know. They ask whether it is recoverable.
Usually it is, and usually the damage was done long before anyone opened a document. The founder built the bridge before understanding what was on the other side of it. I have made similar mistakes with corporate cover behind me, so this is not about inexperience. The moat is what you know and have to keep. The bridge is what the partner has and you have to reach. Guard the moat without building the bridge and you have a well-defended material nobody uses. Build the bridge and forget the moat and you have a customer who no longer needs you. This essay is about managing that boundary, and the best way I know to do it: build the bridge, keep the moat, and understand what neither of them can do.
What is on the other side
Start with what each side wants, because it is rarely said out loud. The startup wants market access, a first customer, an investor signal, and money. The corporate wants a technology it does not have, a problem off its list, and a return on the time it spends on you. In the survey data I use in the session, only about one startup in five has milestones its partner would call shared, and more than seventy percent of these partnerships fall short of what both sides expected. I doubt those two numbers are independent.
The material company knows one material deeply: why it behaves the way it does, what destroys it, where the real process window sits against the one on the spec sheet. Founders price that correctly, and they try to price most of what the partner has: scale, a qualified line that makes tons to a specification; system knowledge, how a new input behaves inside the product and which test failures are real; and capital on a long clock, where a three-year qualification is ordinary.
Founders leave the fourth asset off the list, and in my experience it is the most valuable one. The partner holds the right to qualify. The first essay's rule was that evidence about a product is generated at the product, and the partner usually owns the site where that happens. It also owns the standing that makes the evidence count. In an automotive program the cell maker runs the A, B and C sample stages, the carmaker runs vehicle validation and homologation, and nobody else's data is admissible.
The requirements do not stop at the first customer. A cell going into a data center has to be integrated three times over: into a pack, into the UPS or storage system that an integrator like Schneider Electric or Vertiv builds around the pack, and into the power architecture of the data center operator running an AI cluster behind it. Each layer adds requirements the cell maker never sees on a spec sheet, the pack's thermal limits, the system's safety certification and duty cycle, the operator's load profile, and only the party at each step knows what they are and how to meet them. That knowledge you cannot buy, rent, or build inside a runway. When a founder tells me the partner is slow, they are usually describing the partner doing the one thing the founder cannot do.
One consequence decides more programs than any clause. Whoever runs the qualification interprets the result. A test that ran on the partner's line under the partner's protocol produced data the partner saw first, in a context the partner understands and the material company does not. In practice that result belongs to the partner, whatever the JDA says about data ownership. The founder in the emptying room owns a result they cannot defend on their own. Recovery looks like a paid second phase with success criteria you wrote, part of the testing on your own equipment or at a lab both sides accept, and the raw data in the exhibit rather than the verdict. That costs a quarter and some pride. A year of samples answered by verdicts you cannot interpret costs more.
Which bridge to build
A part maker knows its customer. A materials company usually does not, because the same material can go into an AI data center, a semiconductor fab, a tire or a defense system, and those are four different worlds. The partner is different, the performance that matters is different, the qualification is different, the clock is different. A cell maker tests in months against a UL protocol; a defense prime tests in years against a specification it cannot show you; a tire OEM tests on a track. Finding out which of those markets your material fits is product-market fit, and for a materials company it is a loop rather than a decision: try an application, learn what it needs, adjust the material, try the next. The trouble is that each JDA consumes people, months and a share of your runway, so you can afford two or three of them, not eight.
That is what prototypes and demos are for. A demo at the right scale, in something that looks like the application, tells you whether a market is worth a JDA before you have spent one on it. Two things make a demo work. Enough material to build something real, because a coin cell tells a UPS integrator nothing. And enough understanding of the application to know what to demonstrate, which usually means hiring or borrowing somebody who has worked on the other side of that boundary. The founders who skip this step and sign a JDA with the first partner who returns their call are the ones who stay behind after the session.
The life of a program
The program begins with an NDA, where the mistakes are cheap to avoid. Name your trade secrets as a category, not as a subset of confidential information. Strike the residuals clause, which lets the other side reuse whatever its people remember, and what people remember is the process. Do not disclose before you have filed.
Then comes the proof of concept, and this is where most programs stop. The numbers I collected for the session: twenty to thirty percent of pilots convert to paid work, forty percent of the technical successes die afterward in procurement, and a free pilot sits in limbo about three times longer than a paid one. Lead the pilot rather than be led through it. Write the hypothesis yourself. Set one shared goal in writing, with a go or no-go decision at forty-five to ninety days. Charge for it. The fee measures their seriousness. Share what the material does, not what it is or how it is made. And keep two other customer conversations alive, because a founder with one serious partner and eighteen months of cash is not negotiating from strength, and the other side can read a runway.
If the pilot survives, the JDA follows, a business deal and an IP framework in one document. Background IP goes into an exhibit. Foreground ownership needs to be assigned before the work starts, not after somebody has invented something. Exclusivity is traded for volume and never given for access, and the break-up terms are written while everyone is still friendly. The traps are joint ownership left undefined, grantback creep, and accidental joint inventorship, where a partner's engineer suggested one change and is now named on your patent.
At scale the danger changes from disclosure to lock-in, and the protections change with it: the right to sublicense for manufacturing, a defined field of use, a clean exit, and not letting one customer become the company, which is what the first essay's Panasonic story is about. The one rule I would keep if I had to throw the rest away: never let the disclosure get ahead of the relationship.
What you are protecting, and from whom
In materials the process secret usually outlives the patent. A composition patent publishes within eighteen months and expires after twenty years. The process window that makes the composition work at ton scale stays secret for as long as you keep it, and a competitor cannot infer it from the product in their hands. So decide element by element. Patent the integrated system and the claims a competitor's product would visibly infringe, and keep the process parameters, the data and the models behind the unglamorous system that makes a trade secret real: need-to-know access, a register, logs, and an offboarding checklist.
There is a Silicon Valley view that you move fast and sort out the IP later. For a company the size of Apple or Tesla it works, most of the time. Even Apple had to switch off the Apple Watch blood-oxygen sensor in the United States for a year and a half after Masimo won at the International Trade Commission. In materials, where the product is the process and the process is the secret, later usually means never. The other view I hear is that China and Korea do not care about IP, so filing there is wasted money. My experience is the opposite. Filing and establishing IP in China and Korea is what protected the operations I was responsible for there, and CATL, LG Energy Solution and Samsung are among the most prolific patent filers in the world. They take IP seriously because it works on them too.
Founders assume the moat is a small-company problem. The largest trade-secret case in the battery industry was between two established companies. LG Energy Solution and SK Innovation settled in 2021 for 1.8 billion dollars, after the International Trade Commission ruled that SK had misappropriated LG's trade secrets in a case built around employees who moved from one company to the other. Size is not a defense. The leak path is people and partners, which is why collaboration discipline is your IP protection and not a constraint on it.
The bridge is not a small-company problem either. Two established companies have the same structure underneath as a startup and its partner: two bodies of tacit knowledge that do not transfer by document, one site where the evidence is generated, a contract that cannot specify experiments nobody has designed. What changes is the symmetry. Nobody blinks, so programs stall rather than die, and they can stall for years. Add a third party, a cathode supplier, a cell maker and an OEM, and every added company adds a boundary and a clock. The slowest clock wins.
There is a Nobel Prize in why the contracts do not help. Oliver Hart's observation is that contracts are necessarily incomplete: no agreement can specify what the parties should do in circumstances nobody anticipated when they signed, so what a contract allocates is residual control, the right to decide about everything the document did not foresee. On signing day of a joint development program nobody knows which formulation will win, which requirement will bind, or what the third iteration should look like. The agreement says who decides and who owns the result. That is all a contract can do, and it is why good terms do not save these programs. Structure protects the moat. It does not build the bridge.
The people who build the bridge
The question I get most often after the session is not about clauses. It is how to find the person on the other side who will push.
You need two, and they are usually different people. The first is a champion at the level where strategy is made, someone moved by the customer narrative, who can explain to their own leadership why this matters to the company. That person gets you the budget and the air cover. The second is a technical or business champion, someone moved by your hypothesis about their problem. That person gets you line time and honest data. Air cover with no line time produces a program that exists on slides. An engineer who believes in you and cannot get a slot on the line produces a friendship.
Finding them starts with a hypothesis about why this company needs you now. The shortest route I know is to ask the engineer who ran your sample who signs off on the platform decision, and then to ask that person what they have been told to deliver this year. Then protect the relationship. Know what the champion is measured on, and if a champion goes quiet, find out why, that week. A champion going quiet is the earliest warning you will get, months ahead of any letter, and losing one is how most programs I have watched end. Nobody cancels them. They stop being pushed.
A goal only one side holds is not shared. The test I use is whether each side's champion could present the next milestone to their own boss as a win, in their own language. If either one cannot, the milestone is wrong. Under-commit and over-deliver, because credibility on the other side is built one delivered sample at a time and lost with one slipped promise. Yours is the time to deliver. Theirs is the time to evaluate, and their clock is not yours to shorten.
If you sit on the corporate side, read that as a mirror. Your side has the two champions or it does not, and if the supplier cannot name them, the program is not real yet. Your pilot has written criteria and a date, or it is a free option you will let expire. The sample you sent back with a verdict cost the supplier a quarter of its runway to make. If you want the next one closer, return something they can interpret. The corporates that get the most out of small suppliers treat the pilot as a purchase rather than a favor, and they get better materials for it.
Then there are the cultures, three at once. The startup's clock is runway, so a founder will rationally accept technical risk to save three months. The corporate's clock is the product program, where a field failure is a career event. Each is right to. Inside the partner, procurement does not care about your champion and the plant manager is measured on utilization. Until a program has friends in both places, it has not made it inside the company. And working in a global company taught me to take national culture seriously. A yes that means we will study it and a yes that means order the raw material sound identical to a founder who has only ever heard one of them. One of the best compliments I received came in a review with a major Japanese OEM: that the Cabot team behaved like a Japanese company, understanding the need and responding to it.
The order, the way I say it in the session and in my advising: relationship, then contract, then IP. No clause saves a broken relationship, and the contract exists to keep it working, which is why it should say how disputes get resolved before anyone has one. Good projects are well defined and they succeed, and poorly defined projects do not.
What crosses the bridge
Suppose you do all of it: the right market, the qualification asset priced at its real value, both champions found, procurement on your side. That is a well-managed program, and it is rarer than it should be. This essay, and most of my advising, is about tilting that balance toward the company bringing the new material. Yet even then the program runs on one channel, because three gaps remain that no amount of management closes.
The first is knowledge. The supplier's understanding of its material lives in the heads of three or four people, and the partner's understanding of its line lives in the heads of a few more. Neither transfers by document, because you can only absorb information you already have neighboring knowledge to interpret. The supplier has never run a qualification, so the partner's instincts bounce off. The partner never spent four years failing to make this material, so the supplier's intuition bounces off too. Cohen and Levinthal called this absorptive capacity, and Szulanski found the same friction between two plants of the same company. Between companies competing for the same margin it is worse.
The second is capital, and the problem is the clock rather than the amount. The startup's money runs out in eighteen months, and the partner's next program review is in three years. Trust does not close that difference. It only makes it visible earlier.
The third is manufacturing, and founders often rank it last when it belongs first. For a hardtech company, manufacturing is what makes it a company. A startup makes grams reproducibly, kilograms on a good month. The partner needs tons, from a qualified line, with a documented history. Between those two states sit pilot scale, process transfer and a qualification campaign, and the material that worked at a hundred grams frequently stops working at a hundred kilograms. Particle size drifts. Impurities that never mattered start mattering. The startup discovers that its material was partly an artifact of its own process, at the point where its knowledge is thinnest, because the party with the least experience of scale is the one being asked to guarantee it. It takes twice as long and costs more than you think, and if you plan on that basis you will be fine.
Together the three gaps produce a failure that runs in the same order almost every time. Capital pressure pushes the supplier to promise a drop-in material, and a drop-in claim asserts that no validation boundary exists at your interface. The manufacturing gap falsifies the claim: at real scale on a real line the material moves the process window and changes which requirement is limiting. Then the knowledge gap blocks the explanation. The partner cannot describe what changed on its line without exposing the line, and the supplier cannot describe what varies batch to batch without exposing the batch process. What survives all three constraints is one channel. Samples out, verdict back.
You ship the sample. You wait three weeks. The reply is a smiley face. It can be a literal emoji. I have seen it too many times. That is good news, technically, and you still have no idea what to make next. A better, neutral or worse reply carries at most about 1.6 bits. Identifying one of 256 equally plausible options would take eight. Private knowledge narrows that gap, though not to 1.6 bits, and every reply has to be reinterpreted when the formulation changes or a different requirement becomes limiting. Von Hippel saw this decades ago: when the information a problem needs lives at two sites, the problem does not relocate, it iterates, and iterating is affordable only if what passes back and forth is less sticky than the underlying information. Here the sample is expensive and the verdict carries almost nothing, so the loop can run for years without converging.
One complete-product test is a real batch, a formulation built around it, a slot on a line, and a run at application scale with people standing around the equipment. In my experience that is multiple people-months. At an illustrative two person-months per test, forty tests consume about seven person-years; fourteen hundred consume over two hundred, on the same chemistry, with the same people. A large integrator eats that as a program delay. A startup with eighteen months of cash cannot. The same inefficiency an incumbent books as frustration, an entrant books as death, which makes coordination a filter on which technologies reach the market at all, and the filter has nothing to do with whether the material was good.
I have been part of more than a hundred joint development programs, on both sides of the table. Twenty to thirty delivered what they were signed to deliver. That is personal experience, not an industry statistic. But very few of the failures were failures of the material. Most ran out of appetite: one more round of samples whose result nobody could explain, and somebody senior said enough.
So the requirement: whatever mechanism runs the program has to let each side send enough for the group to decide what to build next, and not enough for anyone to reproduce what the other side does. Share what it does, not what it is or how it is made. For most of my career I assumed no such mechanism existed. The next essay is about the one I built.
