How to Design & Build a SaaS Platform Pressure Tested for the Enterprise w/ Domo CPO Catherine Wong

here today to welcome Catherine Wong from Domo. She is the Chief Product Officer. She's here to discuss today, to discuss how to design and build a SaaS platform pressure tested for the enterprise. These are the questions to ask your head of engineering or product. And I am here to let her take it away. However, first, before she gets started, my bad, if you guys have any questions, please put them over into the Q&A. We're going to try and get to those later in the session. All to you, Catherine.

Thank you, Caitlin. So welcome to our discussion on how to build a SaaS platform pressure tested for the enterprise. I am often asked about this general topic because I've built several major platforms that are handling trillions of transactions at the rate of millions of transactions per minute, used by the largest enterprise companies in the world, from CEO to line worker. And there is so much to this topic, and we only have 30 minutes. So today, I'm going to give you an insider view. I'm going to highlight 7 questions that any CEO or business leader should be asking someone in my role. And some of these questions can be a little uncomfortable, but they spark great dialogue. And they're, they're really important when you're trying to make sure that your platform is enterprise-grade and enterprise-ready. So whether you're a business leader or you're more on the tech or product side, these are wonderful questions to ask yourselves as a leadership team as you chart the course. Of your platform. My assumption is that you are growing currently as fast as possible on at least one of these three vectors. You're growing your customer base, you are growing your organization, either hiring or upgrading talent, and/or you are growing your tech, meaning you are building product and features. If you're not rapidly growing on at least one of these vectors, then this talk is not for you. So why do Why did I select these 3 growth factors? I've experienced massive accelerated growth on all 3 of these throughout my career. And I have found that they're the most critical and influential when considering enterprise readiness. I've made a ton of mistakes, and I am happy to share what I've learned so that you don't have to repeat those mistakes. A little bit about my journey. I was an early engineer at Omniture. And then at Adobe, I led multiple hundreds of engineers, designers, architects across the world. Launch new businesses for growth through acquisition and organic efforts. And at Doma, I joined while we were still in stealth mode. Uh, we rapidly scaled the team and the tech and, uh, pulled, uh, out of stealth mode, uh, took the company public, and we are still rapidly growing. So before we launch into the 7 questions to ask, I think it's important to give you some context on why I selected these key questions to ask your head of engineering or product and to discuss potentially as an executive team. My perspective is that you build for enterprise, yes, and you design for people. Yes, the tech is important, and it gets a lot of airtime, rightfully so. But my 20-ish years of doing this has also repeatedly reminded me that you can't lose sight of the endgame, which is that people, humans, are who must be able to create and receive value from the tech. So people, not tech, decide to purchase your enterprise platform and then give you that ever-important renewal in SaaS. and people are who build your enterprise SaaS platform and maintain it, even in the middle of the night. So my life view is that we each want to have an impact on people's lives. It's why we often get into software and to business. And we want our platform and our services to add real value. That's what drives us as leaders. So first, I'm going to highlight one question to ask about org and when you are growing your org. That's not to say there aren't other questions There are. There are a lot of questions that are important to cover here. But given the time that we are living in right now, as leaders, I feel that we have such an overwhelming opportunity to fix an important problem as an industry. So I'm only going to highlight one question to discuss when it comes to org growth for developing an enterprise platform. And that is this. What are the women engineers on your team, or the people of color, saying would improve things? If you don't know the answer to the question, then I encourage you to ask it and to start finding out and incorporating the answers into the actions that you take. I will share a personal experience. I was 17 years into my career as a software engineer, an architect, a designer. I've been in product management, uh, M&A, and as an executive. And it was 17 years into my career before I my C-level manager asked me bluntly and very openly, Katherine, what would make things better for you here? I'd been asked similar questions in roundabout ways through surveys, but never so personally and so openly. And I've always enjoyed the teams I've worked with. It's always been fantastic. I've intentionally chosen to work with these teams throughout my career. But that simple question meant so much. It took me aback. The openness and the frankness and the willingness to hear whatever it was that I might mention, that was a huge moment for me and for us as a, as a leadership team. So I thought about the question on what would make things better, and I did come back and share some aspects that would make me feel more welcome and feel less separate and more part of the team. And that manager, that executive, absolutely acted on those changes, and the environment benefited other female and diverse execs who would would go on to join our team. So that experience meant the world to me. And I— from that, I have always included this as something that I ask other leaders, which is, what are they saying— what are women and other diverse employees saying would improve things? The second set of questions I'm going to cover have to do with how to grow and build and design your enterprise-grade tech. So this is product and features. So I've got 3 questions that I think are great to spark dialogue. The question on tech growth that I want to cover first is, what are our product design tenets? What do we value and why? There's amazing dialogue that results from this. And so, you know, my question to you would be, if you had to list 10, 10 product design tenets, what are they? And would your product managers, your designers, your engineers, and your support team, because in software as a service, it's a constant cycle, would they all repeat the same 10 product design tenets and values? And the reason why this is really critical is because of speed and scale. You want to empower your most valuable asset, which is your employees, to make the best decisions possible as quickly as possible. That's so critical when building out a platform. And so that means you want to federate out your decision-making, and you want to give those same tenets or guidelines or values that influence the decisions that are made throughout your entire organization. A little personal experience that I can share here is we have our own product design tenets at Domo. We spent a lot of time thinking about them, made sure there was alignment, and they work. So for one example, we were implementing self-service payments, which is a pretty standard project. It was one of 30 different projects we were running at the time, so we were moving very quickly. And because one of our tenets is what's shown here, it is start with open. Even though it wasn't spec'd, the designs didn't show it, the mockups didn't reflect it, the engineer on the project himself decided to change the self-service pay permissions to start with open. And as he presented that in the sprint demo, his explanation was that because of the product design tenet, he felt empowered to make that call and move quickly. And of course, it was the call that we would want. So it's incredibly powerful for speed and for developing enterprise software, which can get very complex. But if you have these tenets and these values really crisply defined and communicated to where everyone can play them back, there is a huge benefit to that. So the third question you should be asking when building out an enterprise-grade platform is, how will you let me know about an outage? What will we do when something majorly breaks? Assuming you're running fast, there will be issues with scaling the tech. And personally, I'm OK with that. I think there are healthy breaks and unhealthy breaks, but I love the healthy breaks. Breakage, the ones where you knew it was likely going to happen, you knew where it would happen in the pipeline or in the platform, and you resisted the temptation to overbuild because you knew how to address it. Your team knows how to address it just in time. And that means that you're really riding that razor-thin edge of time to market and stability. And that's part of my magic sauce for sure. I will say, though, that the time to figure out how to talk about an outage or breakage is not during the crisis. It's beforehand. So having this discussion is really critical among the execs. And, you know, Josh James, our CEO at Domo, he was a great example for me in this. The first month after I joined the company, he raised it, and he asked, how are we going to do it? Are we texting? Are we calling? How are you going to let me know when something happens? And also give him, you know, a lot of credit for deciding beforehand how he was going to react when he got the news, because it's not always great news when you get that text or call. And he has been really supportive when he gets the call and encouraged and expressed confidence that we know how to fix it. And that makes a world of difference too in a situation that's already challenging. But I have worked ahead of time in preparing for this scenario with the head of legal, the head of PR, certainly the customer success officer, making sure we know what are the internal communication plans, what are our predefined templates templates for email or even Twitter status updates so that customers can self-serve. All of this is part of being enterprise ready in knowing how are you going to react, how are you going to communicate, and then how do you make sure that the teams who need to solve the problem have that ability and they're not pulled offline all the time to, to give updates. So really organizing that process helps you scale most when you need it. So the next question that I want to cover and suggest that you discuss when it comes to tech growth is to have a frank discussion around what you are deferring to build. And actually asking the question of what else we could defer. This sparks great discussion. And the reason why is because, of course, not everything can be built at once, even though we wish that we could. The magic is in making the right calls on what you can defer and when. So often sales and the business are pushing for those next features they can sell, which is great. I'm a huge advocate for tech with purpose, meaning the tech is there to drive an outcome. And so we in engineering and product will defer certain infrastructure or scale pieces or certain capabilities as needed, but we all know there's a point at which you really need to bite the bullet and put those foundational pillars in. So When's the last time you had a raw discussion on what you were deferring building? Examples of things that teams should be discussing, because it's very difficult to retrofit later, or can be expensive, is governance. Governance is often in this category. Roles, permissioning models, globalization plumbing that impacts an enterprise platform, particularly as you try and go international, microservice management and troubleshooting, If you know, you know what I'm talking about, and there's a whole list of other types of things like this that I would ask and suggest that you review at regular times. The benefit of doing this is that there's a real peace of mind, I think, that comes with knowing what you're deliberately choosing to defer and when will you have that opportunity and that discussion on when to change the course of action. So for example, I and my CEO, we have sometimes pinky swore on planes or wherever we were, where we were really talking through this list of potential things to defer or to reprioritize. And we've made that commitment that, hey, right now we're going to defer it, but when the signal comes and we need to make this a priority, we all know we're going to be ready to do that. So the final section of questions that I'm going to cover is around facilitating enterprise customer growth. And the first question is one that I ask a lot, which is, which customers scare you and why? So we embrace the customers who are smart and who are pushing the boundaries of our product. And yes, as product engineering leaders, that can scare us a little. It means that we're going to have to run into the fire. There's an accelerated pressure on the teams. And having that discussion on why a customer scares you, it's incredibly informative. It tells you where you have soft spots in the platform, and it tells you where you might need to look ahead and figure out how to emphasize and build capabilities for specific customer profiles. So, you know, years ago, for example, we were working with a Fortune 50 retail a retailer, one of the largest. They started to use the product. And quickly, we realized they were pushing the product faster and harder than we had anticipated. And I knew we would scale to meet their needs, but it was definitely faster than I had planned for. And so— and it was happening on multiple fronts. Volume of data, the rate of data that was coming in, the number of employees across the globe that they were going to have use the product, the ways in which they were using it. It was on mobile, iPad, desktop, boardrooms. It definitely made me take some deep breaths. And so what did we do? We embraced them, and we brought our then scariest customer onto the customer advisory board so that they could have a seat at the table and we could have a really close, tight relationship with them. And that has really helped influence the enterprise level and readiness of our platform. We did it again later with healthcare, which brings in regulatory requirements and other aspects and did the same thing. If a customer scares me a little, I actually take note and I try and embrace them even more and make sure that I'm really listening and we're dialoguing about what they're trying to do with the product. The 6th question that I would suggest asking and discussing is, enterprise, SMB, consumer, what would it take? What changes, what kind of lead time would you need on the platform in order to be able to come up with these different flavors? I've been fortunate to have had the experience of scaling both the tech and the internal processes that are needed to traverse the spectrum. And it's important, it's important to kind of think about it beforehand and plan your routes. So today, I know at this conference, we're talking about enterprise. But we all know that the lines blend, and you may have the option of selling to smaller businesses or monetizing a consumer experience. And it might be regionally influenced as well. So all of these have different usage profiles on your platform. And having the discussion helps you really figure out if your feature switch and versioning strategy is what it needs to be, which bottlenecks in the platform are going to be more important to scale out than others, and what lead time might look like for opening up, let's say, a free version of your enterprise platform that grows into enterprise deployment. Appointments, for example. So I have absolutely held in reserve plans for scaling specific pinch points, knowing that within 2 days I could implement a release valve within the platform if the business grew this way or this way. And that approach has really allowed us to grow rapidly over the years and optimize for time to market. The 7th and final question is one that I'm really passionate about. Your best developers and product people are artists more than they are accountants. And the pride of ownership and passion of their craft— passion for their craft is something that you'll find in the best of the best. So facilitating and empowering your engineers and your product managers and your designers to experience customer pain and happiness as directly as possible is truly one of the fastest and surest ways to build and design an enterprise-grade platform. The ideal, of course, is if they— if employees can use the platform for their day-to-day job, and where that's possible, it's magical. Sometimes you've got to get creative to figure out ways in which they can do this. But something that is always available, no matter what the enterprise platform is servicing, is the ability to directly connect customer praise and feedback to the product teams to encourage emotional connection with the customer on a regular basis. So ways in which we can do this are sharing customer quotes on a weekly basis. I do that every week with my leadership team. Inviting engineers and designers and product managers to join customer calls when they're escalated with support. And really exposing the breadth of feedback and interaction to your employees. So one example of this is that we had a customer who was in sales, visiting a sales region, which included Utah, and he happened to drive down the highway and see this rooster. You see on the left. He recognized it as the Domo Rooster, and he pulled off the next highway exit, walked into the lobby, and asked to see Sean and Mark from the mobile team. They had never met in person. He just knew the engineers' names from exchanging emails on his product feedback. And the reason he asked to see them, and that he took time out of his day, is that he wanted to thank them in person for the product, for the mobile app that they were creating that literally changed his job. While being on the road as a sales leader. And so the engineers are the ones in the hoodies in this photo, as you could probably guess. It was a great moment, but it was just a regular Wednesday. And that passion from our customers is really what drives what we do. So the key takeaways are to remember that ultimately enterprise-grade platforms are designed for people. Diversity and inclusion aren't just buzzwords. Building out an inclusive culture and team is going to build a better enterprise platform. Platform for a diverse audience. So it's important to ask and to cultivate that inclusive culture. Uh, you need to plan on things breaking, uh, assuming that you're growing fast at all, and deciding how you're going to react beforehand leads to a much better outcome. And as much as I love tech and geeking out over petabytes and throughput and scale and architecture, I truly believe it starts and ends with people. Your customers, especially the ones who scare you, and your employees, who should be empowered and directly connected connected with your customer happiness. The bits and the bytes are the easy part of our jobs. The differentiator is actually in the questions you ask and the way in which you listen and respond as a leader. Thank you.

Thank you, Katherine. We do have a question that I want to throw to you with the few minutes we have left, and it is, how much time do you spend directly working with your customers? As opposed to working with your engineer teams? And then, with all that being said, how do you balance that type of time with them?

I think that's a great question. And, you know, it'll vary. It's— it's— there's a bit of a rhythm to it for me personally. And so what I look to make sure we have are steady channels of customer feedback, because I think you need a variety of channels that you're listening to and engaging with. So a steady one that we have, of course, is just product feedback from within the product that they can submit. I look at every single one of those. And so that's just an ongoing investment. Then in addition to that steady stream, we also have syncs with our support team and our field team. So that's how we also receive feedback. And then of course, the Customer Advisory Board, which may be on a quarterly— usually on a quarterly quarterly schedule. With COVID you know, we've had to adjust a little bit. But typically, we would shoot for, in a regular environment, you know, twice a year in person at least, and then quarterly calls as well. So, you know, we have that program as well where we're trying to invest in developing those relationships, really, and having those sessions. Of course, around the time of our user conference, we have a bigger session with the Customer Advisory Board where we'll really get down into the details And the other program that we learn a lot from is actually the beta program. So as we release the features to beta and customers are able to test those out and give us feedback, you know, certainly before big releases, that ramps up as we're listening to that signal. So, you know, those are— I think it's important to call out that you need a healthy diet of how you receive and interact with those customers. Customers. In terms of then time with the engineering team, I would say that's the bulk of the time, in terms of the product vision and release schedules and everything that goes into actually maintaining and delivering an enterprise-grade platform. I would say it's probably, on my schedule, 70% to 80% of the time, and then maybe 20% to 30% of the time with customers. And fields. And, you know, I kind of lump all of a lot of signal gathering in that bucket.

Thank you. Thank you for that, for that very thorough answer. We do have a few more questions coming in. I do want to pass these over to you after, since we are wrapping up now. For everyone who participated, and Catherine, thank you so, so much. Catherine, do you mind flipping back over to where your Twitter handle is so people can connect with you? And they can reach out to you with these questions directly, or we'll do some follow-up on our end. Appreciate everyone attending, and again, thank you, Catherine, and thank you to the Domo team. I hope you guys are sticking around for some more SAS/STR Enterprise sessions, and we will talk to you soon. Thanks again, Catherine.

Thank you.