Leaning LiDAR Product Development

Long before Eric Ries published his must-read book The Lean Startup, its terms and principles were beginning to be applied within the startup mecca that is Silicon Valley. Since the book was published last year, buzzwords like pivot and minimum viable product have been woven into the fabric of the small business world, at times nearly to the point of overuse. Many of the concepts and ideas are not new. In fact, much of The Lean Startup draws from principles practiced at Toyota and elsewhere and described in the seminal book The Toyota Way. The Lean Startup refreshes these and adapts then deftly for todays entrepreneur.

As a long-time LiDAR developer, I initially had the impression that Ries lean lessons were primarily applicable to web-based software products and platforms, having only limited overlap with LiDAR sensor companies and markets. After reading the book and hearing Eric Ries speak on a couple occasions, I now know I was quite mistaken. I believe there are numerous best practices you can apply to your next LiDAR-related startup or new product initiative

At the core of The Lean Startup is the recognition that a new endeavor (company or product) is usually created in conditions of extreme uncertainty. Who are the customers and how do they behave? Who are the buyers and are they the same people as the end users? What product features are the ones that deliver the most value and trigger the buy decision? How much interoperability with other existing customer tools is really necessary? The list of questions goes on and on. The Lean Startup proposes an approach to reduce this uncertainty as quickly and efficiently as possible.

In this article, I discuss a few of Eric Ries best practices that I think you can apply to your own LiDAR business or product area.

Deliberately Identify Leap of Faith Assumptions
In every business case, whether it is for a startup or a derivative of an existing product, the financial model gets built on a house of cards. The cards are assumptions and they often have a leap-of-faith aspect to them. Some assumptions are buried within others. Far too frequently, especially for advanced technology products like LiDAR, the assumptions amount to hopes rather than logical inferences. They serve to justify the technology push and can easily lead to an oversold product idea.

It is critical to explicitly identify these assumptions. Scrutinize them to make sure you are not overlooking important ones. Prioritize them by level of impact and degree of uncertainty. There are invariably two or three that, if determined to be wrong, would cut the legs out from under your strategy. And by the way, the non-technical assumptions tend to outnumber the technical ones.

Apply the Build-Measure-Learn Construct with Pre-Planned Pivot Meetings
One thing is certain: no matter what, some assumption within your new LiDAR product idea will be fatally flawed. It may be a technical aspect, user interface feature, your price point, your sales or distribution channel, or any of a number of other possibilities. You must discover these flaws early. Thus, a central focal point of The Lean Startup is the Build-Measure-Learn cycle. Learning and adapting is something we all espouse to do and the Build-Measure-Learn cycle provides the process for what Ries calls Validated Learning.

Achieving learning serendipitously is what all too often takes place. I define this as rear-view-window business planning. A sophisticated product is developed based on potential customer input and a lot of hunches. Then the product is released after a significant effort over multiple years. The market either fizzles or was never there in the first place. The plug is ultimately pulled, and learning then rears its head at the post-mortem meeting. We spent all this money, but hey, we found these valuable lessons to apply to a full redo of the product or the next new product in the queue. Sound familiar?

The design strategy and process must be shaped differently. It must explicitly define Build-Measure-Learn cycles. Keep in mind that in cases of a new or uncertain market segment, the customer does not define the demand in your build-measure-learn loop. Rather, it is your assumption about the customer that creates this demand. With that perspective, your sensitivity to the leaps of faith you are making grows. Turn your team loose with those as the drivers of what minimum viable features need to be built and tested or what customer behaviors or preferences need to be discovered. Make sure to include business development team in the discussions! Define next years internal research and development (IRAD) by running the build-measure-learn loop backwards. What do you need to learn or validate? How might you measure it? What is the minimum viable product implementation that supports that measurement in a cost-effective way? You then have your initial IRAD tasks.

Schedule bimonthly or quarterly pivot meetings. A pivot is a strategic course correction that preserves the end vision. Pivot meetings are strategy meetings where the key decision makers grapple with the cold hard facts from the build-measure-learn cycles completed since the last meeting. You may decide the data tells you to press on and persevere. Or, as painful as it can sometimes be, a pivot may be required to achieve sustainable growth.

Scheduling the pivot meetings in advance does two things. First, it enables you to work backward from those meeting dates to assure adequate focus is applied to the right things. Second, it builds the pivot discussions into the woodwork of normal operations. Invariably, the urgent preempts the important in most organizations. Having standing strategy pivot meetings helps maintain focus despite the clutter of the daily grind. Also, over time and as the product or market matures, Ries cautions that there will be a tendency to de-emphasize this so-called innovative accounting cycle. Resist this temptation.

Shrink Your Batch Size to Improve Efficiency and Extend the Runway
In small organizations, the length of runway is often measured as the amount of remaining funding divided by the monthly burn rate. But what is actually more precious and a better indication of runway length is the number of pivots, the number of build-measure-learn cycles, you can achieve with the remaining funds. For LiDAR hardware companies, this tends to be especially challenging. These systems are often complex, expensive and laden with long-lead components. LiDAR software tools have a much easier task but can get bogged down in the same traps. The batch size grows and the build-measure-learn cycle slows.

Compressing the build-measure-learn cycle is paramount. It lengthens the runway and increases the opportunity to learn. A compressed build-measure-learn cycle mindset tends to have the effect of reducing the batch size for the next development cycle. Smaller batch sizes are much more efficient. This can be counter-intuitive, but read The Lean Startup or any number of other write-ups on lean processes to see example after example that will convince you otherwise. Consider engineering change requests and the belief that it smaller batches will bring things to a halt due to the effort required to complete the release process. Have faith that if all the engineering change requests are smaller in scope, your organization will by necessity figure a way to eliminate the waste in the release process. It is far too easy to live with an inefficient process if it is only executed once per month or once per quarter.

For LiDAR hardware companies, it is oh so easy to create a large batch for the next product release. Feature after feature is added, along with fix after fix to address deficiencies uncovered by field engineers and customers. These accumulate and cause the next product release to slide to the right and grow in cost. I have experienced this effect first hand on far too many occasions. As I reflect on these slow build-measure-learn cycles, it causes much pain and a sincere wish that The Lean Startup was in my hands earlier as I certainly contributed to the scope growth. And when the product or product update was finally released, it is amazing how many of the new features or repaired bugs have little/no effect on new customer adoption or even customer satisfaction.

Rethink your IRAD budget. In many organizations, IRAD performance is tracked by how well the team is spending to plan. Excess scrutiny is invited the moment there is a deviation. This is not rapid build-measure-learn thinking. Defining a rigid plan that yields a large batch size will only guarantee one thing: the money will get spent. And usually that means the team will be working at capacity to complete the single batch. Learning will be limited. Instead, identify the most critical assumptions and assure those are validated as early and as efficiently as possible. Break the development roadmap into small batches and pre-planned pivot meetings. Track the teams performance in terms of intentional learning rather than a spending plan. Scrutinizing the former will invariably take care of the latter.

Eric Ries The Lean Startup and his blog Startup Lessons Learned are wonderful resources. The LiDAR community is often not very capital efficient. Thus, it is easy to dismiss a book and author that appears to be biased toward web-based startups. Think creatively to apply Ries best practices to your organization and, like me, youll change your mind.

Dr. Stephen Hannon is the principal and founder of Mind the Gap, LLC (MindtheGapLLC.com) where he advises startups and small companies across a range of business and technical issues. Steve was previously with Lockheed Martin Corporation, Coherent Technologies, Inc., and SRI International. He is best known for his founding role establishing the WindTracer Doppler Lidar product, in use at airports and other facilities around the world. Steve received his Electrical Engineering education at MIT and the University of Illinois. His blog can be found at MindtheGapLLC.com/steves-blog.html.