Time to Profit is the Purpose of a Startup

Identifying the keys to Business Growth
(Post 3)

In the first blog chapter I mentioned a new idea of Time to Profit.  Often people in the startup ecosystem talk about Time to Market as a significant measure of success. 

What’s the difference? Time to Market proves you can ship a product, placing priority on getting something “out there” and hoping it meets all the market’s requirements for performance, reliability, and production scalability. Sometimes, a startup considers the strategic aspects of presenting a product to market. But often, they don’t consider all of these factors, and the initial product offering falls short. This may cause early adopters to abandon the first product offering, hoping for a second product that never comes. Then social media takes over and the shortcomings are the headline news, negatively influencing the next generation of potential customers. The company winds down while looking for additional rounds of funding, reducing headcount, until the doors are locked.

Time to Profit is a different approach where certain performance, growth, and interdependencies are considered up front, allowing a startup to offer a “Known” first generation, with the foundations of a second generation being laid, as the first one ships. It borrows concepts from larger companies, for example platform design, and design for manufacturing and testing, but does NOT let them slow the commercialization progress, managing the risk required to ship the first ever product of its type. These concepts allow the startup to know very quickly what can be counted on, and what needs extra attention. Stated in another way, it allows the startup to rank and partition risk, whether it’s design, reliability, supply chain, process or test and then manage it objectively.

This behavior allows the internal alignment of resources on solving problems that need to be solved, and better communication of those risks internally and to investors. This helps to reduce the stress associated with potentially difficult times by knowing the “Knowns”, so resources can be applied to solve the “Unknowns”.

My goal is to provide technology-based start-up (and growth) companies with the best product commercialization methods and techniques to enable companies to achieve the fastest possible Time to Profit.

The Big Question: Can your startup settle down enough to see what’s going to STOP you from commercializing your first product? Startups are all about the positive, emphasizing culture, hard work and fun. But as inconveniently and previously mentioned, they are also expected to become a profit-making enterprise.

Getting rid of the noise

You’ve started a new venture, and shared this exciting news with friends, family, and business contacts. These interested parties – not to mention, investors and other stakeholders - want to hear what’s going well. Very often, there is little in the way of discussions on what needs be done, by whom, by when, to reach the next performance milestone. Startups love to discuss things in terms of “Good and Bad” but fail to discuss things in terms of “How Good and How Bad”. The subtle difference makes a huge difference in answering the above questions.

Good and Bad is qualitative, How Good and How Bad are quantitative. Hard-Tech startups often require the compilation and analysis of many process steps, at many process states, with many precision materials added in a precise order. These factors often combine, in a multifactored ways, to create the desirable results that enable the new product offering. Even when it’s a hybrid system of hard-tech components, controls and signal processing, these design elements need to be understood from a design margin and compatibility perspective.

I figure at this point I can introduce this concept that Signal to Noise Detection at all Levels is the Challenge! Signal vs noise is a shorthand that engineering types use to differentiate the information that is needed or meaningful (the “signal”) versus the random variation or static that interferes with the signal (the “noise”). Think of your old AM radio. (Am I dating myself?) The Signal is this case is quantitative data that can be used, with confidence, to make decisions, in all areas of the enterprise from technical to commercial, and manufacturing and supply chain to quality systems. The Noise in the case is the universe. The noise is all the contributors to background chatter. Examples are everything from suppliers who don’t produce your parts correctly, to uncalibrated test and measurement equipment giving you inaccurate information, to customers who change requirements without notification, to sales guys who sells a thing that can yet be produced, to well-meaning advice givers. These sources of noise can cause the enterprise to make uniformed decisions, without fully understanding the risks associated with those decisions.

It's not always easy to discriminate between the signal and the noise, particularly in the earliest stages of startup founding and product design. The ability to detect what is noise should improve significantly over time as your mission and design processes become clearer, resulting in an actual reduction of noise.

t1 - t10 represent time periods over a technology’s or product’s development; Percentage of Cumulative Performance represents the actual product’s performance considering the combination of the product’s design, manufacturing, test and reliability against actual customer requirements

For now, t1-t10 on the horizontal axis will represent development and operational steps.  Later I’ll relate these to product life cycles.

How do we determine noise acceptable noise level, or in measurement talk the discrimination level, to feel confident that you are making decision with known risk and the best available quantitative data? And note, the best available might be all you have as a startup executive or manager.  

The answer is that you characterize them using best practices, to distill all factors down into two buckets, Critical to Function (CTF) Parameters and Product Limiting Factors (PLF).

Critical to Function (CTF) Parameter

  • A subset of a product’s specified parameters that are critical to its performance

  • CTF’s may be limited by material performance or availability, process technology and capability, supply chain capability, intellectual property restrictions, industry allocation (IC’s in 2021),

  • These may be known or still need to be discover during product, process, and test development

Product Limiting Factor (PLF)

  • Of the CTF Parameters, these are the 5-10% of the CTF, if not solved, will keep a product from achieving its potential. This causes:

  • Failure to meet time to market, volume, or profit targets

  • Failure to meet yield and economic goals

  • Failure to achieve the desired reliability necessary for successful adoption of the product or service

Risk and “the Unknowns” will always be present but their impact can be minimized if CTF and PLF are identified sooner than later.

A hard-tech entrepreneur needs to be comfortable with the knowns and unknowns. Once something (parameter, process, material recipe) is better understood and is heading toward a Known, control it and make sure it can be realized repeatably and sustainably, and at a sufficient level of control to ensure it never bothers you again. If the parameter keeps sliding back into instability, or has a disproportionate impact on performance, it might a CTF. These need special attention.

Again, there are reams of materials on traditional metrology and process control out there. I’ll touch on some useful content but will more likely present hyperlinks to such material as concepts are introduced.

In closing, startups are being funded for a breakthrough in technology, services, or systems. They are not being funded to recreate what’s been used as best practices and methods. If it’s public, use it. The art and science is to take what you need from what’s been used before and derive it to your ends applying it to where you are in your Product Life Cycle. But again, that’s the next blog chapter.