Designing Your SaaS Company For Growth With Steve Boak
When startups think about growth, they often focus on product and sales, but what is commonly overlooked is the critical role design can play in customer adoption. Steve Boak, the VP of Product Design at Datadog, and Rico Mallozzi explore the role of design in a developer tool company, how design can be a contributor to product adoption and growth, why it's important to let customers experience the whole product and the role of design in a DevOps company. They also get into how you can be consistent yet provide customization within your product, and the future of enterprise tech UX.
Listen to the podcast here:
Designing Your SaaS Company For Growth With Steve Boak
I'm extremely excited to have this conversation with Steve Boak, VP of Product Design at Datadog. Steve has worked at the intersection of enterprise SaaS, developer tools, design for most of his career and was Cofounder of a monitoring tool company called Opsee before joining Datadog in 2016. In this episode, we explore the role of design in a developer tool company, how design can be a catalyst for company growth, how to be consistent yet provide customization within your product, and what the future of enterprise tech UX looks like. I hope you’ll enjoy this episode as much as I did.
Steve, thank you for joining us for this episode.
Thanks, Rico, for having me. It's a pleasure.
I'm excited to talk about design in the context of startup growth. The first thing I want to talk about is understanding your experience and you can give an idea on how a designer gets into the developer tooling space, not necessarily somewhat of an oil and water scenario there. I'd love to hear your background and how you got in there.
As a designer, it's not the most intuitive place to end up. One of my favorite blog posts about design is called I Only Work on Shiny Products. The premise is like most designers gravitate towards these companies like Facebook and Instagram that already have these beautiful polished products that people are accustomed to using every day. Tools for software engineers are not the most intuitive place to end up. I tried to double major in Engineering and Design in school, but it would take me six years to graduate. In grad school, I've had a hybrid design engineering program and then got connected with architects. The first six years of my career before software, I ended up working with Frank Gehry and some of the world's best architects on building projects and working on the technology in those projects.
It was this technological dimension to figuring out very visual and physical things. I'll spare you the long story of how that connects to software. I met one guy in particular named Shad who, when I moved to San Francisco, had started an email list called Post Architectural of all the people who had left the architecture industry and were now working on data visualization problems. It was through that connection. These products with data visualization that have a technical element, that's the way that it all fits together for me.
These hard-technical problems are the things that I enjoy solving. For engineering tools, there are these other dimensions. When I got connected with the first set of founders at the small dev tools startup that I was working with called Boundary, one of the cool things about these companies is its engineers building software for themselves. They have their own product mindset about the tools that they want to build for themselves. As a designer, I feel like a natural place to land where these people care a lot about what they're building. They're building it for themselves. They're passionate about what they're building. Those are all kinds of things that have led me to this space over time.
From an enterprise tech, can you give us a little background about some of the experiences you've had? I know you also started your own company in the developer space as well.
Before Datadog, I started a small company called Opsee. It was a monitoring tool connected to AWS and cloud computing. I worked at two other dev tools companies before that. Since that first startup Boundary that I worked at, the dev tools company, I've been hooked for the reasons that I said. These other engineers were passionate about what they're building. Over time, I've seen the developer experience and user experience evolve a ton. When it comes to design in this space, it's a build versus buy. As a company building tools for software engineers, you're always competing with your own customers because they're engineers.
They could theoretically build a lot of this themselves. You're trying to make them say, “I don't want to build this.” I'd rather pay you to do it. If you think about some of the big dev tools companies like Twilio, if you're building an app and that app sends text messages and makes phone calls, more than likely you're using Twilio. Why would you write all that telephony code yourself or Stripe in payments? Are you going to build a PCI-compliant data center? Are you going to run all that payments code and risk the security vulnerabilities? You could pay them to do it.
Datadog is a lot like this in monitoring in general. People can write their own monitoring tools. People do. Sometimes, they'll connect data from their hosts to dashboards and they'll use open-source tools that they build on their own. We're also trying to offer a first-class experience on top of that. These one-click integrations with AWS if you are running hosts and other services. In AWS, you can integrate all that data with the push of a button. This mentality of how do you make this great experience. This is not a low-margin utility business where it's high touch.
We're spending a lot of time with our customers making sure they have a great experience. We have a large support and sales team to help that. Design is one part of creating a great customer experience. That means these are engineers but they value the tool enough that they're paying us for it. It's also an honest business. We're not ad-supported. It's an uncomplicated business. People are paying us money every month for software. If they like it, they keep paying us. If they don't like it, they leave.
It's a binary choice but the product is clear in this transaction, unlike some of the other products we use in our daily lives. You bring up a good point. There are two types of developer tools. There are the API interface type tools like Twilio and Stripe. There's more of a Datadog which has a very rich visual experience. How does design compare between the two? For the API world, is it more focused on incredible documentation, the experience that the product person gets or the user gets, and then for yours? It is a dashboard and a visual experience with integration clicks, etc.
This is a great point and a great distinction. The big difference between us and companies like Twilio and Stripe. It's an oversimplification. Both of these companies have a lot of products. Stripe has some visual and interactive products, but Datadog has always been a visual tool, dashboard, and alert. Stripe and Twilio’s core businesses is API so that you don't have to write payments code, telephony code, Datadog, the monitoring, or the whole experience around that. You can build your own dashboards. You can drag and drop. I didn't realize this when I entered the dev tool space, but this lucky convergence was both a technical tool and a visual tool. There are other companies like this. GitHub is popular because it creates a great user experience around committing and code sharing.
That's a distinction between us and the other API companies. I was lucky. I didn't realize this when I entered, but it's an important part of why I like it. What makes for good design when it comes to APIs’ error messages? These are important user experience problems. One of the questions we're debating right now at Datadog is that when you go from one part of the product to the next, the query that you'll enter into a search box, the syntax might be a little bit different. The way you run a search in one place will be different from the way you run in another one. These are not classically thought of as design problems, but they're important to the user experience that you have consistent query syntax. We're working hard to try to solve that.
Being a designer, one of the critical things is the user’s feedback. The engineering community is somewhat of an introverted community in some ways, but they're also very active in digital communities and especially in the open-source community. How was the process of getting user feedback in an engineering first organization work?
What you touched on there is crucial to the way business is done these days with developer tools especially. The old way of selling software to an enterprise would be you take the CIO out for golf. Maybe you score a deal through that. Now, the entire business model has shifted to a mentality of land and expand where what you want is for an engineer, a small team, maybe inside of a large company to come in the front door, go to the website, sign up, and try out the product. They love the experience.
It’s guerrilla marketing. They talk about it inside, how much they love it, and the tool spreads internally. A lot of software companies certainly Datadog has been a huge part of our success story. The fact that it is turnkey, anyone can get started. Land and expand is half of the story that you want one small team to evangelize the tool internally. The bundle and upsell is the other part of it. Datadog has many products, not just one. If a customer comes in and has a great experience with one of them, they will start using many of our products. That's also crucial to the growth of our business.
It’s a great segue to what I want to talk about in the latter half of this conversation, how can design be a catalyst for growth? Datadog is one of the very hot companies that has also leveraged product-led growth, which is a popular go-to-market motion for enterprise technology companies. With that being said, how do you use design as a mechanism for growth for the organization? What is the collaboration between the other parts of the organization to make sure that they're in alignment?
Based on these two principles, land and expand, bundle and upsell, a lot of this gets into the way we think about designing the product. First, land and expand. If you want one team to turn into many teams inside of a company using your product, you want a consistent but also very customizable experience. As people move from one part of the product to another, you want it to feel comfortable and familiar so that they don't have to relearn things from the beginning. Each of these teams is going to have distinct needs. That might be saving certain kinds of searches or creating their own dashboards, or giving them away that some of our largest customers, there might be hundreds of engineers using Datadog across dozens of teams. Each of those teams has a slightly different way of using the product.
That ability to grow depends on those two things that each team can personalize the product to their own needs and they can still have a consistent feel across the many different products that we offer. Design plays a big part in that. The second thing is the literal way that we're selling products. Amit, our Chief Product Officer, has been ruthless about this since day one that we should never stop somebody from buying something. Through my own experiences, buying software has been startling to see how common it is for there to be barriers to this.
Without naming names, I've gone through procurement for a few different companies and some make it incredibly easy, even with a seat base. If you're paying for a certain number of users on a piece of software, some might make it easy to add more seats and they audit them at the end of the month or the quarter. You true-up in this model versus other tools where we've had to sign paperwork every time we add a seat. The latter seems insane that they're making you jump through hurdles. Amit and the product experience generally has been focused on this like, “Don't stop people from using things.”
In the event that somebody is using one of our products and they're thinking about using another one, we'll offer two weeks unpaid with no credit card asked or anything like that, you can start using it. Even after those two weeks, we're not going to cut you off. A CSM or an account representative is going to get in touch with you and try to work through a solution that makes everyone happy so that we're not ever trying to stop you from doing things. That sounds obvious as I say it, but it doesn't seem to be the default case. I'm proud that it's something that we do.
Metered billing, in general, seems to be a newish thing. The idea that you're not going to know what your bill is at the end of the month. Tools like AWS and Datadog, we invest a lot in transparency in terms of providing dashboards and other tools to proactively tell you, “Here's where you're spending money on right now.” Right now means to the day, to the hour because large spikes in usage can mess with that. We try to provide a lot of transparency into it but this is not something that is inherently underhanded. The idea that you're not going to know what your bill is at the end of the month because that can swing by huge amounts.
I like the phrase you use there is what the product is. You want to be consistent to provide also some level of customization. It's a precarious balance, but one that's very important is to expand within the organization because every use case is not going to be the same. The second element you brought up there is not allowing everyone to experience the full product, no matter what type of user you are. That's important in a product-led growth company to make sure that they get those a-ha moments to convert them to a paying customer. If you start walling off the garden and they may lose some of that value, that might be critical for them to make that purchasing decision. What do you look for in your team when you're building out a design team? What are the skills necessary for an enterprise technology designer, specifically one focused on engineering products?
First, I mentioned my love for the technical parts of this job. There are some designers and product managers who have no interest in the technical parts of this work. It gets deep. How do containers and serverless functions work? How do these arcane and specific technologies, Redis or Kafka or something like getting into some product that's going to monitor the guts of a deep backend engineering system? Not all of the designers on our team are working on these kinds of deep, challenging problems, but that's an important part of the work.
There's also a visual, this dragging and dropping, interactive experience like authoring a dashboard. That's like another thread that we're looking for expertise. One of the things I love about enterprise software is that even at our scale, Datadog has 10,000 plus customers globally, which is not a huge number. Maybe 1,000 or 2,000 of those customers are paying us more than $100,000 a year. This power-law distribution of revenue is true of many enterprise software companies. We invest these proportionate amounts of time with our biggest customers.
As opposed to a consumer product company that's doing a ton of split testing and optimization, we're still doing a lot of boots on the ground, qualitative research and analysis, and spending actual time with our customers. Those kinds of relationships and the way we do our work is also something. We're looking for people like that kind of environment and who are willing to step outside of themselves. I don't think anyone on the design team at Datadog is an actual Datadog customer. We aren't the core user. You have to be willing to step outside yourself, understand the needs of these people, and invest time to do that. The good news with a dev tools company is our own engineers use the product so we can do a ton of in-house user research and our own teams use everything. We roll out everything internally before we roll it out to customers. That's another thing that's rewarding about this. It often feels like you're building something for your neighbor, like the engineers sitting next to you.
Do you split test the Datadog product externally too? I know you said it's much more of a consumer kind of thing, but will you do that as well?
In certain narrow ways for things like onboarding where the vast majority of people are coming through and we have the numbers to do it. For a lot of the more niche parts of the product experience, I don't think we even have the numbers to do that kind of product development.
One of the things in product-led growth is creating virality where we invite one person to invite another person. What are some of the design elements that you've embedded in the Datadog product to help do that? I know one of them is inherently leaving the product open, but are there any other triggers that you have embedded in the design of the product?
For most of Datadog's history, I don't think we've thought about growth that way. We don't bill based on the number of people using the product. It's all about the number of hosts. The social aspect of growth is more about, again, this land and expand, where one team tells another team and they start monitoring their infrastructure. It's spreading through social mechanisms, but the actual unit of growth is the number of hosts and services that they're monitoring. Increasingly, the product experience that people have alerts. For example, when you create an alert, this is the thing that wakes you up in the middle of the night.
You want to have the knowledge that your team is involved in this. We have a new incident management product that the whole point is to bring a team of people together to solve a problem. Once you've recognized that something is broken, you do things like specify an incident commander. One person whose job it is to oversee that incident. You bring a team of people in to be notified. You can assign them tasks. As a part of investigating this incident, we discovered this problem. This person is responsible for solving it. With some of Datadog's newer products, there is becoming more of a social element to the product experience.
In your mind, someone who's started a company in the developer space and scaled a company in the developer space, should design be part of the core team from day one? You might be biased.
I'm obviously biased. I've tried to make a career out of design, being involved in these technical and product conversations early. I've unfortunately been at companies where design is an afterthought. The engineers and product managers, the business leadership as it were are making important product decisions. Design is brought in later to make it look pretty or something like this. A lot of what we're trying to do is open doors as a part of the design process. When we have an idea for a new product offering, design’s role is to explore a bunch of different options and put those options in front of important stakeholders to make a better decision for the entire company. One of the things that I'm most proud of on this team is we have a few designers focusing on data visualization. It's such an important part of the Datadog product experience that we have these specialist designers who can write code and build visualizations. Normal design tools and normal design processes won't work for these big and complex visualizations.
The only way we can test out ideas and see if the product ideas we're thinking about are working is to build prototypes with code. That iterative process of exploring and figuring out what's working, that's fundamentally design's role in the business is to try things out and put them in front of people and see what's working. That mentality, that role in the company is crucial. One of the other fun facts, several dev tools companies I know Datadog, but also GitHub, Stripe, all of these companies for their first several years of operation didn't have any product managers because its engineers are building software for themselves. Often, engineers and designers are working in close collaboration because they already have a built-in sense of the product goals because they're building it for themselves.
One interesting fact is Dylan, who's the Founder of Figma. I was listening to him and he keeps track of the engineer to design ratio at these larger organizations. The design pool keeps getting larger to the engineering ratio, obviously not one-to-one, but it is a growing factor. There's a cognizance of the importance of design and enterprise technology. That's exciting to hear. It will become earlier in the process. I want to talk about the future of design. One of the sayings I used to hear is, “The future of UX is no UX.” Can you talk a little bit about how you see the UX paradigm evolving in enterprise technology?
A lot of the developer tool experience or enterprise tool experience is these troubleshooting workflows where you try to find what's broken and you're searching, filtering, drilling down into problems, and try to uncover what the underlying issue is. This is a pretty manual process. You maybe look at some alerts that came in or look at some dashboards and you find things that are going wrong. You're working your way through this in a manual way. One of the most interesting changes that we've introduced in our product and what's happening in the industry generally is the introduction of data science and methods like AI and machine learning where we can short circuit some of this. Datadog has a feature called Watchdog. What we can do is we're automatically trolling around your system, looking for unusual behavior, like a spike in errors or a spike in latency, a response time of service.
We can surface that to you as an event like a social media style event in a feed. Even if you weren't looking for this specifically, you didn't have an alert connected to it, or a dashboard looking at it, we can go and find it for you anyway. We're able to uncover new kinds of activity that you might not have seen otherwise. We can start to surface that to you in other parts of the product. You might be looking at a dashboard where you have all the graphs that you've put there but we can also surface this event to you that we've uncovered and automate some of that detection of unusual behavior and build that into the experience, helping you find these answers to these questions faster.
It's almost in a sense, UX is becoming proactive rather than a display. The display engages you, switching the seat around there.
This proactive-reactive distinction is a big part of how we think about the product experience. When you get an alert, that is a reactive experience. Something has told you this is broken and then you have to go and figure out what it is. In Datadog's office, our own engineers have TVs up on the walls with Datadog dashboards that show them how their systems are operating and what's healthy. If it's a service that this engineering team has written, they understand it well. They can glance at that dashboard and understand if something is wrong. They know what those key metrics are supposed to look like. It's a good way of framing it. Not only like the dashboard is fundamentally a proactive tool but if you can then take that a step further and say, “Not only the grass here and you can hopefully spot what's wrong, we can show you something interesting there that maybe you weren't thinking about.”
This was a great conversation. My last question has nothing to do about design or enterprise technology but more about you. What's your favorite TV show right now?
When I was thinking about this, we watched Ozark. It's not new. In this moment, everyone being stuck inside the darkness and nihilism of that show felt cathartic. It's hard to watch. It's an anxiety-inducing show, but I felt emotionally connected to it. I don't know if you've seen Palm Springs the movie. It has this darkness and nihilism to it. For some reason, these kinds of things are connecting with me right now.
My wife's seen both of them. She watched Ozark a lot. I've seen episodes here and there but I've heard it's a great show. There are a lot of parallels but that's excellent. I'll have to finish the seasons out and I'll let you know what I think of it as well. Thanks again, Steve, for taking the time to speak with us. I know this was a great conversation. Oftentimes, we don't talk about design and enterprise tech. It was good to have this conversation about how it can be so integral to building a successful company. Thank you.
Thanks, Rico. It’s a pleasure.
About Steve Boak
I'm a VP of Product Design at Datadog, the monitoring and analytics platform for developers, IT operations teams and business users in the cloud age. I've been designing enterprise developer tools for the last 11 years, and I was previously the co-founder and head of product at Opsee.
I also co-hosted Don’t Make Me Code, a podcast on Developer Experience (DX) design.
Disclaimer: This article is for informational purposes only. It is not an advertisement, and it is not intended to provide advice or services of any kind, and does not constitute an offer to buy or sell, nor a solicitation of any offer to buy or sell, any security or other financial instrument in any fund sponsored by Sapphire Ventures, LLC (“Sapphire”). The information contained herein is not an investment recommendation, and may not be relied on in any manner as, legal, tax, or investment advice. While Sapphire has used reasonable efforts to obtain information from reliable sources, we make no representations or warranties as to the accuracy, reliability, or completeness of third-party information presented within this document or survey itself. All metrics presented are derived from survey respondent answers only, whereby no outside sources were used in compiling the index. Metrics presented do not in any way represent official statements by Sapphire. Various content and views contained within this article and index represent those of the survey participants only, which do not necessarily reflect the views of Sapphire. Such views are subject to change at any point and do not in any way represent official statements by Sapphire. No guarantee of investment performance is being provided and no inference to the contrary should be made. Past performance is not indicative of future results.