How does HashiCorp think about solving problems?

Transcript

Armon: An interesting question that we often get is how does HashiCorp pick which problems to solve and how to solve them? Today we have a portfolio of six or seven different major open-source projects so people often ask how do we pick which problems to focus on and how do we build the tools? I think for us what it has really always come back to is saying, "Is there a core workflow problem that we can identify?"

And what I mean by that very concretely with Vagrant for example is, is there a workflow challenge around, "Hey, I'm a developer who joins a new company, joins a new team, and it takes me two weeks to get my development environment set up, because I have to read a wiki and follow a bunch of steps. And inevitably it doesn't work because the wiki's out of date." That's a very concrete and specific workflow problem: Developer joins company, developer joins team. How do I onboard and quickly get them productive?

And so it starts by saying is this a common enough workflow problem? Do we see this all over the place? And if so, can we click out a layer and say is there a product that can be built around this? Because not all workflow problems are amenable to that. Some workflow problems are problems of your own creation: You've created a workflow that is so strange and complex that really only you have it, so there's really no point solving it in a tool in a more general way.

But if it's a problem that is more general, something like setting up a development environment—almost every developer has that problem—then there's an opportunity to look at that and say, "Okay, can we build a tool that simplifies that problem, abstracts in a way that's going to be nice to use and provides leverage to all of those users that have that same problem?"

And I think the final piece of that is, I think a common misconception: Build it and they will come. And I think as Mitchell knows, it's very much not true.

Mitchell: It's a lie.

Armon: How many downloads did Vagrant do the first year?

Mitchell: The first year, the total first year downloads for Vagrant were like 500. And I thought you build this great technology—well, what I thought was a great technology—and people will find it, and use it, and so on. It's not true at all.

Armon: Right. I think what we've learned from that is it's not enough just to find the workflow and build the tool, you have to go further and educate the market about it. We have to go out there and teach people, "Hey, is this a problem you have? Take a look at Vagrant, here's how it can solve your problem."

And it really starts with the first hundred users, you know them by name. And it's really a boots-on-the-ground, educational… building a community around these products. And that's how we think about it, is starting from that workflow.

Mitchell, is there anything you want to add to how we think about workflows?

Mitchell: I think it's easy as we're a company that builds technical tools for technical people, it's easy in that sort of industry to get really into the technology and forget about the people aspect. And a really important thing I think we do differently than a lot of other companies in our space is that we really think human-centric around the tool.

I think Vault is the best example of that, because Vault took a fairly staggeringly different approach to security. Different from other tools, different than security engineers expected Vault to work. Different in a lot of ways.

And the reason for that was really we felt that security tools in their current form were so focused on security that they were basically unapproachable by people. And we flipped that around. It's like how do we actually make it first approachable by people, but also be just as secure?

And so we thought about that first, and we do that across all our products. And so I think that brings a level of human-friendly workflow to that problem, which is core to the whole thing. And after that, you can build the product around it, and you can think through the really deep technical problems of what data structures and technologies you're going to use to solve it. You could get really into that and it's fun, but you've got to make sure you think about the people first.

Armon: Yeah, and I think we almost are continuing down that same people-centric line of thinking as we look at our commercial products as well. We're really starting to look at, "What does it mean if I go from one user who's really productive with a tool like Terraform, to how does a team of 10 people use it? How does a team of 100 people use it? How do 1,000 people use Terraform to collaborate together with infrastructure?

And what you start to understand is you're not solving at that scale necessarily technical problems so much as trying to understand what is the workflow that people should use to collaborate together? How do they do that safely? How do we bring all these different work streams together in a way that's going to compose nicely and be pleasant to use, as opposed to everybody hates the tool?

I think that has continued to be the way we think about it: We first solve the individual's workflow problem with open source, build this tool that people really love. And then how do we look beyond that to how do we help teams of people, organizations of people, also use it effectively and love the tools?

Mitchell: Yeah, another way to look at it—drilling in to why the workflow is so important—is that it's sort of ... being the primary interface to the tool, whether that interface is the command line, a user interface, or something else. It's usually the same workflow.

That's what people have to learn, and you have to teach your whole company. That's hard to educate. If that's changing all the time, it's hard to relearn. And so you could kind of iterate and fix the core technology. We try to get it right the first time, but you could work on that. But if you're making wide sweeping changes to the workflow, it's just disruptive to the whole organization. And so it's really important to get that right first.