I’m Gabe Monroy, Chief Product Officer for DigitalOcean. AMA 👇

@mrahmadawais to be clear the strategy and roadmap for improving developer experience isn’t mine, it belongs to the team! They’ve been hard at work and I will continue to support them. That said there are a few things I am looking to see improved vis-a-vi App Platform. I’d like to see build times that are significantly faster. I’d like to see deeper integration with the full suite of DO services like databases, marketplace solutions, etc. Maybe some serverless functions ;) More broadly, DO simplicity is something our customers love, and I am laser focused on *scaling simplicity*. We have a new organizational structure and operating model in place to ensure we continue to be design-led as we add more products and features to the platform. I have asked the User Experience team at DO to take an even more prominent role in helping guide the developer experience across the platform.

@gabe_monroy thanks for sharing.

@ozzie Yes I believe there’s more we can do on the GLB front. We partner closely with Cloudflare today on some of these capabilities. What would be your ideal experience?

@xakpc Very important question, Pavel. In circumstances like this it's critical that we at DigitalOcean (and other cloud/service providers) take guidance from the US federal government and other international institutions so we can respond appropriately without causing outages to vital services and information.

@seanmavley 7 years since your first droplet, huh? You beat me by a year! I've been amazed at the growth of the developer community in Africa. We are actively working on increasing our presence there. On a personal note, I'd love to spend some time visiting the startup communities on the continent in person. I find I learn a lot more that way.

@kylerjphillips so far my biggest challenge has been building connections with people virtually when starting a new role. It's a challenge many people have faced throughout the pandemic, so not unique to me or DO. Teams are built on a foundation of trust and that's especially true at the executive level, where the decisions you make impact many people. It's hard to build that trust foundation over Zoom, but it's worked out better than I thought. It probably helps that DigitalOcean was >60% remote going into the pandemic.

@clivernco at DO we are focused exclusively on developers and small-to-medium sized business, with an emphasis on tech-forward startups. I wouldn’t say we are competing directly with hyperscalers, since they are putting most of their energy toward Fortune 5000 customers and their needs for digital transformation. Digital transformation is a huge business, so hyperscalers don’t pay much attention to a 10 person startup trying to build a SaaS business. At DO that’s our entire focus, and it is a large and growing part of the market. On product uniqueness, we are focused on *scaling simplicity* as we add more products and features to the platform. In my experience customers don’t want 17 ways to run a container, they want a platform that is thoughtfully designed with strong opinions and a happy-path for common scenarios. The devil is in the details, of course, but that’s what you can expect from us.

@emmanuel_genard I have good news for you. We are actively working on integrating Nimbella into the DigitalOcean platform, and plan to offer serverless capabilities in first half of 2022. Sign up here and we will get in touch with you soon: https://www.digitalocean.com/nim.... Also as someone who ran the Serverless businesses at Azure including Azure Functions, Azure Logic Apps, Azure Event Grid, Dapr, KEDA, etc. I would say it’s still early days for Serverless.

@kukreja_nikita sales in a SaaS context is an interesting role. In theory, with product/market fit and the right level of marketing, SaaS products should mostly sell themselves. Instead sales people in SaaS companies often find themselves debugging product/market fit as part of the sales process. Maybe the jobs-to-be-done haven't been identified, the product value proposition isn't clear enough, or the product simply doesn't fulfill the promise to customers. It's your job to channel that feedback to the product and engineering teams. You should really be functioning as an extended part of the product team, versus solely acting as a quota-carrying salesperson (though you may do that also). It's important to remember that the job of a startup isn't to build products, it's to generate a repeatable sales model. One that can be scaled with further investment. Hopefully that challenge is interesting to you!

@leroy_gardner1 I wish I knew that you don't have to build a prototype of a product or feature to understand if it's likely to be successful. Often showing some potential customers a mock UI or product experience is enough to capture the feedback you need to hit the target on the engineering side. Building and testing mocks with customers is so easy and cheap compared to building a full prototype. Of course when I was an engineer I used to convince myself that I had to build the prototype first. That was because it was more fun than talking with customers, and I wanted to write the code. However when those prototypes inevitably failed due to lack of early customer feedback, I started to find the failure of the products more painful than talking to customers early on. Eventually I realized that talking to customers early makes engineering a lot more fun. Now I couldn't envision it any other way.

@jackcrane on the serverless front, absolutely. Sign up for our beta here: https://www.digitalocean.com/nim.... AI is something we are looking at also. Is there a particular capability you have in mind? AI inferencing via off-the-shelf models? Full ML capability?

@jackcrane makes perfect sense. I'll take that back to the team!

@adamcbuchanan in my experience the most important thing to get engineers, PMs, and designers aligned is developing a shared sense of customer empathy. Over many years I’ve learned that simply delivering the features that customers ask for can actually take you in the wrong direction! Instead it’s important to understand the customers’ job-to-be-done and recognize that they are hiring your product for a job they need completed. The team needs to understand what those jobs are and how their roadmap can improve the product to produce better outcomes for customers. For more information on Jobs to be done theory, check out this Harvard Business Review article (https://hbr.org/2016/09/know-you...) or this YouTube video () from Clay Christensen on using jobs-to-be-done theory with McDonalds to improve their milkshakes. I learned a ton while at Microsoft, mostly around how to lead large product teams at scale. It’s very different from operating at a startup scale, and requires a different approach around things like organizational planning processes, dependency alignment, etc. That said, I’ve been told I have a “startup mindset” which isn’t always present in folks who come from big tech. I like to move quickly and I like my teams to do the same. That part hasn’t changed from my startup days.

@roxkstar_74 I'm not sure since it's not my focus area, but I'll ask someone from that team to provide an update here. FWIW I am huge fan of live streaming myself. It's a really authentic way to engage with a community. And yes, we always need help! I'll leave this here: https://www.digitalocean.com/car...

@roxkstar_74 Catch DigitalOcean live streams by following us on YouTube, LinkedIn, Facebook, and Twitch. Check out previously live-streamed DigitalOcean Tech Talks (https://do.co/techtalks) and Cloud Chats (https://do.co/cloudchats), and let us know what else you'd like to see! As for overall dev content, we'd love to create even more resources that help builders around the world grow, from tutorials to videos, Q&A, docs, and beyond: https://www.digitalocean.com/com... P.S. We're a bit biased, but really enjoyed this recent live stream featuring Gabe & Anil:

@berthakgokong I appreciate the feedback on the tutorials. I am constantly hearing how developers are leaning on DO’s community content to help developers on their learning journey. We are investing even more in that direction. Regarding customer care, I’d love to better understand the pain you experienced on the support and customer care front. At DO we aspire for support to be a big differentiator. We live and breathe small businesses as opposed to enterprises, which is very different from most cloud providers. Can you share more details on how we missed the mark for you?

@gabe_monroy Thank you for the response, I think the support has changed since the last time I was there. This time I was able to open a ticket directly. I was trying to get assistance with the App Platform, but I think it will be resolved since I can now log a ticket.

@berthakgokong glad to hear that. If you do get stuck, please reach me over email at firstname@digitalocean.com and I'll look into it.

@shivi_jalota Promotion ke bahane kuch bhi out of context puchna zaruri hai?

@fullofsid apse thodi puccha !

@shivi_jalota Fair, respect the hustle

@fullofsid :)

@manab_boruah I joined DO in October so I wasn’t around when it was initially taken to market by Ben and Moisey Uretsky, the original founders. I’d love to ask them this question! :)

@leandro_aguiar DO does not have a datacenter in the LATAM area right now. We are working on it! As someone of Latin descent (my father was born in Cuba, mother born in Curacao – island off coast of Venezuela), I know how vibrant the developer community is in LATAM, and I am personally eager to serve that community. Stay tuned…

@gabe_monroy and I born in Brazil from Italian family and today I live in Italy :) Yes LATAM has a very vibrant developer community. Thanks for the answer.

@fernando_pimenta1 with more than 60% of our business coming from outside of North America, we are working hard to make DO friendlier to the global developer community. See my answer to Leandro re: DCs in LATAM. To add to that, I’ll never forget visiting customers in Chile a few years back when I worked for Microsoft. I learned it was >150ms latency to the closest Azure datacenter from Santiago. Super painful to have datacenters that far away, so we owe it to developers to provide DCs across the globe to enable low-latency to end-users for applications that are increasingly global in nature. It’s a top priority. I hear you on local currency support and payment gateways being a challenge. We have been studying this problem and we recently added Google Pay support to try and improve the customer experience during signup. We are also looking at language localization, which is something I’ve seen be wildly successful in open source projects I’ve been a part of. These changes won’t happen overnight, but we are committed to doing more.

@jack_torse Identity and auth management are absolutely on our radar. I’m a big believer in identity-based auth being a step-function improvement for developers, I believe DO has the opportunity to uplevel simplicity using some of the new technologies available today. On Windows VMs, that is not something we have on the roadmap right now. It’s a tricky problem that crosses hypervisor technology as well as OS licensing, and our research hasn’t flagged this as critically important to customers yet. Do you have a scenario you can share to help me understand your goals and outcomes? Lift and shift maybe?

@matt_butcher great to hear from you. It’s a fantastic question and I don’t think there is one set of guidance that would apply to all products and scenarios. Here are some thoughts, though: Marketing to managers/directors is great when you understand product/market fit and are looking to scale up revenue. Marketing spend should equate somehow to revenue with a well-understood ROI (e.g. LTV to CAC ratio). If you aren’t ready to experiment within those parameters, it’s probably too early to do traditional product marketing. DevRel is hugely important to any developer-facing product. DevRel designed to get developers to try your product is great in early stages when you’re still finding product/market fit, trying to build buzz, and grow an end-user community. DevRel can also be great as a megaphone for more mature products, but the content and messaging might vary. Open source community engagement isn’t applicable in every product, but for infrastructure software (WASM being a good example) startups have the opportunity to develop a community of contributors who can help build a technology base. It’s a huge victory to convince OSS contributors to invest their personal time as it demonstrates buy-in on the technical approach. However it’s important to distinguish between OSS project/market fit and product/market fit. The former can help with the latter, but only if paying end-users are a clear goal set out by leadership, and the product strategy supports how to tackle both. See Docker in 2019 for an example of project/market fit being prioritized over product/market fit, though Docker, Inc seems to have corrected that with their subscription business today.