Donald Hasson

Rahul Abhyankar [00:03] Donald, thanks for joining Product Leader's Journey. Welcome to the show.

Donald Hasson [00:07] Thanks, Rahul, appreciate it. Looking forward to it.

Rahul Abhyankar [00:09] So you've been at Dashlane as Chief Product Officer for a little over a year now, just over. Dashlane is one of the leading vendors in password management in the industry, and I just have to start off with a curious question here. I don't know how many passwords and accounts I've got. I've lost track of that. What are you seeing in terms of how many accounts do people have nowadays?

Donald Hasson [00:32] It's interesting because you don't think about it. We've just done a refresh on the research and the average is 227 passwords. So it's an incredible number, and it's the reason why this type of product exists, because it's either impossible to remember them all, or you have the same one across the board, or some weird variation that people have manufactured over the years to try to keep basically the same one and reuse it, which, of course, is unsecured. 227 passwords is an impossible thing to manage, and the number is just growing exponentially because of the number of things that we depend on in terms of our digital life and services that we lead into.

Rahul Abhyankar [01:12] That reminded me of this meme from Friends where Joey and Rachel are having this conversation and he tells her that his new password is invalid. And she asks why is that his password? And he says, well, if I forget my password, the computer is going to tell me my password is invalid. But when we think about passwords, it is such an emotional scenario, just from the standpoint of what do you pick as your password, and then forgetting one, worst case getting hacked. So there is just so much emotion in terms of this whole aspect of having passwords. So how do you factor that in when you're thinking about building products and figuring out how to bring delight? When we talk about user delight, how do you do that?

Donald Hasson [02:03] It's a great point. It's funny you word it that way. I don't know if I've articulated it that way in the past. But the story I like to tell is I became a Dashlane customer probably five, six, seven years ago through recommendations of friends, before I was even close to this opportunity. I'd been in the cybersecurity industry. I knew about all the risks, but I was doing the thing that I tell people is the worst idea. I wasn't writing them on Post-its. It wasn't that bad. But I had this spreadsheet of passwords and I tried to get crafty, as I was just talking about, sort of tweaking them a bit, and we had models. And I got Dashlane because eventually it became unwieldy.

It took me a really long time to let go of the old way of doing it because of what you said. It wasn't logical, it was emotional. Like what if I'm in some place where I lose an internet connection? By the way, that's not a problem anymore. But at the time I'm working through these things and I need to tell someone my password or some brand, you start making things up. And so I started getting my passwords in there. Of course they were the same old password, just had them in Dashlane. And eventually sites started telling me, hey, your password's not strong enough. Dashlane started really getting good at telling me your score isn't good enough. I started getting more and more comfortable with this notion of having Dashlane create a random, unique, long, hyper-secure password.

And it was a leap of faith. It was weird how hard it was to let go of knowing the password. A leap of faith to get to it. And now it's amazing to think about the fact that I can't even imagine going back. Even for me being in cybersecurity, I had to let go of the emotional side of it and think logically, this is the right way. Now it's so much easier, it's a breath of fresh air, a weight off my shoulders that I don't have to ever worry about these things in terms of memorizing them, and they're hyper secure. So it becomes the best of both worlds.

But the challenge that we all have in the credential management industry is that piece that humans are holding on to what is essentially a digital identity, like their own identity. So it's hard to let go of that. So to answer your other question, how have we done this? It comes down to being an incredibly trustworthy product. So this comes from a standpoint of giving the sense of confidence to the end user, to where we are in the product being predictive, being proactive, showing them where they're going to start to see these points of value, but then being incredibly reliable. Hyper fast loading. We measure the milliseconds it takes to show the Dashlane D on a website before we log someone in, so they don't even have to think about it. It's a blink of an eye, you're in. And you do that enough times that end users are like, I got it, and so they can count on it.

Rahul Abhyankar [04:46] So you mentioned system-generated passwords, and I know that you don't have any way of looking inside what passwords people have, but do you have a sense of what percentage of passwords that Dashlane stores are system-generated versus chosen by the user?

Donald Hasson [05:03] I don't have the stat off the top of my head, but everything is anonymized. Certainly the ability to generate a password is something that is an incredibly common use case. The other aspect of it is that we even have on our website username generators, password generators. So even if they're not using it, storing in Dashlane, they go to our site, and that is actually a really popular part of our website. People search for this. They go to our site, randomly generate a password, which of course uses all of our proprietary algorithms to make a really good password, and then they may or may not store it in Dashlane, but it's a really popular use.

Rahul Abhyankar [05:39] Oh, that's interesting. So even if I'm not a Dashlane user, I could come to the Dashlane website to just create a random password.

Donald Hasson [05:45] That's right. It's literally a click of a button. In half a second you have a randomly generated password. You can tweak it to say unique or special characters or not, or numbers or uppercase or whatever. However you want to do it and it'll create that password for you. The goal is that they do that, they see Dashlane, and then they decide they want to use Dashlane. But for us, it's the right thing to do, because we want people to have access to these tools, no matter what.

Rahul Abhyankar [06:13] Just out of curiosity, I asked Microsoft Copilot a question. I said, if you were to guess my password, what steps would you take? And it came back with a response saying, well, I'm not allowed to do anything unethical or guess passwords. So ask me a different question. I can understand that, for ethical or legal implications, that's how Copilot responded. But how much of this education do you see putting into the product as education for users to say, hey, your password is easily guessed for these reasons and so on? So how do you think about user education as a capability and a feature?

Donald Hasson [06:52] So much of our product, of course we have a consumer product and a business product, and at the end of the day it's about the end user behavior and the choices that they make, because there's only so much that we, or even an IT administrator, can do or even mandate. We lean a lot on giving guidance. We certainly try to give as much guidance as we can to an IT administrator. So password health score is a really big deal, and many of our customers, that's a front and center thing, share it out with their broader organization on a weekly basis. They try to almost gamify it to get that score up, because at the end of the day, that score being high gives them a solid defense against one of the greatest attack vectors, which is credentials and identity security.

So for the users, we got to get the balance right between they don't care, they don't spend a lot of time in the product, and that's by design. So we have very few moments to make quick suggestions. Of course, the obvious thing of if you have a weak password, we're going to make a recommendation and we'll give the guidance to go to the site to change it, et cetera. We have a thing called Dark Web Insights, which allows us to gather data from the dark web and see if this is a leaked or compromised credential, then we can obviously give that guidance that they need to make that change. There is a bit of education, but there's also a bit of let us just do the thing for you that we all know is the right thing. And that goes back a bit to the trust thing that I talked about, that we've established, both Dashlane and to some extent the broader industry, an element of trust that this is the right way to do it, and we're proving this out. And now they can walk away and be confident, knowing that they've done the right thing.

Rahul Abhyankar [08:32] So you have a consumer product line, you have enterprise customers, so you have a full enterprise password management suite. When you think about B2C, B2B, very different philosophies of building products, even go-to-market, product-led growth versus the traditional enterprise-led go-to-market. So what learnings from either side have you been able to leverage to make the other product better?

Donald Hasson [08:58] That's a great question, because it is things that we're actively leaning more heavily into. So Dashlane and the broader industry sort of grew up around the consumer space, and few of the competitors made earlier moves to the B2B side. By far the easiest answer to your question is because we lean so heavily on the consumer front, the end user is really the biggest quote-unquote challenge. It can be really hard if you depend on an end user to make your company more secure by using software. It can be really hard for end users to follow the procedures to use the software in the right way. In some cases, if a piece of security software is hard to use, it can be worse because end users try to work around it. And so for us, we sort of got lucky in the sense that we solved the hardest problem for a lot of security products, which is making this enjoyable for an end user.

Something that they actually want to use when they get into it for the first time, maybe has to get over that emotional hump that we talked about. The moment they have that first autofill experience, the light bulb goes off and all of a sudden they're starting to put all their things in there. Now it's a convenience. Now they have access to it on their web browser, their mobile browser, anywhere. They can do personal and business split, all those sorts of things. So it's a bit of a flywheel, both in terms of the awareness of Dashlane but also the product functionality and what we lead. Now of course we've had to shore up some things around giving IT admins more visibility and more empowerment, which is what we're leaning heavily on now, to take some of those same concepts and making it easy, enjoyable, out of the way for the end users, applying those same concepts for the IT admin, who also doesn't want to live in this tool all day. They just want to see the security, see the results, see the outcome.

Rahul Abhyankar [10:45] Dashlane is also a good case study for how we think about competition. You mentioned earlier that some of the other password management vendors went into the enterprise first. But when you look at competition broadly now, you've got browsers providing password management, so not exactly a like-for-like, but a substitute alternative. And then on the other end of the spectrum, you've got companies that are trying to get rid of passwords altogether. So how do you look at this competitive landscape, and how does that influence your product strategy and the decisions that you're making?

Donald Hasson [11:24] It's interesting. I kind of assess those sorts of things. Obviously you look at your direct competitors, and I sort of have this idea of second-tier indirect competitors that are maybe solving a subset of the problems in maybe different ways but nevertheless are loosely competitors. And then you have the sort of native solutions.

Rahul Abhyankar [11:42] They may be good enough.

Donald Hasson [11:44] They may be good enough, for sure, and that's a huge challenge. You have the native solution, so it may be something that's baked into the operating system or, of course, as you mentioned, in our case, in the browser or in the mobile devices. You have the competitors that are offering a holistic solution, and what we offer sometimes may even be just a feature for them that they have just built into their product. At the end of the day, there may still be people writing them in notebooks, which by the way is in and of itself a competitor, but for the most part, they're solving it somehow. In fact, just like a lot of industries, do nothing is probably the biggest competitor that a vendor may have. And do nothing doesn't mean they're literally doing nothing. It means they're solving the problem in another way. Is there a better way? Yeah, but they're getting by with what they have.

So for us, there's a few things. One is we have certainly the aspect of SSO, which is doing its very best to try to get fewer and fewer passwords and doing a great job. SSO is a fantastic solution to improve security, usability, all the things that it's promised to do. There are certainly some aspects of it that have still some challenges. On the other end of the spectrum, passkeys is significant. So now it's just an adoption challenge. So you look at password managers, like, okay, so what's the future of password managers? And the answer is you still need a way to manage passkeys. Although they are far more secure, the management of them actually, in some ways, could be a little bit more difficult, because you can't just write down a passkey. It's impossible. And actually what we're actively working through is trying to shore up ways to help businesses manage it, because if not, that's going to be a barrier for them to adopt passkeys, which we need to remove all those barriers, give them the same level of visibility, bring that to passkeys so we can finally do away with all passwords. We still need a solution that gives management ability of passwords or passkeys overall, and we're in a unique position.

Rahul Abhyankar [13:42] So let's come to Dashlane and the product organization. You have a research ops function. What is that function?

Donald Hasson [13:51] So to be clear, we have a research function. We actually roll ops under a product ops function, sort of research ops under product ops, and they work very closely together. It's not going to be a big team of people. They're going to be fairly unique in their skill set. Research is a big part of that, and so they're doing kind of UX research. And we started realizing it's not just UX research that's a part of it, but really it's broader market research, and UX is part of that. One of the big things that we landed on as we were looking at how we scale and grow the functionality is we're not going to hire 20 researchers. We need to have a way to scale out the skill set. Product team, between product managers, product designers, analysts, even with some of our technical folks as well, really do solid research using standard best practices, things that you wouldn't get had you not had someone that was an expert in market research on the team, and they can share that out.

Rahul Abhyankar [14:48] I do want to come back to product ops, but before we go there, I want to extend this aspect of research and learning from customers. How do you solicit input, feedback, suggestions from customers?

Donald Hasson [15:03] I think there's a pretty common set of sources of input. We have a public portal where customers can see some of the things that are coming up in terms of loose direction of where we're going from a roadmap standpoint, but start to share feedback with us and hear from them. One of the questions I like to ask are what are your top five priorities for the next 12 months? Because that unbiased, forget Dashlane for a second, you start to get some really interesting things to come out of that.

Rahul Abhyankar [15:33] So back to that portal that you have made available for customers to enter their feedback, suggestions, requests. Anytime you give a vehicle like that for people and they start putting in their features and suggestions, there is an expectation that that's going to get acted upon. So how do you manage that expectation?

Donald Hasson [15:55] I think I've been hearing about the black hole of feature requests for 20 years. Back in the day, it used to be an email address and we had hyper-manual process that was rarely kept up, old-school ways of doing it. And yeah, it was referred to as the black hole, because it's not that we're not trying, but we get 150 requests a month and we build two features, and so just the statistics alone mean we're not going to address a lot of it. So the short answer is you've got to show some engagement. You will disappoint people to some extent, and the reality is, as I said, there's only a small percent that we can actually address.

So there's a few things that I've done. One is showing some engagement lets them know that we're thinking and paying attention, and you can't do that as much as I'd really like because you just don't have the people to be able to do it. Usually it takes a product manager or designer that can put a thoughtful response back together. There's some tools that will just allow us to show sort of status updates. So just changing the status alone says, hey, there's someone actually paying attention to this, at least a little bit. One of the things I really like to do, which actually takes some discipline, is going back and saying we're actually not going to do this. Because in reality, it's more fair to the person asking to tell them that up front than it is to sort of keep them hanging on, to bait them along the way and one day we might get to it, which is a terrible way to do it. You're pretty sure you're not going to do it. It's really better just to go back and give them a thoughtful response. Here's what you can do today, here's the workaround, whatever it may be, that why you're not going to put that as a high priority and give them that answer.

So it's a really tough balance. As much engagement as we can give, as much leaning into the portal and showing that it is a tool that's a vehicle for communication that in some ways is bi-directional, that gives us the best chance of showing it's not a black hole. And then of course, the more that we can keep cool features coming out that are coming from that, that at least gives them an indication. My feature didn't make it, but geez, these two or three things are really cool that these guys came out with, that gives them a bit of a sense.

Rahul Abhyankar [18:00] Really, that follow-up conversation is really the most important aspect of understanding why, why not, and so on. Donald, you mentioned something which I thought is important to pull the thread on a little bit. You said that you ask customers outside of Dashlane what are their priorities for the next 12 months and so on. We as product people, we get caught up in our own roadmaps, not realizing that customers have their roadmaps too. What interesting things have you learned, not just at Dashlane, but looking back in your career, where there's maybe a story about what you learned from customers' roadmaps?

Donald Hasson [18:43] It's funny, because it's actually a pretty rare event. And usually it's the more enterprise level customers where you're doing a QBR, we're sharing our roadmap. If we're lucky, they'll share their roadmap, and we try to do some level of alignment. And as you can expect, we're only one vendor for all of the things we're thinking about. You get a little bit, but you can at least start to think about, get more context for their world. And then of course, there's enough occasions where there's value that we're either thinking about or actively building, that we can say we can help you on one or two things that you've shown there.

Even on our best days, we have our roadmap, and I've been guilty of this in my career as well. I walk the roadmap, I get validation that they're interested in a few things, and I go maybe a little bit deeper. But that's our world. That's a very narrow view of things. It doesn't take a lot to be in their world for a little bit.

Obviously roadmaps are one. Setting aside all notions of, of course, going on site really gives you context. It's amazing. We can spend so much time sort of rationalizing and working through our own roadmaps. You spend 10 minutes with a customer and you're like eyes wide open. You go on site, you watch them use your product, and it's amazing to see the difference between our best demo environments — we try to make them as real as we can — and test environments and a customer. At the end of the day, they make it work for their work, and you start to see some really interesting things.

So I think tying it back to the roadmap conversation, those play out in the roadmap as well, because the roadmap for them, their internal roadmap, is what their IT or security or identity department, what they're thinking about for the next 12 months. They have done the work, just like product people are doing. These are the five or six highest priority things, the things they're going to put their valuable, precious resources towards. That means we need to be aware of that, if not thinking about ways we can help them, because no matter where we were on their list, those are the highest priority things where we can be potentially providing the most value. Those are where you start to find the biggest, what I think about as the biggest levers. We can increment our product, we can adjust things to make it a little bit easier for them. But when you start to see this new world that's outside of where you are but close enough to what your product could solve for, that's a major stepwise function. That's a major change in what value your product can bring to those customers.

So to me, I use this a lot, it's all about the context, being in their world. A colleague of mine used to joke about, we want to know our customers better than their mothers do. What motivates them, what drives them, what gets them excited about their work? Because kind of back to all the other conversation, at the end of the day there's still an emotional aspect of what they're doing. We want to know what that is so we can help shore that up for them and provide value in an area that is something that's going to drive some emotion, that's going to drive value, that's going to make them be able to celebrate what they're doing, make them look good to their organization and to their leadership. Those are all important things. The context is so critical.

Rahul Abhyankar [21:49] Talking about roadmaps, we can look at time as an enemy or time as a friend. How do you look at time?

Donald Hasson [21:56] Oh, I love this topic. So our new CEO, John Bennett, he joined just about a month or so after I did last year, and he is famous for calling it beautiful constraints. By the way, not just time, but obviously resources, other resources as well. But time is certainly the one that we think the most about, because resources are not nearly as flexible. Over the years, of course, back in the early days, we're doing releases maybe every six months or something like that. For a variety of reasons, you put those constraints, but there's such long horizons. Sometimes releases have been planned out a year, year and a half in advance. It takes us six months to build the thing.

Now we're in a place where it's all about thinking about the smallest possible slice that we can build, but then time boxing. In the sort of four quadrants, you have the resources, you have quality, you have scope, and you have time. Quality, we say, is fixed. We have a very high bar for quality. Resourcing, yes, you have some fungibility around that. We try not to move that too much, it could be disruptive. It really comes down to time and scope. And of course, you have a tradeoff. You can say you're going to fix scope and then time is however long it takes, or you fix time and scope. You could do a blend of the two, but that can get a little bit messy.

So the way that I've set this up is, we all work better in small increments. Everything we do, long-term life goals, you've got to break it down into something that's yearly or monthly or weekly or even daily, to think about the increment you're going to take to move towards this big thing. So it's a small step in a big direction. And then by the way, let's not forget that there's a snowball effect that happens. So the virtuous cycle, we build something, we learn from it, we tweak it, we build a little bit more, we tweak it, and this grows into this thing that all of a sudden is a very innovative solution starting out of something very small.

We're still humans and we like to see successes soon. We don't want to wait for them. So I would much rather get a small feature out once a month, get really good feedback on it, and feel that success and feel that accomplishment across all the teams than wait six months to get that same thing, even if it's way better in six months. If I do six one-month increments, it will be 10 times better than one six-month increment, no matter what.

Now the first couple, one of the things that I've had to work with the teams across the board, by the way, not just product engineering, but sales, marketing and CX, the first couple are not going to necessarily hit the mark, but here's what we're trying to, the story we're trying to tell, here's where we're going with it. And so if it doesn't give us that feedback, we'll quickly iterate. We may do fast follow, we may do the next month. The aspect of keeping the time fixed and limiting the scope is one of the harder things, because what happens, especially for the teams, is when you get into the, they are deep into this feature, they're getting excited about it, they see the vision, what the potential of this thing, and they just want to keep going. They want to keep building this cool thing and go to the next level.

But the challenge is that that's high risk, because we don't know, as I mentioned, in six months. We don't know what the market, it doesn't matter until they actually are using the thing. So the discipline is setting that fixed amount of time. And by the way, I've had to negotiate this with every engineering team I've worked with for the past probably five or six years. I've gotten it down to as frequently as build something for no longer than four weeks. Not everything fits in that bucket, but it's a really good target. We're here about four to six weeks now because we have some complexities due to the zero knowledge architecture that we have, but nevertheless, it's a fixed time box that's relatively small that we can be somewhat predictive on. And so you do your best. You're not touching quality, rarely touching resources, but you cut the scope as far down as you can to get it to fit in that time box. You get it out there, and you know exactly where you stand at that point. There's no more guessing. Now you can learn and now you can iterate on it, and that's a really powerful concept.

Rahul Abhyankar [26:00] And how do engineering teams respond to that?

Donald Hasson [26:03] It takes some getting used to, I'll be honest with you. Just the concept of beautiful constraints. When you have a healthy constraint that is time-bound, that is resource-bound, it is within the scope of the feature and you're limiting the scope, what it does is it forces you to be really efficient with what you're doing. And the end result of that is a feature that does exactly what it's supposed to do in the way that customers want it to, and not all the fluff around. You've got a lot of time. What I've seen with features is it starts here and the fluff grows out and you end up, at the end, people don't use most of that. Then you have the feature bloat and those sorts of things.

And so in some ways, by the way, it can actually be harder to strip away the things, because you're like, well, maybe I need that thing over there. Oh, I did hear this one customer say that one thing about it. But you've got to make the really hard choice to focus on that 80-20, to get that 80% that really matters. The 20% that applies to the 80 that really matters. That's the beautiful constraint. That's what forces that. And you come out with, what we lean into a lot at Dashlane is simplicity, by virtue of the fact that we don't put all the fluff and extra things in there that are just really not needed at the end of the day.

Rahul Abhyankar [27:21] Interesting. So I want to come back to product ops. We touched upon that earlier. Why should a product organization need a product ops function? What do you take into account before you put in this function, and how do you make it successful? How do you measure the success of this function? So kind of a longer question, but let's start with, why does a product org need product ops?

Donald Hasson [27:44] What I like to say about this is, when you look at most other functions of any size at all, whether it's sales or marketing or CX, they have someone and maybe even a team of people that are thinking about the operational aspect of that department. And why is that? Operations is what allows us to make scalable, repeatable processes effective, and that requires building and maintaining those processes. Almost always there's tooling that has to be brought in and maintained and integrated with other tools. You mentioned the metrics aspect of it. Almost every department has some form of metrics that they're tracking to ensure that as they grow, that they're still hitting the KPIs that matter to the business, that are driving the business forward.

And so what was interesting for me is that over the many years that product management has sort of been developing, it took a long time, I think, for all of us to realize that in many ways, it's just as operational as any function. Even our next door neighbors in engineering have engineering ops functions. But for some reason, we thought, I guess because we were kind of part of engineering in some cases, we got by with what they were doing, but we build sort of ad hoc processes, and the reality is that's the wrong way of thinking about it.

One of the things that I had to do with every company that I go to is, what are the things that you're doing that you should not be doing? There are things that should be taken on by another function, and you don't always get to slot it in, but usually you find a lot of things that PMs just get dropped in a lap. Product management is dictating the thing that we all care about or driving towards, which is the product we're selling, supporting, et cetera. Super critical that that is as operational, if not more, than even other aspects of business.

So for me, you're not going to do it when you're probably a 25-person company. There is a point where you start to need to think about product ops. My belief is it's far earlier than people think. I don't think you have to be a thousand-employee company to have a product ops function, or even 500. I think that a product ops person will make every other person on product, as well as cross-functional folks that engage with product, better. So it's a force multiplier. It's a thing where product managers don't have to think about the process. They think about, back to the point we made earlier, they can start to really think hard about the questions that they're asking our future or current customers, versus trying to figure out how to prioritize a backlog in a spreadsheet because they don't have a tool to do it or they're just making this up for the first time or some ad hoc other way that things are going down. So we can systematize things.

The way I talk to my product team, because sometimes, I mean, there's process, don't get me wrong, there's things that they don't always immediately see the value, but the way I talk about this is, those things are working for you in the background as you get the habit going. So now your mental capacity is far more freed up. You're spending 80% of your time thinking about these ad hoc things, addressing question X and Y and going to 15 different directions every single day. You have 5% of your time or 15% of your time left to do the meaningful work. Let's take all that stuff out, systematize it, get into a process and a tool and a framework, just like we want for salespeople.

We want salespeople being their best on the phone with the customer, trying to sell them on an idea, to understand their pain, to dig deep into what they're doing. It's the same concept with product people. We want them thinking at a higher level, getting outside of the sort of day-to-day. And as far as I have seen in my career, that is impossible to do without solid systems, solid processes. And you cannot do that by depending on one of your PMs or some person on the product team doing that as a halftime job. It never, ever works. The tools you buy languish, the processes aren't kept up, it doesn't scale the organization. The only way I've found to do it is someone that thinks hard about this every day and is good at that aspect of ops. They can run that for you. It doesn't take needing a team of 100 people to benefit from having product ops. I don't know what the number is exactly. It's probably more than five PMs and five designers, so maybe it's a team of like 10, but it's far earlier than I think most people give it credit for.

Rahul Abhyankar [32:09] So how many people do you see in a product ops role? How big is that function likely to get at all?

Donald Hasson [32:17] You mean in terms of the size of the team, the size of product ops? So I'll give you where we are. Obviously there's a whole slew of various ratios between PM to design and PM to engineering and PM to product marketing. I haven't seen, at least not personally seen, a stat that says how many exactly do you get to product ops. The other thing that I'm also conscious of is this is a very specialized field, fairly new. It usually takes me a little bit of educating with my leadership and cross-functional partners to help understand why it's there and the benefit. It doesn't take long before they see it, but it does take a little bit of that.

I'm also conscious that I don't want to bring it up, it doesn't need to be a huge team of people. So I started out with one, and we had just over about 30 folks on the product org. We got fortunate enough, for a variety of reasons, we have another person on the product ops team now, that we had some agreements with engineering that made this work out really well. So we actually have two now. I would say for us, we're right on, because of the way that we're using their individual skill sets, that's a perfect fit for us. Probably other organizations, you may be able to do okay, get a really good start with just one person for, say, 20, 30 people, something like that.

When you start to get into the bigger product orgs, 50 or 100 people, you're going to start to need to think about a team that can even start to specialize a bit within product operations, because it can be such a massively varied role, because of, in some ways, how specialized it is, actually has them, their fingers into a lot of things, everything from, we talked about earlier, research ops, the aspects that PMs are doing, product design and design ops, which is a whole other category of things that we actually have only just started scratching the surface on, as well as working with cross-functional partners in terms of setting up the interlock processes. Launch, for example, is a huge deal. It's easy when you launch once every month or six months. When you're launching something every week, that's an ongoing thing that you've got to get really systematized to make it work. So those things is where you start to get a lot of the benefit.

Rahul Abhyankar [34:28] Very interesting. Well, Donald, thanks a lot. This has been just a great conversation, and I really appreciate you taking the time to be on the show.

Donald Hasson [34:37] I really enjoyed it, Rahul. Thank you so much, I appreciate it.