.svg){kind=small}
Building a deeptech company isn’t about building deeptech.
TLDR:
Your product sucks. If you want revenue then focus on the product and the product delivery early, even if you working in an emerging area. Your clients want solutions, not technologies. You probably need better software engineers and a business development manager too.
Firstly if you’ve not heard of Clayton Christensen, then stop reading this article and go watch this talk by him instead.
He explains the topic of disruptive technology beautifully. He invented the phrase after all. In his immensely popular book “The Innovator’s Dilemma”, he hypothesized that the 2 kinds of innovations are:
Where the company makes marginal and continuous improvements to a product line based on customer feedback. These innovations often create efficiency gains that decrease company overhead and maximize profits.
A new way of providing a solution that at first may only appeal to a niche audience, and may appear to be inferior to current methods, but has the potential to overtake competitors. This innovation usually does not have reasonable unit economics, or appeal to a broad market.
Both types on innovation require investment, and the preference for short terms gains forces companies into the “innovator’s dilemma’’ where they are financially motivated to choose sustaining innovations over disruptive ones all the way to bankruptcy as the market moves and leaves them in the dust. Interestingly he also argues how it is disruptive innovations, not sustaining ones, that grow economies and they often increase employment in the labor force, and redistribute wealth.
So, as a new company looking to displace huge incumbents and change the world, you want to be disruptive by focusing on these new technologies and methods of doing things. These companies are often referred to as “deeptech” companies — ones with a particular focus on new and emerging technologies.
But when a new company wants to break in and disrupt the market, they are often taught by incubators, accelerators and VCs to follow Minimal Viable Product model (MVP) and general Problem/Solution methodology. Problem/Solution states that “Your clients don’t want machine learning, quantum computing or blockchain. They want solutions to problems!”. MVP says “just get something that barely works, then throw it straight into the market to get feedback”.
The question is how do you do this, and make money, this while developing brand new technology?
The often quoted method is that you should first focus on niche areas, which may have different requirements to the rest of the market, and try and expand from there. This generally makes sense, and sounds great, but isn’t always possible in practice. There usually isn’t enough money to be made in this niche or you find other startups are also trying to grow in the same niche. You also can’t show the high growth you need to attract investors as your unit economics aren’t positive. Investors want fast growth.
The solution I've most commonly seen is that VCs just throw insane amounts of money at companies, claiming to be developing deeptech-quantum-labgrown-meat-on-the-blockchain, to try and race to build a commercializable product with broad market appeal. However, like Juicero and Theranos demonstrated, you don’t know what will become of these investments when the time from market is so long, and there is so little product validation that can be weighed in contracts and coins.
On top of this, rapid investment means jumping from a small team to a large one. This really isn’t efficient as your product development methods (CICD, architectures, etc) and internal company structures and processes aren’t properly established yet. Sure “move fast and break things’’ if you want, but it’s not efficient in terms of expenditure per deliverable.
The skeptical part of me thinks these most smart companies know that this (taking lots of money and trying to rush to complete product without initial customers) is a bad idea. I believe they are doing it anyway because they don’t actually want revenue. They believe that, if they make revenue, it actually decreases the value of the company in the eyes of VCs. They just want VC money, and no revenue will ever be enough to satisfy a VC.
I think the often overlooked phrase from Clayton Christensen gives us the better way (assuming you want to make money that is). He states
“Most disruptive innovation is not from new technology. It’s from applications of matured technology to new areas, or in novel ways.”
I believe this applies everywhere, but especially in areas with a very broad application (such as AI and machine learning) which is quite mature at this point. There seems to be a misunderstanding that it’s brand new technology that makes breakthroughs in markets, instead of existing technology with new applications. There was nothing stopping people building Airbnb in 1997, for example, but it was mature technology in the late 2000’s that allowed it to grow.
Your customers want solutions to problems. And a solution is not a technology; it is a product. Your use of MVP model to deploy a product to market should reflect this. That means get software engineers to deploy the product, and start working on Business development immediately to validate the product.
The long and short of this is that if you have a deep tech company in a computing field, then you should still have a frontend (or at least a full stack) engineer to make this a real product from day one. You then need business development to start to learn about your own sales process and how to manage customer relationships. Yes, its back to the MVP model, but the point is this applies to deeptech too! You need to get what you have infront of customers super early and not turn your company into an academic research group.
I’ve learnt this from my own company. Staple is deeptech AI, and AI companies are notoriously hard to commercialize.
Initially we focused solely on the tech — artificial intelligence provided via APIs only. All on the cloud, SaaS model. But the product was hard to sell, and hard for non-technical people to articulate.
We were doing expert panels and podcasts to get our name out there and impress VCs, and consulting to make ends-meet while we kept boot strapping.
When discussing our product with customers, the developers we spoke to loved it — clean data extracted and structured in a single API call. Great!
However, developers are not the people who get to make purchasing decisions in companies. We then realized we needed lots of API calls to generate a profit, which meant going to mid-tier to large companies who could provide that volume. People with authority to make decisions in these companies usually didn’t know what an API is, and didn’t understand what we were providing. They struggled with the basic flow charts. Then middle managers and finance wanted everything on premise, convinced all data is some gold dust of immense value (as they had no doubt read in a magazine). Nothing could be on the cloud.
The good news is we got the product out there early — and took this feedback onboard quickly. We pivoted to focus on larger enterprises, with the option for on premise deployments (at a cost) along with cloud offering, a clear and intuitive user interface, and custom integrations for large customers. We also needed a dedicated and experienced business development manager to manage the client relationship, and DevOps to deploy and manage the product delivery. All of this made the product and sales cycles much more clear. Looking back it is obvious we did not have that clarity in our sales approach before. But then all of the above obviously wasn’t what we had imagined in building and running an AI company… we had imagined the AI.
This was hard, but getting the MVP out early immediately taught us lessons that we could not have learned otherwise; focus on the product, and focus beyond just technology and functionality, but on the interactions with the customers too.
Now the staff in the company reflects the attitude of the company. We have dedicated research, and still hire a lot of PhDs, but now we have dedicated sales, front end and dedicated DevOps too. As a result, a great product with happy customers. Our users probably don’t care that we are using state of the art ML methodologies in our solutions; they just want the results and a pretty user interface. The decision makers don’t care either; they just want a good ROI so they can take credit for the initiative in the next yearly review.
Imagine if we hadn’t had full stack engineers to turn our technology into a product early though? We would be hitting the market later with the same approach, with bigger sales targets to cover the burn, and we would disintegrate up on market entry. We could have been the Juicero of automated data extraction. Or Element AI.
That would have been embarrassing.
This doesn’t mean you shouldn’t be innovating, and making advances in your field. It’s great that your technology is proprietary. But research and tech innovation that shouldn’t be the focus for a young company. You are a for-profit company, not a research group or a hacker community.
Emphasis must be made on the packaging and delivery of the product as early as you can (which is why I talk SO MUCH above DevOps). Or you can ignore this and just keep consulting to make ends-meet, and doing panels and podcasts to hide the fact you’ve got no customers.
FIN
Josh Kettlewell is CTO at Staple AI.
Staple is a platform for extracting data from documents — regardless of layout or language. No templates. English, Spanish, Korean, Japanese — you name it, we scan it. Do you want to automate your invoice processing? E-KYC processing? Dealing with PDFS/photos/word docs/etc. of varying formats or layouts? Use Staple!
Contact Staple today to start a free trial to cut mundane data extraction and processing work out of your business. Email hello@staple.io or go to www.staple.ai