As Chief Product Officer at DigitalOcean and a developer-turned-entrepreneur, Gabe Monroy shares how founders can avoid the trap of over-engineering products that customers won’t pay for and how to de-risk product development through a simple analogy of candy, vitamins, and painkillers.
Approaching product development with a founders mentality requires a deep understanding of what pains your customers.
You Make Something Awesome, and No One Buys It
Before Monroy joined Digital Ocean, he built a SaaS product with a friend in 2011. This was when everything in the tech world was all about Amazon Web Services. Tech companies realized that this cloud thing might be for real, but the word on the street was that AWS was too hard and complex for customers to realize its benefits.
That’s when OpDemand was born. Monroy admits the product was overengineered and missing some features, but overall, a beautiful piece of work. It took one year and a million dollars to create, but product traction, conversion, and revenue were low.
Startup folks are lean and mean, so they were going to iterate. And to do that, they decided to start talking to customers.
They found customers didn’t understand the value props of the product. So Monroy’s team built out all of the features they wanted. When they released it into the world…nothing; it had no impact.
They had an awesome product, but no one to buy it. Why?
Candy, Vitamins, and Painkillers
Kevin Fong, a VC, said, “We divide business plans into three categories: candy, vitamins, and painkillers. We throw away the candy. We look at the vitamins. We really like painkillers.”
Candy — A nice treat, but you can live without it.
Vitamins — Can improve your life, but they’re only a nice-to-have.
Painkillers — Are the must-haves; you can’t live without them, and easiest to sell.
Not every product must be a painkiller to be successful. Look at video games. They’re candy giving off quick dopamine hits and bringing in loads of revenue.
But to serve customers, you must understand which kind of product you’re selling.
That’s why OpDemand tanked. They failed to distinguish and communicate what they were offering.
When talking to customers, what they perceive as the value of your product is way more important than what you think the value is. And you’ll never figure that out if you don’t spend time talking to them and doing the work upfront.
If Monroy could go back and do it all over, he’d take this concept of road before code seriously. His main lessons learned throughout his career are:
- Study the desired outcomes of your customer carefully.
- Design your product experience to enable these outcomes seamlessly.
- Document your core product flows in a visual walkthrough.
- Walk customers through them. “Here’s what the product would look like if we built it.”
- Get customer feedback on the walkthrough before writing any code.
- Do this with your engineering team so that they can develop customer empathy.
Figure Out The “Jobs To Be Done”
Clay Christensen of Harvard Business School worked with Mcdonald’s to increase milkshake sales. Yep, people drink milkshakes as their “breakfast” drink of choice.
His team talked to customers, built out a long list of features they wanted, and incorporated them into the recipe.
Can you guess what happened? Nothing. It didn’t impact sales at all.
So they decided to think differently. Customers were “hiring” milkshakes to do a “job” for them during the morning. What was the job to be done?
They discovered customers had long, boring commutes to work in the morning and needed something to keep them engaged during the drive and to stave off hunger until lunch. So they were buying a shake.
You could also hire a banana, but that’s not as exciting. A candy bar would also do the job nicely, but they didn’t make you feel too good.
So by understanding the job the milkshake was hired to do, they got to work. And would you believe it? Increasing the viscosity of the shake, making it more challenging to get it out of the straw, therefore, longer to drink, increased sales.
The takeaway here is clear. To build the best version of a project, you must understand the job to be done. Customers will tell you what they think would make a product better, but they don’t know. So figure out what the job to be done is, and solve for that.
Pivot From Vitamins To Painkillers
To pivot from vitamins to painkillers, you need to focus on the must-haves by developing “painkillers” for your customer’s problem. It will better serve your business than only focusing on nice-to-haves like vitamins.
If you have a headache, you want an immediate solution to make it go away. That’s typically the best way to look at creating painkillers. How can you make their pain go away?
Vitamins are seen as “prevention.” Like a banana, that’s not very action-inducing for many. But a painkiller who can make you better right now? People will act now to take away their pain.
If you only build what customers say they want and don’t take the time to understand the jobs to be done, you’ll get misled in product development. What is the outcome? Why will they hire your product vs. an alternative product or path altogether?
Once you have that information, you can create a strategy. When you understand the must-haves aligned with your product’s promise, you’ll know how to shift from a vitamin to painkiller. You always want to create value for customers, and to do that, keep a pulse on the perceived value at all times.
If you ask them what they want, you’ll get a whole list of features that they like, but you’ll miss the heart of the matter.
Key Takeaways
When thinking about candy, vitamins, and painkillers, make sure you hit the road before you code.
- Understand which one you’re selling.
- Talk to customers to understand how they perceive your product.
- Take a design-first approach and leverage technology like design sprints.
- Know your customers’ jobs to be done — understanding their motivation and intended outcomes.
The post Why You Want To Develop Product Painkillers, Not Vitamins with DigitalOcean CPO Gabe Monroy (Pod 633 + Video) appeared first on SaaStr.
via https://www.aiupnow.com
Amanda Beaty, Khareem Sudlow
