Mike Donovan is SVP of Product at Sauce Labs, a test and error reporting solution. He started his career as a software engineer and worked as a web developer at NASA, University of Maryland, College Park, and Dante Consulting. Mike later joined Aquicore, an ESG data and analytics platform, before transitioning into product management. He joined Sauce Labs in 2020 as Director of Product.
In our conversation, Mike talks about how experiencing the “symptoms” of being a software engineer, such as constantly changing priorities, has made him a better product manager. He discusses how leading an open source community is similar to running a SaaS company — you’re doing it to solve a problem that a lot of people care about. Mike also shares the five key business drivers that tie up to revenue and how he rallies his team around these objectives.
My story at Sauce Labs is one of career progression: I started as a group product manager, running product for our core offering, and then, over time, expanded my scope. Now I run the whole portfolio.
Before Sauce Labs, I ran product and engineering for a startup in DC. I was an early employee and, when I left, there were 150 people. Before that, I had spent really a whole other career — over 15 years — as an engineer. I have a computer science degree and did the whole full-stack engineering thing. That eventually took me into the product management world.
As I was becoming more of an engineering leader, I realized the best thing I could do for engineers was to be a better product manager. It sounds silly, but I only worked with probably one out of 25 good product managers. I used to think I never needed product managers. I’d say that I just need some business-oriented or user-oriented engineers.
You eventually learn that it is actually a full-time job. You start counting up all the nights you spend building the product, coding until 3 a.m. every night to build products that aren’t actually useful for the world. I traced it back to really bad product management and set out on a mission to improve product management instead of engineering.
It’s probably a mix of both — the idea of treating an open source community or your open source project like a product manager would. The individual contributor part of an open source project is more around the community, but if you’re the maintainer or the creator and you want to create something new, you’re doing it to solve a problem that a lot of people care about. Just like a company, it starts by solving a problem that maybe you felt, but that you think a lot of people will pay you money for. I think in an open source community, it’s similar, there’s just no money being exchanged.
It still forces you to do the same things, like understand the user pain point that they have and the job you’re helping them do with your project. That’s how you incentivize building a community around it. And I think that’s maybe how you can measure success. It’s not business drivers as I talk about for a money-making product, but it’s a more relatable way for an open source project to think about how well you can build your community around it.
Understanding who you’re building the project for is also really important, because if the user is not the same as the contributor, you won’t be able to build that community around it. In open source, you want the people who are using it to be the ones who also contribute to the project, and so you kind of have to find the intersection of those two things.
Yeah. The same thing happens in B2B SaaS software. There’s the practitioner, who’s the user, and that’s usually different from the buyer, the person who actually has to make the purchasing decision. Sometimes they’re the same, but in most B2B-type SaaS tools, they’re not. And you have to think about both of them. When you’re a product manager and you want to impact those business drivers, you have to think about both of those people to make a successful product. It’s the same exact thing for open source.
Sauce Labs is a 15-year-old company. Open source is core to our founding principles. It’s core to how we’ve operated as a business, and we’ve really used it to better developer lives across the board. We were founded by the same people who created the most famous and still most popular automated testing framework in existence, Selenium. It almost created a whole new way of doing testing, at least at the scale that it has reached.
The Selenium community has actually turned into a standard. It’s not like one project runs that standard. We support many, many projects. We don’t own any of the projects, but we definitely support the Selenium project and a lot of other ones, like Appium. That’s kind of core to who we are because of the history of promoting contributions and using open source technology. We think it’s what builds the best experience for developers, no matter what they’re doing.
It starts with the symptoms, the ones that I experienced, where engineers feel like priorities are constantly changing. It’s a lot of thrashing around what they’re working on. You spend a lot of time working in one direction and then it changes abruptly. And then you’re demoralized when you don’t see the thing you were working on go into the world to help people. Maybe you’re not understanding the impact that your code is having on the business or your users. Whatever the reason is for why you’re writing that line of code, you’re not really seeing or understanding the impact. These are usually the symptoms of a lack of good product management.
When you go a little deeper into that, you might find that the product managers don’t truly understand the business the software or product is in service of. A lot of product managers understand a feature, how the system works, the users and what their days look like, and that’s all helpful. That can definitely help you make good decisions. But to really make great decisions in product, you have to be able to connect the user’s pain and job with how you make money as a business.
That can be very hard to do. There’s not always a direct connection between, if the user X does this action, then it makes me this much money. A lot of times, it’s an ambiguous calculation, but you really have to deeply understand that. Because once you understand the drivers of how you make money as a business, then the prioritization decisions and changes in priority go away. You’ll always know that your strategy is in service to those business drivers.
Every time I’ve seen priorities change abruptly, it’s because something was prioritized without fully understanding the business drivers behind it. That’s why it becomes so easy to deprioritize something: it was never clear why it should have been prioritized to begin with.
It generally starts with net revenue. I’m always trying to make more money tomorrow than I did yesterday.
In a SaaS business, there are usually five key business drivers to always be thinking about:
Those five drivers are normally why you are building something or prioritizing a feature to be built, and they’re all in service of revenue. They’re one level below revenue that makes the feature you might be building or the code you’re writing. Ultimately, the revenue goal is if you can tie it to one of those five drivers.
I try to set up a culture that supports this mindset. And to do that, I do a couple of things.
The first is how we’re organized. A lot of other companies are organized around the way the architecture was created or around different user personas, and I think that creates ambiguity in ownership. I like to organize ourselves around the products that we sell. That way, there’s literally a group of people across product management, engineering, design, product marketing, etc., all focused on improving the business performance of that product. Organizing yourself around the business is key to the way the engineering teams are set up.
The second thing I do is make a cross-functional team responsible for the business outcomes and I hold them accountable for that. I have to not only empower them to impact the business metric, but I have to enable them with the right data, systems, and access to the business that they need to actually move the needle on any of these business drivers and grow revenue.
Something I do slightly differently is regarding the traditional product trio: product management, engineering lead, and design. I think it’s actually more of a quartet because I think that you need product marketing involved as an equal member in that. I could build something that works really well that’s an elegant architectural solution, but if nobody knows about it, it might as well not have been ever built. Product marketing makes it so the world knows about it. I bring all those responsibilities together. It doesn’t necessarily have to be four different people, but each of those responsibilities has to be accounted for.
The last thing I do is make sure that the product and engineering teams operate in the same rhythm of the business. A lot of times, you’ll see teams work on a roadmap that’s constantly rolling. They don’t make commitments and it gets done when it gets done. That’s kind of silly when the entire rest of the business operates on a fiscal calendar. We all need to understand that we operate within that same cadence. So when we’re doing our planning, delivery, launches, and our execution, it’s all in the mindset of, “I need to impact these business metrics by this board meeting because that’s what the whole business runs on.” I work backward from that fiscal calendar.
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
Want to get sent new PM Leadership Spotlights when they come out?
Hypergrowth happens when a company experiences an exceptionally rapid rate of expansion, typically more than 40 percent annual growth.
Detractors have long-term effects like negative brand perception, reduced customer loyalty, and a decrease in sales.
To proactively address liability concerns, you can create an internal product recall team for dealing with risks and ensuring quality.
Our Galileo AI Fall ’24 release makes Highlights available to all Pro and Enterprise customers. We’re also debuting Ask Galileo, which enables you to directly ask questions about what you see in session replays.
Learn more →
