Guerilla Product Development — A new approach to product development process stages
In 1983, Jay Conrad Levinson published his influential book Guerilla Marketing. It was based on the concept of Guerilla warfare, which is using novel or unconventional methods to fight a war. Similarly, Levinson defined how one would use novel or unconventional techniques to promote or market products. I did not discover this amazing book until more than a decade later when I had my first start-up company and was looking for novel and inexpensive techniques to get the word out about my awesome products. The biggest concept from the book that resonated with me was this idea about strategic, targeted, eye-grabbing items that would cause a memorable experience where people were more likely to recommend your products or services via word of mouth.
Fast forward almost 25 years, and here I am running a Robotics and Consumer Electronics consultancy — OLogic — and some of these concepts resonate for me outside of marketing related tasks. I realized a while ago that this idea of targeted, unconventional techniques for product development is something we do every day at my company; we just hadn’t given it a label or a name. So, today, I am finally giving it a name, inspired by his book, and I am calling it Guerilla Product Development. In this article and a couple more to follow, I will outline some of the concepts of this technique of product development and give some specific examples of how we use these ideas in the development of Robotic and Consumer Electronic products.
Many of the items I am going to talk about here are things you may already know, as I have incorporated multiple different methodologies to optimize our own performance over the years. Perhaps I am just assigning new nomenclature, or semantic context, to terms you might know by other names. No matter what, this is the process I created and follow at OLogic. It has worked extremely well for us and maybe you will gain some insight and benefit in your own product development life by knowing the way I approach the problem.
In my time as the CEO of OLogic, I have seen many product failures, some of which I was involved in and some I was not. It feels more proactive to me to write an article on the things that will lead you to success, as opposed to the highly simplistic, “Don’t fail like these folks did!” Of course, all of these failures and successes have shaped my opinion on what you should or shouldn’t do during a product development cycle, and that’s what I would like to share.
Guerilla Marketing: Easy and Inexpensive Strategies for Making Big Profits from Your Small Business
Introduction and Background
I have generally not been one to read a bunch of business books, and then follow their methods to the letter. Usually I am the type of person who forges their own path through painful trial-and error-experimentation, with a process to follow falling out logically at the end based on success or failure.
When I have fully decided that a result is worth getting I go ahead of it and make trial after trial until it comes. — Thomas Edison
Maybe you are this way, too? If you are, I think the items I will outline here will resonate with you. The bulk of what is contained in this article is just my advice. None of it is rule-of-law. My plan here is a series of articles to get through it all in bit-sized chunks. Having read through all the articles, if they help you to forge a better understanding of your own product path, then all the hard work it took to write the posts will be worth it!
One of my main principles in product development is to get to the essence of the product quickly, finding its unique or core value without spending a lot of time and money to see if it’s viable, and if it’s not, you must “cut bait,” leave, and move on. At OLogic, on a weekly basis, I encounter entrepreneurs with cool product concepts, and perhaps even a working prototype, that they are looking to take to market somehow. It blows my mind sometimes when I hear they have been at it for years, tinkering away in their garage. My usual advice here is
Fail quickly, if you are going to Fail
Move on to the next big idea quickly to find one that succeeds. You don’t want to waste two years or more of your life to fail later. This concept isn’t anything new or novel. I have seen it over and over, but I have been surprised at how many people don’t live it. It was ingrained in a book which is a must-read for any startup founder called The Lean Startup by Eric Ries.
It is filled with not necessarily new business and engineering concepts, but re-frames them in a new way that has wider appeal in business circles. One heavily-used concept in the book, which now seems like de facto product development language, is the idea of the “MVP” or Minimally Viable Product. The book describes how the aim of any founder is to try to arrive at this product as quickly and cheaply as you can to enable the founder to obtain customer feedback/validation to understand whether the implementation is worthwhile. If you are contemplating doing a start-up company, this book is a must-read.
Last, you need to assume you are not going to follow-through on your first idea. Repetition makes things come as second nature. Don’t settle for your first idea. In the words of Conan the Barbarian
What does not kill you makes you strong!
If you are building a start-up company, make sure you have enough funds to not only follow-through on that first idea, but be able to make a left-turn during your product development cycle.
I think small startups tend to benefit most from this type of advice, especially those who have never built a hardware product before. However, you would be surprised at how often big brands don’t think things through when building new product concepts, and get stuck in the same places the small start-up’s do.
The Two Hemispheres of Product Development: There are two hemispheres of product development and you cannot get a product to market without them both. The first is product concept and design, and the second is implementation. My consultancy comes from the implementation side, not the design side. So take my advice with that in mind. Most of the time I get involved in a project if the design side is incomplete, or un-implementable, I have to go back and help the customer fix it before they can move forward with the implementation.
Guerilla Product Development
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
This is the high-level list of things I am usually thinking about whenever I am working on a new product project. You need to have a good structured method of planning and organization, or you will be doomed to chaos, repeating the same mistakes over and over. I bet right now you are thinking, hmmm….these items don’t seem very unconventional, but I’ll bet if you think back to how you are doing things in your own product development cycle, you aren’t doing this.
Think of each of these items like a like the game Jenga. They all stack on top of each other, and it becomes more and more difficult or precarious to change them once you have moved on to the next step. For example, when you product is ready to go to production, it’s pretty hard to go back and fix the market fit problem.
Planning your Product
This seems so common-sense, so stupidly common sense, that I am sure that as you are reading this you are thinking to yourself
Duh! Everybody knows that?!? This is crummy advice. :-(
From what I have seen, only people who have done it 10 or 20 times before seem to be able to ACTUALLY do it. Again, since we are on the implementation-side of building products, we get exposed to poor product plans on a daily basis. I don’t actually keep a scorecard here because the numbers would be hugely depressing. I literally can’t count the number of times where someone came in with a one page document describing their product requirements, and spent 2 hours explaining it, with lots of hand-waving about how we should fill in the missing gaps. They didn’t do any kind of organized design cycle up-front. Thankfully we are able to realize this quickly, and set up an engagement where we can go back and help them create all the missing documents to make the vision and implementation plan crystal clear.
There are five pieces to a product plan:
- Requirements Documentation — Explains what the product could, should, and must do.
- Specification/Implementation Documentation — Explains an implementation plan for how the requirements can be met.
- User Stories — A document that describes a typical user interaction or experience with the product. Often starting with this, can lead to many requirements you didn’t think of.
- Timeline — Think through how long it will realistically take to do everything you need to do to get to the end.
- Budget — Do you have enough money to implement all the items in your requirements? Maybe you need to adjust them to meet the budget.
Yes, I know, many of you classically trained product design people will holler from the rafters saying, “That’s not enough!!!” — This is not a treatise on exactly every single thing you should ever do….this IS Guerrilla Product Design — Fast, Strategic, Targeted, Unconventional!
Lesson: Spend the time to plan your product and write down the plan. Don’t leave it in your head for others to guess at. If you have to wave your hands explaining it, you didn’t plan it well enough.
The Design Side — Market Fit
Before you can even begin a product, you need a good design. The best products in the world not only perform their job well; they look sexy while doing it. Generally, you cannot determine good market fit if you don’t have a basic idea of what it is going to look like or what the user experience will feel like. Here is the first place in your product design journey you need to employ the first Guerilla technique. Get some help from a professional industrial designer.
I have had the absolute honor of working with some of the best industrial design firms in Silicon Valley over the years, and I can tell you from first hand experience, the better the industrial designer, the better the end product. Here are some of my favorites. If you go to their websites you will find products they have designed from everyday tech brands you will recognize. Here is my secret list of favorites:
Over the years, I have realized that a very small number of studios design the bulk of the consumer or medical products out there. Each of these design studios has some absolutely amazingly talented designers. It is their own personal touch that adds that secret sauce to how a product looks, and how you use it, that makes people want to buy it by just glancing at it. We can all appreciate stunning design when we see it, and creating it is a talent.
On the other hand, I have seen many products that look horrible, but work incredibly well. Sometimes it feels sad to see a product that works so well, but isn’t selling just because it is missing that sizzle that draws people’s attention.
Drawing 3D models of beautiful product concepts is only the first step that these firms will provide. The unsung part of their process that you typically don’t hear about is user research and study. Taking the product concepts, perhaps building tangible 3D printed models, and putting them in the hands of actual users to gauge their reaction to how they are supposed to work, and then feeding that back into the design process, is the golden part of the services they provide. This kind of work is incredibly important and difficult to do on your own if you have never done it before. It frequently makes the difference between product success or failure.
Many times customers will come to me to build a product and they haven’t done any of this. One of the first things I will typically do is steer them back on track by helping them gather their product requirements and engaging an Industrial Design (ID) professional. How is this a Guerilla tactic? This seems pretty conventional and expensive, but it doesn’t need to be. You can either use a small ID firm engagement, or if you cannot afford it, find a talented individual industrial designer to add to your team such as our exceptional industrial designer here at OLogic, or use a contractor platform where people moonlight and design students offer services to build their own portfolios. What I am saying is that this is not a role you can bypass and make it work anyway. I think this is one of the most important pieces of advice I give to my customers. You would think it is, but if you had met as many people as I have who have not done this, you would realize doing it this way is pretty unconventional for small businesses. Only the big, well established brands seem to do it.
Lesson: If you don’t study your market fit first, before you build anything, failure will be imminent. Get some help from an industrial designer!
Domain Expertise
I cannot tell you how many times someone calls me up with a product concept or idea, in a domain they know nothing about, where they would like to solve a problem using robotics. Guerilla technique #3, is you MUST have domain knowledge. I have seen dozens of products go to market where clearly it was built by people with no domain expertise whatsoever.
A perfect shining example of this is shown in this fantastic article in Robotics Business Review where they interview Aaron Prather who is FedEx’s R&D Evangelist. Getting Your Robot Startup into the Big Leagues — The ABCD Approach
One of the best quotes from this article is when Aaron says :
“When I find myself sitting across from young CEOs who have been in academics for their whole life and they tell me they created a solution for one of my company’s critical tasks, but they have no experience with that task themselves, I already have one foot out the door.”
If you aren’t an expert at the task you are going to automate, then you have literally no idea what you are getting yourself into. Aaron’s article really resonates with me because when I was in college, I had a job driving a parcel truck of the now defunct Local Parcel Service here in the San Francisco Bay Area. I probably logged 100,000 miles in their trucks delivering packages all over the San Francisco Bay Area. As a college student I always wanted extra dollars, so after my driving shift ended, I would stay late and help unload trucks, sort packages, and reload for the next morning’s deliveries. That was more than 30 years ago. Great memories driving those trucks and delivering parcels, but you would never see me stepping up to someone like Aaron with a truck-unloading robot. You need the insider knowledge of the pain points Aaron’s team members face every day. You need to not only know the job, but all the hidden details you could only learn by shadowing many truck unloading teams at a facility for days, weeks or months. And, don’t do it just at FedEx; do it at UPS and DHL, too. Then you will start to understand the domain and the type of problems you will be expected to solve. Academic knowledge is needed to build a robot, but the practical day-to-day operations will make or break whatever solution you provide.
Lesson: No domain expertise in the area you are developing your product = GUARANTEED FAILURE.
Examples of Product Path Planning
We are only a few steps into my Guerilla Product techniques, and so far all the focus has been on the first three, Product Planning, Market Fit, and Domain Expertise. Everyone wants to see some examples of these things in-action, and in the last couple of years I have had a great, front-row seat for many. I picked out two who I felt I could write about easily, because their CEO’s are friends, and hopefully they don’t disagree with my writing 😉
TickTock.ai
I am a pretty visual learner and I have a hard time with high-level concepts like the ones I have presented without some concrete examples to back it up. For example, in my last Medium article, I had to fall back onto my friend Ryan Hickman and his robotics startup TickTock, not to be confused with the video streaming platform my teenage daughter is addicted to. When Ryan and his co-founder Soohyun Bae got started, they didn’t have a huge pile of money, but he had a good vision of what kind of robotic products he wanted to build. Ryan published a multi-part Medium article series on exactly the steps they took, which although Ryan and Soohyun decided to pursue a different path in the end, their steps were exactly spot-on. An Exclusive Look Inside TickTocks Consumer Robot Product Explorations
If you read through his articles you will see tons of gorgeous renderings of product concepts, as well as exact user-experience stories of how they expected people would use and interact with the product. They are described visually. Hundreds of concepts of how it could work, and how people could interact with it best. Did they spend a million dollars coming up with these designs? Nooooo! They hired a brilliant Industrial designer as part of the core team. Specifically, this guy, Bryan De Leon — I wouldn’t have called him out here if I hadn’t noticed Ryan did it in his original article :-).
Ryan and Soohyun followed some of Eric Ries Lean Startup methods. They tapped into their network of friends for help. They stayed focused and strategic on the plan first. Not knowing what I was getting myself into, I even let them incubate their startup in my conference room for what I thought would be a month or two, which ended up being a year, so their team had a workspace where they could get this stuff going without a bunch of distractions.
If you read Ryan’s whole series, you will see a shift from a focus on the home, to a focus on back-of-house operations in a grocery store. Differentiating in Point to Point Mobility
His amazing series of article raises many big questions! Why did they do that when it seemed like they had a really awesome concept for a home robot solution??? Why did they make a left-turn like that? Their product ideation was awesome, the user experience stories were great! The answer? Market Fit. They found a better, bigger opportunity by pivoting to back-of-store operations where the environment is much more structured and less chaotic than the home. Ryan, Soohyun and team did the research. They spent 100s of hours interviewing potential customers, and investors, and realized there was a larger market opportunity elsewhere. They made a plan, and were willing to change the plan before they spent millions of dollars building where the market fit was not perfect.
Dusty Robotics
Dusty Robotics is run by my good friend Tessa Lau who is both a robotics expert and a thought leader in the robotics industry. Her CTO, Phil Herget, knows how to take a problem and break it down expertly into small pieces to analyze if it can be done and how easy it will be to do it. They make this fantastic robotic product which automates the layout of floor plans during building construction. Every time I see someone who learns about their product and watches a video or a demo of it doing it’s thing, you see a lightbulb come on in their head. Wow! That’s a genius application of robotics to a real-world problem! How did they come up with that? How did they get the domain expertise? They did it through planning and analysis market fit. They learned to become domain experts on building layout.
When Dusty Robotics got started, I had the honor of being able to watch them engage in their early product design and market fit discussions. If you remember that conference room that TickTock was occupying from my prior example, it had recently become empty and Dusty needed some short-term office space, so they moved in. They knew there were plenty of opportunities in the construction space for robotic disruption, however, they needed to acquire the domain expertise to know the best fit. How did they do this? Initially through pure personal networking. They started making tons of friends in construction and went out of their way to go to construction sites to hang out and watch and learn from experts how things were done.
One of the initial ideas they had was moving materials around the site using a robotic platform, but that seemed too chaotic and unstructured from site to site. They researched it thoroughly and finally had enough info to decide it wasn’t the ideal choice. The next idea they had was to build a big robot vacuum cleaner for construction. They went to construction sites, they got permission to clean up messes with brooms and shovels, and debris bags. They measured how much material they would have to suck up, and how long it would have to run, and had almost settled on this idea, until as Tessa tells it, they noticed marks on the floor being used for laying out the walls of the interior of the building. Thankfully they had good flexible thinking, because they were able to shift it. They noticed the construction teams with blue marking tape drawing lines on the floors to finish out the building. They spent the time learning exactly how that job is done. This job seemed ideal for disruption with a robot. When they finally had a basic working prototype, they spent 100's of hours with teams doing this job to ensure they covered every aspect of the task. They even had bake-offs with the site workers to see who could lay down a floor plan faster, the team or the robot.
This is the kind of market research, domain expertise learning, and market fit work you need to do if you are going to build a product in a domain you are not familiar with. You can’t read academic papers on how buildings are built to find market fit. You have to go out there and actually get dirty, over and over again on a construction site. You have to meet customers who will see your product vision and help evangelize your solution, and give you continuous feedback on how to improve the product. You have to do this before you build anything.
They have spent 100's of hours on building sites testing their solution, and continuously improving it, adding to their arsenal of domain expertise on building layouts. Did they just build a robot to solve a problem? Nooo! It’s gotta look good while it’s doing the job. That’s ½ of what sells it to the next person who sees it in action. They hired our in-house, brilliant Industrial Designer, Zack Alban, to make it look sexy, and look like something that belongs on a construction site. Not something that belongs at a children’s birthday party, a construction site!
Unknowingly, because I had never coined any of these steps before, Dusty followed many of my early Guerilla steps 😉. They Planned their Product, Found Market Fit, got Domain Expertise, and then engaged their friends to help, hiring mercenaries to fill in on the areas they needed help. I know you are saying at this point, this is all common-sense! This is not unconventional! Ohhh but it is sooo unconventional. Even today, after all the followings of the Lean Startup movement, 90% of the people I see doing product development these days don’t do all these things. Dusty did, and they are forging a path to glory with their amazing product!
Final Thoughts
Every year my favorite ski resort has an event in the spring time called the Pond Skim. The goal is to ski quickly down a hill where there is a pond of water waiting at the bottom, and you have to skim across the surface to the other side without falling in. Product development, is a-lot like this Pond Skim event. Some people seem to be able to effortlessly traverse the pond over and over, some barely make it to the other side, sinking into the water, and some wipe-out fantastically, head-over-heels into the water.
Like pond skimming, it is extremely difficult to bring a product to market successfully. Most people may do this once or twice in their career, but as a consulting engineering company, we have been involved in hundreds of products. Some with major brands and big budgets, others on a shoestring budget from a bootstrapped startup with a laser-focused use case that is critical to the life of the company. Of these, some have succeeded and some have failed. Having seen firsthand what those companies and people did correctly to succeed has helped me to expand my understanding and expertise. I feel privileged to have gained from all these learning opportunities. Not surprisingly, dozens of friends in industry have asked me to share those valuable experiences so they may learn from them, too. It is tricky for me, because many of the OLogic customers really don’t want me sharing war stories from their product development cycle. However, it is these types of stories that allow people I don’t already know, or maybe colleagues who haven’t heard them before, to learn and absorb them into their own experiences. I have slowly been crafting these Guerilla steps into a development process of my own that we have ingrained into the DNA of OLogic, ensuring a higher probability of success in our commissioned projects, and helping my customers succeed in the market. In this article, I really only covered steps one through four. It is my intent to cover the next ones in a couple more articles, with hopefully more good examples to share, so stay tuned for more information on my Guerilla Product Development series!
Read Part 2 of this guide — Guerilla Product Development from MVP to Production
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.
