S2E3 - The Future of Passwords & Product Ops - Donald Hasson, CPO Dashlane

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

0:00:07 - Donald Hasson
Thanks, Rahul, appreciate it, looking forward to it. 

0:00:09 - Rahul Abhyankar
And 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? 

0:00:32 - Donald Hasson
Yeah, 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 kind of reuse it, which, of course, is unsecured, and so 227 passwords is an impossible thing to manage and, by the way, 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. 

Building user delight for heightened emotions

0:01:12 - Rahul Abhyankar
You know 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 you know she asked 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 you know, when we think about passwords, it is such an emotional scenario, right. 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? 

0:02:03 - Donald Hasson
It's a great point. It's funny you word it that way. I don't know if I would have ever if I've articulated 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 ideas. Like 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, like it became unwieldy. 

It took me a really long time to let go of like 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 like working through these things and I need to tell someone my password or some things like that, 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 like really getting good at telling me like your score isn't good enough. I started getting this, getting more and more comfortable with this notion of having Dashlane create a random, of having Dashlane create a random, unique, long, hyper-secure password. 

And it was a leap of faith. It was weird like to 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 like 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 like 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, and I mean in terms of like memorizing them and they're hyper secure. So like 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, they're 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. I mean 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. 

0:04:46 - Rahul Abhyankar
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? 

0:05:03 - Donald Hasson
Yeah, so I don't have the stat off the top of my head, but everything is anonymized, and so 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 a 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.

0:05:39 - Rahul Abhyankar
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. 

0:05:45 - Donald Hasson
That's right. That's right, and it's literally a click of a button in a half a second you have a random generated password. You can tweak it to say like 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. 

User education as a feature of the product

0:06:13 - Rahul Abhyankar
Yeah, you know, 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. Okay, I can understand that, you know, 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, well, you know, 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? 

0:06:52 - Donald Hasson
So much of our product, I mean, 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 like a front and center thing, they share it out with their broader organization like 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, right, and that's by design. 

So we have very few moments to make quick suggestions either, the 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. 

Lessons from B2C and B2B to make the other better 

0:08:32 - Rahul Abhyankar
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? 

0:08:58 - Donald Hasson
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. 

Types of Competition

0:10:45 - Rahul Abhyankar
You know, Dashlane is also a good case study for how we think about competition, right? I mean, 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? 

0:11:24 - Donald Hasson
Yeah, yeah, it's interesting. I kind of assess those sorts of things Like 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. 

0:11:42 - Rahul Abhyankar
They may be good enough. 

0:11:44 - Donald Hasson
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. Yeah, 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, like, 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 is 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 don't. 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. 

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

Avoiding the black hole of feature requests

0:13:51 - Donald Hasson
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 like it's not just UX research that's a part of it, but really it's like 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. 

0:14:48 - Rahul Abhyankar
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? 

0:15:03 - Donald Hasson
Yeah, yeah, 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 like 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. 

0:15:33 - Rahul Abhyankar
So you know 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. 

0:15:53 - Donald Hasson
So how do you manage that expectation?

0:15:55 - Donald Hasson
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 right I mean 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. 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. We do have there's some tools that will just allow us to show sort of status updates. So just change 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. 

It's more fair to the person asking to tell them that up front than it is to sort of keep them hanging on right, 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 say 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 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. 

Knowing customers better than their mothers do

0:18:00 - Rahul Abhyankar
That gives them a bit of a sense of yeah, 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? 

0:18:43 - Donald Hasson
Yeah, 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, you know, we try to do some level of alignment and, as you can expect, there's going to be 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 occasion where there's value that we're either thinking about or active, like 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. 

By the way, I mean, obviously roadmaps are one. I mean, setting aside all notions of like, of course, going on site really gives you context. It's amazing Like 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 like 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 it is now 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. I mean, that's a major change in what value your product can bring to those customers. So, like it's 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. 

Beautiful constraints of product development - Time, Scope, Resources, Quality

0:21:49 - Rahul Abhyankar
Talking about roadmaps. We can look at time as an enemy or time as a friend. How do you look at time? 

0:21:56 - Donald Hasson
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 you know resources, other resources as well, but time is certainly the one that we think the most about, because resources are not nearly as flexible. It's over the years. I mean, of course, you know back in the early days, like 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 like long horizons. Sometimes releases have been planned out 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 kind of four quadrants. Right, 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 right 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. 

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 CXs. The first couple are not going to necessarily hit the mark, but here's what we're trying to story, we're trying to tell, here's where we're going with it, and so, if it doesn't give us that feedback and we'll quickly iterate, we may do fast follow, we may do the next month or this, as we mentioned. Yeah, the aspect of keeping the time fixed and limiting the scope is one of the harder things, because what happens, especially for the teams and this is when you get into like the they are deep into this feature, they're getting excited about, 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, who, 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 or 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. 

0:26:00 - Rahul Abhyankar
And how do engineering teams respond to that? 

0:26:03 - Donald Hasson
It takes some getting used to. I'll be honest with you Just the concept of beautiful constraints. It's 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 and 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 there's the fluff grows out and you end up in like, in the day, 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 I mean mean not in some ways always 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. 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 of 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. Interesting. 

Why does a product org need Product Ops?

0:27:21 - Rahul Abhyankar
So I want to come back to product ops. We talked 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? 

0:27:44 - Donald Hasson
Yeah. So what I like to say about this is, when you look at most other functions of any size at all, so whether it's sales or marketing or CX, 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 like 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. I mean, even our next door neighbors in engineering have engineering ops functions. But for some reason we thought like 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 like 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 there's. You find a lot of things that PMs just got. They get dropped in a lap, like product management is dictating what, 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 the crack 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 and 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, right? 

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. 

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

0:32:17 - Donald Hasson
You mean in terms of the size of the team, the size of product ops. Yeah, so I'll give you where we are. I mean, obviously there's a whole slew of various ratios between, like, pm to design and PM to engineering and PM to product marketing. I haven't seen at least not I've 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 products 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 start scratching the surface on, as well as like 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, like 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. 

0:34:28 - Rahul Abhyankar
Okay, 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. 

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

Transcribed by https://podium.page