Guerilla Product Development — From MVP to Production
Over the last 15 years I have run a consultancy focused on product development in the Robotics and Consumer Electronics industry. During this time I have had the honor of being involved in the product development cycle of literally 100s of products, and working with many talented people across the industry. I have seen things both amazing and horrifying. My friends in the industry have always asked me to share experiences through stories or process steps they can learn from to help make their product development cycle better. Recently, I started writing these steps down, and I have given my steps a name: Guerilla Product Development. The idea here is using unconventional methods to fight the war of product development, my own methods mostly, and not necessarily things you will find in a textbook.
Part 1 of this story is here: Guerilla Product Development — A new approach to produce development stages
Guerilla Product Development
Here is the outline again of all the steps. I really only covered steps 1 through 4 in the prior article.
The Basics of Guerilla Product Development
- Plan your Product Development — If you haven’t written down a set of requirements, and planned how to execute, you are doing it wrong.
- Market Fit First — Field of Dreams products rarely succeed — Do your market research, then build a product for that market.
- Domain Expertise — Do NOT build a product in a domain where you know nothing. You will be doomed to failure.
- Surround Yourself — with close associates + a team of mercenaries. You can’t be an expert on everything — hire experts who know the things you don’t. You need a team that gets along well and is willing to admit when they don’t know something — No room for big ego’s or narcissistic personalities.
- Iterate early and often — Failing repeatedly is the BEST option.
- MVP — as quick as possible once you know market fit — and TEST it with actual customers.
- Strike problems fast — Eliminate any red-flag tech hurdles in the beginning.
- Design to Scale — Do not pick product components from hobbyist parts.
- Partner Early — with a Contract Manufacturer (CM) and your entire supply chain.
- Sell — your product before you finish making it.
Teamwork
To continue on the journey toward a great product development process, there is much to say on the topic of teamwork and team building. In fact, as I contemplate it here, I realize I could probably write an entire article just about this topic alone.
I had the fortunate and amazing experience of working at Hewlett Packard as a Software Engineer in the early 90s, right out of college. The teamwork and team-oriented approach to software engineering at HP was amazing and I felt like each day I learned something new from my colleagues or managers. Big shout-out to all my old HP friends. Almost everyone I know who has spent time working there, had a really special experience there. During this time, David Packard published his book on this culture, The HP Way: How Bill Hewlett and I built our Company.
When the book was released, they handed out a copy of it to everyone. I remember thinking as I read it that I saw countless daily examples of people working together just like in the book. Unfortunately, I don’t think the family-style culture of the HP Way exists so much anymore in the modern HP Enterprise, but after marinating in this fantastic culture, it really shaped my thinking of what kinds of things I value in good teamwork. Good teamwork comes from having a great team of happy, enthusiastic people to work together. Concepts from this book like “flexible work schedules” and my favorite “management by walking around,” are ingrained in my psyche from my early career time there. I highly recommend reading it. For a 25-year-old book, it has many concepts in it that are extremely relevant in building great work environments. You absolutely cannot have good teamwork if the work environment sucks.
I will discuss the team process more in the next section, but something I want to reiterate over and over because it is so vitally important, is the concept of NOBODY WORKS ALONE. What happens when that one person who knows everything on the project gets sick, or the customer asks a question and that one person isn’t available? Nobody should ever work alone on a project — EVER. To me, teamwork and good work culture go hand-in-hand.
This whole teamwork discussion would not be complete without discussing my teamwork pet peeve, which is toxic engineers. I will try to keep this piece short because, again, I could probably write a whole article on it. When I define a toxic engineer, I define them as either someone who is super prone to narcissism or gaslighting others. It is impossible to fulfill the Never Work Alone mandate if you have people like this on your team because they always WANT to work alone. I know sometimes it is tempting to add a “genius” like this to your team, but don’t do it. You may not regret it soon, but you will regret it later when your team revolts and refuses to work with someone who is toxic to the team culture, or worse yet they say nothing, and slowly flee your enterprise by leaving.
On the topic of interviewing and hiring, which any ex-HP person will recognize is the concept of Behavioral Interviewing, the Society for Human Resource Management has a great PDF download that explains this interviewing process. Interviewing Guide for Early Career Candidates
In a nutshell, Behavioral Interviewing has a focus on coming up with specific examples in their past work where they’ve handled certain situations they might encounter in your organization. A typical behavioral interview question might begin with the phrase “Tell me about a time in work or in school when you…..” and then put on the end of that something they will need to do in your organization. Get them to be specific as possible coming up with an exact example in their prior history of how they dealt with a specific situation. Don’t let them generalize. You will often find this technique to be very revealing about how they might handle situations in your organization.
Beyond using the Behavioral Interview techniques, the greatest piece of advice I can give someone with a growing company on team building or hiring is: Make sure part of your interview process contains some interview questions with a couple of “unsolvable problems” that are presented as being knowledge any engineer worth their salt could solve. If the candidate trying to solve the problem presents either the wrong answer and cannot admit they got it wrong, or tries to blame the test as being rigged, or tries to gaslight you into thinking it’s your fault for not presenting the problem right, this is a huge red flag. You literally cannot have good teamwork with an individual like this on your team….EVER. I know I sound harsh when I say all this, but you cannot build a family-like work environment with a toxic personality on the team. Am I sounding like a broken record here? Hire someone who tries to gaslight you during a job interview at your own peril.
On a less-dark note, don’t be afraid to bring outside consultants into your project. Make sure you thoroughly vet them first using my tips above, but when there is some critical, deeply technical thing you need for a project, and nobody on your team has the knowledge, don’t be afraid to bring in an outsider to help. I have seen some large organizations which suffer from the Not Invented Here syndrome of being unable to bring in outside consultants to help because they feel it contaminates their internal knowledge pool.
Lesson: Step number 4 of the guerilla methods, is to break this conventional cycle of staying inside your organization and get help from the outside world from smart collaborative people.
Iterating Early and Often
I originally came from the software engineering world, and software engineering practices and methods are usually my starting point for building good processes. Being a young software engineer in the mid-90s, I had a front-row seat for the latest and greatest methods, one of them being “Extreme Programming”.
One of the big take-away items I had from this method was the concept of always working together with a partner in programming pairs or teams of two. The other one was this idea of doing lots of small software releases, rather than giant ones, as it spread out the risk of new bugs or problems into shorter time scales where they could be resolved quickly.
This method of software development eventually rolled up to be part of what we now know as Agile Software Development.
Agile methodology is highly used in the Lean Start-Up book by Eric Ries and is a must-read for any startup founder.
Often customers don’t want to hear this idea of a highly iterative process because it sounds expensive and error-prone. Using Agile methods for developing hardware and software allows you to stay lean, and make mistakes early where you can fix them at the lowest possible cost. It is a highly parallel process and allows you to achieve a fast development calendar while fixing issues quickly along the way.
There is another method which for some stupid reason I still see people gravitating to these days, and it is what I lovingly refer to as “The Product Development Model of Doom”. Avoid this method at all costs — The Waterfall Model:
The idea in Waterfall is you break your project up into very specific phases, with each phase depending on the subsequent ones. You aren’t allowed to move onto the next phase until the current one is complete and perfect. I have had customers who insist they are using Agile methods in their product development strategy, and when you break down how they are approaching the problem, there is very little parallelism, and they are clearly following a Waterfall methodology. My advice to anyone embarking on a hardware development project is to avoid Waterfall methodology. Take a hard look at what you are doing and ask yourself if you are doing Agile? Or Waterfall?
Another problem that comes up, even when employing Agile methodologies, is the issue that failure=bad. In a highly iterative process, failure=good, because it’s just as important to know what doesn’t work, as well as what does. I have seen some organizations that fundamentally cannot operate this way. Many view that perfection is the only allowable outcome, and failure of any kind is not an option, and that any hint of iteration due to failure should be a source of shame that requires penance from the engineering team. This can create a huge problem if your organization is set-up this way since the essence of iteration is making mistakes and revising them quickly. Do not treat your project as a rocket, that will only be fueled and flown once, and if it explodes you are done forever. Take a lesson from Elon Musk and Space-X. They have blown up quite a few rockets, and are ready to iterate quickly with new revisions to make the design better.
Lesson: Iterating early and often = identifying problems quickly and fixing them when the cost is lowest.
MVP Quickly
“We must learn what customers really want, not what they say they want or what we think they should want.” — Eric Ries
Field of Dreams products usually don’t succeed. If you build it they will come should NOT be your mantra. Building something market-focused with the minimum feature set is pretty easy to do if you spend time with your potential customers. You can NOT guess at this.
To distill this down as simply as I can, you really want to go out, interview as many potential customers as possible, and build a product that they really want. The closer you can put into someone’s hand something that resembles the real thing they will get when they buy it, the more valuable the feedback will be. You will learn what works, what doesn’t and what features and capabilities of the product are actually necessary.
There is literally nothing that causes me more anxiety than someone who hires OLogic to design their product, with lots of seemingly clear requirements that LOOK like they were gathered from customer interviews, only to find out later it was something someone cooked up in their head of what they thought the customers wanted. Want to see me come completely unglued in meeting?!?! Reveal to me you never spoke to any potential customer ever after the construction of a first prototype is underway. This has happened to me repeatedly. I WANT my customers to succeed, and I KNOW this product feedback is the difference between success and failure. What can be worse is when they insist on proceeding without changing course once a revelation like this is made. I usually liken this situation to one of, someone who has never walked a tightrope, hiring us (professional tightrope walkers) to help, and then they string a rope across the Grand Canyon and force us to watch them walk across it for the first time. It is gut-wrenching.
Interviewing potential customers for your product early and often is key to having your first MVP containing the key features that will influence purchasing decisions. If you don’t know your customers, you will also be doomed. You can’t take the easy way out of this and just interview your friends or family members. When we worked on toy products for Hasbro, if a marketing person took a toy prototype home and showed it to their family or their own kids and used that to influence decision making, it was called “Kitchen Table Market Research”, and it was a fire-able offense. It is tempting to short-cut the hard work of actually going out and showing product directions to customers, and using their feedback to influence the development. But don’t take the short-cut — it’s just not worth it.
When I look at CEO friends who are killing it in the market because they did this process correctly, I hold up Dusty Robotics again. This video clip captures exactly what you want to be doing.
Strike Problems Fast
Let me lay out a “pretend” scenario. A Fortune 500 company comes to us and says, “We want to get into the robotics business. We already have a team working on a couple of robotic concepts, and have been working on it for months, but we would like to hire OLogic to make a prototype that is more like the real product we want to build. We are planning on dogfooding the product on our own sprawling corporate campuses, and then engaging a few partner organizations as early adopters. We have a prototype we want you to build a competing design for to evaluate options. It is an intra-office delivery robot, and here are some product concepts.”
There is a fully blown out product requirements document that has already been written, with such fun features as a smartphone app that can summon the robot to your desk, and where you can put something in the bin on top and then send it on its way to your co-worker who might be at their desk or somewhere else in the building. There are lots of issues, or problems fundamentally wrong with this whole product concept, that is explained away using lots of hand-waving in the initial requirements meetings. All kinds of red-flags are going off in your head about the whole concept, and they clearly need help. What do you do? You certainly could freak out and run away screaming…..that is always an option. ;-)
This scenario is totally hypothetical, but the most important lesson here is to take the items you know you can solve easily, set them aside, and only focus on the hard-issues that are going to take some research to solve. Either these hard-to-solve problems need to be resolved quickly, OR they need to not be part of the initial product requirements. Usually, I follow the basic 5-step problem-solving process which I made a simple diagram for below. Funny, I remember learning this in like the 4th grade, but people take such a scatter-brained approach these days to problem-solving, I have seen people actually not do this.
The big question here with these 5 steps, is how do you do it quickly? The key to this is to parallelize the tasks and be evaluating solution options as you make the list of possibilities. You can skip to the end quickly this way. It may not yield the “optimal” solution, but many times it gives you a solution days faster than the optimal solution, with the opportunity to go back and find the optimal one later.
Perfectionism is frequently the root of failed projects. Break the cycle.
If the scenario is one where you need to ditch an actual requirement in order to make the product more realistic, you absolutely have to go back and see how important it is to market fit.
So, what do I actually do in this hypothetical scenario? I would literally propose a project where we go visit the campus of the big company building the robot, plus the campuses of several alpha test sites. I would take piles of pictures and interview people who might be end-users. Plus, I would look through the list of requirements and find out which “red flag” ones are not solvable in the time-table outlined. Then, I would look for other requirements they didn’t think of when writing the PRD because perhaps they missed some. Was it written by someone who doesn’t understand the requirements of deploying a robotic product? It will generally be revealed through site visits and photographs of potential deployment locations. Make sure to fix those problems up-front in your MVP design process or risk having your product fail when you show it to a customer for the first time.
In our hypothetical example here, we go on a site visit and low-and-behold — the building has glass everywhere inside. Glass walls are common. What does that mean for basic Lidar-based SLAM navigation or 3D camera obstacle avoidance? Trouble! You need sensors on the robot that can detect glass easily and avoid it. This simple little bit of R&D can lead to a solution that would not have been discovered until much later in the process. Problem found and solved before we built anything. You can apply this example to almost any product development cycle if you put your mind to looking ahead as to how the product will be used and the environment it will be used in. Make sure you have the time and the budget allocated up-front in your product development cycle to strike problems quickly!
Obviously, there are tons of other obstacles to overcome in this project, but the goal was to show a simple example of how it can be done.
Lesson: Eliminate any red-flag issues in your product requirements through simple research up-front and reduce product development risk.
Final Thoughts
Without good teamwork and a good iterative process, there is no way to get to an MVP with the issues resolved in a reasonable amount of time. I always seem to think about skiing at the end of writing all these good tidbits down. With that said, sometimes it makes sense to put a sign up, block the trail, and do a little bit of work before heading back to the race-course. Whether that be improving your team morale or figuring out how to apply more agile methodology to your process, getting these items planned right before setting off to build products is crucial to your product success. It’s important to have a business process in place to support your development efforts. STOP! Take time before you build a product to contemplate the process you are going to go through to get to your end goal. Write it down and collaborate with your teammates on how you plan doing the work before you actually go and do it. Putting pen to paper and organizing yourself out of the chaos before it begins will save you hours, days, weeks of development time. At OLogic, we have an entire team dedicated to capturing all our “Tribal Knowledge” to make sure we do the process better each time.
When in doubt, stop and make a process for it. Then everyone on your team knows what the roadmap looks like and knows what the next steps in the process should be. There are tons of online tools you can use for doing internal knowledge capture and process documentation. Jeepers, I am just realizing I could write a whole Medium article on just this issue all by itself. At OLogic, we use a combination of Confluence and Lucid Chart to capture all this info. However, there are many other good ones out there like Tettra, Slab, or Bit.ai. We literally evaluated them all at one point. However, I think the most important thing is to figure out what tools fit best with your team. Everyone seems to have different needs, and just because you have a good tool for capturing processes doesn’t mean you can get everyone to use it.
Teamwork, Iterative and Agile techniques, having a good MVP, and striking problems quickly were the focus of this section of my Guerilla Product Development techniques. The last three Guerilla techniques are to Design to Scale, Partner Early with a CM, and Sell your Product before you finish making it. In the next article I am going to reveal all my secrets on getting ready for manufacturing, and doing product lifecycle management, so get ready for that.
Read Part 3 of this guide: Guerilla Product Development — Scaling to Selling
In case you just showed up and read this, Part 1 of this story is here: Guerilla Product Development — A new approach to produce development stages
About the Author
Ted Larson is the CEO of OLogic, Silicon Valley’s premier robotics and consumer electronics consultancy. Ted is a Software/Hardware Geek with 25+ yrs. of experience designing, and building consumer and robotic products. His current interest areas are robotics, artificial intelligence, and embedded systems in consumer electronic devices.
