Sign up for updates. Be part of our community.

Technical Founder 101: Communicating with Non-Technical Stakeholders

Of all the hats a technical founder must wear, ‘Ambassador to the Nontechnical World’ is one of the most important. Unlike many research concepts which can remain for decades in a rarified realm of journal publication and grant funding, ideas preparing to run the startup gauntlet will in every case need the strategic and financial support of nontechnical allies.

A lot of early work revolves around identifying, engaging, and sometimes selling advisors and investors on an opportunity emerging from a complex biological, engineering, or computational discovery. The success or failure of the venture may depend on your ability, as a technical founder, to both educate partners and update them as problems arise during development, beta testing, or scale-up. Making every effort to get this right is essential. If you fail to explain your product’s underlying complexity in a reassuring way, you may never receive that first round of financing. If you gloss over problems or are perceived as having misled partners about important technical shortcomings or threats, the damage to your reputation may be profound. You may never, as the saying goes, work in this town again.

Below are three important lessons I learned as the technical founder of my first startup, ones that I carry with me today when I find myself on the ‘other side of the table’ from inventors and technical founders.


The most important advice I have for you is to never frame the challenge of communicating the basics of your technology as ‘dumbing it down.’

This is a very risky headspace to be in when speaking with someone who may be able to provide you with much needed advice or much needed capital. Rather, take a page from the physicist Richard Feynman who believed that if you can’t explain a principle to a college freshman, then you yourself don’t yet understand it. In any case, if you are sitting down with someone who can provide you with hundreds of thousands, or even millions, of dollars, chances are they know a lot more than a first-year undergraduate and they almost certainly are not dumb. Your task is to translate your technology so that these folks – experts in unrelated fields – can both readily explain it back to you but also have some intuition about the types of problems likely to be encountered during development.

Getting the description of your technology to where it needs to be will require practice. In your first conversations with advisors or investors, you will probably be seeking something like a ‘minimal viable explanation’ that will improve over time. Look for accessible analogies from other fields, or better yet everyday life, and look for readily available visual aids. In my first startup, we were pretty effective in describing our technology for isolating circulating tumor cells from patients, using a bowl of M&Ms.


No matter how good you are at explaining what your technology does, at some level it will still be a black box to many people in your startup’s orbit. It usually can’t be helped. When things are going well, having a stake in a black box is not really a problem for an early stage investor. However, when things go badly (and things usually do, at least for a while) folks will start to become very curious, and probably worried, about what exactly is inside that box.

Importantly for you and your team, it’s essential that the box isn’t black for everybody. Someone (or preferably a team of someones) needs to know exactly what is inside. When things go sideways with your technology, there needs to be a plan for communicating in increasing detail how the thing works and what’s gone awry. My experience is that conversations around these details can be difficult. When things were working, your technology was a thing of wonder. Once trouble appears and you have to start digging into the inner workings, your technology can be a source of confusion and, critically for investors, wariness.

This is when your communication must be at its peak. You’ll need to drill down on the technical problem in a thoughtful and frank way. Avoid jargon. Frame the issue in terms of how it impacts your value proposition and user experience. When possible, a discussion of a problem needs to include an accompanying plan for how to move ahead. What new advisors or consultants will be needed? Have they been contacted? What will a fix likely cost? How will this impact the short-term burn rate and the long-term COGS? Is the problem a nuisance or a company killer? How and when will you be able to know which?


Implicit in all the above is the issue of uncertainty and technical risk. It’s hard to predict the future, especially around a new venture, and there is always a chance that what you have created just won’t work. It can’t be made reliably, or to scale, or won’t hold up under use. It may be too complicated. Whether you have personally come to grips with this reality or not, any experienced partner will have, and it will be baked into their appraisal, and even valuation, of your startup.

Beyond the facts, you need to understand the lens through which you view your work. As a technical founder you likely came from a science or engineering background in which you were trained to couch your conclusions. As a result, you may acknowledge (perhaps with undue weight) how much remains unknown about the science underlying your technology. Or, you may alternatively assert (perhaps with undue confidence) how well any technical problems are being managed. Additionally, it’s easy to look at the overall riskiness of what’s happening from your financial perspective. You won’t have much insight into how your investors are viewing your enterprise in terms of risk, especially in light of the rest of their investment activities.

There’s no reason why you and your partners should inherently share a framework for uncertainty and risk. As a result, smart technical founders will engage these topics early. You should be careful not to do so in a way that sets off alarms regarding your technology. Rather, let your partners know that it’s important that you share a common understanding about what is knowable and what is not, which uncertainties demand clarification and which can be expectantly followed, and what process you’ll use to update them, in a proportional way, on the severity of issues as they arise.

The role of technical founder is one of the most exciting roles in any new startup. It’s a chance to think about science and engineering in a deeply applied way. It’s also a chance to position yourself as a thoughtful expert in circles you may have never traveled. Communicating the promise, limitations, and threats of your invention or discovery to non-technical partners is a challenge that will arise early and often. Take time to frame your ideas in an accessible, non-condescending way. Be ready, when troubles arise, to start introducing your partners to the true nuts and bolts, but with a focus on identifying problems and solving them.

Lastly, remember that everyone in a startup approaches the opportunity with differing appetites for uncertainty and risk. Assuring a common understanding of how uncertainty will be evaluated and communicated, even when the technical details may become heady, will help build the kinds of bonds that will be needed for your startup’s early days.