Venture Principles - An Engineering Perspective
Robotics often feels like the olympics of engineering in that it demands the integration of many different disciplines. Our team is split between gear-heads (knuckle dragging Tarek) and cone-heads (soft hands Josh), and the only thing they can agree on is making fun of the BD guy (@Conor - just what is it that you do here?). However, amidst the good-natured mockery, we have coalesced around a core set of product engineering principles that everyone agrees on. We think these are particularly relevant to venture engineers, but we'd go further to say that even Big Boring Companies could use more of the below.
Best Part is No Part
This was a constant Elon refrain at SpaceX. People often ask some version of how can we solve for X? The first question should be do we need to do X in the first place.
The present or imagined customer isn't purchasing your widget - they're purchasing a solution to their problem. We had to remind ourselves of this recently when thinking through how to deploy a computer vision solution in logistics. We had envisioned a number of complex ways to get our optical suite where it needed to go before realizing that in some use cases we could just pipe our model directly into existing camera infrastructure and skip hardware all together.
This problem is rife when any particular tech gets hot. In a startup, where capital and resources are finite, this mentality is an absolute requirement.
Perfect is the Enemy of Good Enough
@Tarek was once told by NASA that they would have to take a major delay on Crew Dragon because the material they used to cover 1000s of bolt-heads on the exterior of the vehicle exceeded the off-gassing acceptable limit. They were headed for an excavation of all the material and a major rework when someone suggested scraping 1/8 inch off the top of each bolt-hole and using a slightly different material on top as a ‘plug’. NASA shrugged, said, fine, and the vehicle stayed on track after what amounted to an all-night industrial application of blemish cream.
We assume that procurement officers aren't ooing and aaahing over the elegance of our latest GitHub commit, but are very concerned about whether the product does what we say it does. Deep into our first build at Ironbird we have already had to downgrade custom or fancy parts to off the shelf hardware to move faster and stay on the critical path.
Fly The Rocket, Not the Model
Technical overhead grows quickly for any complex product — data storage systems, analysis models, brainstorming notes, product management tools, emails, Slack, etc. The list is endless. Through all of this noise, it’s easy to lose track of the only thing that actually matters - the product itself.
A simple reminder to constantly ask, “how does this make the product better” helps prevent overhead from overtaking the product. Or, as Bezos puts it, “focus only what makes your beer taste insanely better.” Innovation isn't an academic exercise in proving to the world how smart we are — the product should do the talking.
Get Something in Customers’ Hands Faster Than You Want to
As we mentioned in our inaugural post, our philosophy is to tackle the hardest part of any build first, create something ugly that works, and then ruthlessly iterate and improve until the goalposts are out of reach for any other team.
This can be uncomfortable. We just spun up an app derived from a product we’ll tell you about later this month. It crashes 20% of the time and has a B- user interface — but it also does something no other app on the market can do! Merely putting it in the hands of our design partners has unleashed a slew of useful feedback. Improving the UX and making edge cases work are relatively easy compared to developing the core tech, and we'd rather have our customers helping us get from B- to A+ than guessing at the right path.
From a BD perspective, this requires expectation setting and finding champions who understand how these development cycles work. If you walk into a boardroom and pitch an ugly product you’re going down. Many business leaders think tech engineering is more or less magic that spits out fully-formed widgets. However, if you enthusiastically pitch the VP of Engineering on a scrappy beta they can relate to, or quickly meet the needs of a line manager and ask for directional feedback, you are creating more champions while learning faster than the next firm.