Ep. #2, Building for Enterprise Developers

Craig Kerstiens: This week we've got Banjot from Docker with us. I'm Craig Kerstiens, and Rimas is our host. I'll let Banjot introduce himself a little bit.

Banjot Chanana: Thanks, Craig. I'm Banjot, and I run product management for Docker Datacenter, which is our enterprise commercial products. I've been with Docker for about a year and a half. I've been in product management about 10 years or so, maybe just over. I was previously at VMware as well.

Craig: An enterprise background. I think Docker is definitely interesting or growing an interest to the enterprise. We've got a couple of interesting topics today around developers and enterprise. Those two don't always go hand in hand in the same sentence.

We can probably just dig right in. I would love to hear a little bit from a product managers perspective, how you balance out both, internally and then externally. Docker's huge with developers, massive developer adoption.

I remember Solomon's initial opening lightning talk at PyCon where he unveiled it. And from that point on, just rocket ship. But you can tell it's been a journey, it looks like it, to the enterprise. Can you talk a little bit on the product process of that? How do you balance that?

Banjot: It's been an interesting foray, because when I joined Docker, the open source adoption, the developer option, was already there. And so that's something I didn't have to worry about.

What was interesting was we were already talking to enterprises. So there was a lot of interest from enterprise IT or central IT. From the IT side of the house, the more regulated side of the house. We were already getting calls about, "How do we now adopt this? What do we do? Our developers are already using it."

And so there's an interesting journey that happened inside the organizations that we didn't really get to see. To be honest, we saw the end result of it. So that was pretty cool, that we got the benefit of it from the open source side and that it just landed in our lap, quite honestly.

That being said, we had to think about product very differently. Coming from VMware, I had a strong understanding of what enterprise IT was looking for and what enterprises want out of a product. And so we focused a lot on that.

The balance I think we tried to strike was that we didn't want to lose the value proposition that Docker brought to the developer.

We knew if we could find a way to keep the developer audience engaged with the parts of the product that they already knew and loved, and not change those pieces, but behind the black box be able to add the capabilities that we knew the enterprise guys wanted: HA (High Availability) or integration into authentication systems, stuff like that. We knew we had to add to the product, but we didn't want to change, say, the docker run interface. We knew folks just want to do docker run.

Craig: In theory, I think that makes a ton of sense. That sounds like a big "but," though. The devil's in the details. Great, go add all the high value things for enterprises, right? Support contracts, HA, permissions, ACLs (Access Control Lists), all those sort of things.

But I imagine there's a lot of "devil's in the details" down there. In particular, I'm curious around how much did you worry about alienating that developer experience? How do you test that, going throughout?

You say you don't want to change docker run. How is that one experience that you identified? How did you go about saying these are sacred to the developer, and how does that dichotomy play out?

Banjot: We started with the default that we weren't going to change any developer experience. And that was the easy first starting point.

Craig: How long did that last?

Banjot: That lasted fairly far, actually. I don't think we've actually changed anything in our commercial product. Now, what we had to do? I think think this was an interesting architectural design problem. How do you not change that interface but still provide authorization controls around the ability to do docker run?

I want Craig to do docker run. But Rimas, he can't do docker run. He can only view logs. So he can do docker logs but that's it. Being able to provide that, call it middleware or proxy, that was, I think, the ingenious part. And I'll give credit completely to the development team having figured out how to bridge that gap.

In fact, in one of our products we prevent customers to be able to exec into the container while still being able to do everything else. The ability to do that gives them an "unauthorized" when they attempt to do it. But to still allow them to do docker logs, docker run, docker whatever else, was critical.

We haven't gotten to the point where we've had to say, "That's not possible. We can't control that," but I'm sure it's coming. And I think we'll have to evaluate case by case whether it's something we say, "This might be something we have to live without," or "No, we're going to put our heads to the grindstone and just figure it out."

Rimas Silkaitis: One of the questions I have, relating to going developer-to-enterprise, mostly internal to the organization, did you find that making that transition, or at least making that part of the product manifest itself in challenges with internal culture or organization or anything else like that? Because, as you know, product is very much leading with a very soft touch. Were there any challenges internally in the organization?

Banjot: Absolutely. Well, internal to our organization?

Rimas: Yes, to your organization. Not necessarily your customers.

Banjot: Customers had their own challenges.

Rimas: Exactly. But you know, when you start off on the developer, and they move to enterprise, sometimes there's a challenge to say, "We've identified that the enterprise wants these things but the developer doesn't.

Craig: Developers love building advanced administration authorization screens, right?

Banjot: Yeah, totally...

Craig: That's what they live for.

Banjot: That was an interesting challenge, because as you guys know, with the roots in open source,

everything we've done on the commercial products is actually still rooted in the open source.

When we want to do things like add authorization controls, the big question was, "How do we do this if it's not in the open source project? Do we write a PR and try to get it in, or do we just build it as a proprietary functionality, just on our own?"

We've opted today to push that functionality into the open source. And so what we've said is the right thing for us to do is actually to get this functionality. We know that most individual developers, most open source developers, don't want to add that stuff. So we took on the burden of, "Let's write the PR. Let's push it in there."

We talked to the maintainer. We make sure they're okay with it. We make sure it's directionally the right thing for Docker as a project, and then we push it through and hope for the best, quite honestly. There have been cases where it didn't get there in time for us, or we didn't add the functionality when we needed it to. In some cases we've lived without it and said, "Okay, we'll just wait. We'll wait for the community to agree that this is the right thing to do."

I'm surprised, to be honest. I've been surprised that the community, nine times out of 10, has agreed with us. They've said, "Yup, that's a good thing for someone to do. We didn't want to do it, but it's good that you guys did it."

Craig: I'm curious, to probe a little bit more on that. Internally, how excited are the developers who work on that? Are there some tricks you've learned there? There's the cool pieces, the really awesome new technical feature. And then there's those permission controls in the open source project. Someone's got to write that. If I'm the developer, I'm picking the former. So I'm curious if there are any tricks, or have you just magically found developers that are happy to work on those things?

Banjot: It's interesting. On my team, for sure, I've got a very seasoned engineering team who's actually mostly been developing for the enterprise.

What I think has worked for us is we've actually rotated folks into the open source project and then back out.

With that rotation, we've got folks that understand how to respond to the community, how to work with the community, how to work with maintainers. And then, on the other side, they've also seen the pain when a customer comes yelling and says, "What do you mean you did HA this way?" or "What do you mean you can only do basic auth and not active directory integration with Kerberos?" So that's helped us a lot.

Craig: That's a pretty interesting model, that rotation. Is that across the board? Is that some cases? Is that up to the engineer? How does that work?

Banjot: So far it's been up to the engineer, and we definitely promote it inside the company. There have been, for sure, folks that have wanted to do it. We encourage them to do it. I wouldn't say it's mandatory by any means yet.

There are folks that stayed in open source and only really want to work in open source. And there are other folks that haven't rotated into open source yet. But just even doing one or two engineers within a team dramatically changes the interface with that team that they rotated out of.

Craig: That makes a lot of sense. We saw some of that early on at Heroku, actually, when we would have team swaps where people would trade or interview with another team, and swap, that cross rotation. Not doing it to everyone, because some engineers really want to just stay where they are, and they're happy there, which is fine. You also have some good long-term knowledge that way. That rotation creates some shared understanding, which is nice.

Rimas: You talk about having engineers that are a very enterprise focused. Was that very intentional when you brought them into the company, or was that just happenstance?

Banjot: I think it was very intentional. We interviewed folks that had that background. I wouldn't say we wouldn't have hired someone who didn't have that background, but we definitely ran into folks, and certainly my network of engineers, they're all folks that have worked in enterprise. So I pulled on those folks.

There were a couple guys from VMware who went off and did a startup called Netkine. We pulled them in, and we said, "Hey guys, come work in this really cool thing." They're like, "Yeah, this looks really familiar. I know exactly what to do, and I know how to integrate with LDAP and AD, and I know how to make sure I can stream out the monitoring systems." And so I know where all the right plugable interfaces are.

It was very much something we've focused on doing, but it wasn't by virtue of, "Hey, we'll never hire anyone who's open source." We've actually added a couple folks that have been in open source projects and are now part of the team, and they quickly catch on.

Craig: You've got a bunch of open source developers, and now here's a product manager from the enterprise, or here's a engineer from the enterprise, very different. I just felt like it goes back to your early days there, because now you guys are a bigger company, and I'm sure you adjusted to it pretty well. But how is that reaction?

I find, anytime you introduce product management to a group of engineers for the first time, it's like an immediate, "No, you're not telling me what to do. I've been working all along. I know how to write code." Especially on the enterprise side, any tips from that? Any experiences learned like, "We should have done it this way," or "This worked really well"?

Banjot: I think I was the first PM, short of Scott Johnston, who runs the product management team himself. He came in with a lot of enterprise background. I was probably the first line-level PM that he hired that had enterprise experience, and I treaded carefully.

I think my first learning was that it wasn't that most folks were adverse to understanding it; they were largely ignorant of it. And so I spent a lot of time just writing down all of my observations, even if they were things that I had heard a thousand times before. I wrote them down, shared them with folks. I think, over time, folks became more and more curious. But I think you're right. First PM into an organization, we were lucky we only had three engineers working on the enterprise stuff at that point.

We didn't have a lot of adversary action when I joined, so that was a hurdle I didn't have to cross. But gaining the credibility of the team, making sure that even the open source team knew that I knew what I was talking about or that I had the experience, I didn't start with the assumption that they trusted me or that they thought that I knew what I was doing. I would try to prove that, "Here's the customer discussions we've had to date. Summarize them, put them in a format that's easily digestible, send them out to the team. Say 'Here's what we're hearing,' and let them come to the same conclusions that I may already knew or have a gut instinct about."

I think it's no different than entering any other engineering team, but it's something that you have to be more mindful of, especially when the team is looking at you and saying, "I don't even know who these customers are. I've never heard of these folks. They don't contribute. They don't try to contribute to the project, why should we listen to them?"

Craig: I imagine it's even doubly so when you talk about some enterprise customers, some company that powers something that they use every day, but it's an enterprise company they've never heard of. It's not a developer company. it's not Travis CI, not CircleCI. It's like a proprietary CI server company, or they deliver uniforms. Something like that. It has a real business behind it, but isn't front and center in their mind.

Rimas: Let's talk about the enterprise a little bit more in detail in that regard. I think one of the challenges is recognizing that sometimes you're going to be selling to the enterprise, and that doesn't necessarily mean that the users of your product within that enterprise are going to be the same individuals.

This actually brings up one of the topics I really wanted to talk about today, which was packaging and pricing.

You think about enterprise as being a small set of customers that you're trying to build things for. How do you price things differently for that subset of the market versus the developers?

Which you may have hundreds, hundreds of thousands. Where you can throw out pricing one day and change it the next.

Banjot: It's an entirely different challenge, on the enterprise side. I've talked to folks who've done SaaS models and have done developer-oriented tools. Justen Stepca, who joined Docker just about the same time I did, came from Atlassian. And so we compared a lot of notes about what it's like to price developer tools versus the enterprise software.

One of the interesting points he said was, "We raised prices at Atlassian five times." And I was like, "I don't think, at VMware, we could have ever gotten away with something like that."

Craig: I actually vividly recall a talk from someone at VMware that I think tried multiple times to change pricing, and I think they finally did it once at the end of an eighth year tenure. I was like, "That sounds horribly painful."

Banjot: The one time we did change pricing at VMware, we got blasted for it, and we had to change it back. So it didn't last very long. We found things out, interestingly, about trying to price for the enterprise, even though there were developers who were using the product already.

We knew we had to price around some resource that they were already buying and that they had a model for.

So things like pricing around storage or pricing around servers, that made a lot of sense to them. If you price around things like an application, or in Heroku, what is it called?

Craig: Dyno.

Banjot: The dyno, yeah. We tried a couple of those models, and a bunch of the enterprise customers looked at us funny.

Craig: I think that's a really interesting one, because that dives into a really deep philosophical pricing debate. Are you pricing a known entity? Especially servers or memory, something like that. You're quickly in a commodity market, suddenly, because there's already that anchor out there.

I think Heroku is really interesting in that this new dyno, that comprises many of these things, isn't something that it could anchor against. So it was a good and bad. You had to educate along the way, but that anchor wasn't there. So I think it's a really powerful one.

Interesting that you found that heavily anchoring against that gets you through a couple of those meetings with the accounting approval, that kind of stuff. But interesting that you didn't see some of those other things. Or did you see some of those? Like, "Well, it's anchored to this, so..."

Banjot: We got pushback in both ways. We, at one point, had gotten pushback that we weren't pricing against a resource like a dyno or memory. And folks were saying, "I don't really want your pricing against some physical object, that you're providing value on top of that object." But that doesn't really align with who's getting value out of the system.

The guy who's buying the server doesn't really get the most out of Docker. The guy who's using that server happens to be using it with his containers. That guy gets a lot of value, but he could care less if it's one server or 100 servers. So there's an interesting dichotomy.

What we ended up deciding, and we knew at some level we were going to have to tweak this model, given where the market was around container and container orchestration, we decided to focus on the simplicity of our pricing model. Let's keep it one vector, not two.

We actually initially started with two vectors of pricing. We said, "We'll charge you per node, and then we'll also charge you for the number of instances of registry that you run, where you're selling registry at the time." That turned tout to be difficult because they couldn't fathom how many registers they were going to run in two years from now or a year from now.

Then we simplified further to, "Let's price down to a piece of resource, say, our server, that you guys understand." We opted for that model, to focus on simplicity, and given how quickly the space was moving, we decided that being able to educate folks, we didn't have the liberty to do that.

If I had to do it all over again, if the market was different and it was moving at a different rate, I would have opted for something like a dyno or some resource that we could control a little bit better. But given how fast everything has been moving, and the container space, we decided that wasn't even an option we could consider.

Rimas: You talk about speed and the container space, and part of this discussion right now is pricing. How do you test pricing quickly with enterprise customers? Because you only have so many of them? You don't have thousands that you can go to and maybe do an AB test or something. Do you have any tips or tricks?

Craig: You also mentioned right there, this price for a year or two. How am I going to be using it? Buying for two years from now, I can't imagine the Heavybit portfolio companies are thinking "Two years from now? I can't even imagine what we're going to be building or selling or shipping at that point, much less spreading a contract for two years from now."

Banjot: It's crazy. We have customers who want to sign two-year and three-year contracts upfront. They want to pay us all upfront. They want to know exactly where we're going to be, road map wise.

At some point you throw up your hands and say, "This is my best guess, given where the mark is going, where the industry's going." But you can do experimentation. What's interesting, my one piece of advice is,

don't list your prices if you're experimenting. If you throw them on a website, it's very difficult to try out different models with different customers.

When you do get to enterprises, and you do want to experiment, you can at some level, and not at extremes, but you can say with your first few customers, "Let's try this pricing model, and let's try that pricing model," and you sign custom contracts. That's an overhead you have to bear.

Sales order management, your sales team, all of your back end processes, you've got these weird custom contracts sitting back there. But it does allow you to experiment and learn. And then you can say, "I think we found a model that works and that's not going to drive us into the ground in a year. Let's move with that."

Craig: Rough rule of thumb there, how many do you try? Do you try five, 10, 20, 100?

Banjot: I wouldn't say to do more than five. I'd say you can do five custom deals without getting too crazy. I think when you get into 10 or 20, then things start getting difficult, because you will have those anyways.

You have to remember the moment you go into the enterprise, even if you standardize you pricing and said, "We're pricing per dyno, and it's five dollars a dyno, or whatever." The moment you walk into Johnson & Johnson or ADP or something, they're going to do a custom deal anyways. And so you end up with those no matter what, and so you have to be ready to have a buffer of capacity to deal with all of that.

One thing we did was we worked with a few consultants to actually interview, not our customer base, but our perspective customer base, to get a sense of where they were thinking in terms of pricing models and where to anchor. And that worked out really well. We got a lot of great feedback about what didn't work, and then we shortened the range of what was a possibility. At that point we could experiment quickly and then work towards a scalable model.

Rimas: Excellent. I want to go back to one of the things that we had talked about here, and that was to not show pricing on any website. That's been one of my challenges of selling to enterprises, because if I have this dual market here, where I'm selling to the developer, and then on top of that I've got the enterprise, it's almost impossible to not put pricing on the website. Because the developer just wants, "Here's my price. This is what I'm going to pay for it." And anything else that I can do on the developer side, this is quite the dichotomy.

Banjot: It's a tough one. I'd say if you can validate your developer pricing model, it doesn't have to necessarily align with your enterprise pricing model, but you can somehow segregate how they interact on your website. It's not that you can never have pricing on your website. I think, while you're experimenting, you can't do it.

Once you've experimented and you've figured it out, then make it public. Make it visible and make it known, and allow people to come in and swipe and go grab whatever they need.

Especially if they're smaller and they don't want to talk to your sales folks, plenty of organizations in the mid-market who are like that. If there's a way to segregate on your website, and we've tried to do this on our website, we have specific pricing that we say is for server and for cloud, or we actually have specific editions of our product. Docker Datacenter versus Docker Cloud, they're very much geared towards different types of customers.

Our Docker Cloud pricing is right out in the open, transparent. You can forecast it, you can see exactly how much it's going to cost you for a number of repos and X number of servers. Our Docker Datacenter pricing, we don't forecast, and we don't tell anything about. We tell you to call us, and we work it out and try to figure out what's the right model for you.

As we worked though that, we're now getting to the point where we do want to publicize it. We want to make it well known and make sure people know that it's available, and they can swipe and come get it.

Craig: I think it's a really important piece, that a lot of startups are really hesitant to have a sales person and funnel, at least in the developer world. Its like, you don't want to have to talk to a salesperson.

You don't have to funnel customers through the salesperson, but there is a certain class of customer there that wants to talk to a salesperson, that wants that high touch.

That set of customers really will self identify really well. So just have them available. You don't have to push them through it, but just making available to them lets customers self identify pretty well.

Banjot: At one point, we weren't even publicizing a phone number to call our sales team with. We started getting emails from folks that said, "I want to talk to a salesperson. Please give me a phone number to call." That's when we knew we had the right person. You definitely have to accommodate for both. If you're going to be both a developer-oriented, as well as an enterprise-oriented sale.

Craig: We were talking a little bit earlier about going from developer to enterprise. Now we're talking about pricing and packaging sales a little bit. Docker has so much initial momentum with developers, and enterprise has heard about it, they'd asked. How do you go in through an organization? How do you find the buyer? How did you find that experience? Any tips on that side?

Banjot: That was a real learning experience for us. As we started to engage, we found there were buyers at multiple levels. One would be the app development teams who may want to buy for their team alone. Very different type of buying experience. Very different expectation on the price.

Craig: And budget too, usually.

Banjot: Budget, yeah. Very different model there. We also found, at least for us, the build and release teams or DevOps teams also would come to us and say, "We're interested in Docker." And again, similarly, very different model of how they want to see things priced.

They don't want to focus on, necessarily, a per-user or a per-resource type of pricing. Because they don't control the users, and they don't control the servers. They want something that's much more flexible, that's a one-time hit by the server, by this instance type of pricing, and their budgets are much smaller than, say, operations teams.

I would say the third bucket is your operations teams, or your central IT teams, or even central purchasing for enterprise developers. Those guys are the ones that spend big. So, when they come out of the woodwork and you find them, sometimes you have to travel the organization to find those folks.

We started a lot with the individual developers. What I think was helpful for us is, when we got to the release teams, they were very happy and eager to pass the purchasing process over to the ops team and say, "Those guys will buy it. They've got the budget. They've got a lot of budget. So let them buy it, and we'll use it."

Craig: That makes a lot of sense. It reminds me a little bit of Redgate tools. They built a kind of tooling for SQL servers, and their model is like, "Give it to the DBAs." Really kind of "land and expand." Get a free version, get a cheap version, and then go into the enterprise and say, "Look, you need this." And the purchasing would be like, "No, we're fine." And it's like, "But you've got 15 people in your organization buying it, right?"

I recall one interesting piece. One of the former founders of Redgate wrote, I think, a 30-page book, "A Usefully Short Guide to Software Pricing." One of its big takeaways was, "Price the product to the purchasing power of that person." It is interesting because you could have a price point then, right there, for the single user. But then for your enterprise, IT purchaser approved of spending for the entire IT. It's a very different process and price point that you want to be at for that.

Banjot: Absolutely, I couldn't agree more. There's a phrase we used to say, even at VMware, which was, "Your buyer, your user and the person you market to can all be different people." And so you have to know how to make sure you're talking to the right person when it's a buying situation, and what their buying power is versus what you may be marketing.

Who you may be marketing to versus who may actually end up using your product; those may be three independent people with three entirely different motivations.

They may, in fact, be people who view your product very differently. That's another friction we found as well, is that sometimes the buyer doesn't know exactly what they're buying into, and the guy who's using it does. That person may give you very distinct feedback about what pricing they may allow for or may accommodate in a POC, and what they're willing to pay for something or how they want to use it.

Craig: I think it's probably not a well known fact to a lot of startups, but certain buying/spending limits are tied to your rank, and it's pretty standard across a lot of enterprises that I had the purchasing power of $100 a month or $1,000 a month, and being able to anchor that can be really powerful.

Rimas: It seems like we're circling around a concept, and one of the things that I like to do when I'm working in enterprise-type situations is building personas for the people that I'll be selling to or marketing to. Do you find that that's useful in this context? Do you do those exercises yourselves?

Banjot: Yeah, we did. Actually, when I first started at Docker, we started actually with personas. We actually called them after Star Wars characters. So it was kind of funny. And Scott even went so far as to actually buy a dummy that we dressed up. We had a Han Solo persona.

Craig: What persona did that embody?

Banjot: It was the DevOps engineer. And so we actually had Han Solo sitting in a chair, fully dressed with his outfit and a little sign that says, "I'm the DevOps engineer." We even had little Han Solo figures on our desk to remind us that this was the person who we were talking to mostly, on a day-to-day basis.

I think buyer personas and user personas are key to this entire equation.

I think sometimes it's easy to think about who the user is. I know the guy who's going to be actually working on this product day in and day out, because that's when you start your problem statements with. But figuring out who's going to be the actual buyer, I think that's where you start engaging with your sales teams, and where you start going out and actually working with them on accounts, and trying to find that buyer.

Rimas: You were out there, hitting the street with the sales team?

Banjot: Absolutely. Early on, it was as important for me to be on the street with the sales team as much as it was for them to be sitting and watching demos of our product internally. So we tried to share as much of that as early on as possible. We came up with three different buyer personas, and then we outlined what we thought the motivations were on each one, and we keep iterating on them.

We're still working on them. They're not perfectly tuned, by any means, but I think it's something. Even when I was at VM, where we kept doing year after year, every six months, we'd just revisit them and ask if these are the right personas. If you can't find them, that's when you know you got to hit the streets and got to do some research.

Rimas: Definitely will. That's what they say about product management. It's never done. It's never finished and perfect.

Banjot: That's right. And no answers are in the building.

Craig: Shifting a little bit, we talked a lot about the product management practice, and I've been fortunate to know Solomon and Scott for a little while now. It's been interesting because Docker has so much hype, and I think most companies would kill for that.

But there's a lot of hype that "it cures cancer," right? And it does all of these things. How do you manage that expectation? Both internally, but also externally, as you're building the product to a future state. How do you manage hose expectations on the product side?

Banjot: I think it's definitely been difficult with customers, because the moment they see something ship, even if it's a 1.0, they look at it, and they expect the world. They expect it to do everything that every other competitor can already do, or something they've built internally.

They're like, "You guys are Docker. There must be thousands of people in that company." And there isn't. "You guys must be able to build this, lickity split, no problem." So it's been extremely important for us to work with the sales team and the sales engineering teams. We have a small number, so it's easy, but we keep them very much abreast of what's coming in the product, what's there today, where the caveats are.

What are the conversations that you should have upfront? If we really think this is a really good prospect, we're talking to a customer and we think this is a very big purchase and a potential customer, let's be transparent with them about what's there and what's not there. We don't want to get into a situation where they expect something that's not in the product.

That tight loop with sales and sales engineers is so important early on, and it doesn't seem like an obvious thing to do, even if you're still in development of the product. We were even pre beta and not even alpha. We literally just had a prototype and we're trying to get our first iterations done. You know, that was the time to actually start setting some expectations with customers and with our partners, as well as with our own sales team.

But I'd say for most startups, if you've got a small sales team, keep them close. Keep them as close to engineering as you can. Not next to an engineer, but keep them.

Craig: You mean sales can sometimes distract engineering?

Banjot: Yeah, sometimes... "Hey, could you just do this one thing for this one customer?" But I think it's important for them to see all the works and know that the works are there. Because they can help you sell around them, too. Sometimes what we think is an impenetrable, awful gap in the product, they look at and say, "I can find a way to sell around that. That's not horrible, and I'll make sure the customer knows. But that's not something that should prevent us from closing a deal."

Craig: You mention that iteration, that tight loop with them. How does that work? Is that just face-to-face, email? What are your mechanisms there for actually staying in that tight loop with sales?

Banjot: For me, the way we kept tight loops, and we didn't do it as well as I had wanted to, but I think the things that I would advise are to have some sort of, whether it's the end of a sprint or maybe it's at the end of every other sprint, you give them a quick roundup of, "Here's where the product is." Let them see the product in its early stages. Let them ask questions.

We would have very open demo sessions so that the sales team or sales engineering team or product marketing team, and at this point we're talking about one or two people, invites them into the room and lets them see what's there. Or recording it and sending it out for them was important.

We also set up Slack channels right away. We've been using Slack internally. We set up Slack channels so that sales, engineering, product management, we could all be on the same channel. When we were small enough, it worked. Eventually we carved off a development-only channel, so that the developers and product managers could have their say without always putting something out there that might not be ready for sales digestion yet. So that worked really well.

Honestly, we used in-person, Slack and email, and that depended a lot on how the team digested it. I would say our VP of sales was a big email fan. Our sales engineers loved Slack, and product marketing loved in-person. We would do all three, and that took a lot of diligence on our part to make sure we were consistent across all three mechanisms. But it just depends on how the organization grows up communicating.

Craig: I think that's a key piece of product management. You're the interface of so many other teams that it's important for them to interface with you, but for you to figure out how to interface with them so that they hear it. That it's the mechanism that they like. It's not that you sent an email out to the entire company. You have to assume that no one read it, and you have to make sure they actually consumed it some other way.

Banjot: That's right. If you can train folks, which I think, over time, what we've done is now trained our sales engineers to come to us via Slack. We've eliminated at least one of those mechanisms. We've started to move away from email and just do pure Slack, person-to-person.

Craig: And how is that process? How did you train them in that process?

Banjot: We started sending things via email, and then over time we would say, "We're going to start announcing these types of things on Slack only." And then over time they actually appreciated Slack much more than say the account managers did, but over time the account managers followed their lead. And so it took a little time.

It took us probably about three or four months, but now we're just all on Slack, and so it just comes across on Slack, everyone sees it. You can assume largely that everyone's read it, and then we try to still do a rollup every so often and say, "Okay, here's everything that's happened. Just make sure you're still aware."

Rimas: Talking about sales, one of the things that all the sales people I interact with really want to know is road map, right? We touched on that word once today, and once they get ahold of that road map, man, it's like sales are just happening all over the place, by what's on that road map.

I know there's a want to share stuff, like what we've just been talking about. But how do you manage that expectation between road map, which may or may not happen in the future, and giving your sales team enough information to make that next deal?

Banjot: That was tough. That was an area of friction, especially when you haven't shipped yet. You're pre 1.0, and everyone's like, "What's coming?" And then, as soon 1.0 hits, everyone's like "What's coming next?"

I think two things that we learned there was, as soon as we shipped our 1.0, we tried to have a road map ready. But that road map was only accessible through product management. We found out pretty quickly that it was not scalable, because almost every customer looked at our 1.0 and said, "These are interesting features, but I want the 'next' things. Where are you headed?"

Craig: What do you mean by "only accessible through product management"?

Banjot: We literally hid it in a folder and said, "If you want to have a road map discussion with a customer, we will not tell you what's in the road map unless you bring a product manager into the room." And so that helped us in two ways.

Craig: That feels pretty safe. My default experiences, I don't want a sales guys promising the product features that I don't know. I'm not in the meeting, so I don't know what's said.

Banjot: That's right. I think that's the traditional, conservative approach, which worked for a little while. Then, as we started to grow and add more account managers, one of the things we did was we enabled one or two of the SEs that we really trusted, and we worked with our SE manager, Chad Metcalf, who had come over from Puppet Labs.

We worked with him and we said, "We want to give you the road map, and we're going to tell you exactly what's in there." We knew he was technical and savvy enough to know what to promise and what not to promise. In fact, he never promised, so that was great.

What we did was we enabled him on the road map, and once we did that, what happened was interesting. We were able to use the road map as a selling tool as well. We actually had him talking about the road map and then coming right back to us with feedback about a given feature.

At one point in our 1.0, we had Roger, who was running sales, call it our "four magic features." He's like, "I need these four features to sell the product. You get them in as quickly as possible, we'll sell this thing." We said "Great." We needed to know which one comes first. And Chad was able to get though a number of customer conversations, find out that here was the one magic feature that if we could do it, that would push everyone over the edge.

We basically upturned our entire road map to get that one feature in before anything else. And so, just by enabling an SE that we trusted, and being a part of those conversations as well, we were able to figure out that there was a single feature that was really going to make it.

So now we've gotten to the point where we've got enough product out there, they're not selling road map anymore, and when we do want to have a road map discussion, we're back to, "Call a product manager," which works well. We did have a point where we put together enough of a road map that was, say, based on first half, second half or next quarter, and then everything else. We gave it to the sale team and said, "If you need this, pull it out. But you can't promise anything. You have to call us before you promise a customer one of these features."

Craig: That makes a lot of sense. I think the conservative side is always safest if you can be there. But kind of deputizing an SE to be able to have the technical details, not promise too much, and then also come back and what that associate PM had and say, "I can prioritize things too, because I'm hearing the customer conversations, and they're already in a lot of them."

It's not an extra meeting for them. It's not extra time out of their calendar, and getting that validation of sales would come back and say, "These four, they're all my top priority." Actually getting that ranked list is important.

Banjot: It helped us a lot, and it depends on how big your sales organizations. I think, for most startups, you want to be in every conversation anyways.

You hold the road map tightly to your chest, but as your team grows, you have to find a way to scale it and not get it out there in full public view. But use it as a way to help you prioritize.

And your SEs can do that. That's something that they probably should be trained and are able to do.

Rimas: That was actually my next question. When's that progression from holding it tight to your chest to then giving it out? Because I feel like that goes with the growth of the team. I feel like there's got to be some inflection point where you say, "This is it. Now it's time to switch over."

Banjot: I think we got to four SEs, and I think we had about a dozen account managers at that point. Depending on how busy they were, they got to a point where they were busy enough that we couldn't scale to accommodate all those conversations. To be honest, it wasn't necessary for us to be in the conversation to figure out exactly what the feature was. We knew what the feature they were going to ask is about.

Craig: You're not usually in that first conversation, either. It's the second or third or fourth. So they're taking a lot more meetings. It's not a one-to-one mapping of their meetings.

Banjot: Exactly. We weren't in every meeting. It was the meeting where they said, "We want to talk about your road map," or "We want to talk bout this feature. When is it coming?" That would be the point where it was only two of us in product management, outside of Scott, and so at that point we knew we had to scale a little bit farther.

I'd say it came and went, so we scaled out, and then we kind of scaled back. We said, "Now that there's enough product out there, and you guys are selling today's product, not tomorrow's, we've got enough in the 1.0 or the 1.5 or the 2.0. Now keep selling." Now we've gone back to holding our road maps to our chest and saying, "Nobody knows the road map except us. Call us when you need it."

Rimas: Was there ever a period that you never had an SE on the team, and you were playing that role for a little while?

Banjot: I was lucky. When I came in, I joined literally the same time Chad Metcalf, who is our SE manager. He came on at exactly the same time. I would say we were tag teaming for a little while. He was hitting accounts. I actually wanted to be in those conversations as well. I told him, "If there's any conversation you can't be at, and you need an SE, I used to be one, so it'd be great to help out." And he was like, "Wonderful."

Once the account team found out, my calendar just got booked for two weeks with back-to-back meetings. It was a great learning experience.

You learn a lot by hearing your account manager pitch the same thing that you're trying to build, and hear how they're positioning it.

See if they've got to back pedal or dance or whatever it is. And then sometimes they'll just put you on the spot and say, "Banjot, since you're here, why don't you pitch the product?" And then you do your own dance. It's a fun tap dance once in a while.

Craig: Thanks for the time today. I think we covered a lot on developers, enterprise, a nice spread in between. Before we wrap up, any big advice from going from developer to enterprise? Anything we didn't cover today? Any tips or tricks for other PMs out there, or founders working on that developer crowd and starting to think about the enterprise?

Banjot: Just to summarize the things we talked about, I think developers are a different buying experience. They're a different user experience. They are an entirely different persona than if you've traditionally sold to enterprise, and vise versa. If you've largely sold to developers, then selling, and users of the enterprise, look entirely different in the way they buy and what they buy. And what they buy on is entirely different.

It's good to know both sides of the audience, if you're selling to both, and if you have to, or if you can figure out your funnel from one to the other. Figure out exactly how you market, or have users that are developers but buyers that are enterprise. It's possible to do. We're certainly starting to see that in Docker, and I think it's something that every startup, it should be heartening to hear that, that is a very possible business model.

Craig: Awesome to hear that it is possible. Just because you have a ton of free developers, you can actually create a business on the other side. Thanks so much for joining us today.

Banjot: My pleasure.

Rimas: Thank you very much.

Banjot: Thank you, Craig. Thanks, Rimas.