Ep. #22, Data-Driven Enterprise with Derek Steer of Mode

Grant Miller: All , Derek. Thank you so much for joining us.

Derek Steer: Thank you for having me. It's great to be here.

Grant: Cool. Let's just dive into your background.

Why don't you tell us a little bit about how you got to starting Mode?

Derek: Sure. It goes all the way back to high school, honestly.

I took my first economics class and I had this fantastic teacher.

I grew up in San Francisco, I went to local high school, and there was this great teacher there who was working on the AP econ tests.

Like, producing the tests. He was a producer of the test, so he was a well-known teacher and he was just spectacular and really nudged me in that direction.

When I got to college I studied economics, and then I went to my first job where I wanted to actually apply that understanding of economics that I had learned, so I went to this really niche consulting firm where I did analysis of demand in antitrust cases and big mergers.

Sometimes I worked on behalf of the government, sometimes on behalf of big companies to try to understand whether some big merger or antitrust action or allegation was going to have a negative effect on consumers.

Ironically, that was the hardest math that I ever did.

We were building advanced statistical models to understand the impact of whatever was going to happen on pricing for consumers from there, like any consulting job.

After a couple of years it became rote and I decided I was ready for something new.

I ended up going to Facebook, and one of the folks I really looked up to from that consulting firm left and took a job as an analyst at Facebook on the monetization analytics team.

He said, "Derek. You've got to come over here."

Grant: This is 2007, or something?

Derek: Yeah, this is like 2010 or so.

At the time, just to put things in perspective, Facebook hadn't beaten MySpace and hadn't clearly established itself.

While I was at Facebook, Google+ launched. So that's the timeframe we're talking about here.

Grant: "The Facebook Killer," Google+.

Derek: Google+, yeah, really. But people at Facebook took it very seriously.

I went there as a contractor, actually, so I had this image of business school that was really drilled into me by my parents and by spending some time at a consulting firm.

I had this traditional established path, and even though I had grown up in San Francisco, which is the land of startups, people always ask me "You must have grown up and been there through the .com boom."

I didn't see any of it because I was a kid.

I wasn't actually involved, so I had this real traditional path drilled into me and that's what I thought it was on.

I ended up joining Facebook just very briefly as a contractor, and within my first month I asked my boss there to write a recommendation for business school for me.

Grant: Funny.

Derek: Isn't it? That I got there and right away I was like, "This is great. But we talked about this, I'm going to leave here in 6 months or a year."

Grant: Like, the fastest-growing company that's about to-- Going to IPO sometime soon, and you're like, "I need to leave and go to business school."

Derek: That's correct. That's exactly how I thought about it, and what's really even funnier is that just to be honest, I was not particularly committed to that job in any way.

I didn't even think that I was going to work in tech.

I thought this was a fun stop off that to me was interesting because I liked Facebook, the product, and I was a real user of it.

But at least when I joined Facebook there, I was not really thinking about it as a long term thing.

I thought I was going to go back to consulting after business school. So, I applied to all these business schools.

Not a ton of them, but a few good business schools.

I got waitlisted or didn't get in to any of those that I wanted to get into, and I started re-evaluating my options and thinking "OK, actually now that I've been at this place for a few months seeing how things operate, this is way better than consulting. I don't know why I would want to go back there."

Where previously I didn't think of myself as going into technology at all, and this isn't really a trend for me.

I've been very lucky in that I've had good opportunities presented to me, and I haven't been afraid to go and take them.

In general it's worked out. Probably I missed some things along the way too, but a lot of my career progression has been happenstance where I just got really excited about something.

I think there is something to be learned from this, that putting yourself in a position where you're really excited about the thing that you're doing might be a way to make yourself more successful.

People always project stuff back on their history, and there's a lot of revisionist history.

So maybe that's what I'm doing here, but regardless, there's no way I could have at that time mapped out my pathway to becoming a CEO.

That was certainly not on my mind at all, and if you told me at that time that I was going to become a CEO of a tech company I would have laughed in your face.

Grant: OK. Then you left Facebook at some point, and then you-- Is that when you went to Yammer? What was next?

Derek: By the time I started coming back from business school I was evaluating all my options, and I thought "I could try to stay at Facebook and become a full time employee and take on some bigger role there, or I could go somewhere else, I could wait around and try business school again," I was really searching for something.

I ended up applying to Yammer largely because at Facebook at the time all communications happened through Outlook.

I was there because I loved Facebook, the product, but even working there when I spent time on Facebook it felt like I wasn't doing my job.

What I wanted was, "I spend all this time doing my job, and Facebook is a great communication tool, so I want to use Facebook to do my job."

That's what Yammer was. I found it exactly in that way. I Googled "Facebook for work," found Yammer, applied.

Grant: Funny.

Derek: Yeah, I know. Just totally out of the blue.

I think that's the only job that I've just applied to cold, without knowing anyone or getting connected through a career center or anything.

I applied out of nowhere, and at the time it was especially unique to see "Facebook" on someone's resume.

Grant: Yeah, right.

Derek: So I went in and I met the head of the team, Pete Fishman, who--

Grant: Because most people weren't leaving Facebook at that point.

Derek: That's right. Yeah, it wasn't-- People were just going there.

Grant: Right. It was sucking in. Everyone was coming in and no one was leaving, so to leave was somewhat unique.

Derek: They may have just interviewed me just to see what that was even about, just for their morbid curiosity, but I went in and I and I met the head of the team there. We clicked immediately.

Grant: The head of the data science team, or the head of the product team? Who were you interviewing with?

Derek: It was called "The analytics team." The guy's name is Pete Fishman, he's gone on to take a number of roles.

Right now he's at Eaze, the cannabis company.

Grant: Sure.

Derek: He's gone on to do a bunch of other interesting stuff, but what I saw in him was just great mentorship and great understanding of how companies can drive themselves forward through data.

Grant: OK. So you got the job at Yammer, and what was that role and what were you doing?

Derek: My title was Quantitative Product Analyst, which is about as narrow of a title as you can get.

In particular, it was focused on product. Although when I got there, the role I had come from at Facebook, I was working on monetization, so I had to do something about ads.

I was doing all the ad pricing stuff, and I got to Facebook and pretty quickly realized "This whole team is full of quantitative product analysts and the business side of the house is not getting a lot of love. That's the thing that I know a little bit about, maybe I can help."

I pretty quickly got to work helping out the customer success team, and the sales team marketing, bits and pieces for anyone who needed something there.

Grant: OK. So, you were starting to do this job or were supposed to do this job around helping people in the product organization understand how and what was being utilized, and how to improve it.

Then you saw this other opportunity to apply data to more of the business problems?

Derek: This happened very quickly in my tenure at Yammer, maybe within the first month or so I got back to my boss and said "It seems like there's some smart people handling this product stuff, but no one is really helping the rest of the company. I can go do that."

He said to me, "OK. But don't screw it up." He gave me a pretty long leash, and I'm really grateful for that.

It turned into quite a bit. I ended up doing stuff that traditionally falls into sales ops, and once the company was later acquired by Microsoft I ended up leading the roll out of a marketing automation software, which is in many ways a data problem.

There's so much that I got to do and see because I was not allowed to be the first data person to touch any of those departments.

Grant: Did you work closely with some of the senior leadership at Yammer while you were doing that?

Derek: Yeah, I did. Actually, Mode Series C was led by Valor, and the partner at Valor who led it, David Obrand, was the chief customer officer at Yammer back in the day.

He came in reasonably well into my tenure at Yammer, shortly before the company was acquired, to help scale it up.

His background was at Salesforce and he was a fantastic enterprise sales person and sales leader, so when he came in I got to work with him really closely on building the system that Yammer was going to use to scale up.

Now you look five years and change later, he's leading the round in Mode as an investor at his growth equity firm.

Grant: It's funny how those things work out, right?

Derek: It's -- Yeah. Not exactly a coincidence.

Grant: In my opinion, I think about enterprise software particularly as this small ecosystem at some point.

Once you get involved in it, there's a lot of incentives to continuously be a good actor.

To take care of your customers and the people you work with, because there's a strong likelihood that you'll want to work together later on and there will be an opportunity to do so later on.

This is a great example. I'm sure he loved working with you at Yammer, so when the opportunity arose to work with you as part of Mode I'm sure he jumped on it.

Derek: It highlights something that I learned around the time that I started Mode, or really realized around the time that I started Mode.

I used to have this notion that working at a "Good" company was useful for a person so that - - It was like a stamp of approval, like getting a degree from Stanford or Harvard.

I don't have a Stanford or Harvard degree, I went to Occidental College, which is a great school where I learned a lot and had a great time, but it's not seen in the same way.

For a long time I felt like I needed some stamp on my resume.

The consulting firm I worked at was tops in the industry in which I worked, but it was a really narrow field that most people didn't know, so it wasn't helping me with the rest of my career.

When I went out to start Mode it became really clear that the value of the brand is nowhere near the value of referenceability, especially if you're going to start a company.

Being one mutual connection removed from great investors, or even being a first degree connection with great investors where they know who you are and have seen you do quality work, believe in you as a leader or analyst or whatever it is that you do, that's the valuable part.

Grant: I get that. The idea that you can impress some folks and create a good impression, and then that later on is something that you can leverage either through a second party reference, or they just they want to work with you again.

What are some of the core things you learned while at Yammer? How long were you there, and what was the --?

Yammer was a pretty high-flying startup, I think it was acquired for over a billion.

Derek: That's right. Microsoft bought Yammer for $1.2 billion in I want to say 2012.

Grant: Yeah, pretty fast. Company was only a couple of years old at that point. Four years?

Derek: Four or five years, maybe. I was there for a little over a year and a half at the time of the acquisition, or thereabouts, and then for another year following.

Grant: Then is that what inspired you to start Mode? Or how did you--? Where does Mode come into the picture?

Derek: There were hints about Mode from the moment I got to Facebook.

I've always been interested in the meta problem, how to do the thing you're doing better regardless of what it is that I'm doing.

When I looked at the stuff that I was doing at Yammer and the stuff I was doing at Facebook, both of those companies had built internal tools to help their analytics and data science teams do their jobs.

If you were to look around at the other companies that were really well known for how they use data, at the time that was Zynga, LinkedIn, Spotify was on that list, Google of course.

Those companies had all built something internally, and at some point you got to ask "Why?" Tableau existed at that time, it was less mature than it is today, obviously, but it existed.

There was MicroStrategy and other sorts of alternatives for the business to understand what's happening, so I don't think we fully realized that at that time.

Now I've spent a lot of time thinking about it and trying to figure out, "Why did it feel like we had to build this internally? Why did it feel like we had to go out and build Mode?"

The answer is that a lot of the software that folks have traditionally used to do data analysis is about making dashboards, and it's about working in a pretty simplistic way. Drag and drop.

It's about empowering most people at the company to see a dashboard, do some basic manipulation in a drag and drop manner, not have to write any code and be able to get the basic stuff. To me, what this is about is really just running business as usual better. But that's not the value that people want to get out of data, and the reason that these companies that are really successful build big teams is they know that there's something more to it than business as usual.

There's some insight to be unlocked that can produce a step change in the business, and the way that you do that is you put smart people on the problem and you get them as many cycles as possible answering different questions.

By definition, you don't know where that value is going to be. Because if you did you would already be using it, exploiting it for some business benefit.

If you don't know where that value is going to be, then the best thing you can do is look as many places--

Be smart about those places, but look as many places as possible to try to find it.

That's really what this is, and Mode is really optimized to do that.

That's what those tools that those companies built were really for and that's what Mode is built for, but that's also just the whole premise of great analytics or data science.

That's the goal, that's what companies should be trying to do.

That's what Mode is out here evangelizing and building products for, is to help those companies get as many cycles as possible in answering the real meaty questions so that they can create step changes in their businesses.

Grant: Very cool. So, you know this opportunity from your time at Facebook and Yammer and you have this idea, and you've found a couple of co-founders and then just got the business up and running?

What were the early days, what did it look like?

Derek: There was a time at Yammer when I got together with Ben Stansel and Josh Ferguson, who are the two other founders of Mode, and we talked about what it would be like to bring these other products to market.

We talked about open sourcing things that we had done at Yammer, and ultimately determined that we wanted to create a company around this because it's not just about a piece of software, it's a whole set of things that we can bring content.

We have a SQL tutorial that's one of the most viewed SQL tutorials on the internet.

We wanted to be able to do stuff like that, to help people learn and help people collaborate in the community in a way that we just wouldn't have had the resources to do if we open sourced the software.

Plus open sourcing things is really difficult, especially at a company like Microsoft at that time.

We looked at it and said "This is going to be a challenge for us. There's probably not an appetite for the company to do this."

Grant: Got it. You could approach Microsoft and try to get it open sourced because the rest of the world needs it, but that's just going to be a lot of work, especially at Microsoft seven years ago.

So instead, let's leave and start a company and take the things we learned and build that as a product.

Derek: Yeah, that's right. We were startup people, too. I don't think we--

Grant: Neither of you-- None of you had started a company before, correct?

Derek: That's right.

None of us had founded a company, but we were coming from a really fast paced environment and it just felt like there were so many barriers to taking the thing we had already built and getting it out that we didn't even know how to go about navigating Microsoft to get the OK on that.

So we said, "We're just going to start from scratch. Total clean slate. We're going to leave."

The way that it happened is-- When I have friends, I have a number of friends who now come to me and ask "What's it like starting a company? Can you give me advice on this?"

What I tell all of them is, "Just make sure that when you go do it, you can't think about anything else that you would rather do.

For us, it was just the only thing I thought about. I woke up and it was "I want to start this company and build this product to get this out into the world."

When I went to sleep, it was "This is the only thing I want to be doing," and when I was at work I was constantly thinking about it.

It was a distraction from everything else that I had to do to a point where at some point it was just like, we had to do it.

There was nothing else that I could do except for go and work on this product.

Grant: So, did you then just started building a prototype? When did you raise money, etc?

Derek: It was really critical for us to create clean separation from the previous company, for legal reasons.

We consulted with lawyers and made sure to do it in as clean a way as possible so that we weren't liable to Microsoft for anything.

All three of us, Ben, Josh and I, we had the same boss and we went to him on one day together and said "Sorry, we're leaving to go do this thing."

I think it was a tough day for him, but also, he was one of the first investors in the company when we went out and sought money.

When we left the company, after we had left to David Sachs and to Adam Tassone, Adam-- David was the CEO of Yammer and Adam was the CTO, and a number of other executives and said--

"We're taking this stuff that was really effective at Yammer and we're going to build a version of it that anyone can use, and we're going to help other companies act like Yammer and be really great at uncovering those pieces of knowledge that can get their businesses to the next level. Do you want to invest?"

A lot of them, like I was saying about referenceability, a lot of them said "You did great work. I saw how effective this was." So, all of our early investors in the first round were Yammer executives.

Grant: Interesting. Had you worked closely with David Sachs while you were at Yammer, or was he off and just a degree away?

Derek: I hadn't personally worked with him that closely.

I was the stand in for my boss a few times, and at that point I was-- That was a scary situation for me to get called to the meeting with Sachs.

Now we have a closer relationship and I'm no longer afraid of going into a meeting with him, but at the time that was a big deal for me.

At some level, I was a little bit surprised that he was so excited about backing this company.

But we had done good enough work that it was filtered up to him, and he understood the value of the tools internally at Yammer, and said "OK. This is a thing that can be valuable for other businesses as well."

Grant: So, you start building and hire some folks. How much did you raise to start?

Derek: $500K.

Grant: OK.

Derek: Then we did more shortly after that, and this is the thing that I would probably do differently. I think the fundraising, the market is different now.

Grant: Yeah, for sure.

Derek: In part because there are so many tools readily available to help businesses bootstrap that you can get to pretty good revenue traction before raising money, but at the time all of the founders felt like we had to pay ourselves some salary, so we raised a little bit of money.

Grant: I also think on the other side I see a lot of rounds that come together where people are raising $3-4-5 million dollars before there's a team or a product, or anything else.

Derek: I honestly thought we would be able to do that, and this is where I think TechCrunch does a lot of companies a disservice.

I don't think it's good-- I think it's always good to have a little bit of pressure and to be a little bit hungry.

It forces you to be focused, and I think that raising money on day one when I look back in retrospect, allowed us to be a little bit sloppy.

I think also we had a bit of a mindset that was "We built a thing that was really valuable, and we know that it's valuable, and so let's just go and rebuild that."

We could have saved ourselves some time by spending a little bit more time with customers early on, understanding what other companies needed more of.

For most businesses, very few companies start like that, where you've come off of building something and you say "I'm going to go build that exact same thing, or something very similar to it."

Most folks will naturally be a little bit more in touch with their customers than Mode was in the early days.

But for us, it was very much like "OK. We've got a set of friends who want this thing, let's get the thing we know is valuable out to our friends, get them using it quickly, and then go from there."

I think there are just other ways we could have done it. I think having a little bit less money would have sharpened us on getting it out to a broader set of people faster, getting more feedback before we built more products.

Grant: OK. But you managed to take that $500K, get some customers. How many early customers? Who were you targeting? What did it look like at that point?

Derek: We were really just targeting friends.

It was, send a text message over to that person who we used to work with, who now works at a different company, and say "We're building this thing that I've shown you in the past. Do you want it?"

Grant: "You should use it."

Derek: And the answer is, "Yeah."

Grant: Were you charging them? What was your--?

Derek: Not at first. We did open beta at first, we really just wanted people to go and use it.

We did have a little bit of a detour where we had this notion, it was clear at that time -- It had just become clear that GitHub was really taking off.

We had this this idea that if we-- You can still see this in Mode today too, if you use the product.

We wanted to provide a way for different companies or people from different companies to share ideas about how to solve common problems.

So, most companies care at the basic level about the same things you care about.

Customer retention or having repeat customers if you're a commerce business, you think about it in slightly different terms but it's a similar concept.

You care about growth and engagement, and I think about these things in a B2B context and that's probably right for the audience of this podcast.

Grant: For sure.

Derek: But you can translate that pretty easily to other businesses, and a lot of these concepts, you can solve them in simple ways and then you can solve them in more difficult and sometimes more valuable ways.

The reality for most startups anyway, is that when you're solving a problem you usually want to do the simple version and move on.

But if there is a public place where you can go and draw upon the better versions and adopt them quickly, then that's great.

Then you get this cyclical effect where if you have a community that's building common solutions, then you get people who start building data to conform to those solutions.

That's when it really becomes hardened and becomes valuable.

You see this when I look at bootstrap, for example, and the effect that it's had on how people even think about the construction of a website today, that's the thing that we saw possible with solutions to common problems.

So when you go into Mode today, you see the public data warehouse.

This was our vision, was that people will be able to put dummy data out there and build solutions to common problems like churn.

Grant: Interesting.

Derek: Things that are things that are more robust than just, "Count up all your churned customers or churned users."

Ultimately that wasn't that successful, I think.

Or the understanding that I've come to have about this is that the best products in the B2B world tend to take things that are hard, that people already want to do, and make them easy.

There wasn't a community of people who already wanted to do this.

This wasn't open source software where you had tons of people contributing to open source software, but really struggling to merge other people's changes and deploy them. That process was awful until GitHub came along.

For Mode, if you were to look at the community of open source data analysis there was none really.

No one was trying to do that, and there was this big barrier of "I don't want to leak a bunch of my company's proprietary data. I don't want to give away trade secrets or anything. I'll just not bother with that."

That was the attitude, and I think it still is.

Grant: I'm guessing you didn't have that at Yammer.

That was an add-on, you thought "This will be the thing that makes this have a network effect and makes us go viral. People will start to use us for this open data set."

Derek: Yeah, and it was the thing that we wanted to do because we believed in it.

Grant: Right.

Derek: What I think having a little bit less money would have done for us is we would have invalidated that notion faster.

Now one good thing did come of this, which is that this public data warehouse allowed me to upload a bunch of sample data and build a tutorial, and that tutorial now drives hundreds of thousands of unique visitors every month.

Grant: This is the SQL tutorial?

Derek: Yeah, it's big. It's a real brand builder for us, at the very least.

Again, I talk about these sorts of things in business terms but also at the end of the day, I'm really proud of that.

I'm proud of a lot of stuff that we've done at Mode, but I am especially proud of the things we do that we don't earn direct profit from that contribute back to the analytics and data science community.

Grant: Just as a reference, this is basically a tutorial for how to do SQL queries.

You wrote that as part of this open data project, but it had this obviously huge secondary effect, which is probably through references and SEO and things where people were trying to learn SQL end up on your tooling and your tutorial. Is that right?

Derek: Yes. The SEO certainly drives a pretty good amount of the traffic there now, which was not deliberate at first.

We made a more deliberate effort to do that later. The real purpose of it, I had taught SQL at the consulting company where I worked and I taught it at Yammer.

I taught bits and pieces of it to people at Facebook, but not in a very official capacity.

It was just something that I knew how to teach to people really well and had gotten to be an expert in, but particularly SQL for data analysis.

At that time, now there's data camp and all of these other insight data science, if you're coming out of academia.

There's all of these programs now that will teach folks data analysis specific skills.

But at the time, SQL was the lingua franca for data analysis in technology companies at the very least, but really anyone who was working with tons of data that sat in a database, you were writing SQL.

All of the tutorials, all of the books, everything was written for software development.

In order to actually get past the first bit of whatever your learning material was, you were creating tables and you were spinning up a database.

You were doing all this stuff that for most analysts or data scientists, you don't really do.

When I showed up on day one at Facebook or at Yammer, my job was "Read data from the database.

Write a select statement to get some data, aggregate within that, sub queries and that kind of thing.

Just writing the most advanced select statements to get back the information that I need, but not creating stuff. I don't really care about table design, at least at first."

Eventually you come to learn that stuff, but the basics are really like "Let's take people who have an elementary understanding of maybe programming, maybe Excel, and let's map the concepts that they already know to just reading data and analyzing it."

That's really what SQL School is. That's the name of the tutorial, we call it SQL School.

It's really just about "Let's map these things to the stuff that you already know, cut out all the superfluous stuff and make it fun by giving you Billboard Top 40 data, and off you go."

Grant: It's interesting, because I love that you're like "Separate out the DBA tasks. Table creation, database optimization, all this kind of stuff from the entire tutorial and just assume you have data."

Because that's the reality for most people that's already in this format, and now you need to query it and like put it together and do some joins and other things.

I don't need to know how to set it all up, I just need to know how to query into it.

You created this great guide for that, and then I think it's really interesting because it just feeds your community.

It feeds your audience, these are the people that become data scientists, that become users of your tool.

You want them to be more like your whole tool is more SQL oriented than, to your point, any other data science tool out there that were drag and drop oriented.

If you can help people use the tool more, it's a self-referencing self-feeding loop. They get a nice, virtuous cycle there.

It also just shows that you guys are experts and you understand how to do this stuff, and if you can teach people then they will probably look at your tool.

Derek: Content marketing isn't anything new, it feels somewhat solved at this point.

The thing that I've come to understand through this is that the best content marketing is tools. Enterprise Ready falls into this category.

Grant: Sure.

Derek: It's something that people can return to continue to get value from, and would recommend to somebody else.

Sometimes a blog post is like that, where you get something really valuable from it and you want to go back.

We strive to do that on our blog, but oftentimes I find the best things are things like this tutorial or Enterprise Ready.

Grant: Sure.

Derek:

The thing that is really powerful about it is that if you are an expert in SQL, you're someone that everyone else looks to.

Those people are going to ask you how they can learn, and once it becomes clear to you that Mode is the best way to learn, then you start recommending it.

This is what we see, and it's part of what has been so powerful, is people that Mode would never come in contact with otherwise use this tutorial. Yes, that's true.

But also, our existing customers use the tutorial, where the analysts and data scientists at a company that currently uses Mode will tell other people, product managers, finance, operations, whoever it may be, "If you want to do a little bit of work beyond what I've done, you got to take this thing I've done and modify it maybe, then you can learn some SQL. It's pretty easy. Here's the tutorial."

Grant: It's like, instead of me sitting next your desk and telling you what to do, I send you this tutorial, you learn it on your own time and at your own pace.

Then you're enabled and I'm not a bottleneck for you to access this data. "Here's all the stuff I was going to teach you anyway.

Plus, more and will probably teach you better than I would have taught you."

So yeah, exactly. It becomes just a referenced item that if experts are sharing it with their ecosystem, it's a testimonial to it. Cool.

Derek: I think it has earned a really good spot in the data analysis, data science communities just by being clear and by teaching to people at the level that they come from, instead of expecting them to know a bunch of programming syntax already.

Grant: Yeah, sure. OK, so I'd love to jump into some of the core things that I think this audience will love.

Obviously we're a very B2B enterprise-focused audience, and you're a data expert. Like, you know how to pull out data.

You did this at Yammer and you've helped a bunch of companies do it at Mode.

How should enterprise software, B2B and SaaS companies be thinking about using the data that they get?

Derek: I would start by saying that the way that most companies think about data today is in a pretty simplistic way.

Like I mentioned earlier, I think companies think of data dashboards as somewhat synonymous.

Dashboards really are about running the operational aspects of your business.

Like I said, the way that I think about it is "Better business as usual." That's valuable. You need that.

Every company needs that, and the way that most companies as a start do that is with Kant tools like Google Analytics or a mix panel, or amplitude.

Something that you can deploy and pretty quickly get information back from.

You don't have to do a bunch of turning knobs or coding, or anything like that.

Most companies then realize that their business is a little bit more complicated, or there's some nuance that they want to understand that isn't provided there.

So, classic example. If you have a marketplace business, then you have two different types of users. Or take Twitch, for example.

One of our longtime customers, Twitch, has three types of constituents, I would say.

Not necessarily users, but people who care. There's streamers, there are viewers, and then there are game developers.

It's a three-sided marketplace, and those types of businesses might use a product like Google Analytics or Amplitude for something, but it's not going to give the whole picture of everything.

You want something that's a little bit more customizable, and that's when you go to the world of BI. You're creating--

Grant: This is business intelligence, right?

Derek: Yes, BI, "Business intelligence."

Where the players historically have been folks like MicroStrategy, and now a lot of folks think of Tableau as one of the leaders here.

It's products that are customizable to fit different types of use cases, where you're doing some underlying data transformation before it's being visualized, and it's usually places that have a heavy focus on visualization and dashboarding.

Then ease of use for non-technical end users. That's a progression these companies go through.

As I mentioned before, where we see a lot of that value at Mode is in digging into raw data and trying to answer really tough questions.

I think this will be easier for me to talk about as we get into some specific examples for what that might look like, but what I would say for most companies, especially in the B2B world, for how you think about data is you should be thinking about how to advance your business first and then map data or what data you can get or what data you have to the types of business questions that you think will be most valuable for you to answer.

So, one of those for Mode was "How should we price? What should our business model be?"

A while ago we published a blog post about adding a freemium product, so there was a product we have called Mode Studio and it is free to use forever.

We did not start with Mode Studio, but we added it several years into Mode's lifetime.

We did a ton of analysis to understand, first of all, whether we should do that.

Then second, how we should split the product to decide which parts of it are free and which parts are behind a paywall, and that sort of thing.

It ended up having exactly the desired effect that we wanted to have, which was to dramatically cut our customer acquisition costs.

It has some other things that we didn't expect, it did some things--

It didn't do some things that we did expect, typical big launch type of stuff, but we prepared for it as well as we possibly could have by understanding how users behaved around certain elements of our product.

Grant: OK. So you used data to make this decision around how to-- What features to include in that freemium product, and even if you should offer a freemium product at all.

What did that look like? What were the key insights or the key data points that drove that decision?

Derek: The thing that I've always remembered is one of the cornerstones of that decision was, first of all, we did use dashboards to tell us that there was some kind of problem that we wanted to solve.

Which is to say, "This is a business that we're getting ready to scale. It would be much easier to do that if our customer acquisition costs were way lower.

What are really big things we could do that would dramatically reduce that?"

Freemium is one of the ideas that we came up with, and it turned out to be a really good one.

Once we started teasing apart all of the details, one of the analyses that was most critical was understanding for existing Mode users at a given company that uses Mode, when do they use any specific feature?

Like, writing a SQL query. We determined that's a feature.

Writing a SQL query, what percentage of companies that end up purchasing Mode write a SQL query and at what point do they do it? 100 % is the answer, and really early.

That one's a no-brainer that we have to include that in the free product.

The things that are used by everyone and immediately are necessary to even function at all, and without them there's probably not a ton of value.

If you were to go through feature by feature and look at the ones that are all used 100 % of the time, that's what you would deduce.

You would say, "This is the core of Mode and necessary. If we're going to give people some free something, then they've got to have these pieces."

Then there are these other features. A really good example is Slack integration. Slack integration, not everyone uses it.

Certainly not the thing that you do immediately, because you probably need to do some analysis before deciding that it's worth pushing analysis into Slack.

That's a thing that we can put on the other side of a paywall, that if you're using the product for free, probably once you decide you need the Slack integration you're also seeing a value that you're willing to pay for the product.

Grant: So, your studio version, is that just a one-player, single player option? Or can you invite team members to that?

Derek: You can invite team members to it.

The way that Mode works is you create an organization for your company, and then you invite people to the organization. The organization is how you manage permissions so that you then connect the organization to one or any number of databases, and people in the organization can then query those databases.

"Can you write some python against it?" Or whatever it is that you want to do, but a lot of the sharing features, things like scheduling a report to be delivered to you every Monday. That thing is in the premium version, so single player mode is, I think, a reasonable way to think about it. Most companies that want to use it in a really collaborative way will pay for the premium product.

Grant: So you are using data, you had a paid product, and maybe your entry point is $250 a month or something before this. Is that right?

Derek: We've gone through a number of different pricing models. The key decisions around this--

Again, this is stuff we had done a ton of analysis around as well, but I will say that type of analysis is always best when married with the conversations that you have with customers.

Understanding why people like or don't like a particular model. There's always a problem with every pricing model.

You're putting a gate, especially if it's metered in some way. If it's based on users, you're disincentivizing folks from adding the next user.

If it is based on data amounts, you're disincentivizing folks from adding more data, which turns out to be a real sticking point.

There's always some challenge. The key challenges that we faced at different points in time, I think the first one was "We're used to seeing people charge different amounts for a creator and a viewer.

Because this is what Tableau does," and as a tiny startup you just say, "OK. Whatever I've got to do to reduce friction in the sales process, that's what I'm going to do."

In general, I think one of the goals of pricing is to reduce friction in sales processes. There are other goals as well, but you should be trying to achieve that at least partially, and as a young company that was one of our priorities.

So we did that for a little while, but we started getting this feedback that was like, "I've got this product manager--"

In order to have that separation and still do contracts of any reasonable size, we did charge a lot of money for analysts and data scientists.

You would say, "OK. That person is three grand a year, and then the viewers are free. That was a pricing model that we had at one point.

That's no longer how we do it. Some of the feedback we got was like, "OK. $3 grand for a data scientist, no problem.

But my product manager, that person is going to do some queries now and then, I really want them to have access to Mode.

But I just don't want to pay the full amount, can we negotiate a half license or something like that?"

We ended up doing a lot of these bespoke deals where we were valuing people at half a license or a quarter of a license or whatever, based on their expected usage.

That was really heavy. It was way more friction than it reduced.

Grant: Lots of SKUs, lots of negotiation.

Derek: We were not even thinking about SKUs yet. This is before structuring things into Salesforce and getting -- This is really early days.

But yes, every contract was totally different.

Grant: Great.

Derek: It was a lot to maintain.

It was really annoying, and we also just didn't want to go to the effort to build a separate experience for a viewer and a creator, because that was going to be a product lift that prevented us from going and doing something else that's valuable, like adding more visualizations or building out R and Python functionality which we didn't have at the time.

We wanted to go do those things that would deliver core product value, rather than building out features that just supported our business model.

I think that's the thing that we did really well, is we had this bottoms-up notion from the beginning.

We can talk more about that too, because I think it's especially relevant to just being Enterprise Ready in general.

But our goal was, first and foremost, "Let's get to the most valuable product and let's deliver that in a way that makes sense for people without handicapping ourselves or limiting ourselves from some future pricing model, or whatever we might want to do.

Only once we've really started to figure out how people experience the value of Mode, should we be hardening that into a system."

Grant: Yeah, I agree.

Derek: The other challenge that we had with that particular pricing model was that $3 grand was a lot.

If you think about the SQL tutorial and what that did for us, we have these fans who had come to us through some other avenue.

Or we had someone, let's say, who works at Company A and then goes to Company B and wants to adopt Mode three.

$3 grand is a lot to ask your boss for, even if you had a great experience learning SQL on Mode, you come in as a junior analyst and you say "I really would like to use this thing at work, but it costs $3 grand a year," most people are too timid for that.

They don't want to do it. They'll just take whatever is handed to them by the company, so that was something that we wanted to solve for in our next model.

Grant: Can you share anything else you've learned, in terms of what has been successful?

Are there things you're thinking about enhancing the freemium? Has it done what you wanted to do and helped reduce your user acquisition costs, etc?

Derek: It cut user acquisition costs in half, essentially the next day.

It did in a different way than you might expect, so Yammer had a freemium model and a gigantic pool of companies that were using the product for free to draw from.

A lot of what I did personally at Yammer was ranking companies that were using the free product and surfacing them as leads to our sales team.

At Mode, it works a little bit differently just by virtue of the type of product that it is. First of all, there's a bigger hurdle to adopting it.

At Yammer, you could just sign up. At Mode, you have to connect to a database.

That immediately places a barrier that we can get over, but we just don't get over it at the same volume that Yammer had.

Right off the bat, it's a slightly different function for what freemium does.

At the same time, we have an audience of analysts and data scientists who really don't want to be sold to.

We tried very hard not to be salesy in that traditional sense. We don't want folks to feel like we're coming on too strong.

This is something that we've also really had to reconcile in a more enterprise world.

Where sometimes that's a little bit necessary, and can be helpful in fact, and people expect it and want it.

But for practitioners, that end of the line data scientist, the authentic approach has proven to be better for us most of the time.

Previously anyone who signed up for Mode in any capacity, we were sending our sales team after.

We were saying "OK, great. You're interested in Mode? We want to hold your hand, make sure that you have a good experience, etc."

And actually, folks didn't really want that.

What this has done is a lot of people who just want to kick the tires to go do that, and it focuses our sales team only on the folks who are really serious about Mode.

Just having that focus is so much more efficient than having the salespeople to reach out to every single person who does anything related to Mode, ever.

Where if you're a salesperson now at Mode, rather than like spending your time trying to talk to and get on the phone, lots of folks who are then going to no show or who aren't really that serious about it, you can go back and contact someone who last saw Mode a year and a half ago.

The product has changed a ton and we have a note in our CRM that says they were interested in a specific feature, now Mode has that feature.

That's a way better conversation. That sort of thing has really allowed us to gain that efficiency that we were looking for when we conceived of the notion of freemium at all.

Grant: That's interesting. I really like the idea that it allows your customers to raise their hand when they're actually really interested, and so you're not bothering the folks that are going to waste your time.

You're not chasing the 5 % that maybe you can get them to convert.

You're chasing the 95 % that are really interested and then you're letting that other demand build up.

Derek: Mode has been driven almost exclusively by inbound to date.

We now do relatively targeted outbound outreach that's been somewhat successful, in part because folks have had some exposure to Mode.

Maybe we reach out to a head of data somewhere who has been subscribing to our e-mail list for a while. We have a list that feels authentic.

We're really careful about making sure that we have only a few articles.

They're all really tight to Mode's brand in terms of just things that analytical people will want to read, or people who use the free product in some capacity in the past, people who've done the tutorial.

That type of stuff, because we've done it mostly in a way that's not too in your face, generates good brand value for us.

Now when we do that outreach we're able to get good conversations, and people are willing to take calls from us because they say "OK, I've had good experiences."

And "I've gotten good content from Mode in the past."

Grant: I love that. That's a really interesting way to think about how to use data from a pricing perspective, and from a feature selection perspective.

One of the things we're thankful for, is this little bit of-- The idea of institutional knowledge.

I would love for you to dive into how you think folks can use data to drive institutional knowledge.

Derek: This is one of my favorite things about data analysis. So, we all know that data is useful in making discrete decisions.

You show up to a meeting, you've got a decision to be made, you've got the data and you make the decision, and you move on. That's wonderful.

Grant: Every time. You just have all the perfect data, you're just ready to-- It's black and white. Just, easy.

Derek: Yes, that's the dream. In all seriousness though, showing up with data does change the tenor of a conversation.

It's not the be all end all, and I would certainly say that anything valuable that we found quantitatively at Mode or at Yammer or the things we found to be true quantitatively, we validated with research.

Actually, I'll give you an example of this. Yammer, for anyone who isn't familiar, Yammer is very similar to Facebook in that it is a platform for folks to post messages.

There are threads, it's not quite like Slack. Slack is chat where it's a stream of stuff.

Yammer was built entirely around a notion of threaded conversations like Facebook, where you have a main post and then you have a bunch of replies to it.

Users of Yammer-- Each company gets its own Yammer network.

What it is essentially a Facebook that is confined just to you and the other people who are at your company.

Grant: Not to be confused with Facebook's product, Facebook for Work.

Derek: That's right. That came later.

Grant: Much later, yeah.

Derek: That wasn't introduced until after Yammer was acquired by Microsoft.

One of the most impactful features from a metrics perspective that Yammer ever produced, it was really simple and it was based on this idea that new users to the product would probably retain better if they had some positive interaction in their first experience.

Seems like common sense, so an enterprising pm had this notion of putting a little black bar at the bottom of every new user's photo.

That's a black bar, white text that says "New." Anyone who has heard me talk--

I talk about this in Mode onboarding all the time, this is one of my favorite examples of anything because it's so simple but so impactful and teaches a really important lesson.

This feature had exactly the intended result, which is to say that when new users showed up, this banner was placed on their photos and it made existing users more likely to interact with those people, even just to say welcome.

You see someone's photo that says "New" on it, "Welcome. This is what Yammer is about."

What that did for Yammer was bananas.

The new user retention had whole percentage point increases, which if you spend enough time analyzing a/b tests to understand a several percentage point sustained increase in a metric is a really big deal.

You don't come across those too often, and it tells us this obvious thing which is "We should keep that. That's a good feature."

I think that's where most people's idea of data analysis ends. "OK, we did the analysis and this thing was great."

But what this really does is it tells us that we have an opportunity now, we now know of a place where we can create really big leverage for the business.

That interaction that folks have, like anything we can do to get existing users to interact with the new ones when they join is probably going to be good.

What you have then is a bunch of PMs who learned this information and then start coming up with other features that might do the same thing, some of which ended up being successful as well.

But it doesn't stop there, in an organization that's really effective at using data or at disseminating this type of information, you're sharing that with your customer success team.

A customer success manager says "OK."

They go to a customer that just bought Yammer and they say, "You're rolling this out? The most critical thing for you to do, administrator or champion, the most critical thing for you to do is to make sure that you interact personally with as many new users as you can. Because that's what's going to get them to stick around. That's what's going to make this successful."

You can use it everywhere, you can use it in marketing materials.

You can have automated emails that help surface new users and allow you to--

Like, I join in and it should show me "There's all of these people who are in your team already. Go have conversations with them," there's so many implications for what you can do here to move the needle for the company that the most valuable thing really is not just the learning initially.

It's this institutional knowledge that's created that informs everyone's jobs, and that when I talk about the value of data, that's why I feel so strongly about this type of work instead of just dashboarding. Because if you are able to unlock one of those insights, one of those things that feels transformative for the business, it's not just useful for you this one time. It's useful for everybody, and it changes the way everyone does their jobs. That is so impactful.

Grant: How would you come about the thesis that if a new user has a positive first experience, or maybe just--

Did you look at the data and pull out "There's some difference between users who get ten messages within the first hour versus users who get zero messages for the first day,"or how did you come about this thesis?

Or was it, have the thesis and then look for data to support it?

Derek: The best part is I don't remember. It's the best and the worst part.

The reason it's the best part is that it was a long time ago, and honestly I don't ever that many details from the day to day work that I did at Yammer.

We're talking about seven, eight years ago. But I do remember that crystal clear. '

That's what makes it the best part, is that we got to this thing and it was like "This is big."

Facebook had their, I think it was like "As long as you connect with seven friends in ten days, then you'll be a sticky Facebook user."

Finding these nuggets of information to point everyone at.

Grant: I guess my question is, if I'm a product person or at a company and I'm looking to find these core insights, should I be trying to come up with a thesis first and then look for the data to support it?

Or should I be trying to look at the data and find things that I think I can then test in more detail?

Derek: I think you always want to approach the data with some hypothesis.

Grant: OK.

Derek: Part of that is my background in economics.

I believe that the analysis should be done to support some type of thesis, usually if you just dive into the big data lake and hope that something interesting comes out, you're unlikely to find something.

It's much better from what I've seen when directed by smart hypotheses developed by smart people.

Grant: OK. Because if you just go into the data, you're going to find something.

But it might just be noise, realistically.

Then if you just have a thesis and you're trying to find data that will either prove or disprove it, you're going to come up with one or the other.

Derek: This points to something really interesting. There are products like Outlier AI, for example, that will take a bunch of events and point out to you the outliers.

That's why it's called "Outlier." I think this is one of the best places for AI in the business intelligence world, and this is where we're going to see AI take over from BI companies in a big way over time.

Dashboards are problem surfacing tools, but they're the type of problem surfacing tool that you have to go check yourself and find the problem.

What Outlier does is it effectively takes the things you would put on a dashboard, and some things that you might not think to put on a dashboard, and surfaces the anomalies to you.

There are things that current technology will miss, like really gradual degradation is not something that Outlier is going to catch too easily just because of the nature.

I could be wrong, maybe the product has evolved to do that since I first saw it in the early days.

But in general, in anomaly detection, it's tough to catch a gradual degradation in something. But spikes, certainly.

Grant: Kind of like how I've put on some pounds over the last 15 years.

Derek: It's not going to catch the creep, but it will catch the spike. If you just do a crash juice cleanse, Outlier will catch it for you.

Grant: Perfect.

Derek: Outlier is taking on those sorts of cases where previously you might just have to look at dashboard all the time, and now or at least over time, products like Outlier will just push information to you and show you what to look at.

But that's still reactive, and it is going to take some proactive thinking about "OK. Here's a place where I think we can get some more value."

The reality is that companies have so much data that it would be impossible to just get in and randomly start doing things and find value.

You've got to have some direction, like at the very least "Here's the portion of our data that would be valuable. At the very least."

So, I might even say because of that it's impossible to just go in randomly.

Everyone's got some hypothesis, even if it's just "I think there's something in our billing data."

Grant: It's not like you're just combing around looking at data, looking at stuff, you generally are forming a thesis as you're looking at user data.

You're like, "What makes people--? It's questions. You start to ask questions and then you start to dive in deeper.

Derek: Take this freemium example. We started with that thing that we wanted to work on.

We got to the end of the year, we had a board meeting and said one of the things we really want to do is reduce our acquisition costs so that we can scale more efficiently.

Then we came up with ideas to do that, and usually you've got some thing that you want to achieve that motivates the question and determines your initial hypotheses.

You get down and you think about it with the people who are closest to the business, and then you start doing analysis.

Grant: Yeah, that makes sense.

The consumer world is definitely filled with folks who are looking at data and spending time analyzing this, and I think it probably often goes under utilized at enterprise software startups, particularly in the early days.

Because most enterprise software companies probably don't have a data scientist on staff and they're probably not spending that much time looking at the data, but trying to find some areas that you can point to make sure you're staying data driven.

A lot of the things you're talking about, everybody should have.

Everybody should have these standard metrics around customer acquisition costs and average lifetime value.

These things are a fairly well-understood insight around, but that information is like "We're going to share with investors."

It's not necessarily what's going to drive your business, those metrics help you benchmark but they don't help you get more usage and get higher conversion rates.

I think thinking through this, and first you have to capture the data and second you have to put it somewhere you can actually analyze it a bit, and then have a thesis or two of things you want to improve.

Areas in benchmarking can show you areas where you might be weak and where you might be strong, so you can use those to find opportunities, but it seems like there's not that much discussion around it.

This is a thing that people talk about, like how to be super data driven early on in enterprise software.

Derek: This is a thing, I agree, that hasn't been talked about really broadly.

My co-founder Ben just went on a little mini tour giving a presentation along with Segment, so Segment, put together a tour of accelerators to talk about how data can be effective and powerful at really early companies.

My co-founder Ben went along and talked about how to do some of that more directed analysis.

It's not just counting up your revenue or the basic stuff that you would pitch to investors, now you need to do the investor stuff too and there are ways that you can do that really effectively that are different from what I think of as your core metrics dashboarding.

In fact, I think that's necessary in order to be compelling as a business to investors.

Very few businesses, just like for software as a service, there's standard sets of software as a service metrics like LTV over CAC.

Obviously any recurring revenue, like there are just things that everyone is going to present. Quick ratios, things like that.

You have to calculate that, and very few businesses will stand out with those metrics.

If you are Slack and you're going to be off the charts on all of those metrics, that's great.

Grant: Most of us aren't Slack.

Derek: Most of us aren't Slack. So, what do you do?

You need to be a little bit more thorough in finding out where the real key strengths of your company are, and that looks similar to developing a hypothesis about a problem and researching into it and figuring out if your hypothesis is correct.

Grant: Yeah, that's great. Moving away from some of the data stuff and talking a little bit more about Mode again, and your progress as an enterprise software company.

I think you've done this bottom up motion most of your time.

You didn't really start off going after the largest enterprises, but now you're doing some bigger deals and you've always had some core features and you've always--

We've talked in the past, one on one, about how focused you are on security and how code reviews and external audits and those are all part of your processes.

But I'd love to just get your perspective on that motion up, and how you think about some of those EnterpriseReady features within the perspective of Mode.

Derek: Yes. There are certain things that we felt were fundamental and necessary for us to do right from day one.

Security has always been a super important thing for us, so in order for Mode to be effective our customers need to feel comfortable putting sensitive data into it.

That's just a necessity. Now this is something that all businesses balance with the desire to move quickly.

In some cases, these things aren't at odds. If our goal in Mode is to sign a bunch of customers as quickly as possible and having great security reduces that friction, then that's wonderful.

That was really the impetus at some point when we got SOC 2 compliant, that was really what drove it, is we had a bunch of customers who were saying "We'd really feel more comfortable if there was some external auditor here to rubber stamp this and say "Yes. Mode actually does the things that they say they do."

Because the things you say are great, and we've since had some of our larger customers bring an independent auditors to validate that we do what we say.

Those have all gone really well because this has already always been a priority for us, but that sort of thing certainly can be, depending on your business, an accelerator for you.

Now there are certain things that sometimes feel like a decelerator, so I'll give you an example.

When people write into Mode customer support, usually it's because they found a bug or they've got some issue with a report that they've built.

Our support team will say "I can help you out. Just give me the report token.

It's a little piece you can find at the end of the URL in your motorport," so you give that to our support team and our support team goes in and looks up some information about your report.

We have this choice to make where we could have said that our support team can just look at your report as though they belong to your company.

We have competitors who do that. We decided that this wasn't an acceptable security tradeoff.

The information that you produce is yours and only yours, and we probably shouldn't be able to see that dashboard that you've created unless you show it to us actively, and you should know that you're doing that.

It makes it harder for our support team to do their jobs.

It would certainly be easier if they could just look at your report and figure out what's wrong with it.

Instead, they have to go off of metadata information about when you created it, how many lines of code it is, how big is the results set it produces.

That kind of stuff usually is enough to get the job done, it's just harder.

Grant: Sure.

Derek: We take the harder path because we think it's more secure for our customers. That's important to us.

Grant: It's the principle of least access, so "They don't need all the data to do that job. Why give it to them? You should be able to do it with a most limited set of data."

If metadata gets you there, then that's the right level of access. If you need to escalate further and further, the customer can make the decision, or not.

Derek: At some point we made the decision to become HIPAA compliant.

We didn't do it on day one because it wasn't the fastest thing to do, we did it when it became an accelerant for the business.

There are lots of tradeoffs in the security world as there are in the general enterprise readiness world, where as a CEO I'm constantly evaluating "What will this really unlock for us?"

Starting from this bottoms up place, a lot of the reason that we started as a bottoms up company, to be quite frank, is that's what we knew.

A lot of Mode's early employees had come from Yammer and that was the way that Yammer did it.

We liked the idea of building a product where we focused first and foremost on the value before we focused on compliance logs, etc.

Now what's happened is as we've delivered that value, we've gotten a pull from our customers who say "We started with this in our analytics and data science teams, now it's everywhere.

We have companies with many thousands of active users on Mode in a given day. We need to help them administer that.

They need to make sure that people are seeing the correct stuff and not the incorrect stuff, so we need to develop systems to help do that.

We've done our best to keep up with that, and it's become a much greater focus for us recently.

Where we've realized not only do these businesses need it, but these are the businesses where Mode is often most successful.

Places that have put a real investment in understanding their business through data, that's a natural fit for Mode.

We should be doing our best to make them as successful as possible.

We have customers today who say "We love Mode. We want to roll it out really broadly. We need you to give us this particular thing."

There's a lot of stuff that we're working through that fits in the general enterprise readiness bucket, like permissions is an example.

Grant: Sure.

Derek: Today it's possible to do lots of things with permissions in Mode, but if you've got a three tiered system where you have very confidential, medium confidential, and not super confidential data and that's all stored in your active directory, and you you've got some real specific rules around who can see which things and it's managed somewhere outside of Mode.

That's a thing that we either need to work with you very closely on to create some custom stuff to interact with our API, or we need to maybe build out some additional product features for.

There's a variety of different scenarios like this, where we're integrating into some company's system in a way that might require a little bit of extra work from us that we need to do.

Grant:

One of the core things across the board is just remembering that your product is not in its silo, it's used as part of a full pipeline or suite of other tools, and some information should be managed other places and brought into your application. I think just taking that perspective and making sure that everyone in your team understands that, like "Your tool is important but there's a whole other suite of tools that all need to work together for this company to get stuff done. You have to focus on integrating them as well."

That's a sounds like that's where you're coming from, from this single sign on and role based access control concept, is it has to integrate pull-in from other places.

Derek: As that relates to building a bottoms up business, the nice thing about bottoms up businesses is you're solving the hardest problem first.

When you go to IT departments and you ask folks what the hardest problem is, in a lot of cases it's just getting people to adopt software.

There's tons of stuff that just sits on people's laptops that they never use, or if you read Challenger Sale, for example.

Any enterprise CEO should be reading that book.

Grant: A greed, it's really great.

Derek: You read Challenger Sale, what's the number one thing that drives sales of software?

It's that you have a lot of support from the users of the software, so the power of a bottoms up business model is real.

Then you need to be pragmatic about how you approach the enterprise readiness aspect of it, which things you do in which order.

For us, it just happened that security was something that we did before enterprise readiness was even on the radar at all, because it was so critical and fundamental to our business.

But there are still elements of it, so we have designed our SOC-2 controls in such a way that there will be an onramp to future things.

In the same way that we are GDPR compliant, which is giving us a good on ramp to California's similar privacy regulations that are going to go into effect next year.

We try to have an eye toward the next thing, like ISO which is a little bit more strict than SOC in terms of how you design your controls.

There are specific controls for ISO, where SOC you can design your own controls around certain parameters.

We're trying to design toward ISO anyway, even though it's not necessary for our business.

Most of our customers and prospects today are totally happy knowing that we've been audited by a third party and that we have real organized controls that we've maintained over a long period of time.

Grant: The compliance certifications I think are always really interesting.

For ISO 27000, it's a great standard to look into.

A lot of it is not that relevant to software companies, there's stuff about loading docks and things you generally aren't going to have to worry about.

But it's a very strong standard, and I always say the most important piece is if you're just aware of it.

It's basically the entire playbook that every CISO is going to be asking you about, so if you want to be able to have a conversation with the folks that are evaluating the security of your product, read the ISO spec and understand their requirements.

Then put as much of it into play as you can, and then just be able to speak to it.

That way you're not caught without knowing what the people are talking about, you can just have the conversation and they can make tradeoffs and say "We at some point in our company's history, we didn't have key cards at every door. Now we do, and that's just part of that spec."

But if you tell somebody that "We're a 20 person company and we just have locks on the doors and everyone has a key," they might be OK with it.

Derek: Administering some of that stuff at a really small company scale can be a lot of overhead. It's probably not worth it.

Grant: But having it, knowing what it is and being able to talk to it and say why you're not doing it and justify it I think is really important.

That's my perspective. Have an opinion, have a perspective, and then be able to talk like a rational, logical person with the other people on the other end.

Understand that they're trying to do their job, which is in order to be ISO 27000 compliant, you have to work with like other ISO 27000 compliant companies.

It's this network effect in itself, and so it's like they're making some exceptions, but they want to know you have a roadmap to getting there as well.

Derek: Yes, I agree with that. There are really two aspects of security, there is an actual security and a perception of security aspect.

You don't actually need to be audited, technically. You don't need to be audited in order to be secure.

Grant: 100% agree.

Derek: It certainly helps, and we do find value in it from the perspective of enhancing our own controls and our own protocols at the company.

I won't pretend that we got absolutely everything right at first, and we have external pen testers to whom we give our source code.

We say, "Just go nuts. Really try to find all the holes."

Every new feature that we introduce, things get tested over time, especially anything that introduces new security surface area is going to get pen tested before we even roll beta customers onto it.

Before we've even put our own company data onto it, we're getting that stuff pen tested.

Grant: Like you said, this white box model where you're giving people access to source code and everything else, too. Which is--

Derek: Yeah. Have at it with the best you can do, we'll give you everything and see if you can break into it. I think that's really valuable.

We've gotten tons of benefit from that. We also do a bug bounty program where we've had some success.

The bug bounty program is a thing that takes a lot of resources to administer it properly, because there's also a lot of garbage that comes through there.

But we feel that's an important thing for us to do in order to maintain a certain level of security.

Grant: To your point though, my problem with some of these certifications is sometimes they are like a point in time checkbox.

I often think that folks are a little bit-- Especially with the vendor security questionnaires.

I think that's a really interesting area where folks are just a little bit rose colored in terms of how they fill those out, and the perspectives that they're giving.

I don't know. I think these security compliances have value, I just don't think that they're the be all end all of security.

Derek: That's what I'm saying, also. You do the compliance work primarily to reduce friction in sales processes.

Grant: Right. It's like getting a college degree to prove that you can do the work.

Derek: That's right. Or in my case, going to Facebook or wherever.

Grant: Sure, exactly.

Derek: Somewhere else to get that seal of approval.

Grant: People often use their biggest customers, and they'll be like "This bank uses us. If they use us, they've done a lot of diligence" and they'll try to leverage that as an example of like, "If they use us, you should be able to use us too.

Derek: There's also, truthfully, just a time in market thing that really helps.

Companies that probably would not have talked to us three years ago will talk to us now, because we have enough of a reputation in the market that it seems legit, seems credible.

If you think about this too, one of the things that comes up all the time is "Should we be building an on prem product?"

Mode today can connect to databases that live in pretty much whatever environment you've got, but our core product is a multitenant SaaS product.

Everyone is logging into the same version of Mode.

Grant: Sure.

Derek: There's been this constant tension of, "Probably we're not going to get into a bank to run their core risk models.

Because those are extremely risk averse organizations, and that's an extremely risk averse thing that we're talking about."

But the level of comfort that folks have with this model continues to grow over time, so there has always been this question of "Should we be building an on prem product right now, because it will open up some new set of customers that today are not comfortable with what we do?

Or should we be focusing more on core product value, and waiting for that to become an easier thing to do or for those companies to become more comfortable with the model that we have, etc?"

This is one of those core debates that we have at Mode every once in a while.

What we've come down on for this is there are things that we can do that are somewhat in between the two that we will continue to do to make folks more comfortable, reduce security, surface area, whatever it is.

But the business tradeoff for us is it would be so costly to re-engineer our product in that way.

First of all, we couldn't have built a bottoms-up product had we done that. Being multitenant SaaS is part of what made Mode easy to adopt in the early days, and what got us a bunch of early customers, and the ability to continually iterate and prove out that value.

We would not be where we are today had we started with an on prem product.

Now it's really a question of, "Do we bridge that gap?" It's a constant tradeoff.

We think about it regularly, and we always come down in the same place, which is we see the market changing where people are comfortable with Mode as a company more and more.

The example I always use is Salesforce. I love Salesforce here. People put incredibly sensitive information into Salesforce, and they have an established brand.

People feel like it's comfortable. They have a bunch of security certifications, of course.

But really more than anything, we've just been there for a long time doing the same thing.

Mode and Salesforce are not the same, of course. But maybe they can be at some point, and the Salesforce example serves as a proof point that when there is enough pull from a business arm, the people who adopt Salesforce, who drive that decision are sales teams, sales operations.

It's those kinds of folks. Those folks have such a pull and so much influence over how the CISOs and IT are going to react, that if you have to have Salesforce in order to drive that business forward the security departments will find a way to make it work.

Grant: My perspective, I obviously have a lot to say on this part.

Derek: Of course.

Grant: Yeah. But basically, you're right in some regards.

In that I think there will always be some number of vendors who are available as true SaaS.

The very base is going to be at least AWS and Google and Microsoft, these infrastructure as a service companies.

Then there's probably going to be a handful of other folks like Salesforce and Slack and Box and some of these other folks that end up becoming infrastructure-esque.

But there's a whole slew of thousands, and tens of thousands of other application vendors, and you our perspective here is that it's a challenge.

I think you started the company five or six years ago, ad so now most companies that are starting are architecting from the very beginning with Kubernetes at their core.

This is just making applications inherently more portable, and you're seeing more open source core components. It's not just Spanner, it's CockroachDB.

It's all these databases that are cloud native and designed around Kubernetes, so we see it just as you would have to re-architect, but the next companies that are coming out are starting from day one with this portability in hand. Compared to the old world of on prem, the software is so much easier to run if you're distributing it to your customer and then running it in their kubernetes cluster. You're just getting this order of magnitude more reliability and less involvement, and it scales better.

We think the world will just blend these two together, and the funny thing about Salesforce I always laugh about is this great multi-tenancy thing.

We created the Cloud and SaaS, but they gave a talk last year at GitHub universe about how amazing they are at administering GitHub enterprise.

So, that's weird right? Salesforce the SaaS company doesn't use GitHub.com internally, they use GitHub Enterprise which they host on Prem.

To me, if SaaS was this obvious be all end all, then why would Salesforce use an on prem product?

It just doesn't make that much sense to me. I think this is where my perspective is always like, I think Marc Benioff and Aaron Levie and these folks have always painted the world as black and white.

It's like, "It's really shades of gray."

There's some things, some data, some areas, some customers, some companies where it's a much more complex "It depends," answer rather than "Yes or no."

And for a business, at any point time it's a yes or no question. I think you've made the right choice at this point.

You need to get out there, it wasn't obvious five years ago that this new architecture would enable us eventually.

But I think over time, our perspective is to just blend and you won't even-- Some customers will be running on prem and they won't even-- You won't really even care at all.

Derek: That all sounds right to me. I think your point about the next generation of companies that are built in the area of Kubernetes is a good point.

We've seen several cut off points. Yammer was founded before public cloud was super popular.

If Yammer were starting today, it probably would be in AWS or GCP or Azure. Azure, right? Because it's owned by Microsoft.

But migrating Yammer to Azure was a challenge, and actually was not completed while I was there.

I'm assuming it got completed at some point, but it wasn't completed while I was at Yammer after the acquisition.

I think actually the GDPR and other modern privacy regulations, which by the way, to me make a ton of sense and I think are the right way to think about privacy.

GDPR, to be determined exactly how it gets enforced, especially on companies like Mode.

We're going to see the Googles and Facebooks of course first, but then eventually there will be some enforcement for everybody.

Grant: Sure.

Derek: Companies born in the post GDPR era will have a lot less work to do to retrofit their systems to make that work.

You'll just build with that type of privacy requirement from the beginning, as there will be things like this in the future.

Probably six years from now there'll be a thing that no one sees, that no one architected for, where we're all going to have to go back and retrofit everything. That's just what happens.

But like you said, Mode makes these decisions today. What we have is a set of customers, some of whom want us to deploy our product on prem.

We could do it, we could do it, it would just take a huge amount of resources.

The reality is that what those folks want more in most cases is some additional type of value to their business.

The thing people clamor for is more value to the business. For Mode the company, yes, we have excluded ourselves from some portion of the market today by not being deployable on prem or buying your own VPC.

That's what we've done, it's a tradeoff that we made deliberately in order to get you a better product faster and in order to grow faster among the audience that we can't reach.

It's been working reasonably well for us, and we'll continue to make that decision.

Grant: Eventually you're going-- You're already probably fully-automated in terms of DevOps and how you guys deploy, and using CI & CDs.

You're doing a lot of the things to cloud native.

You're probably just don't yet have the pure Kubernetes underlying infrastructure, so eventually you will.

That's what happens, you'll have to move services after service on there and it becomes the architecture for the next 20 years anyway.

You're going to get there and then at some point, "We could just ship this."

It goes from being this huge lift to being this, "We could just do that if we want to for a handful of customers, and then if we want to scale it out, then you come to Replicated."

OK, Derek. To wrap this up, let's just do a quick pitch of Mode. How do you talk about this?

What's the 2-5-10 minute, however long you want to talk for, how do you pitch this to folks?

Derek: You already got this pitch a little bit earlier in this conversation, but it's obviously different if I'm talking to an analyst or a data scientist versus someone who's not super familiar.

One thing about Mode for analysts and data scientists, they've always "Gotten" it.

Like, the practitioners, they understand why Mode is going to make them faster at answering questions.

For a lot of them, they feel like they're stuck in this model-building hell, or they're configuring a system and all their time is spent configuring a system for other people to do really simplistic analysis.

Then the real meaty questions that they'd rather be answering, they feel like they don't have time for, or they're bogged down by one-off requests.

That's the thing that they just "Get," and so my pitch to them is very different and it's based around that.

It's like, "Mode does all of your workflow stuff that you need to do."

SQL, Python, R. It ties it all together really cleanly and allows you to get that stuff out of the business quickly, so that you can really spend most of your time on the high-value projects.

You can build the things that those folks need, allow them to then self-serve, and then you can spend your time on answering the things that are going to move the business forward.

That's enough for most analysts or data scientists.

The way that I talk about this with people who aren't practitioners, who aren't familiar, is I set it up more in terms of the types of questions that your business needs to answer.

I talk about, like I said earlier, this notion of "Dashboard-ing" really being about better administering business as usual, and the real value to your business is going to come from these insights that are hidden.

Like the Yammer example that I gave, about that new user badge, that's the thing that's going to make step changes in your business that's going to help everyone at your business become better at their jobs, and it's going to actually change metrics in a meaningful way.

That's what companies want to do . In order to do that, you need to take smart people, your analysts, your data scientists, not bog them down in building dashboard after dashboard.

But give them an opportunity to go and test their hypotheses, or test hypotheses that you work on with them as a product manager, as a CEO, whoever you are.

Work on those hypotheses, get as many turns in answering as many of those as possible, because that's what's going to help you find the insights that are going to get your business to the next level.

What Mode does is Mode makes it easier for those folks to answer questions quickly and get as many turns as possible.

Mode triples the number of cycles that your analysts and data scientists can get through, which means it triples your chances at finding that key business insight that's going to take you to the next level.

Grant: Perfect. Derek, thank you so much. It was awesome having you.

Derek: Yeah. Thanks for having me, Grant.