software defined radio

Strategy to execution, lessons learned and mistakes along the way

On the recommendation of a colleague I recently read the The Lean Startup by Eric Ries (Mark Mitchell wrote a review on this book if you’re interested). It got me to thinking about many projects I’ve worked on including launching online communities at National Instruments, to a new FPGA based software defined radio (SDR) tool, to a cloud based development environments and cloud based services for IoT devices. The online communities, with many follow-on iterations and improvements have proved extremely successful while the others have some more proving to do.

Even though these projects all went I think the projects could have been more effective, and executed more efficiently with less time and resource waste. In hindsight I and my teams would have better off by being more systematic and combining some of the points made in The Lean Startup while using a framework like the Diamond Strategy by Donald C. Hambrick and James W. Fredrickson to define our vision and fundamental assumptions.

Adapted from Hambrick, D. C., & Fredrickson, J. W. (2001). Are you sure you have a strategy? Academy of Management Executive, 19 (4), 51–62. (Source:

In the case of the LabVIEW DSP Design Module, targeted at FPGA synthesis for SDR applications we were able to successfully achieve real time LTE up-link and down-links with a high level graphical development and design capture tool. There were many lessons learned but early on one of the turning points was when we put the tool in front of real communications engineers. Their feedback resulted in significant changes to the graphical model for design capture and also helped us define what a minimum viable product needs to really be (quality of results, number of MIMO channels, wireless standards to support) before we could exposed to the tool to more people. You can see a demo in this video.

In other projects, ironically in some of my cloud based research projects which lend themselves to broader exposure and experimentation, we did more internal thinking and definition without validating key needs with prospects as we could have. This is more than likely because the “cloud” was so different from standard products we were used to, which if I think about it should have had us talking to real world prospects even sooner!

Taking an idea from a concept and vision, to implementing it and iterating on it is a real challenge whatever the market and application. In today’s fast paced and dynamic nature, most of us would be better off articulating that vision, our assumptions and doing what we can to validate them with a real customer and prospect. It’s always a challenge to resist the temptation to wait and deliver what “we” think is the ideal solution, but that delay and lack of input increases the risk we’ll miss the mark on functionality and time to market.