Journey of building a Robotics Product from the ground up
My ever evolving engineering-centric perspective on what goes down when building a Robotics product for the commercial market.
Being a Robotics Engineer in the startup world, I pen down my ever evolving engineering-centric perspective on what goes down when building a Robotics product for the commercial market (from the ground up)—thoughts on work phases, good design, execution speed, and all that jazz.
Ever since I started my career, I was on the lookout for what I wanted to do for a living. Some career experiments later, I happily build Robots in startups or early-stage companies.
My best experience so far has been while building one from the ground up in a startup/innovation lab as one of the first Robotics Engineers — something I’ve been doing for the last three years.
Here’s my retrospective journey of building a Robotics Product from the ground up for the commercial market — things I learnt about engineering and a tad bit of technical management.
While I wouldn’t divulge specifics on what and how we build as Roboticists, I’ll try to paint a holistic picture of my engineering journey and throw my brains out on this canvas, so to speak.
For full disclosure, I currently work at Schmiede.One, an agri-robotics startup/innovation lab based in Germany. I spend most of my time with Software, Computer Vision and Embedded Systems (I try to learn and help with mechanical, but I wouldn’t ever hire myself for a mechanical role 😛).
This post is my curiosity and responsibility — my unfettered thoughts and words on a Saturday evening with a cup of tea. So if I come off as an ass, don’t look at the company. It’s my own doing. 😃
Building a technical product from the ground up is akin to aiming at a moving target — you adjust technical strategies based on market demand/feedback. But you still need a holistic understanding of what the product should look like later to engineer well and have the agility to roll with new information.
Parts of the journey —
Note: Mapping the length of each phase in this diagram to its time duration is very misleading. I drew it such only to bust the idea later 😉
While the biggest challenge I see in the Robotics industry is finding a real problem to solve without giving in to shiny object syndrome, I’ll skirt that topic for another day.
As of today, I find the process of building Robotics Products to have three phases (albeit with no clear boundaries) —
Phase 1 — Building an “almost prototype” with all your focus on R&D
Phase 2 — Building stable and reliable prototype(s) for customer demos as a legit promise of a product
Phase 3 — Building a customer feedback-based stable, reliable, and thoroughly (crazily) tested product that sells.
Phase 4? Get Money! It’s not that simple. But let’s not get ahead of ourselves.
Phase 1 — Building an “almost prototype”
Small team, high enthusiasm, constant technical experiments, continuous designing, rapid feature R&D—there, you have a summary for this phase.
Assuming you know your market well and have an initial idea of what your product should look like (which might change over time), the first critical step is to build a small, curious team of folks with complementary skills.
In my opinion, multi-domain generalists > specialists (in this phase). And innate curiosity goes a long way. Always.
With a cohesive engineering team, these are the R&D days to move the needle rapidly — new features every other day and big functional updates to the system every week. Well, it’s not as fast as software-only product development. Robotics comes with non-trivial engineering uncertainties taking R&D time. Be that as it may, it does feel awesome to build a new big-ass feature in your robot quickly and see it becoming smarter. 😁
I clearly remember this phase with nostalgia. We did some super creative and quick iterations on all fronts — software, vision, embedded, and mechanical. But here’s something we always focus on —good design with scalability in mind and testing (Yes, we did software tests from the start. They are important for further development. Don’t skip them).
Let’s bust a myth — This phase is only about building a prototype-like system as fast as possible. Stability and scalability are afterthoughts.
Nope.
As tempting as it sounds (because speed is your friend in startups), slapdash engineering covering big design flaws in robotics blows up painfully sooner or later—and it’s usually sooner in a product involving multiple domains and moving parts (literally).
Good engineering is not the enemy of speed. In fact, it comes back with 10x time reduction later. The chicken always comes home to roost.
The market is brutal. If you launch a house of cards waiting to fall at the first real stress test, two things happen — market reputation takes a hit, and you have to go back to the drawing board and re-engineer. Maybe the former can be avenged with a great release the second time, but the latter is expensive. This should’ve been done (as much as possible given the time constraints) the first time around.
Now, there’s a case to be made for fast iterations with some leeway for band-aid engineering. The market doesn’t wait forever. There are pressures and feedback-driven directional changes. Been there. But there’s a fine line between rapid makeshift engineering and rushed irreversible bad engineering — hard to estimate. That’s life in this world.
Phase 2 — Building real stable prototype(s)
When I said the diagram in no way represents phase timelines, this is what I meant — it’s possible to assume that the first phase has all the building, fixing and fire fighting followed by happy days if you’ve engineered well. In theory, sure.
But as Yogi Berra said, in theory, there is no difference between theory and practice — in practice there is.
As with most difficult things in life, the last 10% is 90% of the work. And we’re now in the last bit.
Say we built well in phase one given the time constraints. We’re now looking at R&D and some deployment-focused stress testing with real-time firefighting. The real test begins when you’re running the last mile, which starts after you have a prototype-like system that should evolve into a real stable prototype that the market can squint its eyes and judge.
Although the team size usually starts increasing marginally in this phase (you’re not three scrappy engineers building everything), there are a surprising number of nuances to handle— development, customer feedback, electrical/mechanical stability for corner cases (they can be infrequent but fatal), stress testing (that might expose surprising bugs/flaws).
Some problems and feedback can be taken care of easily. Some need you to look at your drawing board. Some are cheeky, elusive corner cases that almost don’t exist (but if they come alive, they bring the system down). And some make you question your current design. Given the interplay between software, AI, electrical, and mechanical domains, it is rather interesting and challenging to find solutions with creativity and analysis.
To add to your single system test woes, this is also where you ideally deploy more than one prototype. Even with a well-engineered system, behavior predictability and consistency across multiple robotics products is a challenging feat. One small difference in the environment can drastically affect your performance metrics — an underrated issue in Robotics.
With multiple unknowns coming into play, this is where you get to know if you designed your system well in Phase One. If yes, you have a fighting chance, so fight. If not, your potential customers are almost at the door. Oops! 😃
Phase 3 — Building a stable, reliable and tested product
Remember that we’re still with the last 10% of our work —that means we’re in the end game.
This phase focuses heavily on multiple prototype deployments, crazy stress testing, polishing the system for presentation, demos, detailed customer feedback and iterating with all that information.
Further down the rabbit hole of deployments and constant demos for sales, each deployment cycle is a task in itself — there are so many variables for every customer setup. With most of your time with deployments-driven engineering, you have to balance R&D and testing based on customer feedback and next-generation system development targets.
It’s essentially like juggling three balls — deployment/demos, firefighting and R&D, whilst adjusting your focus based on what needs immediate attention.
I’ve recently realized that each phase needs a slightly different engineering mindset. While I can’t be specific about which phase we’re in as a company, I can easily say that the scrappy engineer in phase 1one gradually has to become more of a perfectionist (not quite, just closer to it) as we tread on the path to launching a kick-ass product.
I love building well, and quickly, but perfectionism never lured me. And in all honesty, it’s still not my default style and takes some mindset shift. I’m still learning. 😃
The phase also makes you realize the importance of technical management, even for us engineers who are knee-deep in coding and soldering. But it would be wrong to say that technical management and decision-making aren’t important for engineers early on. It’s quite the opposite.
Thoughts on technical management —
When you’re one of the early engineers or join a small team, building isn’t your only job. You also contribute heavily to the technical vision of the project — What do you build? How well do you build? Where’s the line between “well built” and “over-engineered”? What’s the timeline?
Technical decision-making is one of the hardest and most important skills to possess — harder than building. Hence, technical management is an inherent task for an engineer — something we’re always trying to get better at.
As you move from one phase to another, the team size changes based on requirements, funding, project plans, etc. With that, comes the opportunity to be a colleague while maintaining the same output as an individual contributor.
I quite enjoy these aspects of a job role like mine. Trying to be the same (in fact even better) individual engineer while also being of help to others is interesting. I can’t tell seem to pinpoint the reason. It just is fun.
Things I’m looking forward to —
What’s next?
Finding a better personal balance between rapid development and perfection as an engineer
Learning and building next-generation features
Experimenting a lot more
And of course, see the product we built from scratch in the market 😉
Fin.
Sharad