Technology Development vs. Product Development

What are differences in technology development and product development, how do they interact, what helps to measure the maturity of development and what common pitfalls are seen at the intersection of technology and product development?

Based upon many mentor sessions with very different early stage hardware startups, I noticed that we often spend the first sessions on defining where the company is in their development process. This article shall help to distinguish between technology development and product development and gives further reading material in reliable sources linked in the article.

Technology Development

Technology development focuses on research, scientific experimentation and refining a specific technology. When starting a research project, the exact outcome of the project remains unclear and develops over different stages of research - ideally to prove a scientific theory right and develop technology which can get applied to products.

NASA developed a system called Technical Readiness Level to rate the maturity level of a technology. The NASA Website gives a very helpful overview of level definitions for hardware and software including level exit criterias to “level-up”. NASA defines nine levels (TRL1 - TRL9) where TRL1 as the lowest level refers to “basic principles observed” and TRL9 is defined as “system proven in successful mission operations”. 

From a team perspective, technology development requires highly specialized scientists and cooperations with laboratories, scientific research institutes and universities are commonly seen.

Photo by National Cancer Institute on Unsplash

Product Development

Product development on the other hand focuses on solving a problem relevant to the market to successfully sell a product - no matter whether to businesses or consumers. It takes into account scalability of the product, market-demands, cost-effectiveness and above all the user needs. Product development transforms a proven technology concept into a tangible product. Hardware product development follows a common process. For information on a stable product development process, the blog series “How to get from idea to scale” of PRG is a good read. Other than technology development, product development comes with terms like EVT (Engineering Validation Test), DVT (Design Validation Test) and PVT (Production validation test) to measure the maturity of a product development.

The system of TRL can also be applied to product development although with different “level-up” criterias. TRL1-TRL3 can be seen as a phase to identify risks and develop proof-of-concept prototypes. In Design Thinking context, it would foresee iterations of user feedback on concept level to detail the specification and define a minimum viable product. 

Photo by Jo Szczepanska on Unsplash

TRL4-9 iterate on the maturity of prototypes for sub-systems and the final product. In terms of the Hardware Development process, it refers to sub-system rapid prototypes and  prototypes for engineering validation (EVT). A TRL9 in product development context would define a fully-functional low scale prototype. While within the technology development context, the development project ends here - the product development sees additional stages for design validation and certification (DVT) and mass manufacturing readiness (PVT / MP & Field testing).

A good overview of prototype stages vs TRL is available at qualityinspection.org. Please note, hardware product development companies define the prototype stages EVT/DVT/PVT  not necessarily all the same. For consumer electronics mass products, I do like the definition from instrumental.com. 

From a hardware team's perspective, hardware product development requires specialized engineers, product managers, supply chain managers and program managers to develop a commercially successful product.

Interconnections between technology development and product development

There are strong interconnections between technology development and product development. Advancements in technology development influence future products and their introduction to a mass market. Universities known for their research capabilities or researchers themselves may come to breakthroughs in their research field and start a business in order to apply the technologies in products to solve pain points which by now had no mitigation. On the other hand, the development of a product may discover gaps or limitations of a product's functionalities and therewith stimulate technology research. 

While technology development is the baseline, it creates and proves a new (sub)system technology to function while product development is the industrialization - the mass application of the technology implemented in a product. 

Common pitfalls 

Not knowing the development level of all subsystems of the product

It is absolutely essential when starting a hardware product development business, to distinguish on a sub-system level the maturity of the technology used for the product development. A newly developed technology may pass into a product when a functional prototype can prove the requirements are met as defined for the product and its subsystem. When a subsystem development has not yet reached maturity for product integration, this needs to reflect in risk management and product roadmap in order to ensure a product is ready-to-ship within the expected timeline. Please note that many VC funds are also not knowledgeable about technology development and product development and the different risks in them. Communicate your development traction clearly on subsystem level to avoid expectations which can’t be met, especially with a subsystem technology still in development.

Photo by Karla Hernandez on Unsplash

Talking about “prototype” without definition of “what prototype”

As mentioned above, both development processes - technology and product development - include several iterations of “prototypes”. Make sure for every prototype, a definition is available of the extent of the prototype (subsystem), purpose of the prototype (what do you want to validate) and the related stage of development you want to pass. This will help to develop distinct subsystem test iterations without blurring results due to a too open or too wide extent of the prototype. And - baseline for all prototype testing is a mature definition of product & engineering requirements. Without knowing what the product and its subsystems are intended to do - how could you define the scope of any prototype? Continuous and balanced requirement management matters!

Non-adjusted risk management and its communication

When starting a product development process while a sub-systems technology is still in technology development, adds a severe risk to the product development timeline. Make sure that countermeasures are in place in case the subsystem technology development does not advance as required. And in case this subsystem will be the core part of your product, admit and communicate that you are still in technology development and not in product development. This will help to define reliable milestones, especially when working with VC funds who may not be well-experienced in technology development. Otherwise it is very likely to get severely under pressure from investors who may expect product development milestones and timelines already - while you still research on technology level.