Building an Enterprise Roadmap

Introduction

First, thanks for having us here tonight. Marianna, welcome to Heavybit. I think this is your debut event, right? So, Heavybit is this incubation space for mostly developer technologies, founders and companies that really focus on working on next-generation technologies and tools for developers.

A lot of the problems they have is they have great ideas selling to developers that understand developers a lot, but making that transition from developer ecosystem, developer audience, to enterprise audience is a big leap, sometimes. So what we want to do for the next 45-60 minutes is to pick your brain around this transition.

In full disclosure, Marianna and I go way back, since we were together at VMware, in the trenches for many years. Now she's running engineering at Docker where I'm a board member. But before that, she was at Ariba, which was early enterprise software both SaaS and selling a product. And so Marianna has a long career in terms of shipping enterprise software.

Building an Enterprise Roadmap

Maybe the first question is kind of the surprises or challenges. So, when you think about building out enterprise software, what are the biggest challenges in your mind? The big surprises? You've done this multiple times. What kind of warnings would you want to give to the founders out here?

Enterprise Software Challenges

Marianna Tessel: Right, I guess maybe the big surprise is that probably there's no surprise. When you think about building enterprise software, it's pretty much what you think of enterprise software is to be. It's that enterprises expect quality, security, resiliency, everything pops in your mind when you hear enterprise software is pretty much what they expect. I'm not sure that there's anything there that is like a magic wand to master enterprise. But I will tell a few things that became really clear as you go into enterprise that maybe are not 100% obvious.

We talked about security being a big deal. There's all this topic of how you integrate into their existing systems. That's a big deal in enterprises. And pretty quickly they're going to say, "Oh, but I have an LDAP system, and I have an active directory," and this and that. So you kind of thought all of these you can throw out of your MVP product, but very quickly they come back as things that they have to do. Because there's these one or two customers start talking, and they have that system, and you need to integrate. So that's one thing that maybe is a surprise.

Another is the kind of relationship that they want to develop with you. Obviously, if you develop open-source and just want to send and forget, then you can do that. But if you're really trying to establish a relationship with them, and you're really trying to build enterprise software, then they expect that you have all these mechanisms in place to work with them, that you have support, that you will understand what's critical for them, that you will issue patches,

InfoSec could be a big issue for some of them that you will keep them up to date, all of these things. And partnership. In fact, Jerry and I were together at VMware, and one thing that became very clear is that if you're lucky, and it's kind of true for doctors as well, if you're lucky and you become one of these leading, they see you leading a trend. They almost expect this new level of relationship with you where you're like a strategic advisor.

As a company, they want to see where is the field going and how you're going to bring them there. Sometimes they bind to your company, not just because of the product, but they believe you understand this market. You're going to take them on this journey, and they want to partner with you. If you're lucky, you will elevate the relationship pretty quickly to a partnership, and you will go to the levels of the CIOs and the VP of IT, and all of these functions. And that's when you know it's in a different level.

Simple things as understanding that even when you run an engineering function, being available for the customers and being able to pick up the phone, and when they have a problem, to really be there and understand their business. Not your business, their business. You understand how critical it is. You really are there partnering with them, not just like, "Oh, this pesky customer. They're calling again." No. "I'm in it with you. I'm going to fix it for you." That's a big deal, especially for early, early adoption, getting that early credibility.

I would say on the software side, just to summarize what you expect in all the qualities performance, all these different things. And then on the integration and on the partnership side and how you work with them is really critical early on.

Jerry Chen: I would say that through the nuggets I heard there, number one is enterprise buyers really are buying the vision, the roadmap. So you ship them the 1.0, but they're really along the journey where you're taking them.

You're selling the vision more than anything else.

Number two goes to your point around integration and support. They actually want you to be empathetic, to understand their needs. Basically, you had to say, "Hey, there's a bunch of lightspeed technologies out there you need to work with." And they expect you to actually provide the level of support, but also integration of those technologies.

Modern Dev Experience to Enterprise

One thing that I've talked about in the past, and you kind of touched on, was usability of design in your experience. Historically, when you think enterprise software, it's kind of clunky green screen or terrible prompts, and everything still looks like a Windows 95 terminal. Whereas we're spoiled as consumers with this beautiful iPhone or Android apps. Just with a swipe, I would like to pull an application, or something like that. How do you think about bringing contemporary, modern design, user experience, to enterprise software, especially developer software?

MT: I don't know, who has designed Facebook or whatever mobile cool app. When I go to the office, I really want to work with this horrible app that has really bad UI. I think the way to think about it is really to know enterprise UI and consumer UI, so it's fair game to take.

In fact, you look at some of the companies and what they have done, they've taken some concept from consumer UI and they put it in enterprise UI. It looks beautiful and has beautiful colors. Though, I've heard somebody say, "You don't want a too consumerish color in enterprise. They want to make sure you're serious." So don't go too much like, whatever, pink. You want to take those concepts and put them into enterprise.

I would say why I think enterprise has bad name on the UI side is because, truly for most enterprises, it would be really great, but it would be less important than some of the other things.

They will forgive you for some of the UI, but they will not forgive you if you release bad quality. That's unforgivable. So that's why organizations naturally start twisting their resources toward those things, and they do it less on UI. But if you can do all of it, and if it's available to have a great UI, that's important.

Enterprise buyers and decision makers, as far as purchase, they're the same people that actually use consumer apps. That's a really well-kept secret. It's actually the same people.

When they look at fancy dashboards and all these different things, they want that. Again, you remember from VMware, and sometimes it's enough to have something with, "I have this dashboard for you, and this and this, and lots of colors. Maybe you can't understand it, but it looks beautiful." It works wonders in sales as well. So it's nice to have these things, because they want it and we want it.

Similarities Between Enterprise and Individual Devs

JC: So enterprise buyers are consumers too. It's nice to know they're human. Maybe move from enterprise buyers to developers, or we tend to say "developers" as a kind of big, monolithic population. But not all developers are the same. How do you think about enterprise developers, folks working in IT at a large investment bank, a retail company, an insurance company or a manufacturing company? How do you think about enterprise developers? What are their needs, or how are they similar? Or how are they different from folks at Heavybit or folks at Docker or folks in Silicon Valley?

MT: Many of the companies that will start new today, they will start with a cloud provider. You will have very, I don't want to say loose, but maybe less heavy processes. You will be very fast to adopt. What you will find at very traditional enterprises is that they have processes that are set. They often have their own data center, sometimes because of legacy reasons, other times it's because they have to. They feel like they need to have their completely sealed environment.

They have a lot of internal processes, some of them outside of the control of that development team. Again, our InfoSec team said this, or that team said that, or IT team. That has a very, very quick impact on the process of development, how fast it goes, how many teams are involved, the different checks and balances. You end up with a pretty different development process that, again, speed, tools, how quickly you adopt tools, etc.

Having said that, it's kind of interesting that, even in those big enterprises, and again we see that today at Docker as well, how their evolution starts with developers and how they still pick up tools, open-source, and they bring it in. They bring it in.

JC: It used to be, IT was kind of a top-down, centralized decision. You're going to write in Java. You're going to write in .NET or something like that. And today we're seeing what I've been calling developer-defined infrastructure. Developers are making decisions, and that's how Docker's getting grassroots adoption.

When we think about this grassroots adoption, new technologies and new languages, it can be something like a Docker or Hadoop; they're all starting in the open-source community, more or less. I can't think of a new infrastructure, storage or a new data technology (there's a few exceptions in the past five or 10 years) that didn't start in open source.

Open Source and the Sales Process

How does open source change the product process or the sales process? You start with this great open-source community. I think when I invested in Docker, there were 100,000 downloads in the Docker engine. Now there's north of two billion. You think about that usage of the technology out there. How does that help or hurt this product and sales process?

MT: First, it's interesting what you said about how it changed the products. It used to be, and I don't know how many of you actually remember or been in the Valley at that time, but it used to be that you would say "open source" and that would equal to, "Hey, maybe you shouldn't use that."

JC: It's a four-letter word back then, yeah.

MT: Not good quality, you don't know what you're getting, etc. And then, over time, there has been this real change there, where open source now equals freedom, quality, flexibility, integration, all these different things that people have, and that's a real change.

In fact, there's this famous Linus rule, which is, "With enough eyeballs, all bugs are shallow." Meaning that with enough people working open-source, you will find all problems, and you'll end up with better quality. And, honestly, that is true.

Where the community is becoming more something that companies want to be involved with and developers want to be involved with, then the quality of open source has been surpassing some of the closed-source quality.

Basically, there's legitimacy to using open source, which is very important.

Now, at that point, it really becomes a very legitimate sales tool, because now you have this unbelievable distribution platform. You put something out there, and very quickly it becomes available to everybody. It's free; you can't beat the price. You have this way to reach a very broad audience. You can create momentum around this.

You can get the stars and the popularity and all this going, and you can create a whole funnel around this really quickly, without the traditional "You need the salespeople, and you need a big marketing campaign," and all this. So it became an unbelievable sales tool.

Now it's a question of how you go to the next level and how you monetize. From the get-go, you think about, "Hey, I don't want to ship really broken code, but I really want to think about how I'm going to build a business out of it and how I'm going to have enough control points so I have a business."

Jerry, you and I talked about this "land and expand," and is it turning more to "expand to land?" Because you start from expansion, and then you start actually landing this account. I was thinking about it, and I think it's really "expand to land to expand," meaning that you start from, "Get all of your code out there, and everybody use it." Now you want to land this account. Now you want to expand again once you've landed this account. With selling them more and more software, you go through this process of expand, land, expand.

JC: That point is expand, land, expand, expansive use of your product technology out there, usually from open-source uses and developers. Once you have critical mass, you "land a big enterprise deal," and that could be either selling support or monetizing with security or enterprise features.

Then your second expanse is really the key one, because you have to expand beyond just selling support to open source, in my opinion, for a viable business. And so it's expansive usage, land a commercial relationship, and then build a business on top of that.

MT: I would even say, even stronger than what you said about support, if your business is, "I'm going to do a bunch of open source that I'm going to have support," you probably want to think about it.Because that's really quickly going to come to a wall.

Plus, it's very easy for somebody else to offer support, as well, and guess what? They probably already have a support agreement with other companies that will say, "I'm going to offer support, as well." So again, if your business model is, "Let me start open-source, then let me offer support," I would think about a business model like loose product.

JC: So, let's double-click on that expand-land-expand pain point, specifically around Docker. Really, we're seeing this shift in technology from monolithic architectures towards microservices. I think Docker containers and microservices almost go hand in hand because this move towards microservices really demands the use of something like Docker, and Docker enables microservices.

Transitioning to Microservices

When you see the land, which everyone using Docker, building microservices, expand and then the land, what are the pain points you're seeing in these customers after that lease of the land? What are the challenges you're facing when doc microservices are adopting Docker? What is that hook of the conversation that you're having with the customers?

MT: I think a lot of companies, the problem that they have is that they might have an app that they already have, and now they want to move to microservices. So they have a double challenge. "How do I build something that is microservices?" But also, "How do I convert from a monolith to a microservice architecture?"

They having hard time with understanding how to break apart the code, sometimes go from stateful to stateless, and also how to organize their teams and their processes around them. So the challenge could be cultural just as much as technical.

Honestly, for many of them, they actually found that they can use containers without necessarily breaking apart to microservices. Whatever new they do they will try to do in a microservice way. But they could probably take a lot of the other software and break it slightly and put it in some containers, and it's good enough.

You can use volumes, other ways to achieve the same results with containers. They can kind of reap the benefits without going through a whole re-architecture. I think a good approach is obviously to say, "Okay, everything new, I'm going to start. And slowly I'm going to 'convert.'"

JC: The mentality is very different. I was talking to an architect the other day. He was talking about the half-life for one of his VMs was something like 12 or 18 months. The customers brag about how long their virtual machines used to run without a reboot. It was solid. And he said the half-life of his doc containers is like three weeks.

So, you're going from 18 months where these are long-running VMs, to these containers which run for three weeks. Now he's got this hybrid environment, like you described, where he's got some long-running VMs and some of these short-running microservices. But it's fully transitioning more towards these services that are up for 30 minutes to three months and then disappear.

It's real interesting to see this transition to these customers. When you think about talking to the same enterprise buyer who's moving from either a model of application to microservices, could be from VMs to containers to Docker, if you rank order all those things they want: security, usability, cool logo sticker for their laptop or something, what are the P1s, P2s and P3s?

Enterprise Must-Haves

Give some tips to all the developers and founders here, as you kind of rank order the roadmap. What are the must-haves? Is it security? Is it reliability? Is it scale? How do you think about the top one, two, three things that they can't do without?

MT: I think the P1 is the sticker.

JC: Yes! So you need a cute logo like a whale, right?

MT: Yeah, then you can start having a conversation. Honestly, it kind of depends upon the phase you are at. If you're already established, and you are part of many of these companies, and once you establish a quality bar, that's it. That's your new bar. You cannot go below.

Then I would say quality, security, performance, all of these will make it to the top. But when you're just starting, they will forgive you on some clunkiness in some areas. And normally, big enterprises are going to go through dev to test to production rollout, and there's a grace period of time where they will try a software in their environment.

They will slow-roll it into their organizations. There you can play with some of it and give something and understand what they need. Then again, at some point, they want to have this RBAC, role-based access control, which is integration through their existing systems and things like that.

It's also important to understand what kind of app you have. Because we're talking about enterprise apps. So, obviously, if you have infrastructure app, they run their infrastructure on it. They expect that it will be there, it will run, it will be solid, that they can count on it. But if you write a T and E, in Ariba we did a "Travel and Expense." So, if you write in T and E app, again, maybe if it had a little outage here and there, it's still bad.

If you didn't sum up the numbers correctly, that's a big problem. So, think again, who is the audience, and what is your app? And what's really critical for them? But the quality is always up at the top to enterprises.

JC: Specifically, what is the purpose your application? Is it Time and Expenses or Travel and Expenses? Is it infrastructure? What function? The quality for that function has to work, right? Infrastructure has to run. You can deal with a UI bug here or there, modular or design issues, clunky screens, but infrastructure is your P1 reliability.

If it's T and E, uptime doesn't matter as much. But you've got to get the decimal points in the right place. If you juxtapose the decimals and the commas, you're kind of screwed.

Figure out what's the purpose of your product first. Because not all categories are equal.

Who Are You Designing For?

One question to follow up on that is, in your role at Docker, who are you designing for? Are you designing for the developer? Are you designing for the IT owner? You have all these audiences now, and they're starting to blend. DevOps, ops dev, or whatever hashtag term people use these days, who are you designing for, do you think? Or is it multiple personas?

MT: Yeah, we definitely have multiple personas, and there are parts of the product we think of a developer using them. And there are parts of our platform that we think maybe it's more for the IT orgs, but those organizations are also kind of merging, and there's many DevOps. It's hard sometimes to even tell the difference. It's all becoming one big, happy family.

I don't know if you have a question about it, but just to mention, we have another audience, which is our community, and our ecosystem. And that's a very important, especially if you have an open-source project. That's a very important audience for you, as well, is to understand that community, be true to it, and think about them.

JC: The IT and operations are blending. Your design for one is designed to the other, over time, especially. But you can't lose sight of the fact that you're also designing to the open-source community,the millions of users of Docker out there and all the committers and contributors, which is an important reminder.

Pivoting from the specifics around technology and Docker-specific and maybe more back towards learnings around building teams, run engineering teams, and feedback across, because not everyone here is in an infrastructure space, the goal for every startup is to be that big company, right? And scale off from two or three folks in a garage or a beautiful space like this.

Scaling Teams and Hiring

You've done this a few times, scaling from very small to hundreds of millions of dollars. How do you think about scaling your team to meet the needs of these Fortune-500 buyers?

MT: There's talk about how you scale your company, not just engineering. In the beginning, you'll start from a small team, less processes, and you'll add more and more thickness over time. But from a company point of view, I would say, at the beginning maybe you don't need a big sales team. And if you want to rely on open source, then you going to rely there, and you don't need necessarily a big sales muscle.

Over time, you start building more of these customer-facing functions and support and customer success. Even within the beginning, you don't need to think about how you're going to produce patches if you're on-prem software. Then later on, you're going to start thinking about that.

Think about the evolution the organization is going to go through, and think about it as, you're at A and eventually it's going to go through C, but in the middle, you have to go through B. So you don't want to, from the get-go, design this really robust and big org, but say, "This is the direction, but I'm going to go through a phase of something in between that has some things, but it doesn't have others." And build it over time.

JC: The growing is hard to sequence out. If you think about those functions you said: engineering, support, customer success. Which of those functions would you recommend? Don't be afraid to hire ahead, hire slightly early, and those, you'd say, whatever you do, don't hire too early? Sometimes you say, "Sales: don't hire too early." Or somebody could say, "Customer support: you'd rather hire early than late." Because you're never going to get it perfect.

So, if you would say, I don't know, support. Would you err early, or err on the later side, or what would you think about that?

MT: Obviously, start from engineering and product. Start early. If you start from sales, that's wrong. I would actually say that maybe at the beginning, support. You can think about it more like even the engineer, bare, so you don't necessarily have to hire for it, but you have to kind of plan for it.

Create the thinking around it or the culture around it where you want to support your customers. Today in many of the SaaS products, you can do online support. Then a lot of the developers can support customers online, and that's not necessarily a bad thing, to create a culture.

Over time, maybe you choose a product to have tickets and things like that, and you don't necessarily have to create a function. So maybe you create a virtual function by starting to think about those things. Have multiple people wearing multiple hats, and over time, you actually hire a support expert. You actually hire a sales expert. And I would say maybe then you hire one, two people, and then you scale up.

Maybe it's not even if you hire early, you don't start from, "Okay, now we have a budget! Fifty People! Sales!" You don't have anything to sell. They're going to get really frustrated.

JC: Believe me, I have this conversation at the board level all the time. When to bring in your first sales rep, when to start thinking about a professional function around support. I'm going to skip ahead a couple of these questions.

Product/Market Fit

Going back to the staging, often times when you hire sales, when you hire support, when you pour the gas around engineering, this is when you find that magic moment around product/market fit, PMF. It's frustrating because we talk about it a lot. But it's not something you can describe in 140 characters or less. What are the rules of thumb? When do you feel like you know you've found product/market fit, or you're at least approaching something that you think is product/market fit?

MT: Obviously, when you go in and investigate, and you talk to companies that start nodding their heads, and they get really getting excited about what you say, then you know you're onto something. But nodding their head is not actually putting the money down, writing a check.

Ultimately, you only know when they write the check and they're willing to put money. Everything before that is just testing the waters, and thinking about different, you know, how you would optimize it. Are you going to get something that's so much better, that's going to give them speed, that's going to give them scale? What is that axis you are going to go after? Understanding that, testing that and going on.

Very early on, you find that if you release early and release often, and you let them try it and give you feedback, you will find your market fit faster. If you're like, "I asked them a lot of questions, and now I'm going to go in a bunker, and I'm going to build this unbelievable software to release it in a few years," it's obviously a super old methodology.

You have a guess, you have an MVP, and you release out there. They start liking it, start asking for more, then you know you're onto something.

Pricing the Product

JC: That point, especially for the startups, you probably have a bunch of early adopters that can be the open-source community or beta testers for a product. And typically, you're working beta, you're shipping often.

Then at some point in time, let's say you might be at your customer like, "Hey, Marianna, you need to start paying for 'that software.'" And it's always kind of a great moment but a scary moment. When do you know when to ask for that first check? Because sometimes betas can go on forever, especially SaaS software.

They'll keep pushing patches. They'll keep asking for more stuff, because why not? It's free. But at what point do you draw the line, saying, "You know what? At this point forward, we need to enter 'the commercial relationship.'" Are there signals? Or do you keep asking until they get grumpy, and when they get slightly grumpy, then you know you've found it.

MT: When you roll, even a new SaaS product, even from the get-go, if you say, "Everything is free, and I never thought about how I'm going to charge for it," that's honestly a bit of a bug there. I would say, even there, you want to offer a lot of free stuff, but have a notion of paid tier.

I think it's good to educate customers that your software is not free always and for everything.

Start something where they know that you are something that they're also willing to pay for. Not just, like, never again think about money and the relationship with your company. And then, obviously, over time, think about how to create more and more value in paying tier.

You will know, and we've definitely seen it in our offering, where we offer a particular aspect of our software or even in our Docker cloud, and very quickly we'll see customers asking, "Can I get 'this and this?'" And you're like, "Okay, that's something that they want. That's something that they're willing to pay for.

Milestones to Enterprise

JC: If you think about Docker in the past two and a half years, from open-sourcing it in 2013, were there milestones along the way that brought you more towards this enterprise product? Where clearly it was open-source early, and then for the past year, year and a half, how did you nurture this community and nurture the enterprise interest? Talk about that process a little bit.

MT: That'll probably pertain to many of you who will have an open-source product and a vibrant community. I will just talk about that for a second. That's a really critical thing for us. And in everything we do, we think about it. So we want to be really true to the community and understand it, again, not just say, "It's there, but we don't care about it."

We really think about it from everything we do and how we do work, and I had this talk where I talked about the community, and there I shared statistics that in every Docker release that we put, actually a very high percentage of those contributions come from the community. It's sometimes 70%, 60%. This is a very important relationship to us.

What's interesting is, even our internal teams, they are part of the community. Some of our commercial teams, they need things from Docker engine, and we say, "Okay, you go contribute the code in." And they go, write it, and they are also playing a role of being part of the community. That's, again, a very important thing for us that we can stay true to that. And I forgot the other part of your question.

JC: Well, just the whole process. Like "community first" was the clear takeaway around something and is probably so true as to why Docker is still so successful.

Because from product to support to engineering to sales, community comes first.

Then over time, what were either milestones? I don't know, is it something you conquered, like, "Hey, when we hit X number of poll requests or GitHub stars," do you say, "It's time to print the T-shirts, or something like that? Or, it's probably not formulaic, but what signals out there do you look for?

MT: It's kind of interesting, because in the Docker life cycle, I remember in 2014 we said, "Around 2017, enterprises will come in." And within a few months, they were already there. A very obvious sign is when they start knocking on your door, and they start asking, "What is your enterprise offering?" That's a pretty good sign that you need to have one.

But, obviously, when you start seeing adoption, and if you look at the kind of users that are getting adopted, that's a good sign. And again, ideally, you already have in mind what your enterprise offering is, but maybe you haven't started coding that. But it's not something that is a surprise to you that you discover one day you need to develop. It's something that you probably should have in mind.

JC: Great. Well, those are all the questions I had and also those submitted from the community earlier. So, maybe if we have some time, we can take some questions from the audience here.

Q&A

Individual vs. Enterprise Product

MT: In our org, and you're asking about organization, if they're separate or combined, do we have a separate open source, right? I mean, all of the community open source, we do very carefully want to manage that separately. But in some of the enterprise offerings, many people will take our product and go from dev to production. So we actually do want to offer it as not necessarily different.

It's one of the nice things that we have, is that you go from what we call "build to ship to run." We don't want to necessarily offer those as disjointed products, so we think about it as a continuum, how we exactly organize to deliver that.

It's also a function of how we use the open source as part of what bits and pieces we have. What did we acquire? So, some of it, I would say, has to do with more mechanics around it. But, in general, we do also think about it as microservices, so we want to separate it. We want to use a common code as much as possible, and from a product point of view, we want to develop something and ship something that looks like a continuum and has the same experience, as you graduate with the product to different parts of it.

Integrating Open Source

Depending what you think of open source, what role it plays in your offer, if you say, "I want to put it open-source because I want to gain the developers." And the community comes in, pitching in and maybe adding different aspects, that could be a consideration.

Another one is as a distribution channel, as putting it out there. I would say that sometimes you can think about, "Hey, maybe you can start with a free version, so it can accomplish similar distribution without the need to manage community." It's kind of depending what you're trying to get from the open source.

Are you trying to say, "Hey, I want to have people contribute. I want to be able to pull the start and get developer momentum," or you're saying, "Hey, if it's just a distribution channel, and it's truly not something that you want to have developers pitch in," then maybe you can also think about it, "Hey, maybe I should have a tiered pricing and freemium and just kind of see how it goes."

Another idea is maybe there's certain aspects of your product that you want to open source, but not all of it. Doing an open-source project is awesome, but it also needs to be part of your DNA at that point. So you can't say, "I'm open-sourcing it," and then, "I'm forgetting about this, and I'm going to go about my business," and start developing as if it's closed-source.

It is something that you need to be committed to if you want it to be a successful open-source project. Again, one thing that I see many companies do, is they say, "I'm going to open-source this component, so I have some aspects of the benefit. But I don't want to open-source all of it." Think about the reasons. And I think these are the most common ones that I mentioned.

Owning Next Steps

Think about Docker. In the last year and a half, it went from 30 engineers to now over 100 engineers. As you go from that transition, it started from no product to having a product, as you go through this transition, you're going through all sorts of phases. Some of them are when you're an awkward teenager, and you have some things, but you don't have others.

We're probably going to go through a few of those. I obviously like this agile concept of a team that works together and has a clear product owner and a clear engineering owner, and they all are as part of one team. In my experience, that's when you say "product owner."

The question is, do you talk about someone that drives the execution, or somebody that drives the design? In my experience, especially with enterprise software, it's actually super, super useful and important to have product feedback. Someone actually goes and sits with the customer and understands what they want. For some products you can say, "I don't need that, because I understand it," or, "I have something in my company that resembles that, and I don't need that."

But for many, you have to go and ask them, understand what they need and understand how it fits in their environment. And if you don't have somebody that asks these questions, then very quickly you're going to maybe start from something super cool, but quickly you'll find yourself, that you don't understand really their needs. I guess what I'll say is, do you need somebody that gets product feedback for you? Again, my experience is, yes, super useful, super important.

If you want, that often becomes your product owner. But then you can play, depending on the person. You'll say that's an engineering manager, that's your product owner in the agile unit, or maybe that's a product manager, not your product owner. But you still need those functions of somebody getting the feedback and somebody executing, and in my experience, it's not the same person that can do both of them.

So how you then divide, internally, the role of product owner in a very agile sense, depends on the people. Hopefully that answered your question.

Prioritization for Devs vs. Enterprise

Obviously, I'm going to give you the most frustrating answer, which is: it depends what phase you're in, and who you are after that phase. If you're starting from a developer project that goes into the enterprise, and you're just developing that developer offering, guess what? You start there.

If you already have that, and it's 99% there, then maybe each additional dollar, you should spend on your enterprise offering and go there. But if your strategy is, "I want to start from a developer, and then I'm going to go to the enterprise side," okay. Develop this, get this right, and then develop the other thing. Then at that point you balance your resources based on what you perceive as a need.

For example, if you are still developing your first product, you still don't have something that's selling, what's the point of making this even more perfect if you have a big shortage there? But if you still have problem with adoption there, and there's no point, remember when we talked about expand, land, expand? You're not even at the point of landing, because it's not expanded enough. Go invest there.

I'm just saying it kind of depends what phase you are, and it's going to change constantly. And then, once you're finished developing your enterprise, you'll say, "Oh, but my developer product has to change as well." So you're going to move around a little bit, too.

JC: I'll make a plug for a framework. You asked, Dana, for the Heavybit library. I did a talk on something I call "unit of values." My framework to you is, focus on what the smallest unit of value of your product's going to be. If that's a single developer who gets value from it, then you can constrain it there.

If your product only adds value when it's for a larger enterprise, then that's the right constraint. It could be both, but clearly I would scope it down to where the smallest unit of value is, and then grow there. It's easier to start small and grow big, then go big and break it down. Challenge yourself with what that unit of value is or isn't.

Tools That Have Changed Enterprise

MT: There are changes, but again, VMware, even though you think about it as very traditional enterprise software, and IT, it started from developers adopting it and developers bringing it in, it's actually followed a similar path over a much longer period of time. Some things are not exactly new there.

The fact that you have cloud, and you have this shadow IT, it used to be that you truly were dependent on IT to provide you with things so you can install on your machine and run it, so they had the keys to all of it. But now you can deploy anywhere. You can download from anywhere; that's probably the biggest thing, is where you get the software and how quickly you can spin off a machine. All of this is completely game-changing for the industry.

You no longer need somebody to install this big complicated purchase to get it going. All these trends: free available software, open source, cloud development and the availability of it everywhere, they have kind of changed the game. And this is why developers are kings.

JC: The one thing I'd add to all these points is the speed. I think all the barriers that Marianna articulated are true, in terms of you don't need to go to IT to get a server anymore. You can go to a cloud. You can download source code from the cloud, etc. But the economic value of a developer-defined technology is really the speed that can act faster.

I think the story you can tell is two developers talk on a Friday about how to build an application. One developer goes home, specs out exactly what he or she wants to do, files a bunch of tickets, gets servers and opens these firewalls.

Come Monday, he's like, "Look what I did! I created all these tickets of what I need to get this app going." The other developer goes, "I just put this on the cloud, and in a weekend I wrote it. Here it is."

So, in a world where a company like RIM Blackberry goes from the top of the heap to zero in seven years, six years, companies are kind of turning over so fast, you can't wait those three months for a server anymore. And so, I think speed becomes this economic driver that cures a lot of the sins. Anyway, I've got to go, but thank you very much. Thank you, Marianna.