How do we actually make Deep Tech products? And how do we know where any given frontier technology really is in relation to the aspiration or claims of actual products in the market?
It might seem like an odd thing to question in an era where the public faces of high-tech companies are extremely well known and often equally extremely contentious. The casual observer can be forgiven for thinking that such breakthroughs are the product of the maverick figurehead. We’ve been bombarded with them for decades. And even when those stories don’t end well, there’s a fascinating about the human story, which often eclipses the more complex reality of the team using a mixture of processes and systems to make the steady advances required in any form of meaningful innovation. Maybe it’s just more fun to react to topics like Airbnb removing all product manager roles, or have thoughts about the various waves of tech influencers making “day in the life” videos that feed the backlash narrative that techies don’t do any real work. These topics fuel both the media’s coverage and the community’s discourse in ways that might be “fun”. But they are also a little dangerous. As Mary Oliver once said, attention is the beginning of devotion, and the fixation on the most shallow end of the technology news (aka gossip) feels like a wasted opportunity in the era of limitless access to knowledge and collaboration.
So let’s dig into the question of “just how do we think about making and releasing a Deep Tech product?”. Whether you’re a founder, a product manager, an investor, or a curious human trying to make sense of what’s real and what’s hyperbole, it helps to have a lens to look through to see for yourself. In the following, I’ll present exactly that, but first we need to understand why the existing frameworks and systems don’t always afford us the most useful general perspective. Something even the professional analysts get very, very, very wrong.
Looking from the outside in
If we gently agree that the mainstream media is neither interested nor equipped in navigating the nuances of these kinds of technology companies, we must also admit that the majority of our trade publications are guided by press releases about partnerships to nowhere, new models of indeterminate usefulness, and a general aspirational buzz. This kind of content and its coverage are typically narratives to appease internal stakeholders, boost a brand for upcoming investment rounds, or just keep present in the conversation. And that’s fine. I’ve led my share of these efforts myself and am grateful that we have these passionate individuals and their tiny teams who bootstrap these sites into existence.
Any Developer Relations or Investor Relations team in Deep Tech stands on the shoulders (or graves) of the stakeholder relations efforts that came before them. It’s deft work, but it also makes it almost impossible to gauge where a frontier technology is really, really, at from the outside in. And heaven forbid the retail investors that attempt to do so for their speculation on Deep Tech in the public markets. That way lies danger. Into this space we see the usual collection of management consultants and industry analysts. Both have a crucial role. Given the brand recognition of McKinsey, we tend to use their figures when it benefits us (like I did in my open source roles in quantum computing talk last year). We can argue about how accurate the methodology of estimating TAM is, or how much capital inflow is actually reported in potentially disruptive Deep Tech, but it’s not going to shape our strategy. That’s what they want to sell us. Equally we see Gartner with their iconic hype curves and magic quadrants, but what does this really tell us? Gartner is excellent at procurement and the nuances of sourcing, but neither of their views is designed to shape our understanding of Deep Tech progress or our actions at any given stage of getting these things to market.
Looking from the inside out
While there are no singular methods or systems of Deep Tech product development used across the board, there are some common forms. Let’s just skip the kind of SaaS-centric stuff that churned out of the Silicon Valley cultural production line. If you’re like me you’ve long since clocked out of the tired scrum versus kanban, Design Thinking versus Human-Centered Design and “MVP versus MLP versys MRP” thinkpieces. More useful are the frameworks like Technology Readiness Levels and systems like Product Lifecycle Management. This pairing wil be familiar to many if not all Deep Tech teams. Especially where the use of TRLs allows for a structured approach to assess the maturity of a tecnology across a standardised scale, and remains agnostic of tools and processes used to get to each stage gate. The PLM is a system that can then be seen to fit adjacent to TRLs, and focuses instead on a structure and guidelines for how product information should be organised, how processes should flow, and how stakeholders should interact. On paper this pairing should be enough, as it gives us an idea of progress with clear criteria that is abstracted from how that progress is managed on the day-to-day. TRLs alone are a favourite measuring tape for government sovereign funds or academic grant committees, as they give a quantitative measure with widely recognised qualitative criteria. NASA’s contribution to their usage has seen them canonised as the ISO 16290:2013 standard for space system hardware. Cool. But surely there’s something more accessible than space hardware systems and consulting firm graphics to help us think about how frontier technology is evolving towards commercial products?
Looking by evolutionary stage
When we talk about Deep Tech we are talking about a vector of sorts. There’s an implied journey from a scientific frontier all the way through to commercially available products. There’s a lot going on from one end to the other. The scientific exploration gives way to the establishment of technology that can be applied to real-world problems or opportunities. Those require a repeatable and mass reproducable engineering process to then, and really only then, create the sellable product.
This product doesn’t even necessarily have to be commercially viable, as we see after a decade of venture-capital largess, or in the case of sovereign capabilities (e.g. often the polite way of saying “military”).
Science -> Technology → Engineering → Product
If we plot this out we get a readily simplified view that accommodates all the prior models without becoming too simple to mean anything. It fits well between TRLs (which detail the specific technology) and Gartner’s hype curves (which speak to markets). As a simple device this framing helps us not just view but talk about organisational focus and the changes required phase to phase.
Science
Let’s take a company focused on the science first. A quantum computing company, for example, will be initially founded and staffed by scientists and researchers. The common pattern for this stage is to prove viablity of forther research by the meassure of impact and quantity of papers. Even IBM moved from measuring progress by patents to measuring by papers published. If there is a marketing and brand effort, it’s with a mind to recruitment and fundraising efforts.
Technology
Viable scientific explorations will move into a technology focus with their own set of patterns and heuristics. The organisation may register independent of university of government origins, take on operational independence and legal compliance. Any funding will necessitate a governmance overhead, and the distribution of that funding begins the collection of actions that will dfefine the culture of the organisation by what it does, not what it says it is. The goal os “prove this technology is vaiable and can scale” is a focused one, but one that needs to be mindgul of the foundations is creates for the future commercial entity that will build upon it.
Engineering
The engineering phase is one focused on ways to actually produce for a commercial scale. Even a proven technology may linger here for years, decades, or be discarded for either being unviable to build at scale, or simply uneconomical. In our quantum example, the risk of increasing AI discoveries yeilding continual improvements in classic computing performance is one of potentially delaying the economic viablity of quantum-accelerated computing.
Product
the engineering problems scale exponentially when the overall product proposition is considered. Byt his stage,t he organisation is fundamentally different to the scientific phase, both in focus and team dybamics. All of the operational capavity of marketing, sales,s upport, any required supply chain and vendor management, human resources and legal compliance apply. Probaly even a whole lot of lobbying if modern tech is anything to go by.
Parting thoughts
The key to this framing is that these are phases to consider the organisation’s current and future evolution through. Im my opinion this is where Deep Tech startups are unique and these broad strokes are a simple but powerful way to ensure the organisation’s plans and even story for future possibilities is mindful of each era of change. Like any useful device, it exists not to be clever, or sell consulting via pretty graphs the influencers past all over LinkedIn, but to surface discussion and make decisions. In my own experience, this framing has helped surface an organisation’s hidden frictions between back and front teams (such as R&D and Sales), and forces the hard conversations to be had before they become culturally corrosive. And at the very least, this framing supports the awareness of strategic actions relevant to each phase of a company’s growth, and the need for continual reinvention of systems, processes, and even staffing given the shifting priorities and types of activities required. What do you think about this “Science to Technology to Engineering to Product” phase idea? Share your thoughts in the comments.