This follows on from The Category Error in Deep Tech. That post was about the difference between a tech company and a deep-tech company. This one is more for my academic friends thinking about the jump: what I found different once the work had customers, contracts and delivery dates attached to it.
Academia and business are both hard, just in different ways.
Research asks whether something is possible or useful. A business has to make it work for someone who will pay for it, on a real schedule. In deep tech, those get mixed together.
I learnt a lot of this as a software architect at both UAMTec and Arkeus, in the company’s most senior software role at the time, reporting directly to the C-suite. My work sat between the technical team, product and customer commitments.
A mission does not pay the bills
In academia, it is normal to justify work by its possible contribution to science or society. That makes sense for research. In business it becomes dangerous when it replaces the commercial premise.
A business can absolutely do useful things for science or society. But it has to survive long enough to do them. That means solving a problem for people who both can and will pay, and (importantly) investing significant time and effort in the development of those relationships.
One thing I think both Arkeus and UAMTec did well was actually name and build relationships with their key first customers – not just general “defense” or general “water”. This allowed them to tailor their delivery to actually secure sales, whilst being careful not to over-specialise on those one customers needs.
I think this is probably one of the bigger paradigm shifts that the academic-to-business move requires. That is, understanding you must be able to articulate exactly who you are serving (the customer), what they need (the problem) and how you address that need (the product).
Deliver the thing that can be delivered
Most academics know that academic code is different from production code. Closing that gap combines technical work with the need to deliver on a particular date. At Arkeus, the software ran in a time-critical, resource-constrained environment, and missing the project deadline was not an option. That technical complexity and delivery pressure was what made the scope and design decisions matter.
The project also had to build a product and technology base that would give the company a real long-term competitive advantage. Delivering the contract alone would have left us doing contract work with a more interesting R&D story attached.
That is where I developed a fairly strong view about scope. For the immediate delivery, we had to cut high-risk, low-TRL(technology readiness level) features and focus on what we could actually ship against the customer requirements. I worked closely with the product owner to keep that work connected to both the customer’s immediate needs and the written project requirements.
In many cases, design can support rapid delivery while creating affordances for later capabilities. That means making the relevant seams available without building the later capabilities early. Avoiding speculative work and a general-purpose framework still leaves room to choose an architecture where adding a feature later does not mean pulling apart the thing you had to ship now. The customer cannot buy the capabilities you might have in two years, but the decisions in the first delivery determine how hard they will be to build later.
Middle-out: connect the short term to the long term
The first product has to be small enough to build, but still point at the company you are trying to become.
The top-down plan starts with the long-term technology that will make the company hard to replace. The bottom-up plan starts with a customer’s immediate problem and asks what can be delivered credibly now. Deep tech needs to nail this middle-out: work backwards from the customer, and forwards from the differentiating technology, until the two meet in a useful first product.
Without that, you either try to build the whole vision before anyone can buy anything (which is generally not feasible), or you cut so much that you are just another commodity supplier. It also forces a deliberate decision about what is deferred, what must be retained, and what would quietly close off the path to a real advantage.
I think Arkeus handled that well. We kept cutting the immediate problem down until it was shippable, but consciously and explicitly laid the groundwork for integrating revolutionary features as they came online. That seems to have paid off.
Customers start with their problem
Researchers often start with a capability: “what could this unlock?”, but in the commercial setting customers usually come with something already on fire: a deadline, a cost problem, a risk they need off their desk. It’s not that companies don’t have long term goals, it’s that they have a hierarchy of needs which means the deals close easiest when only when the you can explain what it fixes now, what it costs, what can go wrong, and why the customer should take the risk.
I have sat in project updates where an issue threatened a contract deliverable. In those meetings, novelty mattered only if the proposed technology could solve the problem in time, for a plausible price, without creating a larger problem somewhere else.
Even if your product does solve a clear and obvious problem, a product claim needs evidence. A serious customer will compare it with what they already use, a competitor, or some independent measure. At Arkeus, that meant comparing new localisation approaches with GPS, running camera shootouts, and evaluating different single-board computers. Those comparisons gave the customer a way to decide whether the claim was real. A product with no obvious comparison, trial or benchmark will struggle to be taken seriously.
Most organisations, especially large ones, adopt new technology slowly though sometimes there are smaller units with enough budget, authority and pain to try something new. Some commercial contexts have an obvious early customer; others do not. Where they exist, finding them is much better than trying to sell the whole market at once.
This leads into the final point.
Sales is work
I saw another side of this at UAMTec, where I was brought in as the senior software person to work on autonomous submarines. The company already had BarrelEye, a diving product that was gaining adoption.
I had not seen the amount of work behind that adoption. The business-development and sales lead spent a great deal of time finding potential customers, following up by phone and email, answering questions, and keeping conversations alive. It was a useful reality check for me: adoption depends on the slow work of finding people, following up, answering questions and keeping the conversation going.
Arkeus did this well too. The executive team made good use of existing networks and built new ones to get the company in front of the right people. Even in the build phase, that was a hell of a lot of work, and it was in a different league from the networking academics are usually expected to do.
Key Takeaways
If i were to distill this down for a younger version of me, I’d summarise this as follows
- As fast as you can, move to thinking about solving specific people/companies problems
(whilst still keeping the long term vision in tact) - Whatever you are doing, ship it as fast as reasonable
(whilst designing in from the get go, the piece to bring your vision to life) - Find a good business person, with good networks, and bring them on early.