Ep. #8, Driving Product Communication with Dave Cole

Grant Miller: All right, Dave. Thanks for joining me.

Dave Cole: Thanks for having me.

Grant: Cool. I'd love to just jump right in and hear a little bit about your background and how you got to where you are today.

Dave: Sure. Originally I'm from Michigan, I graduated and took the first job that would get me out of the frozen tundra of Michigan. It was this not so sexy job in computer security, back before it was called cyber.

Basically I was with Deloitte and Touche and I figured it was a good company, and I loved Los Angeles. I fell in love the first time I came here and I had to move, I had to do it.

I figured "I will get out of this security industry just as fast as I can, and then I'll do something super cool like web design afterwards." This was in the heady days of '96.

Here we are in 2018 and I completely failed to get out, and many jobs in between. Deloitte turned into a stint at a company called Internet Security Systems out of Atlanta, where I was a consultant.

I did all sorts of stuff. I did penetration tests, security assessments, incident response, all working with ISS's products. It just got to the point to where the company had lost interest in something called "Vuln assessment," and the product associated with it.

I was a consultant out in the field and I was like, "Why don't these knuckleheads get it? Customers need an enterprise version of this." In fact, I got paid as a consultant to design that for Sun Microsystems way back in the day.

As I was trying to explain to the product managers why they should do this, I got tapped on the shoulder for a company called Foundstone who had started a services team similar what I was doing but really wanted to get into product, and had a development team but they just didn't have a product guy.

So I figured, "Why not? I've already felt the pain, I feel empathy with the customer, and I know what I'd want to build." It matched up pretty well to what the guys who were at Foundstone wanted to build, and away we went.

That was my transition into product many moons ago, about 18 years ago.

At Foundstone we basically took this vuln assessment market which had been really a consultant's market at the time, with their new point and shoot security assessments of environment and give you a big fat report hundreds of pages long that tells you all the things that you were doing wrong.

We tried to turn that into a repeatable process, like an enterprise discipline, and the analogy we used was a dental one which seemed to go over pretty well.

Like, "That thing you're doing a couple of times here with the consultants, that's a lot like going to the dentist. This is deep cleaning. But what you really need to do is brush and floss in between, and it ain't real sexy, but it's super important to know what you have and know where the phones are.

That's vuln management, and we're going to help you through that process. So, that was Foundstone, and I did that for four and a half years. Long enough to realize that I didn't know what I was doing, and I needed to go someplace where people had done it at scale.

We did well enough to get acquired by McAfee. Customers were patient and kind, and I hired some people who did know what they were doing and it was a lot of fun. I realized I love products, so I went from there into Symantec, pre-Veritas acquisition.

The Veritas acquisition happened shortly after I joined, and I joined the security response team which was awesome, but not a quote unquote "Real product job." It was about the business of security content and everything that went around it, and the research organization.

It was fascinating and fun and I did learn product at scale, and I met some amazing people there. But ultimately I knew I had to get back into product. I'd learned what it was like to be a product person over an internal cost center.

There were things that were amazing and there was a lot of freedom in that, but it was non-product-y as you might imagine, and I got scooped up by the consumer group, by the Norton group to come in and run the Norton Antivirus. Norton, and its security product line.

That was an opportunity too good to pass up. I nearly left security at that point, and I stayed with Symantec another five years on the consumer side, which was a whole other education.

Eventually I got a really big job at Symantec, eventually exited really big job at Symantec during a massive reduction in workforce when many of the consumer folks were either let go or went off to greener pastures.

From there I went into CrowdStrike to take a run at reinventing the end point space, which from my time in Symantec I felt like it wasn't really their focus, and the guys who started CrowdStrike also felt like it wasn't really McAfee's focus.

We saw this huge opportunity to-- Much like we took vulnerability assessment and turned it into vuln management, take the end point space and really reinvent it for a modern era, which became fashionable to call the next gen endpoint market from CrowdStrike.

We had an amazing run there, lots of fun, easily one of most talented and incredible teams I've worked with. Went from there to Tenable, where I am today. Chief product officer over at Tenable.

We recently went through an IPO in July, which has been a pretty incredible run too. So, product for many years and security for absolutely all of those years in spite of my best efforts.

Grant: That's amazing. That's a very deep background on security, it sounds like a lot of enterprise software. Let's also dive in a little bit.

What was the relationship between the consumer and Norton product and an enterprise offering there?

Dave: Yeah. It's really interesting. This is common in the antivirus industry and it's common elsewhere too, but one of the advantages of having a consumer brand, particularly the AV side, is you can iterate it quickly.

You can automatically update it and no consumer is going to complain that you just tanked their server, "Oh my God, the operational control on this is completely unsatisfactory."

It's like, "No. You're going to automatically push the update, the consumer's going to take it. As long as you don't ask him to reboot they're probably pretty happy with it."

It's like, "Sweet. Awesome new bits delivered without me having to mess with it."

The beauty of that, and I learned this when I was in that internal cost center on the security research side, is all the new security engines are going consumer out to tens of millions of people.

So you see all these threats and all these things, and you can tune the false positive rates, and you can test it and you can make sure you get the performance right, and you can add more things to white listing and honing your efficacy on the consumer side.

In the enterprise product cycle every two to three years, probably much faster now, I've been out of that game for a little bit. But even there, people aren't going to take new stuff without testing it or without a soak period, and so forth.

They're going to lag. That gap between the enterprise and the consumer product turns out to be incredibly useful for testing new capabilities which eventually get rolled up into the slower updating enterprise product, where the cost of integration and in particular the cost of getting it wrong, the risk is much higher.

So there's a really nice ecosystem there of "Try it in the smaller product, test it there that's more fault tolerant, where it's less expensive. Evolve it and when it's pretty well-baked move it up into the midmarket and into the enterprise offering."

Grant: Yeah, that makes total sense. It's almost like-- We do it today with feature flagging, sometimes with your non-enterprise customers you roll out awesome features first to get some real world use cases and then roll it out to the enterprise customer.

But beyond being able to use that as a test bed and get data, was there a relationship from a sales channel? Was there features? Was it the same bits that you just were adding on top of enterprise functionality? How did it relate from a product perspective?

Dave: Yes. This is something that's pretty common for big portfolios, particularly in the security industry. You'll have a team that sits in the middle, like a Security Technologies Group, STG.

It's something we do at Tenable as well, where you have shared engines that are literally the same across products. A vulnerability scanning engine doesn't need to change fundamentally whether it's in a security center or whether it's in Tenable.io, our new cloud offering.

One happens to be on prem, one happens to be cloud, but the security engine can be shared. It was the same thing with Norton and Symantec, and I'm sure it is today.

Where the security engines, interestingly, because they move faster the consumer team actually drives the security engine development itself, and the enterprise team later largely just picks it up.

Now, do they have to add some customization on it at times, and customer driven white listing? Sure. Grandma Jones on the consumer side does not need to test security engines before they roll out, or make sure their custom app is white listed.

So, they add on more manageability and more things that are friendly to the enterprise.

But it's super helpful when you reach scale with a product line, particularly a security one, but I'm sure it's the same thing elsewhere, that you have a shared components group that effectively is an internal development group where you have multiple teams as the customer. It's pretty common.

Grant: In that same regard, were organizations adopting the consumer version of the vulnerability or antivirus, and then upselling themselves in the enterprise or the business version? How did that work?

Dave: Yeah. It's something that was more of a focus around the time I was leaving.

It was one of those where it happened accidentally, but as more and more people started to do BYOD and use their own devices that may have had Norton on it already , there came to be much more awareness around "We should smoothly provide a path from small business and a mid-sized business and enterprise."

But a lot of times corporate structure defies what would otherwise be super logical, because you have an enterprise team that's doing their own thing and the consumer team is over here using different sales channels.

In Symantec's case we had a commercial mid-market team that was mostly cloud oriented, and the progression across the full company portfolio was jagged to say the least, but it's the thing when you're a smaller organization and you're not so siloed out, you have a good shot of doing.

So we're working on that quite a bit at Tenable right now, trying to provide logical migration paths up.

Grant: Yeah. Because I'm sure within the political constraints of an organization where there's different teams that are comped differently based on the performance of their product, it's probably all these different NIST incentives to not allow that to happen, right?

You want people to keep using your product and not move on to some other line of business' offering.

Dave: Massively. Yeah. The one piece that a lot of them don't get right that as I took-- I'd had the whole portfolio for a period of time and you looked at it, and one of the things we wanted to do is come up with a common management framework.

So everybody will abstract out the engines and the engines will sit in the security technology group. But why wouldn't the management APIs be the same?

Because if the management APIs were the same you could just seamlessly migrate them up into more mid-market or enterprise friendly console that gave them additional features, and you just unlocked things inside the agent and so forth.

But when you don't have that mentality you're not-- You don't have empathy with the customers who are going through that growth cycle, or maybe there's an acquisition and MNA and the rest of it. You just don't pay any attention to it.

Grant: Yeah. So it's like, "I think this is probably less of a problem today with most software not being desktop software. With it mainly being SaaS and cloud, so you can always use the same bits.

Rarely do you have a totally separate code bases that are driving different APIs or something like that.

Dave: Yes, and in fairness to Symantec they have moved heavily in that direction. I'm long gone since 2013 and a few things have changed over there in the last half decade.

Grant: But it's always great lessons to learn. Let's just touch on your time at CrowdStrike a little bit as well. Because from what I know of CrowdStrike it's fairly heavily services-oriented business too, is that right?

Dave: Foundstone and CrowdStrike started as Services Place.

Grant: OK.

Dave: Always with the intention of building product. I'll say, I've done product companies that dabbled in services later, and I've done companies-- I've done Foundstone and CrowdStrike, where they had strong services to begin with, and I love having a strong services team.

First off, you can cheat. As a product leader your services team is right there, they're using the product and they have incredible feedback, they're out with the customer.

You can ask them questions that you'd otherwise have to be careful asking a customer because you don't want to look dumb, or it's hard to find them, or you've got to track them down and get to them and the salesperson on the call, or so forth.

When it's like Sally in services who is sitting right next to you in the office, you're like "Sally, what do you think about this? Can we show you something?"

They love it because they're getting direct access to the product and engineering team, and the engineering team loves it because there is this customer sitting right next to them.

The amazing thing from a sales perspective too is if the consultants are happy with the product and they're using it on customer's site, it's an easy sell.

It's like "Here's this product we just used to perform your engagement, we can just leave it here for you." They've already done a partial install, it's the world's best proof of concept, right?

It's a pretty cool model. There's pitfalls there and I've seen companies do it wrong, where they end up splintering the product or just chasing what the consultants want, which is different than what the actual customer wants.

You have to be careful that you build a consultant's tool and that you splinter your product. Having said that, if you can pull it off and really harness that feedback, you get fast proof of concepts and you get great feedback quickly.

You just have to have the discipline not to just do what the consultants say, because make no mistake, they have their own perspective and their one persona.

The trick as a product leader, and that scenario is at what point is the consultant an effective proxy for the actual voice of the customer? In what area is that the voice of the consultant? They may be right, but are you more inclined right now? Do you need to?

Is your business imperative to solve the problem of the consultant, or the customer who is actually using the product? we got a lot of it wrong when we were at Foundstone, like I wasn't-- It was my first product job. I don't think we made anybody happy.

We equally dissatisfied consultants and customers, but it was something that we were-- The founding team at CrowdStrike was really conscious of because of previous experience, and it was something that I was conscious of too having wandered off the path and watched a few others do the same in the meantime.

Grant: That's really cool, I hadn't thought about that as a strategic advantage for product development and engineering to be able to be so close to your customers. Really thinking about it that way is a great point-of-view. I like that a lot.

One thing that is interesting is how you got to Tenable, because I know that it was through a relationship with a board member, maybe. Is that right?

Dave: Yeah. I had just finished working with CrowdStrike and parted ways, and became aware of a project at Excel through a friend. Not through the Excel guys initially, but in the official way that most great projects are started, over beers on University Ave in Palo Alto.

So, this LA story traces its roots back to University Ave, the Crown and Rose if I get the name right. I was out with friends and the next day my buddy called me up and said "There's this friend at Excel who contacted me, and he's got a project. They need some help over at Tenable."

So, thus began the next chapter which was Tenable, and I'd started out as a consultant. I was dead set on starting my own company, but for a whole bunch of reasons it became obvious that I didn't need to start a company at that time, but I needed a job.

Then I fell in love with a Tenable opportunity at the time, with the team that was there, and with the opportunity that it represented.

It turned out one of the guys from Excel was shared across teams-- It was on both boards, both CrowdStrike and Tenable, which made it easy and comfortable for everyone.

Grant: Cool. Then you came in initially as the Chief Product Officer right away?

Dave: I did, yeah. It was interesting. I came in initially as a consultant, I was hired on July 1st of 2016 as Chief Product Officer, and away we went.

The job was to take this incredible business and it was super impressive financially but there was some work to be done on the portfolio. There's work to be done in the product strategy.

We were doing a lot of things and we had to fine tune and hone the product strategy at the time. There was a number of things, there was the thought that "We want to take this company public at some point."

I had a sense around the timing, but we didn't have a CEO, so we had to get a CEO first and we had to clean up marketing and a whole bunch of other stuff.

So, I came on as CPO originally running product marketing, engineering, and product management with a charter to build out a bunch of other things. Program management, design-- We were missing a few things at the time.

Grant: You mentioned earlier that you have a framework that you use for approaching some of that customer input and feature requests, so beyond telemetry I'm guessing there's some stuff that you do when you think about enterprise features and how to-- What to build next. Can you talk a little about that framework?

Dave: Yeah. It's a blend of qualitative and quantitative. It has varying fidelity, so this is going to be a little long. Prepare yourself for a mini-monologue here.

First off, we'll go on the quant side. Like I just said, there's no substitute for having the UI instrumented and also for having things like installers instrumented.

Having install failed codes and everything else, and having them come back. Having good telemetry, privacy, respectful telemetry data coming back from the product is absolutely essential.

A lot of people think that they don't have time for it early, and then you end up paying a heck of a lot more for it later. Like, startups everywhere, embed your telemetry early and you'll thank yourself later.

The product telemetry is a classic area for underinvestment or late investment when it's way more expensive, and it's so much easier now and it's so incredibly cool when it's working.

You don't even have to instrument everything, like figure out what the key questions are. "What are your key market hypotheses?" Instrument it there at least and get a running start, it's really powerful and it short circuits a lot of painful conversations if you can just have the data.

So, that's a really key one. We use Net Promoter Score, I know there's a bunch of different philosophies out there, but Net Promoter Score will give you trailing indicators of sentiment.

To me, having whether it's Qualtrics or NPS or whatever you are using, to me having customer Sat scoring that's outside of support is important.

Grant: So you're popping that up in the product, or what? How are you doing this?

Dave: E-mail.

Grant: E-mail, OK.

Dave: Yeah. Do it over email at six month intervals. You have to make it simple, so we've learned a few things about it. You've got to make it simple.

We've tried longer form ones where you ask a whole bunch of questions and we didn't end up learning that much, and we drove down response rates.

Grant: Just ask the standard NPS questions?

Dave: Ask the standard questions, an open ended or maybe one or two open ended, and done and dusted. You want as much response rates as you can, particularly if you're navigating a product line transition like we have been.

Grant: Are you reaching out to both ends of the spectrum on if they score low or if they score really high? To understand why for both?

Dave: Particularly the low, like most companies we do a better job than most humans. We go after the problems rather than the massive successes, so the CSM team and the support team reached out to the people who were clearly in pain.

I have a good stiff drink before I read all of those myself, because it just hurts when you after read through the painful stuff. Of course you see the good stuff and your eyes skip over it, it's like punitive, it's like "There's no problem to solve there." You don't congratulate yourself, it's like straight to the pain.

Grant: Yeah. That's because as product people that's what you care about . You're like, "Tell me what's the opportunity to make something better?"

Dave:

That's what you learn over time, that you've got to celebrate successes as well a little bit and pat yourself on the back.

Otherwise you hurt your own attitude. But the telemetry, the Net Promoter Score data, and then in the meantime you've got to be tight with your support team.

I'm a huge advocate of being tight with the support team, which means you've got to be in their data with them. I just spent four months working on our incident management, incident response processes, where we made sure we were clearly aligned on what a sev one, sev two, sev three or sev four is, what the SLAs were around it.

Working through the automation we use a combination of Jira with Slack with a service called Blameless, which wraps an instant management framework around Slack with a combination of status page IO and so on. So, that's just--

Grant: All the tooling, all chained together. I like it.

Dave: Yeah, the first time we used Blameless we were in the middle of a sev one incident and I was smiling ear to ear, I was like "This is amazing. This is the best run incident I've ever seen."It was completely--

I'd accepted the fact that there was pain and it wasn't good, but it was when you see that stuff working it's glorious.

Grant: It gives you more control.

Dave: Absolutely. At transparency the team can work together and the dialogue that would have happened before, over jamming people onto a Zoom call or over email is now happening in real time with real collaboration, with structure around it so people know where to play.

It was really awesome to see. Long story short, from a quant side, the things that I look at are the telemetry and the support data. I like to go through it monthly with the team, with the support team and with my leaders.

The Net Promoter Score every six months, and then of course like you monitor that retention rate. But as a product leader like you usually get beat over the head with retention rate.

You don't have to go out and ask for it, you're going to know. It's a trailing indicator. To me, NPS gives you more early signaling around potential retention problems--

Grant: Versus churn, yeah.

Dave: Versus actual churn. If you're waiting at that point you've waited way too long. So, retention rate is interesting. Win rate is interesting too, like "How are you doing in those POCs as quant data?"

But there's so many factors in that, it's in and of itself any one of these can skew. The total quant picture of those things is really powerful. On the qualitative side, there's no substitute for a customer advisory board.

I'm on my fourth company where I've brought in a customer advisory board, we just did it a couple weeks ago in Austin, and it's--

Grant: How many companies do you put on that?

Dave: I like about 20, like 15 to 20. Any more than that it gets a little too big.

Grant: Who do you focus on, what's the--?

Dave: Yeah. There's a sweet spot. You don't want the highest person in the organization, because they don't know what's going on. At the lower levels where you actually can influence the product, the shape of the product.

You don't want the person who's actually living and breathing inside the product every day, because they don't have the broader perspective.

You want the person in the middle of the organization who's oftentimes going to recommend the purchase rather than approve it, and where they have some familiarity with the product and the problem set, but they're not living and breathing it every day. They can see that forest through the trees.

Grant: How do you structure that organization? Like that group, do you say "Every six months we meet, we pay for you to come." How does it all work?

Dave: You pay for as much as you can and as much as you need to. Typically customer handles long travel, we handle hotel and expenses while they're there and everything else.

What you do is you meet in person, typically you do the big event once a year for about two days, that's the classic approach. Opening dinner, full day, and then a half day on the end.

It has to be mainly about dialogue, and the customers want to learn from each other, they want to talk. Your job is to listen and ask the right questions, and to be a good host. It's not to present a ton of content.

It is incredibly insightful, just massively insightful. Assign people to take notes, because you will have such a foundation of learning during that period of time that you can pull from through the rest of the year.

Also what you're doing is you're finding customer sponsors for features and things for later, it's like "I know Suzy at Acme was interested in this feature. We really need a customer sponsor for this feature, and we're going to go back and see if she'd be interested in being one of the early access customers for this."

We use feature flagging just like everybody else to run an early access program. So, the cab is incredibly useful. Now what you want to do, and I've had varying degrees of success of this, I've never hit it out of the park, is turn that into a flowing dialogue over the course of the year.

So last year we brought in Slack. We couldn't really keep the dialogue going as much as we wanted. The thing that did work is we harnessed industry events, which for us like the RSA Conference, we have a get together there for the people who have come to the event.

They're already going to be there, we can host the lunch and dinner at cocktail hour, bring everybody back together at least for a touch in, a touch base.

Similar thing at Black Hat in Vegas, and we have our own customer event too, so we try and not steal a bunch of their time after that outside of the one big meeting a year.

But we try and grab them at different points in the year where they might naturally be there anyways, and pull them back in for a low key event. Maybe a conversation, a focused conversation or two, but those are just to keep people talking and keep things going.

We might bring them shirts or something at the time to create a little more identity for the program. This year we're going to focus pretty hard on pulling more into our Slack channel and using that more.

The other thing we do, and this is really essential for the team, but we try and take customers from the cab and elsewhere to come in and talk to the team once a month. We call it "The voice of the customer series."

W e basically channel our inner Oprah and just do this total talk show format, not unlike this. We let them present out how they use the product to the team.

A nd this not only obviously builds empathy with the organization, with the building the product later, they can say "Right. I remember Joe did this from Acme Corp."

But also what it does is it becomes a really cool way of providing training to new people. It's like "You don't know the customer? Go listen to these three videos of actual customers talking to us about how they use the product."

Of course we do Q and A too, where the team can ask the customer about things, and so forth. It very implicitly communicates to both the customer and our employees that we care, we listen, and that's essential in burning in that customer persona into people's heads.

So, that's some of the qualitative stuff we do as well.

Grant: Yeah. I love both of those. Those are great, and I feel like no one talks about how to do that or what to do in order to create that qualitative feedback. Those are great examples about how to really gather and really execute on that.

I love it. We should do a blog post about both those things at some point.

Dave: Yeah, for sure.

Grant: There's a ton of people that would get a lot of value from understanding how to put that together.

Dave: It was one of those things where it felt like the right thing to do, and then afterwards we realized the angle with employee orientation and everything else. The big one is feature requests that everybody--

That's the big thing for product leaders in particular, is getting the feature requests right. Not over rotating on it, but being thoughtful about it, synthesizing it and so forth.

That's the third and probably most obvious non-synthetic product leader manufactured source of input. But it's also the most obviously tainted at times, because there can be so many circumstances around it.

Whether it's a negotiation ploy, whether it's a real need, but the need is actually being miscommunicated through the game of telephone from sales or channel partner all the way through.

There's actually a bigger business need behind it, or a customer needing to be satisfied in another way.

Feature requests are obvious sources of qualitative input, but there's so much bias and potential bias in them that they have to be really careful with how you handle feature requests.

Grant: When you look at your list of feature requests, are you scoring those on several different criteria for value that they bring to Tenable as well as to your customer? How do you think about the--

Because it's not just like, "OK. That's a good feature, let's build it." There's just probably some additional framework you put around it, is that right?

Dave: I've never seen a waiting framework with features that I felt performed terribly well. I'm sure somebody has come up with them and it works for them.

But to me the process itself of getting all the data in one place and allowing folks to self-service so they're asking good questions and being transparent as a product organization.

That's really important. But after that, to me, there's no substitute from having a product manager working with the sales engineers or working with support and having that team work together to prioritize it.

Ultimately it's the product manager's call, but at the end of the day I'm not a believer in having a magic formula for some of this stuff. There's things like, there's strategic implications, there's business partner things.

There's a whole myriad of factors that go into it. Architectural considerations, and so forth. There's no magic formula that I've ever seen that works.

I've seen people try and pull it off, but I'm not convinced it helped them get any further along than having a smart product manager who is open minded and working thoughtfully with others.

Grant: Yeah. At Replicated, we use a slight framework that Mark and I just started to do naturally. It's funny because I was talking to Andrew from Signal Sciences, we had him on the show before, just randomly on a walk one day he mentioned their framework was similar to ours.

Basically what we do is list all of these features and then we score them in three different categories. One is acquire, convert or retain.

That's just like, "Do we think that feature will strategically help us acquire new customers, convert potential customers, or retain existing customers?" Then score it on a level of effort, which is a fairly obvious thing to do.

That just helps us give a frame of the value that we're going to get by building these features, because obviously there's a million other things you're talking about.

Weighting in the size of the customer, the strategic partnership, what number of customers have asked for it, how big are they? There's all those pieces, because it's--

Especially early on in the product you generally need one of those things more than the other. Maybe you really need bigger top of funnel instead of building more stuff, or acquiring new customers is important.

Or maybe your funnel is breaking, and you need to convert more. Or maybe you're churning too much. So at any point you can focus on some of those features.

Dave: Yeah. That's for sure. You have to know the category of thing that you're adding in.

Grant: Yeah.

Dave: Where I have seen real problems and I'm not convinced there is value is putting in scoring and weightings on scoring and so forth.

Knowing the type of thing you're building and the why, and why relative to something else, is super important.

At the point where you take all those quant inputs before, and weigh them against the qualitative stuff, and you try and come up with the crazy quadratic equation that spits out the answer at the end. That is where I have heartburn. I also--

Grant: This reminds me of a prior conversation you and I had where you mentioned a spreadsheet that somebody had, a product leader had before you, that they used to present to the CFO what features they were going to build.

Dave: Yeah.

Grant: It was this huge complicated thing and the only reason that spreadsheet, that super complicated algorithm spreadsheet is valuable, is because the CFO like loves it.

So you just make it, you weight it however you want to have the features come out to whatever you think. Then it's like, now you can explain it in CFO language.

Dave: It's total kabuki theater.

Grant: Exactly.

Dave: Yeah. It's like, "Let me manufacture enough science behind this in order to validate what my intuition told me five pivot tables ago."

Grant: But it's funny, because sometimes that's what you need to communicate it in the organization to get people to buy in and be like, "Yeah. This is really well thought out."

If you just tell people "I know what we need to build," they'll be like "How?" You're like, "I talked to customers, I look at all the--"

But then you put a spreadsheet in front of them and they're like "Wow. He's got a system."

Dave: Going back to it, it's super important to have the data, but there has to be real deal synthesis of the data. Qual, quant, business direction and other things that defies analysis inside a spreadsheet.

That's what you pay good product managers for, and it's a delicate balance. The analogy I've used is "There's PMs who are short order kitchen chefs, they'll give you whatever you want. The customer orders it up."

That's clearly a terrible model. You end up with awful products that are like Uncle Willie's one man band. It does everything, but nothing at the same time particularly well. Then on the other side, you have the Omakase model.

"You're going to get whatever we give you and you're going to damn well like it like it," clearly doesn't work with the enterprise either.

The way that I've seen this work best is, for me, what we try and do is we have a plan. We know where we want to take the product that's grounded in a big customer problem that's in a worthwhile market, that we feel passionate about.

Then when we know what we want to build, let's say it's role based access control, we have a set of customers that we go to and we test our hypotheses with them.

We don't go to them and tell them to paint on a canvas Bob Ross style. "Paint a few trees. Let's see what happens." But you go in and say "OK, here's what we're thinking. Are we-- Does one of these resonate? Are we off here? What sequencing would you give these, which one's more important?"

And so forth. The feedback is as good as it is directed, the conversation is as good as it is thoughtful, unstructured conversations where you're Bob Ross-ing it does nothing to inspire the confidence of the customer.

It simply means you haven't done your homework beforehand.

Grant: Yeah, you didn't do any preparation and you don't know what you're talking about.

Dave: So, "We'd like you to tell us what to build." That's the short order kitchen model that clearly doesn't work.

Grant: Even when someone tells you, "Here's this feature that we want." If you can come back and say "Great. We've thought about that a little bit in the past, and here's the challenges we came up with."

Or "Here's why we didn't do it, here's what we're thinking why we'll do it in the future," people do appreciate and they start to respect your perspective and your ability to be the partner that's going to deliver this core technology for them for a long time.

Dave: Yeah. A skillful product person in that situation can be very transparent. You can be very transparent and say, "Yep. Totally hear you. Here's why we aren't focused on that right now. This is what it's feeling like. Like, fill me in. Where did I go wrong? Where am I off in it?"

It requires a lot of confidence and a bit of humility to do that, but it's super important and if there's a mistake that I've seen consistently it's when product organizations try to be too opaque.

When out of their own fear or lack of self-confidence they default to opacity, when they probably should just be more open with their decision making is probably very rational. The customer, if they understood it, would probably feel a lot better about that.

Grant: Yeah, that's a great point.

It's like communicating. We put out these release notes and things when you announce these features, and you'll talk about what it is, but it's important to mention why.

Particularly to your more strategic customers, if there's things you didn't deliver for them yet, really showing why you're doing it is a great point.

Dave: It's easy. We had a feature the other day, it's an amazing feature and I'm super excited about that we'll be working on next year in our agent tech.

We explain it and there was all these implied pain points and things that we knew intuitively on the product side that we wanted out of it, but no one was saying what problem it solved for the customer, and you could see it.

It seems like a small thing at the beginning, "Of course it does X Y and Z."

But I'll guarantee you if we kept with that rooted in the technology and what problems we wanted to solve with it, instead of voicing it initially in the voice of the customer and what problem we're trying to solve, the empathy would be lost.

We'd be aimless, and we'd mis-deliver. It's really important to keep that grounding in "What's the problem?" Ideally in the customer's voice.

Grant: That's a great point. I didn't think those different tactics to keep that voice really important in the cadence at which you do that also sounds like an important piece of it.

Dave: Yeah, reinforcement.

Grant: So, one other piece I want to touch on that's really interesting and I don't know that we'll have another guest that's done this right recently, is Tenable recently IPO'd. Congratulations, first of all.

Dave: Thank you.

Grant: But from a product perspective, what does that-- Does that change anything when you are leading up to an IPO? What are you doing that's different? How does that has an impact how you think about product as a product leader?

Dave: Yeah. I just read the product leader's playbook for an IPO.

Grant: Right, exactly.

Dave: It's a best seller. Having been a product leader in a public company at Norton, I found myself in investor meetings.

I had just an incredible boss, a woman leading the organization, Janice Chaffin. She was kind enough to invite me into the investor meetings and really expose a lot of those questions to me and so forth, so that was--

Grant: With the institutional investors--?

Dave: Right.

Grant: That are like a Fidelity or some large fund that buys public stocks and holds them for a long time.

Dave: Absolutely, yeah. So the--

Grant: I don't think most people even know that exists, that there's this relationship and you go pitch all these investor analyst types and talk about what you're doing, and they're getting this insight into your business. That's a--

Dave: Fascinating.

Grant: As a public market's investor, as an individual, you're not doing that. You're not getting that insight.

Dave: Right.

Grant: But that's part of what happens with a publicly traded company, is you end up with these long term partners.

Dave: Yeah, a lot of product in particular is visualizing a future state and working your way back.

So that was how I approached it, and I looked at and said "First off, is the strategy crisp and clear? Can I say it to an investor who has no grounding in the space, and is it going to resonate?"

That was the first work that was done, was on the strategy itself, and really winnowing it down to the core. Which for us is the category transformation play, called "Cyber exposure."

Taking vuln management and moving it into a next gen level, which we call "Cyber exposure." That was the first step, and then winnowing everything off from it, like slicing it down to where that was really the only thing we were doing.

That clarity of message was really important first, and then secondly we had to make sure there was enough total addressable market in it so investors would look at it and say "I get it."

" There's enough proof points, you have enough product proof points to validate that strategy, and those opportunities represent a big enough market today and in the future to where I can see the company continuing to grow and turn into a huge company in the future."

Laying down enough TAM, total addressable market, was super important too in getting the proof points behind it, so that it wasn't just pixie dust. Like , you have to deliver against it and it has to be believable.

Example here is we introduced container security to have a real proof point around DevSecOps and our thesis we had on ephemeral assets and on cloud and cloud technologies.

We took technology we had, passive scanning, and basically tilted it hard to its operational technology which is increasingly targeted by attackers and increasingly connected to IT.

Sinkhole the OT/IT collision, where these formerly air gap networks that had PLC's and industrial control system, everything else, are now increasingly rolling right into the IT assets and they're all increasingly being owned by the CIO and the CISO to create one picture.

We had to introduce an industrial security product in partnership with Siemens, instant validation from one of the titans of that space.

All of a sudden "You've got real total addressable market that spans something much bigger, and people start to have valid proof points behind your market thesis of 'The world's changing and we're going to help change it.'"

Then it was introducing a product called Lumen, announcing a product early this year which changes the narrative from one that's been very technical oriented, and a lot about vulnerabilities and threats to one that is very business oriented.

A conversation about benchmarking, and a conversation about not how you're doing in complete terms of managing 10,000 vulnerabilities that are CVSS rated 7.5 or above.

But hey, you're 20% more exposed than other companies in the retail industry, and you're assessing-- The key problem there is you're assessing things 30% slower. Here's the three things you need to do in order to improve that.

So, those were some of the key things we had to do initially, and then came the really hard part. That was actually the easy part, the hard part was cleaning up the portfolio.

I tried to pull forward every painful product thing I could think of into a pre-IPO state, and do it as fast as I could, responsibly, so I could let things settle before the IPO came out.

The thesis behind that was "I don't want to be making changes that are big to the portfolio that I'd have to explain to an investor." It's going to put my CFO and my CEO in a bad spot, or at least an uncomfortable one where they have to explain something detailed and technical.

Also, I don't want the risk of unintended reverberations of that change flowing through a post IPO state or a public company. I'd rather deal with it when we're private when it's more forgiving.

So, those were really the big things, were to make sure your strategy is tight. You could explain it to everyone. Have proof points and enough TAM, so you have green horizons and blue skies for as long as you can see.

Then, oh my God, do everything you can think that might be painful as fast as you can, and let it settle so that it's clear sailing afterwards.

Grant: Let's dive into that piece, that's really intriguing. It feels like a very specific thing you would be doing pre-IPO. It's trying to get your product portfolio, and it's like you need to rip off all the band aids or something first before you're out there with-- In public with open source.

So, talk about what did you do? How did you-- What was the framework you used and how did you analyze that?

Dave: You do it within the context of the strategy, and the business problem you're trying to solve.

After doing the strategy, and you look at it and you say "OK. This other stuff may be sex, but we're not aiming for sex appeal if we're a Ford F-150, damn it we're going to be the best Ford F-150 we're going to be."

Those things aren't part of our business anymore. So for us, one of the things was a hardware appliance. There was a product that it also--

Grant: You deprecated that?

Dave: Deprecated, yes. Stopped selling.

Grant: You stopped selling it, it was probably selling at some a couple million a year, maybe more.

Dave: Barely.

Grant: OK. But you're saying you wanted to cut that before you IPO'd, because if your end-of-lifing a product that's been contributing any amount like that in your public, maybe it's a problem for the CFO.

Dave: Yeah. It's something you have to explain. There's always going to be things that come up that you have to explain, but it's an order of magnitude.

You want it to be things that happen that are surprises, as opposed to synthetic surprises. Ones that you manufacture for the markets.

We'll deal with the naturally occurring ones, that's going to happen. What you don't want is the synthetic ones that you manufactured simply because you didn't have the foresight to solve these problems before you jumped on the grand stage.

Grant: You know that you're going to do that at some point, so you might as well get rid of it now before you're like-- Before it's a thing and before it's hard to do. It makes total sense.

Dave: Yeah. We did all sorts of things like that. We brought out new pricing and licensing for Tenable IO, launched Tenable IO and started to learn how to sell cloud and really service the enterprise there.

We made changes to the Nexus product line, we deprecated the scanning API, which created portfolio tension. We had several steps in the Nexus portfolio that we took out at that time too.

Grant: Let's just pause right there. Because I knew we talked about this before the show a little bit, but the deprecating of that API was a really interesting piece.

So, you took an API that was inside of your core product that-- Just tell the story real quick around that.

Dave: Yes. Shortly after I arrived I sat down with the then-enterprise head of sales, and he basically told me very directly "We're competing against ourselves and we're enabling our competition."

I was in consulting mode at this time, and I was taking notes furiously as he spoke, like "Tell me more about that. Explain."

He said, "Our customers are big customers today, oftentimes we'll go in and we'll try and sell our enterprise product and they'll say 'I've already got Nexus. I've already got-- I just have it hooked up. I'm using the scanning API, and I use the API and I've got it hooked in. I don't need to talk to you, and you're trying to sell me something that's hundreds of thousands of dollars. Candidly, I can pay you $20 or $30 thousand dollars. I could get everything I need myself.'" There is other scenarios--

Grant: You can buy this entry level core engine, but it doesn't have all the management functionality. Leverage the API and plug it into something else--

Dave: That's right.

Grant: That's doing the job for that?

Dave: That's right. They create their own harnesses around it, or--

Grant: It's almost as if you had this loss leader, which was your entry level product.

Dave: Right.

Grant: People were just buying up the loss leader, rather than also buying it-- If we think about the grocery example, your milk is a loss leader and then you're selling them up on all the other stuff.

Dave: A little bit. We had no problem with people-- We loved our Nexus customers, and still do. The problem was it was being used in a way that wasn't intended.

Grant: Someone coming in and buying like 500 gallons of milk.

Dave: Right.

Grant: You're losing much money.

Dave: Yeah. We weren't so much losing money on it as we were, as these customers were duplicating things we'd already built.

Grant: Right.

Dave: Spending precious time and energy building stuff that candidly we thought we could do better, and spending time that they could be spending running the business.

Grant: So, they're adding these things around your product themselves.

Dave: Right.

Grant: They're iterating and spinning their wheels, and realistically they're paying you $30,000 a year and they're spending a couple hundred thousand dollars a year on internal development and support at these--

Dave: Which we were already doing.

Grant: Repeating the effort.

Dave: Repeating the effort, and that's inefficient. Clearly we'd like to do that for them. There is instances we found afterwards where customers didn't even know we had other things available, because Nexus is such a strong brand.

I had two customers up in the Pacific Northwest recently, I visited them and they said "Oh, thank God you did this. We were doing all this work and we didn't even know you had that."

Now that's not always the reaction, there's people who have loved it a lot less. But having said that, the bigger issue we had is we had competitors, and in particular new competitors who weren't investing anything in the scan engine or anything in the technology itself.

They were basically saying, "Just pay Tenable for Nexus and we'll do all the rest of it," patting us on the head. That was a market that candidly we felt like we should own, and enabling the competition in that scenario wasn't a great idea.

Now, are competitors going to use our APIs? Absolutely, and that's OK. We're fine with that. But what we didn't want, we had an all you can eat licensee model with Nexus, and if they're going to pay they need to pay us a fair price for the number of assets.

Not collecting together a bunch of engines and then paying us very little for that. So, no problem if we--

There's times when we service customers together with competitors, and that needs to be OK. If the customer hires us to solve the problem we're flattered they did that, but it has to be fair for everyone. It has to be a fair price.

Grant: Yeah. That's so interesting. You see some of these examples that are public, like LinkedIn ended their API awhile back and some other companies did the same thing, generally because competitors are pooling all this data out.

So it's hard, because we talk about an API as such an important piece of a product, especially in a modern context.

You need your channel partners to build on top of it, you need other stuff to happen, but there needs to be some control over what people have access to so that you can offer your additional products and keep growing and have that product assortment.

It's a really interesting problem to be faced with, and so you addressed it before the IPO--

Dave: That's right.

Grant: In order to make it a non-problem.

Dave: Yeah. In an attempt to rectify, and also-- Look, there's customers who afterwards were pretty unhappy with that, and some of them went to a competitor. But they paid the competitor a fair price. I'm OK with that.

Grant: Sure.

Dave: At the end of the day when we were allowing people to basically value our category so small because we had allowed for this all you can eat model with a really powerful engine, allowing them to use in a way that wasn't intended--

It wasn't good for the customer and it wasn't good for the category.

Grant: Unsustainable.

Dave: Unsustainable, right. We happen to think that security hygiene and knowing all the assets that you have, knowing their vulnerabilities and managing your exposure, is a huge important problem.

There's an element of this, and I don't want to make it sound too grandiose, but there's an element of this which is respecting yourself and respecting your category, and making sure that the pricing is fair for everyone.

I actually looked at those scenarios where the customer said "I'm really bothered by this, I'm going to go to these other guys."

We looked at that and clearly we'd prefer their business, but at the end of day there was a part of me which said "At least the category is winning."

Grant: Sure.

Dave: Everyone in the category is responsible, that it's healthy.

Grant: Did you announce it pretty far ahead of time, or was there someone to grandfather it, or--?

Dave: We did, yeah. We provided a year of advance notice, and there's plenty of opportunities to extend, and things like that.

Grant: It's not like you just turned it off and said it doesn't exist, which is what LinkedIn did. Basically you gave everyone a lot of notice, and I think that's a really important piece.

Customers, enterprise customers particularly, expect that you can't change things on them that fast. So, you took this change management process.

"We're going to do this. It's going to be in a year. Here's why we have to do it." And if some of them were upset, some of them were upset. That's part of how it works.

Dave: Yeah.

Grant: There's this concept in site reliability engineering called "Error budgets," which are basically how many errors per minute, month, year, can a product have?

Generally people-- This is like the 99.99% SLA stuff, and that concept actually applies beyond the number of website requests or API requests, but it applies here.

Which is you're rolling out a new change, it's some pricing, you should expect some number of people to be upset. If it's 5 %, great, you're within your error budget.

If it's 50%, you've exceeded your error budget and you need to adjust.

Dave: Yeah.

Grant: You should approach marketing, products, sales, with this mindset that change inevitably causes some friction and you're going to get some pushback.

Dave: Yeah.

The only time when you get a 100% happiness is when you are lying to everyone. Because there's an element of this where if you show me the product leader where everyone is delighted with them, they are a terrible product leader.

You're going to make controversial decisions, and you're going to have to do things that people don't like. What you hope is that they look at it and say that it's fair and in the best interest of the business.

Like I said before, in the best interests of the category too. Everybody who plays in a category should feel an obligation to make it healthy as well and respect it.

Grant: Yeah, it's really interesting, that perspective paired with open source is different too.

Because there's this whole other side of open source, and everything should be really open source, and you see people releasing more and more of the proprietary components of their products into the open source world over time.

It's constantly in this chasing new features that make things-- The enterprise version enterprise-y. Obviously there's a lot of value in open source, RedHat just had a recent acquisition of massive size, but it also can in ways cause this race to the bottom.

Or, the counter to that is you have to race to add in new innovation constantly, as you pool features from proprietary into open source. The same thing is true for any category.

It's like, if you have one of your competitors starts a race to the bottom, you have to be constantly innovating with the next level of features and functionality, because things that were three or four years old, those features are not commoditized.

So, you have to be constantly ahead.

Dave: For me, both at Norton and at Tenable, and I even felt this way at CrowdStrike and to a lesser extent at Foundstone.

But as my thinking's evolved as a product leader, my scenario planning and my horizon planning always ends up with me looking at the lowest part of my portfolio and saying "If that became completely commoditized and free, what would I be doing now in order to replace it?"

If you had checked your game plan against fierce commoditization on the low end, even if you're wrong, you're happy. If you're right, you're prepared. You can't get screwed that way.

But if you're prudent, you assume that at some point the low end of your portfolio is going to be subsumed into something else, and hopefully you get the chance to cannibalize it.

Get the chance to make it maybe if it's no longer a monetization play, it's a customer acquisition play, or it's a brand play and everything else. It spreads you out to new markets and so on.

Grant: So, you're thinking about that ahead of time. That's something you planned for and evaluate.

Dave: Yeah. I just assume that at some point the low end of the portfolio is going to evaporate. It's funny when as long as your focus is on building customer lifetime value, for me, I don't care.

This is one of my quant measurements that I look at to gauge overall success, is I try not to get married to any one part of the portfolio, but I want to measure the overall success of the portfolio by customer lifetime value or lifetime-- We'll use CLV.

I want to measure by CLV, and as long as I'm building CLV and CLV is growing, my MPS is good and retention rates stay healthy, I honestly don't care what part of the portfolio falls off at some point.

If we have a cross-sell that doesn't work, it doesn't work and that's OK. That's going to happen. Think about how dynamic the market is, there's going to be times when things just don't make sense anymore, and maybe you roll it into the product and make it free at that point.

It just becomes a differentiating feature, and that's OK. But as long as you're mindful of CLV and you don't become too married to any one product, if you look at each one as a really drawn out market thesis and the embodiment of a market thesis when it no longer holds, that doesn't mean you have to kill it.

It doesn't mean, like in the Norton example I gave before where you are killing it five years in advance. It's OK, watch your telemetry.

If nobody is using the damn thing shoot Old Yeller. Put a bullet in it. But having said that, your thesis changed. That's OK.

Watch your CLV and it really doesn't matter if one product in the portfolio isn't performing the way it used to. Is the portfolio performing the way you expect it to?

Grant: That's great. Having that perspective-- That's a signal of your experience that you've done this for so long, and you have that full portfolio view.

You're thinking not just about product adoption, you're thinking about portfolio lifecycle.

That's a next level above product management, which is portfolio lifecycle, which is why you're Chief Product Officer. It makes sense.

Dave: Yeah. It was really interesting to watch Norton, the AV industry and consumer AV became incredibly crowded. Cost of customer acquisition became very high, and all of a sudden you look at it and you're like-- Retention rates were pretty much maxed out. It's like, so what do you do?

We had good and better, but we didn't have best. We introduced Norton 360. Those decisions were made without me there, but I watched mix shift in the portfolio and ultimately cross-sell, a new cross-sell, like drive continued growth on a big revenue base from 1.8 million up to like 2.1 billion.

Why I left is purely through mix shift in the portfolio, and incremental cross-sell.

Grant: Wait, "Mix shift?"

Dave: Mix shift, right. Mix shift from good to better, and from better to best. In our instance it was Norton Internet Security up to Norton 360.

Grant: So, that's just consumers or people upgrading along the way.

Dave: Yeah, right.

Grant: Cool.

Dave: Right. You have something more to offer them when they come in and renew. "There's this thing over here," and some of the people would need the functionality, and some--

There's a segment of the populace who just want the best thing.

Grant: Yeah, true. It's security, you need the best.

Dave: That's right.

Grant: That's great. One more thing I'd love to just touch on is how Tenable is a big organization now. 1,100 people, you said?

Dave: Yeah. It's around there.

Grant: Yeah. That's big. So, how do you think about communicating within your organization, which is 250 people, on product and engineering into these other orgs?

How do you make sure that people understand the product, and the product strategy, and how do you drive that?

Dave: It's one of the biggest challenges. Particularly not only an organization that's large, but one that's growing, that's adding people aggressively.

Grant: And remote.

Dave: And remote, and increasingly international too. It's one of the biggest challenges we have. It starts out with--

One of the first things I did when I came in, there's a couple of things that I did immediately. One is, I had to request access to certain things in Confluence. They're like, "We'll give you access."

And I said, "No you don't understand. Open up the whole thing and we're going to start documenting everything in one place. Confluence may be good, bad, or indifferent. But it's what we have, damn it, we're going to document everything there."

Grant: Sure.

Dave: So getting religion about doing everything in one place, and having it all in that place, and documenting everything is really important.

Then having it open to everyone. All of a sudden no one had to manage permissions around Confluence anymore. It makes things really easy.

Grant: That's an example of information that's often not incredibly sensitive from a-- It's not like your customer's data.

Dave: Right.

Grant: This is your--

Dave: Your plans.

Grant: Yeah, it's your plans. You should share that pretty broadly within the organization and let everybody see it. That makes sense.

Dave: Then most people go into it, are they really going to avail themselves of it? Probably not. But it's the point, that you're going to be transparent.

If you're going to go through a massive portfolio transition, you can't give the organization or customers perfection, what you can give them is transparency. You owe it to them.

That's incredibly important. So, that's a big piece of it, is just leaving the door to the factory and to the lab open.

Grant: Do you give everyone in the organization a Confluence account?

Dave: They have access to it.

Grant: They have access to it?

Dave: Yeah. So, that's a big piece of it. Weekly road maps, it's not everything we're doing, but a tickle. "Here's a little narrative around what's happening in the important areas."

Grant: You're sharing that with the whole company?

Dave: In Slack.

Grant: In Slack, OK.

Dave: We have a product announcements channel in Slack, we pump it out there. We used to do it through e-mail, we moved it to Slack.

Grant: You're so modern.

Dave: Yeah. We had HipChat, we moved to Slack--

Grant: Like every organization in the world.

Dave: Yeah, like every other organization. The thing that I'll say that had an immediate impact is we had a video conferencing system that was a bit dated.

I brought in Zoom and immediately things got a lot easier, and we deprecated hangouts which turned my laptop into molten lava.

Grant: Yeah. Core Audio D never works.

Dave: Yeah. Those changes, getting the right tools was important. Opening up the tools was incredibly important, and standardization was big.

We do office hours every week on a topic. So, one of my lieutenants does an awesome job where topically we bring in a speaker and we do office hours with about 20 minutes of content.

After that it's all dialogue, Q&A. I do-- It ended up being biannual, about roadmaps every four months.

In the meantime we do an Ask Me Almost Anything, every month where I take questions, I get pelted with questions over Zoom.

Grant: But that's safe for work.

Dave: Yeah.

Grant: Can't have an AMA, got to have an AMAA.

Dave: AMAA, yeah. They've turned out to actually be a lot of fun. It's funny, because we have no one from headquarters on it. It's my product leader who's out in New York, another guy in Phoenix, and it's myself.

They always ask us about the new headquarters or building in Baltimore, in Columbia, Maryland. We all look at each other like, "Next question." But anyways, it's really fun. People ask super insightful things. We end up having a really good time on it.

Getting the feature request process right. We've been working hard on that. I think we've finally got to a good approach there, and we do roundtables now. Executive roundtables with folks.

I used through roundtables with all my team, I'm down a few people on the engineering side so I cut out my own roundtables which hurts.

But I usually try and sit down with everybody on my team in small group settings, about 10 people once a quarter, not happening right now but I've learned so much from that.

I've found great managers who would have went on in anonymity unless I sat down with their team and learned about what they were doing and experienced the great energy that the team had.

Those are all things, and I'll tell you one of the big ones that we started doing last year, which is paid dividends. We get the whole product team together once a quarter and we call it "Release planning," but it's a lot more than that.

We do training there, but that's where a lot of trust is built on the team, where we get together and work things out in front of a whiteboard together.

I continually encourage use of the travel budget. 80% of the cost of any product organization is the people themselves, unless people do really silly things which I've never seen.

You're not going to break your budget on travel, it's just not going to happen with teams getting together to work together.

No matter how good your remote playbook is, it's invaluable to get together and work together for three or four days. It's absolutely essential.

Grant: It creates a level of trust that you don't get if you're always remote.

Dave: Absolutely.

Grant: You have to be in person with people here and again to create that human connection and let them know you're real, and then that's what keeps it from being like you're just a face on a screen or a snarky Slack message.

Dave: Totally. Those are some of the things we use across the org. We do town halls as well, on the product side, and of course we record all of these and post to the internet.

But we do product team town halls where we go through all sorts of stuff. The last one we just did was Jira clean up, getting our Jira projects right for better automated reporting and predictability, incident management feature request processes.

And we're moving towards a deep work session. Partially which you influenced, with the deep workbook like a distraction free Thursday.

Grant: It's so good.

Dave: We're going to be testing where we cut back on meetings, provide guidelines for folks to protect their focus deep work time. So, the town halls work pretty well too for covering topical things that aren't going to come up naturally.

Grant: That's cool. Then I know you also, you personally focus some amount of effort on really good storytelling.

Dave: I love storytelling. It's a personal passion of mine, but--

Grant: It's a really important thing for product leaders to be able to tell the story though. It's so important.

Dave: It's funny, I was listening to Tim Ferriss' podcast and Scott Belsky from Adobe was on it, and he made that point. That that narrative, particularly when you're going through a big transition, whether it's a startup or whether you're in the "Messy middle," as he calls it. "The trough of sorrow."

Or when you're going through a huge transition like we have, where it's a product line transition and a portfolio transition, it's super important to be able to tell stories around it so people can make sense of everything that's happening.

We've thrown a lot at them, and bringing in the stories makes it real for people. Everybody can relate to that. The last thing I'll say that I left out of the coms is I go out on the field.

I have to, because the stories are good, but you've got to show up as the product leader sometimes and I have to build trust with the sales org too.

I'm putting them through a lot of things, I've killed products and I've introduced this crazy new cloud SaaS offering that's uncomfortable at times with new licensing.

You've got to be out in the field and be building empathy and learning from what customers in the field and your field team is saying. That's something that I've really added in the past three, four years.

I've learned a ton from it, and those become stories that I bring back in my town halls and into the product organization. It all ties back into that storytelling too.

Grant: Yeah, and just a little bit about how you personally have tried to improve your storytelling ability, and some of the things you've mentioned in the past. Some of your influences around storytelling, can you talk a little about those?

Dave: Yeah. There was a great training I did during my time at Symantec, and one of the key things that I learned from that is to engage people's senses, and that's one of the things that really pulls people in. It makes it feel real, it makes it feel authentic.

Whether it's saying how something tastes or how something feels or how something smells, or what it looks like, the colors. A lot of people spare the details in the story, but that's what makes them real. That's what makes them engaging and so forth.

I practice a lot on my six-year-old son, so we get a lot-- I get a lot of practice storytelling there, and I find that works really well.

Also, changing your voice intonation even in a business setting, is incredibly important. Whether it's simulating the voice of God by covering a microphone, and there's some speakers that also are really impressive to me for their use of whitespace, of pauses.

Jack Hornfelt who we were talking about beforehand, an amazing Buddhist teacher. If you listen to him speak he's got an incredibly soothing voice, as you would imagine, but he's not afraid to pause and let a point land and settle and make you hungry for the next words.

That white space is incredibly important too. People need to think and digest and so forth, so that tactic as I've become a more confident presenter, not being afraid to let something land and let a little uncomfortable silence come in, and so on.

Also to know when to bring in somebody else's voice, and to let the audience take a breath and hear somebody else's voice come in. It's super important.

I'll use that with kids too, like I'll only talk for a few minutes if I'm telling a story to my son and his friend, and then I'll ask them what-- "All right, the adventures are going off on a big trip. What did they pack for lunch?"

It's immaterial to the story, but they had to think and re-engage. Asking questions of the audience and pulling it back in and making them a part of the story is really important too.

Grant: That's cool. I love that. So, one last thing we try to do in these shows is just give our guests a chance to quickly pitch what their company does.

Partially because it's just helpful to hear how other people describe their business, and when you go into a company what's the two, four, or five minute pitch that you give so that somebody understands "What is Tenable?"

Dave: We're the foundation of a great security program. Hell, we're the foundation of even a mediocre security program.

If you want a protected environment, if you're someone who's ever endeavored to lock down an environment or even provide a minimal level of protection, it starts by knowing what you have--everything that you have.

From your desktop, your laptop, to your service, to your API endpoints, to your containers that are around for 20 seconds, to your industrial control system which is around for 20 years and you can't patch so help you God.

Our first job is bringing all of that in one place, and doing it in a way that's efficient and that's accurate, so you can get that single source of truth so you know what you have.

From there, our job is to intelligently analyze each one of those things for vulnerabilities. For exposure, for ways in which they can be compromised.

Knowing what you have and knowing where you could be breached is the foundation of security.

Like there's nothing more fundamental than that no matter how many times you may hear about Fancy Bear or about what the Chinese are doing, or anything else.

It starts with knowing what you have and knowing where it's vulnerable. The trick on top of that is typically you end up with a huge number of things, and a huge number of vulnerabilities to protect.

The key there, and a long standing problem is prioritization. How do you figure out what to do? What are the few things that truly matter?

That's the piece we've been working on, and bringing that into a narrative that not only technical people can understand and they can get home to dinner on time, because they had five things instead of five thousand. That's a big part of what we're working on now.

Then giving them a way to have a narrative with upper management. Who cares about cyber hygiene now? Who cares about security health?

But they can't get down in the weeds. They need a way of understanding it in terms of analytics, benchmarking, and so on. That's the final missing piece.

We think if we do all of those things well, we help you understand everything, focus in on the things that matter that will prevent a breach, and enable people to talk about security health in a way that's intelligible even to not-so cyber-savvy people.

We think we've got a shot at taking the discipline of security and turning it into something that's as canonical as gap standards for accounting.

So, that's what we're after. We're aiming to really transform this category of vulnerability management into a full discipline of managing cyber exposure in a way that everybody can understand it, and hopefully create this universal standard for understanding security health.

Grant: Dave, that was perfect. Thank you so much for your time, this was incredible and I really do appreciate it.

Dave: Thank you. I had lots of fun.