In my college CS classes, I always thought that speed was the most important part of software. The most valuable products (or so I thought) used only cutting-edge, high-performance sets of algorithms.

But now that I’ve worked to scale Segment for the past eight years–I’ve realized that in many cases, the value proposition of software is really just a lot more… well… basic. More often than not, you don’t need a fancy new algorithm that runs in O(log n) time, a constant-sized data structure, or even a cutting-edge database.

For B2B companies, the most valuable products more or less offer a single value prop: you don’t need to ask permission to get your job done.

The waiting game

To see where I’m coming from, let me share some quick context.

We started Segment eight years ago as 4 guys in an apartment. Today, we’re a little more than 500 people. At this point, it’s hard to know every team at the company, let alone, every individual.

As we’ve grown, I’ve observed a lot more cases where ‘waiting for permission’ plays out.

To use illustrate an example, suppose for a minute that you’re on the engineering team, and you want to start using a new production monitoring tool.

Think you can just throw it straight into production…? Not so fast…

First, you have to explicitly negotiate what you expect from the vendor in terms of support, SLAs, and pricing. Then you need approval for budget, the terms of legal contract, and likely a security review. One proof-of-concept, MSA, and talk with procurement later, you’re ready to go.

To be clear, these steps are critical for a company operating at scale. If you don’t do them, you open yourself up to a lot of risk.

But it’s hard to deny that there’s just a lot of wasted time in these steps. Most of the time isn’t spent doing, but waiting for a response from someone who’s probably busy with their own work.

Waiting isn’t just inefficient, it’s frustrating and expensive. But when a company grows organically, it’s easy to fall into the waiting trap. And it grows exponentially with the size of the company.

Mapping out the labyrinth

In that sense, getting things done at a large company can feel a bit like navigating a dark labyrinth._ You find yourself in a maze of twisty little passages, all alike. _

Now if every member of the Fortune 500 had an identical maze, it would be easy to build tools for them. You could probably even rely on cultural norms to navigate it (“I know to first talk to the DBAs, then security, then legal”).

The trouble though, is that within the enterprise market, every maze is its own special snowflake.

Sure, maybe if you squint at them both, the Walmart maze has a similar shape to the Amazon maze. But on closer examination, you begin to realize just how much processes really differ from company to company.

These processes have existed for years… maybe even decades. Of course we should expect them to diverge!

As software engineers and product managers; we tend ignore those differences far too often.

We tend to spend more time thinking about how the user might adapt themselves to use our software, rather than imagining how our software might change to meet them. Software has to meet the user, not the other way around.

The two jobs of enterprise software

So how do we defeat the waiting problem? How do we meet the user? How do we build the software that can navigate any maze?

I’ll let you in on a secret—the true value of every enterprise product, from AWS to JIRA to Salesforce, is accomplished by just two things:

1. enterprise software encodes the rules for what to do
2. enterprise software automates the doing to avoid the waiting

That’s it! Great software means that my maze isn’t a maze at all, but a high-powered assembly-line that fast-tracks me exactly where I needed to go.

Great software takes all the guesswork out of getting something done, and lets me do it without asking permission.

This, by the way, is the number one reason why enterprise products sometimes take odd UX directions in comparison to the consumer products we’re used to dealing with.

Since encoding processes and rules are one of the two most important aspects of enterprise software, UI and UX count less as differentiating features. Instead, it’s the ability to customize those rules (JIRA, I’m looking at you!).

My favorite example of this is AWS Identity and Access Management (IAM) policies. IAM permissions describe what resources (read “AWS things”) users and services have access to.

IAM policies look like this:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "some-unique-identifier-for-scripting0",
      "Effect": "Allow",
      "Action": [
        "s3:PutObject",
        "s3:GetObjectAcl",
        "s3:GetObject",
        "s3:PutObjectAcl"
      ],
      "Resource": "arn:aws:s3:::my-cool-bucket/*"
    }
  ]
}

From a user perspective, IAM permissions are… well… finicky.

Are they cryptic and hard to get right? You bet. Feel like they require a lot of boilerplate? Sure.

But think about what we’re asking our IAM policies to do here… we’re asking…

Does the software meet my organization? Can they be applied to users both inside and outside the company? Can they literally describe the controls of a 80-year old company?

The answer is a resounding YES.

AWS lets enterprises encode whatever rules they want. They’ve done a good job meeting any customer need rather than forcing the customer to change their whole worldview. The software is just the conduit for enforcing those rules.

Once software has 1) enforced and 2) automated the rules, then a second-order benefit emerges: **de-coupling. **

“De-coupling” an organization

Of the superpowers that great products unlock (greater efficiency, cost savings, reductions in puzzled faces), the biggest is what I’d call “de-coupling” an organization.

In software, when a codebase gets to a certain size, we decide to break it up. We intentionally split the functionality into pieces so the different teams can work independently.

When this happens, these two teams are now “de-coupled.” Each one can move as quickly as possible, in whatever direction it wants to, so long as they don’t break the contract they have with one another.

As it turns out, the exact same thing happens in a business. Layers of your organization can move _years _faster by not having to block or make decisions for one another. They are, in effect, “de-coupled.”

To give you a flavor of what I mean, here’s a few key examples of de-coupling in action:

Devops and Cloud infrastructure

Ten years ago, engineers would have to ask their operations team to buy physical servers. The team would have to buy fresh hardware, install the server in a rack, add the networking, and install the OS. It might take anywhere from one day to three months.

This is kind of crazy a crazy way to build products when you stop and think about it. If your team is launching a new feature, before you do anything else, you have to do capacity planning to figure out how many servers your team needs to purchase ahead of time.

Yet, this is the current reality at most businesses today.

Today, you can have all of this in about 3 minutes by spinning up an EC2 instance on AWS, without asking a soul. Cloud businesses have included all the checks around configuration, security, and budget directly into their AWS configuration and budgets.

No one has to ask permission for new hardware.

Continuous Integration and Continuous Deployment

When I was interning at LinkedIn back in 2010, a release to production was a 48-hour affair. Releases ran on a two-week cycle. Each product team had to ask the production release team in order to get their feature branches merged into master.

In the broader scheme of things, two weeks is even that bad. Many companies are used to shipping their software updates just once per quarter.

In today’s world, there’s a lot less ceremony around pushing to production. Code reviews are still a thing, but many engineering teams have the autonomy to deploy their own code to production. Github Actions, Spinnaker, CircleCI, Travis, and more have made it easy to run checks around code quality, security rules, and production checklists without a human in the loop at all.

No one has to ask permission to deploy if all of the checks pass.

Business Intelligence

Ten years ago, getting answers about your business was complicated. It probably required SQL queries, custom dashboards, and a team of analysts. It was incredibly expensive, requiring some sort of big on-prem database.

Because the solutions were built for analysts and not end-users, they required:

• technical ability to get at the data and understand it
• deep knowledge of what the data means
• significant server cost to collect and store that data

Instead, we’ve seen a lot of forward progress towards “data democratization”.

Today, tools like Amplitude, Mixpanel, Tableau and Looker help non-technical users answer various questions about their business. They no longer have to ask for the answers to basic questions like “how much revenue am I making?” or “what are the top 10 products I’ve solid in the past month?”.

New pay-as-you-go for data like Redshift, Bigquery and Snowflake make storing and analyzing that data dirt cheap.

In effect, this new breed of tools has started to allow anyone to ask questions and get answers (without waiting!).

No one has to ask for answers from their analyst team.

Building great products

That brings me back to the outset of this post.

When thinking about building great software for the enterprise, a question that we don’t ask ourselves enough is: “how can my product save asks for permission?”

We started building Segment by trying to save developers time in integrating various analytics tools. It was a simple need, with a simple solution (one API that adapts to all others). And unwittingly… we helped save PMs from asking their engineering teams for permission to use new tools.

In that time, we’ve learned a bunch of lessons about how to save users from asking for permission:

1. **build API-first — **for years, we didn’t support an API for administrative options (creating users, workspaces, etc). Building new products first as an API saves you from having to constantly add features to meet the customization in the enterprise, and it’s an area I wish we’d invested in earlier.
2. **sane defaults and escape hatches can co-exist — **in the early days, we thought there was hard line between simplicity and customization. You could have a simple product, or one with lots of knobs tot tune, but not both. In reality, it’s much more of a spectrum. The best products have customization and escape hatches at every level, but they guide the user towards ‘sane defaults’. Datadog does a great job with this, getting you value early from pre-configured integrations, but also allowing you to collect data in the ways you see fit.
3. **invest in flexible permissions and notifications — **there are three key areas to invest to become enterprise-ready. You want a) a flexible idea of users and teams b) an easy to customize set of permissions for what those users have access to and c) customizable notifications. Having those three things alone will let your product expand more easily into the enterprise.

Yet of all the things we’ve learned, the biggest lesson has come from how we’ve found our growth.

Time after time, we’ve entered bigger and bigger markets by consistently de-coupling different parts of our customers businesses.

We started by de-coupling the collection of user behavioral data (engineering) from the consumers of that data (marketing, product). We added warehousing and ETL pipelines to let analysts work independently from data engineers. And we added new privacy products to let compliance teams set up a sandbox for their marketing

In that journey, we’ve expanded by helping thousands of companies de-couple across engineering, marketing, product, and privacy.

Each of these separations allows each of our customers to move much more rapidly. The value still comes from a core proposition: encode the rules for data collection, and then enforce them.

---

_Many thanks to Rick Branson and Ian Storm Taylor for providing feedback on this post. _