How to Build a Deeptech Product
How to Build a Deeptech Product
Building products is hard - building deeptech products is harder. In this essay, I've put together my learnings from building a deeptech company + advising 100+ deeptech founders.
With the rise in deeptech startups, I was surprised to see the lack of process for deeptech product development. This often comes from a belief that it is too early for a product development process. It primarily happens for two reasons:
Deeptech founders believe that the product they are building is so unique that no process will be valuable for their use case (so they end up building their own rapidly-changing processes from scratch).
Generally speaking, deeptech startups are founded by research-focused entrepreneurs, and they over-index towards a culture of prototyping (ie. building something that works a few times) rather than a culture of product (ie. building something that works almost every time) so processes are not often worth repeating until a prototype becomes something more substantial.
There are tons of processes developed for software development, and traditional hardware development (I am a big fan of Bolt’s Hardware Product Development Series) - but when it comes to building deeptech products, there is very little content for it out there. So I’ve written the following post to shed some light on the deeptech product development process.
Background Information
I want to provide some context so you better understand the content to follow. I’ve broken the deeptech product development process into the following phases:
Ideation
Prototyping
Minimal Viable Product
Post-MVP
Product Launch
For the purposes of this post, I will primarily be focusing on the first three phases of deeptech product development.
Disclaimer - I understand that each deeptech product is different, and having a standard process for all deeptech products is challenging. As a founder, you should be mindful of which aspects of this product development process will apply well to you, and which will not. That being said, I’ve written the following such that it can be applied to a wide range of deeptech startups/companies.
What is a “deeptech” product?
There are many definitions to what deeptech means, but for the purposes of this post, I am defining “deeptech product” as a product that has high technical risk, but leads to exponential gain with respect to the customer problem once the technical risk is addressed. This means that deeptech products (usually) come out of insights generated through years of research and technical experiments. While this might sound deflating, the years of research is hard to replicate - and quite often leads to an unfair advantage for the startup.
As a result of the high technical risk of the product, the product management that goes into building is very different compared to a software solution. In a lot of cases, deeptech product teams will solve multiple zero-to-one problems in multiple technology areas to make their products work.
Finally, I’ve deliberately chosen a non-industry specific definition, because the first three phases of deeptech product development should scale to any industry.
Building deeptech products as a startup vs. as a large company
Building deeptech products as a startup is very different from building it in a large company. Within a startup, not only do you have to focus on getting product-market fit, but you also have to be aware of raising capital (and being capital efficient). Within larger companies building deeptech products (think Google X), the pressure to raise capital is not as high. As a result, larger companies can take on big bets without consideration for intermediary value.
A good analogy I’ve found that describes this dichotomy is that of building a car - big companies can make a bet directly to build a car and car parts, whereas a startup will usually have to build intermediary products (like a motorcycle) before building the car so they can sell something on the journey to building a car.
Phase One: Ideation
Ideation starts with defining the business problem to be solved. Unlike traditional startups, deeptech companies tend to emerge from developed technology. Therefore a good portion of deeptech startups start out as a solution in search of a problem - this is why a thorough and unbiased problem discovery matters more for the deeptech startups.
The Ideation Phase starts with the founder thinking that their technology can solve an unmet need in the market. The Ideation Phase ends with a proof-of-concept that validates the “hidden truth” to make the business successful.
Problem Discovery
Counter-intuitively, the first step in the problem discovery process is to forget about your technology - and instead focus on the problem of the customer. The purpose of problem discovery is to figure out a “hidden truth” about the market, with the hopes that this insight will lead to the building of a great product.
Some important considerations when doing discovery interviews:
If you are building a B2B product, consider speaking to all those affected by the problem.
This could mean speaking to 10+ people at the same company, with different roles. Often you will discover that everyone involved rarely has the same beliefs about product/vision, and as a result what they should buy.
Aim to get a good idea of the problem severity rather than just whether the problem exists.
Teams at this stage over-value secondary market research (like reading market research reports), rather than primary market research (like talking to potential customers). Reports are great at telling you how big a potential market is, but they won’t say much about the problem severity, or why the problem matters to those facing it. It is this “why” where the hidden truths lie.
Based on the problem severity, you should have a good idea of what the customer currently spends “trying” to solve this problem, and by extension what they might be willing to spend on your solution. If you aim to raise venture capital, you need to show that there is a scalable solution for a large market (ie. $1B+).
Your customer owns the problem, and you own the solution - avoid talking about the solution at this stage (save that for later).
This is the most common mistake of this stage. Technical founders love talking about the technology and solution - but bringing this up pre-maturely will bias the remaining conversation (and will skew your data).
Correlate the customer problem to the role of the person you are talking to.
For example, a sensor engineer at a medical device company might really care about inefficiencies in the lab, but if the engineering manager doesn’t feel this is a problem, then you will have a hard time getting approval for a purchase of automation hardware.
I also highly recommend reading The Mom Test - it covers the above points in more detail.
By the end of problem discovery, you should have a good idea of who the stakeholder is, and what problems they face (sometimes, you will have more than one person as your “customer”).
Developing the Product Roadmap
Before going further, I want to say that this product plan doesn’t need to be a detailed document. The purpose of putting together a product plan is to set out what the goals of the product are, what problems it solves, and how to get there.
Pre-work to developing the product roadmap
Given the output of problem discovery, the next step is to figure out whether your technology will solve the stated problem - in other words, finding a problem that your customers face that can be solved by technology in a scalable way. Some key questions to answer before you start building your R&D plan:
What solution would be a good fit for the problem that has been identified?
What other components do I need to add to my base technology for the solution to have exponential value?
What other solutions have been used to solve this problem? (If other similar solutions have failed, why did they fail?)
Why hasn’t someone tried building what you are building?
Based on the answers from above, you should have a sense of how your technology will exploit the hidden truth. This will become your unique value proposition. For the Medella team, we realized that we could reduce the cost per glucose measurement by 30x or more using artificial sensors that would not be damaged in daily contact lens cleaning, when everyone else was using enzymatic sensors that couldn’t survive the industry standard enzyme cleaners most contact lens wearers were used to.
At this point, either you will have a theoretical unique differentiator, or you will need to tweak your research to build a unique differentiator, based on what you’ve learnt about the market. In the case that you have a proposed differentiator, it’s time to develop the research & development (R&D) plan to build out your proof-of-concept (POC) and your prototype.
How to build a product roadmap
The product roadmap is not a requirements document, or a technical specification. A product roadmap just gives the team a clear idea of what product you aim to build, when, and why. Good founders use this as an anchor when they get carried away with project creep. Here are the key things to keep in mind when building a product roadmap:
You cannot do everything that your customers will want - you will have to prioritize.
Your first set of validation should be on your unique value proposition (if this doesn’t work, then you should quickly pivot).
Build requirements in a way addresses your problem discovery data (ie. what you build should solve a customer’s problem).
Remember - before building a car, build a motorbike first (or even a skateboard). In other words, you should be able to show demonstrated value to your customer with the first iteration of the product, even if it doesn’t exactly match your long term vision right now. Ideally this is a working product, but this could also be validation data, clinical data, or other metrics that allow you to initiate pilots or raise funding.
Here’s a product roadmap example/template that we developed at Lab2Market to help early stage deeptech founders think through what they will be building.
Proof-of-concept (POC) Development
Once the planning is out of the way, the next step is to build. Your proof-of-concept (POC) should validate the technical breakthrough that will lead to the unique differentiator.
As you are building the POC, it is important to come up with meaningful measures of success. For example, if a similar problem is solved before, consider using the same metrics for your product (at Medella, our primary KPIs were sensitivity and specificity, so that we could compare our sensors to other sensors on the market).
Keep in mind that your POC should validate the key hypothesis of your business - does your technology solve a validated customer problem? Here are some things to keep in mind as your are building your POC:
What data do I need to prove that my technology is “good enough” for there to be a good product-market fit? (For battery companies, this might come down to battery lifecycle, battery efficiency, battery safety. For sensor companies, this might come down to size of sensor, sensitivity, specificity. For chip design companies, this might come down to processing speed, power requirements. etc.)
Your POC doesn’t need to be a complete system - it just needs to validate the part of your product that will give you a unique value proposition. Sometimes, this POC will be made up of multiple components rather than a single component - and that’s okay!
Depending on your experience and prior work, developing a POC can take months to years, and will take some of the most dedicated time to build out.
Note: this is where curiosity-driven research stops, but the focus turns to outcome-driven research. If you come from an academic background, this is a big shift in mindset.
Phase Two: Prototyping
Once your POC is built out, it’s time to build the system around it, with the end goal of building a working prototype that you can share with your customers/users to get feedback.
Multiple Proof-of-Concepts (Optional)
Depending on the complexity of your product and what you can out-source, you will need to develop multiple POCs. For example, when building our smart contact lens at Medella, we had three core components that we were building in-house - sensor, antenna, and ASIC chip. The rule of thumb is to out-source where possible - our rationale for in-sourcing the above components was that we couldn’t find anyone else who could have built these components better than us.
The Medella example is an outlier, and most deeptech startups I’ve come across will usually only in-source one key component, and out-source + integrate the rest.
Prototype Integration & Validation
Once you’ve built your POC/s, it’s time to bring everything together. This will take longer than expected - but if you’ve built your prototype in components, you should have a much easier time with debugging.
When testing your prototype, you want to test each component individually:
Test for input/outputs of each component (for example, when building sensors, we tested sensitivity, specificity, but also limit of detection, cycle time, and detection range).
And also at the prototype level:
Did the KPIs measure when all the components were integrated?
Where and how does the system bug out?
While running the above validation tests, you should start developing a checklist of which components will scale, and what components will not (and why). Doing this will help you significantly when it’s time for production.
Once again, the goal of the prototype is not for it to behave or act like the final product - but rather to test out the critical components (that will become market differentiators).
Customer Testing with your Prototype
Finally, and most importantly, you should be able to take your prototype to your customers (either the system or the data from the system) to get feedback. At this stage, you should re-validate the assumptions you made in your problem discovery, and get into further details about how the customer will use your product, and whether it solves the stated problem.
Some teams will use a “looks-like prototype” (it doesn’t have the functionality of the product, but it looks and feels like the product) alongside with a story/use case of how the customer can use the product. It’s always different when you give humans something to hold/touch, rather than to talk about it - they will usually have realizations that they wouldn’t if it was just conversational/presentation of data.
Based on the feedback that you get from your customers, you will have to go back and tweak the product as necessary - generally speaking, the stronger your problem discovery, the less iterations you will have to do at this stage.
Phase Three: Minimal Viable Product
Once you’ve built a working prototype, collected the feedback from your customers, and iterated on your prototype, it’s time to bring it together into a Minimal Viable Product (cue the epic music*).
It’s important to align on a few definitions before we move forward here:
A prototype works in a controlled setting with limited functionality (low reproducibility, limited use, etc.) - but demonstrates the functionality of the key feature/s.
An MVP works in the desired environment with all promised functionality (there might be a few exceptions here). A “desired environment” means in the setting in which the customer will use your product.
A final product not only works in a desired environment, but it is also massively scalable.
Component Development/Sourcing & Integration
This is one of the most tedious parts of the development process. Here, you’ll have to research different vendors/manufacturers, test their component/s within the system (using the KPIs from the prototyping phase), and then test the overall functionality of the system.
Key things to be mindful of at this stage:
Depending on cost and functionality, you’ll have to re-visit which components you in-source vs. out-source. Generally speaking, the trend at this stage is to out-source as much as possible given economies of scale that manufacturers have.
Another important decision to make at this stage is how many MVPs to make. Depending on your use case, this number will change. For example, if you are building a medical device, you’ll need enough to collect statistically significant data for a pre-clinical trial - whereas if you are building a gaming mouse, you’ll have to develop enough to give to your users for testing.
Finally, you’ll have to optimize any components that you’ve developed in-house (usually the one that drives the unfair advantage), so it can scale. This means:
The component can be scaled in production.
The component’s functionality is reproducible.
MVP Validation/Testing
Once the components have been integrated, it’s time to test the functionality of the product. The common question to ask at this stage is “does my product cover the requirements of the customer?”
On Engineering Testing
Depending on the complexity of your product, you might have to work with an engineering firm at this stage to help you with one off integrations and assembly. It is crucial to have an engineering test plan for your MVP - this should cover each of the requirements in Phase 1 (and its iterations). This testing you do at this stage will also be down the road when you will have to do quality control at large scale production.
Another aspect you consider at this stage is your supply chain. (Working with CMs and managing your supply chain deserves a post in itself, so I won’t get into too many details here).
On Product Testing (with Customers)
Now that your product is functional, and does all the things you set out to do, it’s time to give it to customers to test it out.
Note: For technical founders, this is a very scary moment as most engineers/scientists want a perfect product with all the bells and whistles. Two things I would say to calm the nerves here:
If you’ve done your customer discovery work right, you’re likely building something that your customers/users want. Trust the process.
Product development is an iterative process. If you’ve missed features, you can always come back and add it to the next iteration.
Product testing with customers can take many forms depending on your product (pilot studies, paid pilots, private betas, etc.), but common amongst the above is answering the following questions:
Are my customers using the product to solve the problem they stated?
Are there other problems that your product is solving that hadn’t come up before?
Which features are most used? Which features are not used? Are there any key features missing?
What is the process like for getting your product to the users? (If you are building a B2B product, you will often work with many people/groups within a company with differing opinions. You should know which person/department will champion your product, block your product, etc.)
What type of support will your customers need when your product breaks down?
Finally, I cannot emphasize this enough - product development (even in deeptech) is iterative. You might have to repeat the MVP building process until you get the right signals from your customers/users. The purpose of building an MVP is to learn as much as you can about your product-market fit, and iterating based on what you learnt.
On a separate note, a lot of startups will raise funding once an MVP is built as this is an inflection point from an investor’s perspective (you’ve minimized a large part of technical risk).
After building the MVP
After the MVP has been built, divergence in the product pathway starts to emerge. For example, for medical device products, you’ll have to initiate clinical testing, for semiconductor products, you might have to source specialty integration vendors, etc. What is common amongst deeptech startups after building MVP is:
Setting up production (sourcing suppliers, contract manufacturers, quality control, etc.)
Customer testing/feedback via pilots (or other strategies).
Product Launch!
In my next post, I’ll be covering these topics (Phases 4 & 5 from above) in more detail.
Parting Thoughts
I’ve put the above post via my experiences of running Medella Health (where we built a smart contact lens for glucose monitoring), and running the Lab2Market Program (where we have backed 100+ deeptech entrepreneurs in the last two years).
While no two deeptech products are the same, I encourage you to keep the mentality of product-based thinking as you embark on building your deeptech company. While some products will differ in time/resources required for each phase, it’s the thinking behind each phase that is important. I recommend that you develop a unique version of your product plan while using the above framework as a backdrop. Hopefully this post has shown you that building deeptech products doesn’t have to be so complicated.
Huge thanks to the 1517 Team for encouraging me to write this post, and to Anthony to help crystalize my thoughts. If you are interested in starting a deeptech company, reach out to us via the 1517 website.