Why You Want to Develop Product Painkillers, Not Vitamins | DigitalOcean CPO Gabe Monroy

Yo, I'm Gabe Monroy. I'm the Chief Product Officer at DigitalOcean. I'm really excited to share some of what I've learned about approaching product development with a founder's mentality, including the difference between candy, vitamins, and painkillers in the world of product. So before we jump in, I thought it'd be helpful to share a little bit about my background, you know, personally. Prior to DigitalOcean, where I've been having a lot of fun, I was responsible for most of the developer-facing services in Microsoft Azure. And so while I was there, I learned a lot about running large product and engineering teams. I was accountable for billions of dollars in revenue there. But I actually came to Microsoft through an acquisition of a startup I founded called Deis. And though today I'm executive at a publicly traded company, I actually consider myself a founder and an entrepreneur at heart. And I'm going to share a little bit about that journey. Look, I've been very fortunate in my career, and frankly very lucky throughout my career. I think luck is often underestimated. I've sold two startups. At Microsoft, I started Azure's Kubernetes service, which is the fastest growing service, compute service in Azure's history. I helped DigitalOcean launch their first serverless product this year. Lots more innovation we've been delivering at DigitalOcean recently. But, But those successes mask a lot of failures along the way. And I personally think it's less interesting to talk about the successes than it is about the failures. So we're going to spend some time today talking about stuff that blew up and went wrong and what we— what I sort of took away from that. So, tell some stories. First story I'm going to tell is the first startup I ever founded. Company— SaaS startup, actually, called OptiMand. and I haven't actually told this story publicly before, so this should be fun. So, let's rewind the clock back to 2011, right? Oprah has her final episode, Adele is on the top of the charts, right? Good times, right? In the technology landscape though, what we saw was everything was about AWS, right? Amazon Web Services. They were growing like crazy. Tech companies are realizing that this cloud thing might be for real. There's all these benefits, you know, to cloud elasticity, converting capex into opex, all these reasons people want to move to the cloud. However, the word on the street is AWS is too hard, and that that complexity is hindering customers' ability to realize the benefits of the cloud. More flexible, elastic infrastructure, all that stuff, right? So I decided with my friend to start a company, and the goal was to make AWS simpler for end users who wanted to experience the benefits of the cloud. And we were going to do that via a software-as-a-service product called Op Demand. And the name here signified operations, cloud operations on demand. That's what we set out to do. And Eric Ries' Lean Startup book hadn't quite come out yet, but we were on the level, right? Like we knew it was all lean and mean. We were all about delivering that MVP. And so we did what anyone would do in this situation. We raised some seed money, right? And you know, I don't wanna, gloss over that. That was actually kind of difficult, but we did that. We, with that capital, we got our MVP out in a year, right? And you can see sort of, you know, on the screen here, a picture of the landing page, and inside of that laptop view is a view of the product. And it was beautiful. The product was just marvelous. I think we may have over-engineered a little bit, but look, it was great. It was still missing a bunch of features, so still an MVP, but there was Much rejoicing. We were very proud of what we had shipped. But that was short-lived because the product traction wasn't anywhere near what we had expected, right? You were getting website visitors at the top of the funnel, but the conversion was low in terms of actual product usage, and the revenue was even lower, right? But we're lean and mean startup folks. We know this is part of the journey. We're gonna iterate, right? And so we did what anyone would do in this circumstance. We started talking deeply with customers. And so, you know, the way this worked is, you know, we would email customers who signed up, we'd try and set up a feedback call, and, you know, hopefully we get folks on the phone and learn a little bit more about that. The first thing that we found when we were talking with these folks was customers were actually confused about our value proposition. They didn't understand how the product could help them. Right. They clearly signed up, which is, you know, how we got them on the phone in the first place. But it was obvious that they weren't really enthusiastic about the product. They were giving it a go. Right. And those that we did engage, found that, you know, did engage deeply in terms of using the product, they did actually enjoy using it. So that was good. But at the same time, they weren't able to, or willing, frankly, to put in the effort to actually adopt the product in a meaningful way. And that was a big challenge for us. So as we're digesting this customer feedback, we had a good idea of what went wrong, right? Our minimum viable product was too minimal, right? Very common perception, right? We just didn't have enough features, right? And we had this long roadmap of stuff that was excluded from the MVP. So on these calls, we're asking customers, well, what features would get you really excited about using the product, right? And we collected this long list. And some of those things were on our roadmap. Some of them were new things that we heard. Support for discovering and importing resources, team collaboration, new types of templates. And so we worked through that list, we prioritized it, and in startup lean fashion, we cranked out and delivered all those new features. And nothing. No impact. No impact. How frustrating is that, right? You listen to customers, you build what they claim that they want, and there's actually no impact. On the other side of that. And so at this point, the team's actually kind of like fighting amongst themselves, because clearly, you know, we're having a hard time figuring out how to guide the future direction. You know, at this point, things are looking kind of grim. And so with desperation in the air, you know, I personally decided to go reach out to customers again, but this time, I wasn't going to talk about our product, right? I was instead going to ask higher-level questions. Why did you land on our website, right? What is it you were trying to do, right? Well, why did you land on our website? We were trying to build an application. Okay, you know, that sort of lines up with what we had thought. Well, what do you usually do when you want to build an application? Many customers said AWS. Great, awesome. That was sort of the premise of the company, so good to hear that. A lot of other customers said, "We use Heroku," and we actually didn't expect that. We didn't think we were competing with Heroku, but from the perspective of our customers, we were. And actually, that's what matters more. And the follow-on question to that is, well, why not just use Heroku? And I'll never forget, I got this quote from, you know, must have been 10 customers. If you could give me something like Heroku that I could run on my own AWS account, that would give me the control and flexibility that I need, and I would pay a lot for that. Emphasis on that last point, and I would pay a lot for that. And so with that, we executed a pivot, right? And this is one of those difficult startup pivots. You know, I lost team members during this period. It was unclear whether this was going to be successful. We didn't really have, you know, necessarily enough capital to fully execute the pivot. We weren't sure how this was going to work. Very common position a lot of startups will find themselves themselves in. And so we pivoted towards, you know, essentially delivering on that last, what I would pay a lot for. And to our surprise, I suppose, to some of the team members' surprise, it was wildly successful. We saw lots of traction in terms of Deis being adopted for, you know, folks who were looking to make AWS easier to use. Deis was ultimately acquired twice, first by a company called Engine Yard, the Ruby on Rails past, Later we spun that out and it was acquired again by Microsoft, and that's how I ended up getting into Microsoft to bootstrap the container services business. And so, you know, it's interesting to me, people ask me like, well, like, what are your big takeaways like on this journey? And I go back to this phrase that I heard, which is candy, vitamins, and painkillers in the world of product. And so let me talk a little bit about you know, what I mean here. First, I want to give credit where credit's due. I actually had to do a little bit of digging on this. This is actually from Kevin Fong, a venture capitalist, and the quote I was able to find is, "We divide business plans into 3 categories: candy, vitamins, and painkillers. We throw away the candy, we look at the vitamins, and we really like the painkillers." Now, to define this a little bit more deeply, candy, it's a nice treat. Right, but you can live without it, right? Vitamins, vitamins improve your life, right? But they are a nice to have. And painkillers are the must-haves. And because of the must-haves, they end up being the easiest things to sell. Now I want to be very clear about this. Not every product must be a painkiller to be successful. Candy sells really well. A good example of this is gaming, right? Game, video games, mobile games on your phone, that's candy, right? It's giving you a quick dopamine hit. Like, you can make a lot of money selling candy. Let's be very clear, there's great product experiences that you could build there. It's important to know what you're selling, whether you're selling candy, vitamins, or painkillers. And again, painkillers tend to be the easiest to sell. Now the problem that we had with OptiMan was we were failing to communicate what we were offering. The UI was candy, the Marketing made it feel like a vitamin. AWS made easy is indicative of something that's a nice to have, not a must have. But we were selling it as if it was a must have, and it was just completely misaligned, and our entire go-to-market suffered as a result. But to put this into more focus, I wanna tell you another story, which is the story of Azure Container Service, which it just turns out is sort of the next thing I did right after I joined Microsoft. So as happens when you join a large company through an acquisition, I was immediately handed some stuff that was being worked on by other teams. In this case, a service, a product called Azure Container Service, had went GA in 2016, about a year before I had arrived. And the idea here was, you know, push-button access to a container orchestration system in the cloud, different flavors of orchestration. The specifics of the product didn't really matter, because to me as a product person, I need to figure out what is the perceived value from our end users. And so that's exactly what I started to do. So, so, you know, once I arrived, I started interviewing customers, and what I found during those interviews was ACS really was a vitamin and it wasn't a painkiller. And, and here are some quotes that I was able to, to recall from, from these discussions. Uh, I was able to set up the equivalent solution myself on Azure, but ACS saved me a lot of time. Okay, ACS is great. I was able to get rid of my custom solution and switch to ACS. ACS doesn't yet support the server type I need, so I'm going to keep using my own solution, and I'll probably switch over if you add this feature. What's, what's common here is there's another solution to this problem, right? ACS was not a must-have given these quotes. It was a nice-to-have, right? And screams vitamin in terms of this taxonomy of vitamins and painkillers. And so what we did with this— and this is stuff I had learned during the OptiMan experience— was really put the product away, right? ACS was my product. Forget about that. Talk about what the customer outcome needs to be. And clearly in this case, there was a custom solution that folks were using instead of the product that I wanted them to be buying. And so I started asking questions about what they were using for their custom solution. Well, customers with their own solution experience pain with upgrades and reliability. It takes too much time to upgrade to new versions. We have to set up and move systems, move things around, tear the old system down. Okay, that sounds kind of painful. Uh, when we're serving a lot of traffic, our homegrown system sometimes crashes. Ouch, that sounds painful. Uh, we aren't sure why. We need something more reliable for our customers. Interesting. This sounds painful, right? And so with this, you know, knowledge and, and with this feedback, what we were able to do is take sort of the general product landscape that we were in, but pivoted to a different area, which resulted in the creation of Azure's Kubernetes Service, AKS, which is a product that I helped launch in 2017 following the feedback that I was just sharing with you. AKS featured all of the things that customers were asking for, better reliability, upgrade support integrated, all the stuff we were hearing that was painful for customers was present in this new product and in this new solution. And as a result, this became the fastest growing compute service in the history of Azure. Very impressive. And to me, a great example of the difference between vitamins and painkillers. Now, to go a little bit deeper into this, I want to share, you know, some more lessons that I've learned sort of throughout this journey. And there are quite a few, so I'm limiting it a bit here. The first thing I would say is, if I could go back and do it all over again, the startups, all the engineering work and product work that I did while at Azure, even some stuff we've done early at DEO, I would really take this concept of road before code a lot more seriously. To understand if you are building candy vitamins or painkillers, you need to take a design-first approach where you're out engaged in market, talking with customers, ideally before you write a line of code. And in fact, we've operationalized this at DigitalOcean, and you know, we're well known for building very simple products. We do this as part of the design-led engineering that we perform at DO, and that's part of the reason we get products that have that level of simplicity built in from the outside. So what does this really look like? Well, really what you want to do is you want to study the desired outcomes of your customer very carefully, right? It's outcome-focused. It's not product feature and functionality-focused. You also want to make sure that you're designing your product experiences to enable those outcomes to become seamless, right? It should be part of the product journey that those outcomes are able to be achieved. Our customers don't have to exit your product, come back to your product in order to achieve that outcome. But the biggest thing I found is documenting your core product flows in a visual walkthrough and then walking customers through, here's what the product would look like if we built it, right? You didn't build anything other than some mocks or some screenshots, right? You built just some flow. In terms of, you know, what you would design for folks. And when you do that, and when you bring your engineering team along for the ride as you're talking with customers, you end up developing a sense of customer empathy, and you're able to understand how your customers perceive your product. And this is unbelievably critical, because there's a very big difference between what you put on the marketing page in terms of the value pillars for your product, Product is going to help you save money. It's going to help you, you know, be more productive. It's going to help you do whatever, help make your team happier, right? That's your marketing page. When you talk to your customers, what they perceive the value of your product to be is way more important than what you think the value of your product is. And you're never going to know that if you don't spend time talking with your customers and sort of doing that work upfront. Up front to de-risk the engineering cycle. Because again, it's extremely expensive to actually build something all the way through. Think about that MVP that we built at OptiMand, right? That cost me about a million bucks to go deliver that. Million dollars. I didn't really have meaningful product feedback until after I had shipped an MVP that cost me a million bucks. What if I had just built some mocks and talked to customers early on, right? How much would that have cost me? $50K? $25K? Right? De-risking product development is the goal in Road Before Code. And the other part about this is avoiding the pivots, right? Like, it's funny, in the startup ecosystem, we talk a lot about pivoting. They're sort of, you know, hey, we we pivoted and we worked through it. But you know what? I've lived pivots many times in my career. They are not fun. I don't want to have to do a pivot, right? And so if you can hit the road before you code, you can avoid that painful experience. And I'd really encourage all you to think about that as you move forward. The next thing I want to share is a concept called Jobs to Be Done. And this is really— deeply ingrained in how we develop products at DigitalOcean, but it's something that, you know, I've become really attached to as I've developed my product leadership skills. This concept comes from Clay Christensen over at Harvard Business School, and there's this really cool YouTube video that I've linked to in the deck, and I really encourage you to check it out if you haven't. But he talks about how Harvard Business School worked with McDonald's to help them increase milkshake sales, right? And so, you know, Christensen team, you know, they essentially asked customers, you know, what they wanted and they built that, right? So you go talk to milkshake customers, you say, hey, you know, what would we need to do to make the milkshake better so that you'd want to buy more milkshakes, right? And they did that and they collected this long list of features. And they added all of that stuff into the milkshake recipe. And they went back to the customers and said, here's the brand new and improved milkshakes. It's got everything you asked for in it. And what was the result? No impact. Didn't impact sales of milkshakes at all. Right? Does that sound familiar? Does that sound familiar for any of you in the audience? Asking customers, hey, what can we do to improve the product? You go do that thing. Nothing ends up happening. Not all that uncommon, I found, right? So what they did here with this Jobs to Be Done framework is they thought about the problem differently. And they said customers are hiring the milkshake to do a job, right? And it was actually in the morning. One of the weird things about milkshake sales is people buy milkshakes at like in the morning. Is that weird? It's like you think it's like a dessert or whatever, but no, milkshake sales happen in the morning. So what was the job to be done at 7:00 AM you know, where people were buying a milkshake, right? And how could we understand that job better to help improve milkshakes? Well, after they focused on the end goal, what they realized was that customers, the job to be done was they had a long and boring commute to work in the morning. And what they needed was something to keep them engaged during that commute to work. And also they needed so that when 10 o'clock came around, they weren't hungry. Be starving, so they could buy a little bit of time to get to lunch. And that was the job that they were hiring the milkshake for. Turned out you could also hire a banana for that job, but banana really doesn't do the job that well. You could hire a candy bar for that job. That candy bar is gonna make you feel kind of gross, right? And you might not want to do that every day. Yeah, that could be problematic from a health perspective. So what they ended up doing with this knowledge was by understanding the job, they realized things like the viscosity of the milkshake, how long it took to drink the milkshake, actually impacted the level of engagement during that drive to work, right? Because if you suck the milkshake down in 10 seconds, it's like, well, that didn't really help me on my long drive to work. If the milkshake takes you 5 minutes to drink because you really can't pull it up through that straw, it's too viscous, well, that keeps you engaged during the drive to work. And that's how they were able to to improve the milkshake and increase sales overall. So, you know, look, to build the best version of the product, in this case it was candy, by the way, Milk Chaser, clearly candy in terms of vitamins, candies, and pickles, you must understand the job to be done. And, you know, for me, when I'm thinking about, you know, what we learned here with Azure's Container Service, ACS, customers wanted to hire ACS. To upgrade their clusters. They wanted to hire ACS to provide reliability, a reliable infrastructure for them. We weren't fulfilling the job to be done that they had brought to the table, and that was a big problem. But the first step was in understanding what that job was. So the next thing I learned here, and the final thing, is this concept of pivoting from vitamin Vitamins to painkillers by finding these must-haves in the product experience. So, you know, at OptiMand, you know, we put out a product and it turned out that product was a vitamin, right? It was a nice-to-have for folks, which is okay, right? A lot of the stuff we do is not going to be a painkiller right out of the gate, and that's fine. But through a process of engaging with customers and really searching for What are those must-haves? We found out, I don't have enough control in either your product or whatever my alternatives are to your product. And that was the must-have. And it turned out that we were able to pivot the product in the same general area, mind you, but we were able to pivot the product around that must-have. That led to Deus. Deus ended up being wildly successful. Right? And so I'd also argue Daeus would never have happened had we not started with the vitamin that was OptiMan. And so you can start on one end of the spectrum and migrate across. Same story for Azure Container Service, right? Azure Container Service, you know, it wasn't getting the job done for customers. It was a nice to have. People had their own custom solutions that they were using for this. You know, they didn't need ACS. They just didn't, and they told us that pretty, pretty verbatim. And they said to us, I am spending too much time managing infrastructure, and that is painful for me, right? And so as we worked on adapting a solution to that, we came out with Azure Kubernetes Service, which was directly derived from the product and learnings that we had through Azure Container Service. And Azure Kubernetes Service again turned out to be one of the fastest growing services in the history of Azure. So to wrap up, the key takeaways here are when thinking about candy, vitamins, and painkillers, it's really important to make sure you hit the road before you code. It is, you know, myself, I'm an engineer by trade, right? I'm a product guy now, Chief Product Officer, video today, but I used to write code and that used to be all I wanted to do. And it was really hard for me as a more technical person to go talk to customers, right? I wanted to spend more time building. Build, build, build. That was the mentality. Build, build, build, right? Talking to customers de-risks the build and it's actually a whole lot less painful. But most importantly, it helps you understand how your customers perceive perceive your product. Not what you want them to perceive your product as, but how it's perceived in reality. Is it candy? Is it a vitamin? Is it a painkiller? And by taking this design-first approach where you leverage technology like design sprints— you know, I don't know how many of you are familiar with the concept of design sprints that come out of Google, or the concept of a customer-driven playbook that has come out of Microsoft. These are frameworks you can use to help structure sprints that will allow you to understand perceived value from your customers and help you de-risk product development. So I'd encourage everyone in the audience here to check out the book Sprints, you know, by the folks who had pioneered design sprints at Google. It can be very accelerating to folks who want to engage in this endeavor. The second point I mentioned is you got to know your customers' jobs to be done. It's really about understanding motivations and outcome orientation. All too often in the product space, we talk about features, we talk about voice of the customer, and we almost delegate the product roadmap to what is the topmost thing that customers are asking for. And as I've learned in, in my experience, if you just build what customers ask for and you don't take the time to understand what they're really trying to do, you are going to get misled in your product direction. You will get misled. You have to understand what is the outcome, what is the job to be done, why are they going to hire your product versus the alternative products or versus an alternative path altogether. And once you understand that, you can really start to prioritize feature development, you know, strategy, in terms of your product, and everything gets easier because you've clarified what your customers actually need. And the last point I want to make is pivoting from vitamins to painkillers by finding must-haves. We are all going to, you know, build products that are all on the spectrum, like candy, vitamins, painkillers, but you can change the disposition of your product as you go by spending time to understand What are those must-haves in the product, right? And you know, it's interesting because as the market dynamics change, as your customers change, your product may start out as a painkiller, but as circumstances in the economy change, as team dynamics change, as organizational dynamics change, your product may start as a painkiller, turn into a vitamin, or turn into a, you know, a piece of candy that isn't actually much value to you. To the organization overall. It's important to keep a pulse on the perceived value of your customers. And I found the framework of candy, vitamins, and painkillers to be very helpful in that.