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.
Over the past year I spent a lot of time on the subway reading books. Here’s my year-end list of favorites. If you want a look at what else I read in 2018, you can check out my reading log here.
Have any recommendations or books I missed on this list? Please give me a shout in the comments section or shoot me a note.
Enjoy the list and see you in 2019.
- The Literary Churchill. My first Churchill biography. The Literary Churchill takes an interesting approach to its subject, trying to explain his life not through his actions or his policies, but through his reading material. This book will teach you about Churchill and about how what we read defines us.
- Seven Brief Lessons on Physics. An enlightening little book on physics. Carlo Rovelli first published these seven essays as a Sunday series in his local newspaper. The result is an Italian stroll through the principles that govern our world. A great read over coffee on a weekend morning.
- Bad Blood. You’ve already heard about this book and about how you have to read it. The movie should be fun.
- Educated. A memoir about finding knowledge for yourself. “In retrospect, I see that this was my education, the one that would matter: the hours I spent sitting at a borrowed desk, struggling to parse narrow strands of Mormon doctrine in mimicry of a brother who’d deserted me. The skill I was learning was a crucial one, the patience to read things I could not yet understand.” This book will remind you what it is you love about learning and reading.
- Red Notice. Probably the closest look you can get at the wave of capitalism that broke across Russia in the 1990s and the pool of corruption it left behind in its wake.
- Barbarians at the Gate. This book details one of the all-time great bidding wars in the history of Wall Street. A fantastic piece of journalism that provides a detailed view of how deal-making actually happens in the upper echelon of buyouts.
- How to Change Your Mind. A book about the emerging science of psychedelic-aided therapy. I didn’t love this book, but it did make me think about how our minds work and how we can strive to stay open-minded as we age. Once you start this book, you’ll find yourself bringing it up in conversation constantly.
- 7 Powers. Operational excellence does not equal long-term sustainable value. Instead, it’s using that operational excellence to build an unassailable advantage that creates the long-term value that comes from high market share and high defensible margins. With 7 Powers, Hamilton Helmer takes the best insights from Porter’s theory of competitive strategy and turns it into a digestible reference to use during points of flux in a company’s trajectory. Highly recommended for product people.
- The Score Takes Care of Itself. Do the little things right and the score will take care of itself. Bill Walsh’s treatise on leadership after a career in which he took the Niners to three super bowl championships.
- The Phoenix Project. All of the groan-inducing, cringe-worthy business fiction of Eli Goldratt’s The Goal is back and better than ever in The Phoenix Project. A great, fun read for anyone working within a product organization.
- Beyond Entrepreneurship. I watched a Reed Hastings lecture. He mentioned he tries to read the first 80 pages of this book once a year. So now I do, too. A good refresher on what great leadership looks like and the importance of setting a vision within a company.
- The Hard Thing About Hard Things. A book of “most important rules” and hip-hop epigraphs. Though tailored for the founder or CEO, The Hard Thing About Hard Things is a great read for anyone who knows how difficult startups can be (no matter the role) and wants well-worn advice on how to survive.
- Stoner. “Sometimes, immersed in his books, there would come to him the awareness of all that he did not know, of all that he had not read; and the serenity for which he labored was shattered as he realized the little time he had in life to read so much, to learn what he had to know.” This novel is one of the better works of American literature I’ve read in a long time. The book’s protagonist, William Stoner, comes of age on the barren soil of a Missouri farm before attending the local university for agriculture school. There, amidst the trappings of chinch bugs and manganese, Stoner takes a required course in English literature. In the hazy afternoon of that classroom, the words of Shakespeare’s Sonnet #73—”this thou perceivest, which makes thy love more strong, To love that well which thou must leave ere long”—set him in reverie. When he awakens, his life has found a new path: teaching. A great campus read on finding your own purpose and happiness in life.
- The Moon and Sixpence. I first read the name Somerset Maugham in the byline of an epigraph. It was a suitable introduction. Maugham’s writing—tight, dry, British—lends itself to quotation with ease. He’s also very funny. The Moon and Sixpence. Maugham’s novel based on the life of painter Paul Gauguin, lends itself both to its author’s quiet humor, and to his meditations on work and purpose. For Maugham’s painter protagonist, it isn’t fame or acclaim or success that he chases. It’s beauty. Beauty, and what it means to find it in life, emerges as the dominant theme of this book. It shows itself most in the protagonist’s monastic pursuit—his paintings, and the dark shroud of understanding contained within them, are its explicit manifestation. But beauty reveals itself in other, subtler ways throughout the novel. There are characters who find beauty in quiet, apartment-bound relationships, characters who find beauty in the families they build. It’s a nudge from Maugham. Create something. Make it beautiful. Be at peace. — Great book.
- The Shining. A happy story for winter in the mountains. A fun way to dive deeper into the mythology of the movie while you test the heart rate monitor on your Apple watch.
“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.
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 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.
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.