This was originally posted on the Knock blog.

Notifications used to help us. They were a signal for what to read and what to do next. They sought to surface what mattered where we needed it most.

But notifications failed us. They became a mess of marketing and noise. They left us to block and tackle and search for value on our own. Now we live in a daily struggle, sifting through information and managing attention across tasks—both personal and professional.

Despite this, notifications can still have value. The decision that unblocks a teammate. The mention that clarifies a top priority. The message that puts us back in touch with a friend.

At Knock we want to help software deliver that value to its users. That starts with giving product and engineering teams the tools they need to deliver great notifications.

What makes a great notification

A notification has one goal: to deliver value to the user on the right channel at the right time. To accomplish this goal, notifications should be designed and sent with the following principles in mind.

• Contextual. A great product understands its users. It knows when they want to hear from it and when they don't. It knows which notifications should be sent outside of working hours (high-priority alerts) and which shouldn't (comments, replies, mentions.)
• Relevant. Advanced notification systems take in multiple inputs to determine whether a notification is relevant for a given user. They evaluate what a given user has engaged with, on which channels, at which time, and use that context to send better notifications to the end user.
• Actionable. When a notification asks a user to act, it should give them the clearest path possible to do so. The gold standard is to let the user act within the notification itself. If that's not an option, the notification should direct the user to where they can complete the action.
• Configurable. A great notification puts its users in control. Whether it's in-app, email, or push, a notification gives the user the ability to close the loop and tell the system they no longer want to receive notifications about that topic. This includes per channel preferences, as well as do-not-disturb and snooze modes.
• Reliable. Notifications need to be 100% reliable. A high-value notification is only valuable to a user when they know they're going to get it every single time.

It's easy to agree on the qualities above as things we'd like to see in the notifications we receive, and we can all point to a few tools that do these things well. But most products don't put these principles into practice.

This doesn't happen because teams knowingly build products that send redundant or spammy notifications. It happens because building and maintaining the systems that power these notifications is (i) a hard problem to solve and (ii) a problem that most teams don't get the time to solve in the right way.

Notification systems are hard

We know this because it happened to us. When we met in our prior roles at Frame.io, we knew notifications were a key part of the product experience. For a time, the most common pain point we heard from NPS detractors was that we sent too many notifications. To solve the problem we built notification batching, smarter digesting, and better email threading to move things in the right direction, but we always knew there was more we could have done for our users.

It's a story we've heard again and again as we've spoken with customers. Teams know they're leaving a better customer experience on the table, but can't devote the time it takes to deliver great notifications.

All of these companies are caught between time spent on their core, differentiating product and the underlying utilities that support it, such as payments, search, authentication, and, yes, notifications. There have been 3rd-party services to help us with most of these utilities—Stripe for payments, Algolia for search, Auth0 and WorkOS for authentication—but as engineering and product teams, we've been left to fend for ourselves when it comes to notifications. Not anymore.

Enter Knock

Knock helps product and engineering teams send great notifications to their users.

Here's how it works. We give our customers an API to tell Knock what's happening in their product. One notify call gives Knock what it needs to power digests, batching, and channel sequenced delivery.

With that context available in Knock, product managers and others can use the dashboard to build, design, and send notifications, without taking valuable time away from engineers. For in-app feeds, we offer pre-built components and SDKs that teams can use to power real-time, fully featured experiences in their frontend. For out-of-app channels, such as email and push, we integrate with the platform providers you already use today.

We handle the basic plumbing of sending notifications for our customers. But as with most 3rd-party APIs, teams get other benefits by outsourcing a utility to a provider that devotes 100% of its time and focus to that problem.

• Ship the notifications you wish you had time to build. Because notifications is our core business, we can obsess over notifications to a degree that wouldn't make sense for anyone else. From handling dark mode variants to sequencing channel delivery to powering dynamic emails that update in real-time—these are the things we can afford to focus on at Knock, because notifications is all we do.
• Empower people who don't code, give time back to people who do. Knock makes notifications self-service for non-developers. Instead of writing Jira tickets and taking valuable time away from engineers, product managers can update notification templates and workflows in minutes instead of days.
• Visibility and quality control for every notification. As a product team grows, its inventory of notifications sent to the customer often gets lost in the shuffle. Siloed teams introduce their own notifications at will, unknowingly degrading the user experience as a result. A system and dashboard in place from day one keeps visibility into what's sent to the customer.

At Knock we enable our customers to bring forward their entire notifications roadmap and ship it to their users in a day. Once it's shipped, we give them the tools to understand the efficacy of those notifications and move them towards a better experience for the customer.

What about X?

There are already a lot of tools that exist today to help send notifications. Here's where we fit in.

Today developers can send a message across any channel—email, SMS, push—with an API call. Notification delivery is a hard problem, and it's been solved by platform providers such as Twilio and MessageBird. Now the hard part isn't the API call to a specific channel, it's everything that comes before it. It's the orchestration of notifications across multiple channels.

Ten years ago the hardest part of notifications was delivery. Now it's avoiding over-delivery. That's where we come in.

What's next

Our mission is to help software communicate with its users.

This starts with giving every company the tools they need to send great notifications. It ends when every product can send intelligent, contextual messaging to their customers.

Notifications don't need to be a nuisance. When done right, they should help us manage our work, stay in flow, and make the most out of the tools we use every day.

We're hiring an incredible team to help solve this problem for engineers, product managers, and end users of software everywhere.

Come join us and let's send notifications that matter.

Sam + Chris

Somehow I made it through a decade in tech without reading The Lean Startup. I suppose at a certain point you read about a book in enough tweets and Medium articles to feel as if you've read the whole thing. Here’s where I net out having finally gotten to the source material.

To start, there’s a lot I like about this book. Its adoption of lean manufacturing principles, its relentless focus on learning and data-driven thinking, its focus on building something people want. Those are learnings I’ve tried to keep in focus throughout my own career in product, and The Lean Startup is a great reminder to double down on those parts of product management.

But there’s also something that The Lean Startup misses, and that’s that you only get one first impression. When you’re in your early network and showing people a beta product, iterate and show them an incomplete product, sure. Find which features add value and which don’t. But when you launch your product to the world, your first complete product that’s supposed to solve a problem for real-world users, you had better get it as close to perfect as you can. It’s an idea that Stewart Butterfield talks about in his memo We Don’t Sell Saddles Here. With a first product, you only get one opportunity to show users a new way of doing things.

In Butterfield’s words:

“The reason for saying we need to do ‘an exceptional, near-perfect job of execution’ is this: When you want something really bad, you will put up with a lot of flaws. But if you do not yet know you want something, your tolerance will be much lower. That’s why it is especially important for us to build a beautiful, elegant and considerate piece of software. Every bit of grace, refinement, and thoughtfulness on our part will pull people along. Every petty irritation will stop them and give the impression that it is not worth it.”

To put too much faith into any one dogma as a product manager is to set yourself up for failure. This is often the case with acolytes of the lean startup school—they compromise on end user experience for the sake of learning. You’ll certainly learn as fast as possible, but often at the expense of a cohort of customers that will be hard to get back into your product. If your company is built on recurring revenue and the long-term value of those customers, that’s a big cost. Lean too far the other way, focus completely on end user experience but forget to measure anything at all, and you’ll end up delivering a beautiful product that no one wants to use.

So what to do? As with most things in product management, the answer sits somewhere in the middle. When you embrace lean startup principles, counter-balance them with the flawless execution Butterfield talks about above (or limit the impact of a lean release with a smaller beta cohort.) Consider data-driven thinking and experimentation, while also weighing the intangibles of what makes a product great. You have to see all of these things at the same time to make the right decision.

One of the first things you learn when you’re starting to drive is to keep your eyes moving. You can’t just stare straight down the road, the tunnel vision will keep you from seeing what’s coming into view. Instead, you keep your eyes moving, a dart to the left, to the right, to the rear-view window, to the speedometer, back to the road. It keeps you alert. You see mistakes before they happen. The Lean Startup is one part of the road to keep an eye on. Your dashboard. A valuable tool, just remember to lift your eyes up from the numbers every so often to see where you’re going.

“The fox knows many things, but the hedgehog knows one big thing.” — Archilochus

“The test of a first-rate intelligence is the ability to hold two opposed ideas in the mind at the same time, and still retain the ability to function.” — F. Scott Fitzgerald

The life of a product manager is one of pattern recognition. You look at problems and try to remember whether you’ve seen them before.

I like quotes as a pattern recognition tool. They’re pithy and memorable, and yet, despite their simplicity, they can provide a lens into deeper, more complex ideas and problems.

Take the two quotes above. They stand strong enough on their own—the first a classifier for idealists and pragmatists, the second a reminder on the role of contradiction and self-doubt in great thinking—but when taken together, these two quotes provide an important lesson to the aspiring product manager, a pattern to recognize.

This lesson is simple. To be a great product manager, you must be both the hedgehog and the fox.

Foxes and hedgehogs

Let’s start with the first quote. “The fox knows many things, but the hedgehog knows one big thing.” I found this a few years ago in Isaiah Berlin’s essay The Hedgehog and the Fox.

In the essay, Berlin classifies the great writers of literature into two categories. On one hand are the hedgehogs, those minds who know one big thing, who forge their worldview with monastic belief into a single, fervent truth. Dante, Proust, Dostoyevsky: these are the cheery titans of camp hedgehog. In the other corner are the foxes. They fashion their pen not around a philosophy, but around the world itself. They write of the reality around them in all of its details and complexities, but without the unifying principle that embodies the work of a hedgehog. Shakespeare, Chekhov, Austen. All foxes.

In his book On Grand Strategy, John Lewis Gaddis’s takes Berlin’s idea out of the world of literature and into the world of war and diplomacy. Here, the hedgehogs represent those leaders with an ultimate purpose or mission, the foxes those leaders with a more tactical, pragmatic bent.

The book looks at these hedgehogs and foxes of history and asks, which is it better to be?

Gaddis starts with the hedgehogs. History is littered with stories of “too much hedgehog, not enough fox.” Napoleon is a good example. Hot off a winning streak through continental Europe, Napoleon set his sights on a trip into Russia. A true hedgehog, he was completely indebted to his vision. He dreamed of a French flag soaring over Moscow. He did not, regrettably, dream of Russian winters or of overextended supply chains. The result speaks for itself: one of the great military fiascos of history. Napoleon marched into Russia with 685,000 men. He marched out with 22,000.

The foxes, too, have their faults. Where hedgehogs (such as Napoleon) err in overcommitting themselves, foxes err in not committing themselves enough. Take General George McClellan, the fastidious Union general who, after weeks of careful planning, preparation, and fortification, always found a reason to call off his latest impending engagement with the Confederate army. These delays, always carefully justified in tidy correspondence, enabled the escape of the Confederate army on multiple occasions, leading to the extension of the Civil War and a massive loss of American life.

It’s here, with the faults of hedgehogs and foxes strewn across history, that Gaddis asks, if a leader can’t find success as a hedgehog or a fox, where can good leadership be found?

His answer: in the middle. To be both hedgehog and fox. To lead others towards a vision with drive and purpose, while spotting the logistical potholes that pock the road leading towards it.

No leader better exemplifies this balance than Abraham Lincoln. Throughout the Civil War, he had but one goal: the preservation of the Union. Everything he did, he did with that goal in mind. Despite his steadfast commitment to that end, Lincoln realized better than anyone the immediate concessions that were needed to ensure the Union’s survival. This meant stomaching his own support of the Fugitive Slave Act in his inaugural (a hugely unpopular decision in the North that allowed Lincoln to keep crucial border-state allies) so that two years later he could be in a position to announce the Emancipation Proclamation. He made short-term concessions in support of a long-term vision.

It’s in this contrast—the short-term and the long-term, the fox and the hedgehog—that we can see what made Lincoln such a great leader: his ability to hold two ideas in opposition.

Ideas in opposition

This brings us to the second quote at the top of this post, Fitzgerald’s famous aphorism: “The test of a first-rate intelligence is the ability to hold two opposed ideas in the mind at the same time, and still retain the ability to function.”

I love this quote. On the surface, it’s so academic, so perfunctory. If you only ever read the quote, it would stay that way forever. But when you read the larger piece it comes from—Fitzgerald’s 1936 essay The Crack-Up—you realize that those words, with their definition of a “first-rate intelligence”, are not coming from a man who has retained the ability to function. Fitzgerald is writing in the waning years of his life. In a few years he’ll be dead at the age of forty four. In this quote, he’s lamenting something he’s lost: the ability to hold two ideas in opposition. For Fitzgerald these ideas were (i) the supreme confidence that he could produce something great and (ii) the complete self-doubt that actually drove him to that greatness. It was faith in the long-term coupled with an almost maniacal attention to detail in the short-term. It was the hedgehog and the fox.

For Fitzgerald, it was a paradox he could only hold on to for so long. He wrote his great novel and then fell into relative obscurity.

I drift into the backstory of The Crack-Up not to mourn Fitzgerald, but to underline that being both fox and hedgehog is hard. To drive towards a vision while embracing the complexities that keep you from achieving it; it’s an ability beyond most of the great figures of history.

The paradox of product

What these quotes are really about is our ability to deal with paradox. To me, there’s no place where that’s more true than the seat of a product leader or founder. A product leader is responsible for contributing to the strategy and vision of the product they help to build. To make that vision a compelling one—not just as something users want to use, but as something that team members wants to build. The only way to do that is by believing, with every ounce of one’s being, that the vision they promote is the right one.

But if the lessons of history tell us anything, it’s that we can’t just set a blind course and expect to find success. Like Napoleon, we, too, might find ourselves walking back the way we came with half the team that started with us. Instead, we have to constantly test that vision and strategy. We have to constantly poke and prod to see whether it’s still relevant, to see whether the landscape has shifted around us. Even when we do arrive at a sound conclusion, we need to doubt whether we’re executing well enough against it, whether the team we’re a part of has the discipline to stay focused against that plan.

So where does that leave us? As product managers, we need to be both believer and doubter. To continue driving forward while always checking to make sure we’re moving in the right direction. This comes forward in a few ways when you’re in product.

The first is in vision and strategy. In tech, where “the platform [sic] for all of your x needs” value props abound, any vision needs to be looked at from an objective distance. Do we want to be the platform of x because we can offer differentiated, defensible value in all of the specific functions that roll up into x; or are we oversimplifying the complexity of our market in pursuit of the grandest vision imaginable? To choose the latter is to look back at three years of product decisions and see a litany of unfocused, unforced errors. It’s the path of too much hedgehog, not enough fox.

On the other end of that spectrum are the aptly named “feature factories” of the product world. The feature factory looks at the immediate short-term wins and tacks them into the product one after another, not stopping to think of the single cohesive vision that those features should work towards. These small fixes make pockets of customers happy, but they rarely build the sort of long-term sustainable value that comes from a continued focus on a single goal or strategy. Herein lies the path of too much fox, not enough hedgehog.

So how do we stay both fox and hedgehog when we work in product?

One way is to look to the other product leaders who have done it. I’ve pointed to Stewart Butterfield’s We Don’t Build Saddles Here on this blog before, but I’ll bring it up again as a careful balance between end vision and the short-term details that get you there. The essay is a bugle blast for Slack employees to rally behind the company’s mission, but its final call to action is actually one about doing all the little things right. That’s not the easiest message to communicate in an inspiring way, but whenever I come back to this essay, it still gets me just as excited to go out and build something great as the first time I read it.

The other way to maintain this balance between the short and long-term is to recognize when you’re drifting too far in either direction. It’s in those moments that you have to remember to constantly redirect yourself back towards the middle, back to an uncomfortable position of paradox. The two quotes above have helped me to strive towards that position, and I hope they can do the same for you.

Last month I heard Slack’s Noah Weiss speak at a First Round Capital event here in NYC.

When I first started in product, Weiss’s reading list was my north star. I spent my first month as a PM pouring through its articles, writing down everything I learned along the way. It’s still the first resource I point people to when they tell me they’re interested in product management.

At the event, Weiss told his story and sprinkled in a few do’s and don’ts throughout. The advice that stuck with me most was a sports analogy: “+/-”.

+/-, or plus-minus, is a statistic that measures a player’s impact on a game. If your plus-minus rating is positive, your team scores more points than its opponent when you’re in the game. When your plus-minus rating is negative, bad things.

Why do sports statisticians track plus-minus? Because it helps show the intangibles, it shows which players make their teams better.

Basketball player Shane Battier, who earned his own write-up in the Times on account of his stellar plus-minus rating, is a good example. By any conventional measure—points, assists, steals—Battier lagged behind others in the league. He was regarded as a “marginal athlete at best.” But a trend emerged. In spite of Battier’s box score reputation, his team won more when he played.

“Here we have a basketball mystery: a player is widely regarded inside the N.B.A. as, at best, a replaceable cog in a machine driven by superstars. And yet every team he has ever played on has acquired some magical ability to win.”

“A magical ability to win.” But why Battier? Because, despite his shortcomings, he brought an intelligence and a hustle to the game that showed up in his plus-minus rating, even if it didn’t show up in the stats we talk about most—shooting percentage, assists, steals. The example of Shane Battier isn’t meant to de-value these traditional statistics (the top of the all-time plus-minus leaderboard is full of players we’d normally associate with great box score stats) but instead to show that there are other, less visible elements of the game that contribute to winning.

Let’s tie it back to product management. When you first start out as a product manager, with that bountiful range of responsibilities in front of you, it’s natural to gravitate towards those that help you stand out, to the parts of the role you’ve spent months reading about. Market research, feature definition, prototyping. You want to pull up from beyond the arc and toss up a deep three, that game-changing silver bullet of a feature that’s going to define your legacy.

The more time you spend in product, the more you realize that as important as the big ideas are (and they are important, just like points and assists are important in basketball,) it’s the work you do to make the team better that matters most. What can you do as a PM to make design, engineering, marketing, services, and others, more successful? What can you do to give your company a “magical ability to win”?

This is the great insight of Andy Grove’s High Output Management, that a manager’s output is measured not by what they produce in a vacuum, but by what his or her entire team (and the teams within his or her sphere of influence) accomplishes.

Sometimes that’s the game winner from deep, other times it’s QA, documentation, removing blockers for engineering, thinking through the details of a piece of UX. In my own experience as a PM, it’s helped a lot to keep these other focuses in mind, the ones that only show up on plus-minus, even when I’m stewing on some larger product theme.

A few weeks ago, Terry Crowley, former manager of Microsoft’s Office team, wrote a great post about essential complexity in systems.

In it Crowley discusses essential complexity, the cost of adding a new feature to a large system, and how the team at Microsoft embraced essential complexity to build a cloud Office suite that could compete with Google Apps on previously asymmetrical features (like concurrency,) while maintaining the robust feature set (and file format) that enabled Microsoft to keep business from Google Apps’s collaborative cloud in the first place.

Much of the response I read concerning the post treated it in a triumphant light (likely influenced by good news re: Office 360 v. Google Apps market share)---the words of a man who had wrested complexity to the ground.

But any who cite victory against complexity should be taken with a grain of salt. Complexity is the emergent behavior that arises from the interaction of lower-level primitives. It is, by many accounts, unpredictable. A complex system can’t be controlled or used to elicit a specific result, it can only be loosely guided towards an objective from the bottom-up. (If you’re looking for a good primer on the science of complexity, check out Mitchell Waldrop’s Complexity.)

When Crowley talks about taking on the “essential complexity” inherent in a large system, and reducing the “accidental complexity” or “unnecessary complexity” introduced to it via a new feature, it’s important to note that he isn’t conquering complexity so much as embracing it (and accepting that his users will, to a certain extent, have to embrace it as well. More on this later.)

In reading Crowley’s discussion of the essential complexity within a given system, I was reminded of two other complexity concepts I’ve been reading about lately. In this post, I’ll explore those different types of complexity, their relation to essential complexity, and how all of this introduces a host of questions that product management (and company leadership) need to consider.

I’ll start with essential complexity and then look at what happens when we abstract it to a higher order of behavior. The first abstraction lands us at what I call “stack complexity”, or the behavior that emerges when different systems interact. The second abstraction moves to “enterprise complexity”, or the behavior that emerges when that stack of systems and vendors interact with the scale and process of an enterprise organization.

Essential complexity

First, let’s look at what Crowley means when he says “essential complexity.”

He starts with the function-cost curve, a way to ascribe the functionality a team develops within a system, and the marginal cost of adding each new feature to that system as more and more functionality gets built in. The general position is that in large systems, the cost of adding a new feature to the system is higher because it needs to consider its interaction with more total product.

In product strategy, you’re always thinking about essential complexity within the context of new features. Crowley explains how at Microsoft they often had to decide whether or not to take on essential complexity. Either make a new product completely compatible with the other feature sets in the suite, thereby increasing its essential complexity (as they attempted with the co-editing features in Office 360,) or cast aside that essential complexity and start the new feature in isolation (as they did with OneNote.)

In the case of Office 360’s Word app, Crowley+co decided to “embrace essential complexity” and build co-editing features on top of the existing Office feature set, rather than build a new, simpler version of Office designed for in-browser collaboration.

This decision gave Microsoft a cloud word processor app compatible with Word formats, “a critical competitive moat with immensely strong network effects.” This led to Microsoft stealing a lot of productivity software market share back from Google Apps.

But the decision also led to a lot of new complexity within Office360. For any user looking for an easy way to collaborate on a document online, the simplest solution still sits within Google Docs. And this is the grain of salt I mentioned earlier. Crowley’s post is fantastic, but we should be careful to read it not as a triumph over complexity, but as an acquiescence to it. The Office team decided to lump co-editing in with their existing feature set and the result is a more complex product than Google Apps---one that’s more difficult to use but offers the range of functionality certain enterprise users need.

So this is essential complexity. Weighing the decision to introduce a new feature into the existing context of the system. Considering that decision within the light of the features your competitors in that space offer. But, in most cases, the decisions around essential complexity are inward ones. Decisions about how things interact within your product suite.

When you move to a higher order of complexity and start thinking about how a system interacts with other systems, you get stack complexity.

Stack complexity

Stack complexity is interesting in that it poses an entirely different set of questions to product management. A set of questions that exist on a different plane than those in essential complexity, and likely exist outside of the scope of what those essential complexity systems are able to do. (I.e. for a long time systems like Microsoft have natively integrated within their suite, and relied on SIs to integrate them within their larger stack.)

Ben Thompson addressed the idea of stack complexity on his blog a few weeks ago:

“When enterprise software first came to be it was primarily focused on automating routine business processes like accounting and enterprise resource planning. At first these solutions were self-contained, but over time, particularly as companies sought to gain usable insights from the data they were collecting, it became necessary for these monolithic software installations to talk to each other.

At the beginning nearly all of these integrations were custom-built and maintained by system integrators; this was manageable as long as the number of integrations were small, but as the number of applications increased the number of potential integrations increased exponentially (integrations = n(n-1)/2 in which n is the number of apps). This not only made it difficult to connect applications, it made even updating a single application a very dicey proposition — what if the custom integrations stopped working?”

With the cloud and its proliferation of services all touting integration-friendly, API-first applications, stack complexity abounds. There are a few different approaches vendors have taken to this problem. Like essential complexity, one approach is to embrace stack complexity, the other is to bow out if it.

Companies embrace stack complexity in different ways. On one hand you have vendors like Slack who want to be the interface on top of everything. Their message to IT buyers is “purchase whatever you want, you can rest assured it’s in the Slack app directory so you can tie it all together.” But being the interface to all systems doesn’t necessarily mean handling the regular and systematic flow of data between those systems. For that use case there are vendors like Mulesoft, seeking to be the common layer between everything. In either case, these vendors are similar in that they’re betting on customers embracing complexity, building a stack out of multiple point solutions and then trying to piece it all together into something that works.

Then there are those companies attempting to eliminate stack complexity for their customers. This is the path for Microsoft and the other full suite providers---in the process of taking on essential complexity, they bow out of stack complexity. For while Microsoft’s Office suite (and other suites like it) provide plenty of integration solutions, they’re not differentiating on them. What they’re differentiating on is the ease of the native integrations within their system; Outlook working with Word working with OneDrive and so on. It’s an interoperability that 1) with a strong enough network effect creates the aforementioned moat of file formats and 2) helps to win out against point solutions. In a late 2015 CIO article on Microsoft’s winning of market share against Google, Outlook was actually cited by IT consultants as the primary driver behind customers switching from Google Apps to Office365. I was stunned when I read that. Outlook over the ease and simplicity of Gmail? But that’s the power of a system that takes on its own essential complexity (and to Crowley’s point, I think Microsoft has done a better job of acquiescing to their own complexity than Google Apps has) so that its customers can opt out of some stack complexity.

On top of this, Microsoft makes it easy for an organization to opt into their entire suite. Not just through their software, or their product strategy, but through an enterprise culture that embraces the organizational complexity of the enterprise. This brings us to our last abstraction of complexity.

Enterprise complexity

If essential complexity is the complexity within a single system, and stack complexity is that within a collection of systems, then enterprise complexity is the loose term I use for what happens when you move to yet a higher order behavior and start to look at how the users (and buyers) within an organization interact with that collection of systems.

Like stack complexity, enterprise complexity asks a completely different set of questions than essential complexity, this time not just of product management, but of the entire vendor as a whole. How is implementation run? Are customers expected to learn how to use the product on their own, or are you putting people on the ground to help them? Do you offer dedicated support teams for your biggest customers? How does your product’s system administration scale to a true enterprise organization? These are the types of questions posed by enterprise complexity. And what’s more, since it’s a higher-level of complexity involving the lower-level elements already discussed---each feature, each system, the interaction of all of those systems and features, the people that use them, etc---it gets even harder to predict what emergent behavior will come out of it.

This means that when it comes to enterprise complexity, there is no single product management strategy that makes it all better. Instead, a vendor embraces enterprise complexity from the bottom-up by making sure every lower-level element within their own business (just one part of which is product) drives towards the emergent behavior of enterprise success. A lot of people call this bottom-up structuring “enterprise ready”. Whatever we call it, the takeaway is this: you only survive in the enterprise by embracing it everywhere in your business. Sales. Services. Marketing. It doesn’t just come from product.

A great example of this is Charles Fitzgerald’s recent post Google’s Scalability Day. In a fun twist, it starts with the example of Microsoft in the late 90s, a giant who, by many measures, hadn’t yet become “enterprise ready.”

“Microsoft at the time was an extremely engineering-centric company, so it processed all the criticisms through a technical lens. Soft, cultural, customer, and go-to-market issues were discarded as they did not readily compute and the broader case against Microsoft’s enterprise maturity was distilled down to the concrete and measurable issue of scalability. The company assumed some benchmarks plus updated product roadmaps would clear up any remaining “misunderstandings” about Microsoft and the enterprise.

The event was a disaster and served to underscore that all the criticism was true. It was a technical response to non-technical issues and showed that the company didn’t even know what it didn’t know about serving enterprise customers. Internally, the event served as a painful wake-up call that helped the company realize that going after the enterprise was going to be a long slog and would require lots of hard and not very exciting work.”

Fitzgerald then brings the thread back to where we started: Microsoft Office v. Google Apps, and the latter’s push into the enterprise through an asymmetrical product strategy focusing on collaboration and co-editing.

“I couldn’t help but think about Scalability Day while watching Google’s #GCPNext event today. After telling us for months that this event would demonstrate a step function in their ability to compete for the enterprise, it was a technology fest oblivious to the elephant in the room: does Google have any interest in or actual focus on addressing all the boring and non-product issues required to level up and serve enterprise customers?”

This is the importance of enterprise complexity. Even if you’re the vendor with the simpler, easier-to-use solution---in this case, Google---if you haven’t embraced the complexity of the enterprise and “all the boring...non-product issues” required to succeed within it, you might actually be the more difficult solution for enterprise buyers to purchase and scale across their organization.

For product and non-product managers alike, it’s important to consider the essential complexity within their own solution, as well as how it plays with their customers’ stacks and organizations. The simplest product isn’t always the one that wins in the enterprise.