When it Comes to Product, Shoot Pellets Before Cannonballs
Note: the original phrase is “shoot bullets before cannonballs.” The word pellet has been used instead of bullet for sensitivity.
Jim Collins has this great quote, “shoot pellets before cannonballs.” This quote is in reference to leadership. More context:
Foolish leaders rely on cannonballs. Wise leaders shoot pellets first.
— Jim Collins
He’s talking about how, in difficult times, desperate leaders will act on untested assumptions (and fire cannonballs), instead of testing ideas in a low cost, low risk way (shooting pellets).
What I find so attractive about this statement and everything that Jim goes on to say is: it exactly sums up how we approach making a product from scratch. What we commonly call MVP’s (minimum viable products) or MLP’s (minimum loveable products). In fact, I couldn’t believe that he wasn’t talking about digital product development.
But maybe he is, just in an indirect way. As we’ve heard so many times before, an idea is not valuable, it’s how the idea is executed. In early stage companies execution can make or break a business. When we talk about how to build successful products in early stage companies, we are really talking about leadership. The type of leadership that is not going to jump into the deep end, without first dipping a toe in the water. Perhaps it’s the CEO that takes this approach, or the Chief Product Officer, or the Product Manager. However, what’s even better is if the organisation as a whole can come together on how they approach decision making, which ultimately informs and defines how the organisation builds a product.
First Principles
What I find to be such a good companion to this way of thinking, is the First Principle approach. This has become famous in recent years thanks to Elon Musk.
“With first principles, you boil things down to the most fundamental truths…and then reason up from there.”
— Musk
I understand that making a product is hard. I’ve done it a handful of times myself and it’s humbling how fast confidence can turn into quicksand. However, what often happens and what is so dangerous is: fundamental truths get replaced with assumptions. In a way that we’re not honest with ourselves. What is not said is, “hey, this is my bias — or this is my assumption.” Instead the assumption is just kinda dropped into the product making process as a fact; something we’re meant to believe because someone with authority said so.
We may not have the luxury every single time of taking one fundamental truth and building on it with another one; there may be times when we have to take a little risk and throw a strongly formed and research-backed decision into the mix, but this is not an excuse for not trying to validate through first principles first.
“Pellets are miniature cannonballs. They’re inexpensive, easy to make, and easy to shoot. Outcomes are obvious.”
— Jim Collins
How can you fire pellets to figure out your fundamental truths?
This is the core of Lean UX. The famous “Think, Make, Check” cycle that Lean UX is so well known for. Now that we have this context, we can better frame the question: how can you Think, Make and Check your way to fundamental truths? Truths, which you can actually build upon.
That little thing called a business model…
“Your job as a founder is to quickly validate whether the business model is correct by seeing if customers behave as your model predicts. Most of the time the darn customers don’t behave as you predicted.”
— Steve Blank
Most of the time, what we end up building is different than what we set out to build, based on what we learn along the way. More specifically, how customers and the market responds to our product. Firing cannonballs is effectively a way to skip this process, it’s a way to miss opportunities to learn.
Avoid This One Major Mistake
This one mistake creates a host of other issues that can suffocate a business:
Over investing in a solution without thoroughly understanding the problem you’re solving or actually solving a problem (a.k.a. creating something that nobody needs).
Other problems this creates:
- Buying or building technologies that the company becomes wedded to
- Legacy code that requires more (unnecessary) hires to maintain
- Starts a product / business trajectory that is very hard to change
- An abundance of software/code that a company has a hard time letting go of due to sunk cost fallacy
- Long sprint cycles, slower releases resulting in even less learning
- Unhappy employees
- Probably some unhealthy coping mechanisms
Adapt When Necessary
It’s great to agree on a process and method of decision making. Remember to be flexible and nimble in your ability to change and adapt your process to where you are in the product lifecycle. While learning never really ends, it’s much more useful in the beginning before your product idea is fully formed — so bake time for that into the process. Product design is important but you may spend more time on it after you’ve learned enough to make really solid and long-lasting product decisions; so don’t get too bogged down in perfection too early. Most of all, make sure you’re getting the most value from people on your team; include team members in the decision-making process — when people feel involved, they tend to work towards goals better together.
While this is not a comprehensive post on the MVP/MLP process; if you enjoyed this post — you might like to read more about product solution fit and product market fit.
