Here’s a secret they probably didn’t tell you in engineering school: failure is okay. As a matter of fact, failure is more than okay when you’re doing it with a purpose, to learn. Learning what doesn’t work is just as valuable as knowing what does work, especially in dealing with the complex, nuanced customer needs you are likely trying to satisfy. When you experiment as a scientist does, failure has a much different and more positive meaning; it is expected and desirable. At the beginning of a project, your understanding of the deep customer needs (read that again – the deep customer needs, not the surface features they will tell you about) is incomplete, so you have to experiment and learn, try and fail, and then try again in order to land on an optimal solution. Your ideas may look great on paper, but will they work for real-life customers in the real world? In other words, you need to take an experimental approach to building software and use customer feedback to drive decisions every step of the way. It may be counter-intuitive, but this is also true (if not especially true) when working deeply technical ideas that have little to no user-interface. Why? Because that deep technology stack is presumably deep because it is doing meaningful work for someone. And yes, it is harder to get feedback on software that has no UI and may take a year to code before it compiles and integrates with other components. After all, you can’t crank out a prototype or ask someone to try out an early version in a usability lab. However (perhaps this is a good topic for a future blog) there are plenty of ways to investigate very early on if the “job” that you intend your highly innovative and deeply technical non UI software to do is going to rock the world of the person who is ultimately going to use it… or not. That is what you need to discover earlier, rather than later. Will your work rock the world for the people consuming it? Wouldn’t it be better to learn early on that customers (or whoever is benefiting from the work you are doing) don’t really like what you’re building? Or maybe only kind of like it? Or even if they do, maybe they aren’t willing to pay for it? Wouldn’t it be nice to know this before you sink a lot of time and energy into building your solution? And wouldn’t it be nice to figure out which of your assumptions are wrong so that you can modify your approach as quickly as possible and still have the time, money and energy to try again? Rather than investing weeks or months getting an idea coded and ready to ship, spend a few hours or days building a rapid prototype and then test it with customers to be sure you are on the right track. And if you experience failure along the way, that is a good thing as it means you are one step closer to building something truly amazing.