Explore vs Execute

source

The arrogance of “what got us here will get us there”

Founders can appear arrogant when they start their companies, because they are. After all, most startups fail, and just look at these cocky founders, absolutely sure theirs will succeed.

(Actually most aren’t sure—the honest ones are scared shitless, hoping they can figure it out before everyone finds out they’re a fraud and they crack. I find that the ones who are genuninely, deeply confident in their success, are most likely to fail. They’re not connected with reality, and reality ultimately wins.)

But founder arrogance peaks once the company has had some success and has hit Product/Market Fit. It was such a hard scrabble to get here, against all odds, and now it’s actually working! Sure there was luck, but mostly there were a lot of good decisions, and a good product that solves a real problem, and decent marketing in a decent market, as evidenced by new customers showing up every day and deciding to pay for it. Incontrovertible evidence that we were right!

What the arrogant founder doesn’t recognize, is that the needs of the company dramatically change after Product/Market Fit. Everyone and almost every thing at the company has to change and adapt. Including the founder.

This doesn’t make sesne to the arrogant founder, because surely the evidence points the other way:

We reached our current success because of the way I ran the company, the decisions that we made, the trade-offs we made, the style of work that we have, the team that we built, our attitude towards features versus design versus fixing bugs versus security versus risk. We did it by looking at what was right in front of us instead of pretending that we could build a three-year plan, or even a three-month plan. We did it without a dozen managers and without a finance department.

Therefore, we can avoid doing the dumb things that big companies do. We can avoid becoming the kind of company we quit in order to start this one. We got successful because of certain things, and we will continue to be successful because of those things.

And thus the company descends into disaster and chaos. Here—after Product/Market Fit but before maturity—is the most difficult part of the journey. The founder will insist that “starting the company” is the hardest part, because (a) it was hard and (b) it was the hardest thing so far. But being hard doesn’t make it the hardest. What’s hardest is what comes next.

source

The immediate reason things get difficult is the company is suddenly growing faster than it can manage. For example, there are more support tickets than can be answered, so queues start growing without bound while service quality plummets¹. Hiring quickly and with quality is difficult and unlikely; when when you succeed, it takes six months before a person you reached out to today will make it through the interview process, quit their current job with notice, take a week off, get trained (without training materials, while everyone else is overloaded don’t forget), and finally be productive on their own. Cross-apply that to engineering, design, product, marketing, sales, and finance.

¹ In January 2012 at WP Engine, when we hit Product/Market Fit as documented in a separate article, our Twitter feedback went from “best support team in the world!” to “wow, what happened? they’re crap now.” It took until 2013 before we had enough people and process, both the science of metrics and the art of culture and empathy. Then over the next decade we were known for the best service in the industry, winning many awards, a CSAT of 98% and an NPS of 64.

You’re overwhelmed, digging out makes it worse, and because it happened suddenly, there’s quite literally no time in which to fix it.

Beyond this immediate challenge, a dozen facets of the business start breaking because of scale. Not just software and infrastructure, but people and processes and workflows. Many of these facets are detailed in this article.

The insight that addresses this sudden shift in requirements is to name and detail the very different working styles that are required before and after Product/Market Fit:

• Explore—Figuring out what works, as quickly and flexibly as possible.
• Execute—Becoming excellent at doing what works, while scaling.

You might have heard this dichotomy as “Explore vs Exploit”, because that is the normal term of art used by great strategic thinkers like Roger L. Martin, Clayton Christensen, and James G. March. You can call it “exploit” if you want, and you probably should if you’re searching Google or chatting with AI. But I don’t like that term, because while I’m a red-blooded capitalist like the best of them, I don’t like the aspect of capitalism that exploits employees, exploits customers, exploits resources, or exploits communities. “Exploitation” is when you extract maximum value at the expense of another, rather than maximizing one the best things about capitalism: Creating more value than you consume, where both parties are selfishly better off after transacting, and the entire economy grows.

Anyway, “execute” is more accurate. To meet the challenges listed above, you don’t take advantage of people or goodwill, but rather you move from a modality where you’re “figuring things out” into a modality where you’ve discovered the most important things, and now you’re operationalizing those things: making repeatable, making teachable, making higher quality, automating, and building teams that themselves improve and grow. In short, becoming excellent at execution.

The modality must match the needs of the company. Prior to Product/Market Fit, you don’t yet know what’s supposed to be repeated, and you have to discover and jettison whatever is wrong, as quickly as possible. You don’t know which customer segment should be targeted with advertisements and new features. You don’t know what price to charge or why someone should pick you over a competitor. It is equally wrong—and a common failure mode—for a company to switch from “explore” to “execute” too quickly; it’s commonly called “scaling too soon.”

Explore vs Execute

Before Product/Market Fit, you’re figuring out what works. That means answering questions like:

• Who is the perfect customer?
• Why aren’t all of them buying?
• What is the best niche?
• Which few features make them buy?
• What makes them want to buy?
• What is delightful?
• What distribution channel will work?
• What makes us different?
• What does the customer value?
• What is the customer trying to accomplish?
• What is the right price?
• What are our biggest risks?
• How do we avoid the obvious fatal mistakes?

source

The “Explore” modality is appropriate for answering these questions.

Trying, testing, failing quickly if it’s wrong. Moving quickly, because we’re running out of time and money. Undoing errors. Looking for big shifts, not subtle changes that are too small to be noticed, especially since we don’t have enough data to really measure those changes. Being confident about nothing; questioning everything; seeking the difficult truths.

After Product/Market Fit, those aren’t the questions anymore.

Let that sink in. All that work, all that worry, all the uncertainty, all the probing, all the questions, all the self-doubt… none of that is relevant now. In fact, it’s getting in the way of what needs to be done, which is to execute.

The “Execute” modality is required to answer the new challenges:

Hiring & managing, not just building things

Executive roles transition from building things themselves to building teams that build those things. Everything that needs to be done, must be done by a team, not by a single person. One reason is the amount of work; another is for stability, so that someone can get sick or leave the company without that aspect of the company grinding to a halt. Building teams is a skill set of designing organizational structures, hiring managers (not individual contributors), new methods of communication, being in command instead of in control, more organized prioritization and coordination, and balancing the needs of the organization against the needs of individuals. Just because you know how to write code or design a website does not mean you know how to interview a manager or set priorities or make a decision in a meeting or effectively communicate to a large group of people.

Fixing the shortcuts, not just new features

You built an SLC, and incurred tech debt in exchange for shipping quickly. That was correct in Explore mode, but now customers are hitting those bugs and UX issues, and hitting tech support or even hitting the “cancel” button; you have to pay down that debt and turn your band-aid-laden-proof-of-concept into a great, maintainable, delightful, usable product. You also need automation, test suites, CI/CD, auto-scale infrastructure, separate support prioritization and channels, and more. None of that is “new features.”

source

Solving for rare things becoming common

A bug that affected 1% of customers didn’t matter before. Now it causes 5 support tickets every day, and mad customers who complain on Twitter. Rare things are difficult to detect, difficult to solve, and new problems appear as you continue to grow. Quality becomes a priority, but also changes form. Requirements and processes can address it, but those are new to the company, and likely counter-cultural. You hate process and requirements, remember?

De-risking, not just new innovation

Now you have something to lose. Before, the company was likely to fail because it hadn’t figured out a business model that works, but now the thing that will cause failure is operations. Tech support becomes bad, the product is too buggy, the product doesn’t scale, you can’t keep up with marketing, tracking finance becomes difficult, an emergency security issue appears, legal issues. De-risking execution is now the priority, and that’s a completely different mentality and skill-set from adding new features.

Predictable processes

If you’re growing fast, you’re hiring a lot. The time between deciding to open a position, and having a trained, productive person in that position, is at least six months. Therefore, to hire now, you have to know what the company will require in six to twelve months, and that means the business has to become more predictable. This is true in tech support, sales, engineering, and in standing up new departments like finance or HR or account management.

You cannot permit disruptions in any area of the business, which means playbooks, documentation, measurement, processes, and other objects that maintain predictable outputs even in the face of variable inputs. These guardrails also help new people get up to speed faster and do things your way.

Addressing stalls in growth

You’re going to be underwater trying to satisfy customers while also hiring people, while also not having the documentation and training that those new people need, while also adding new processes, while also changing the culture to match the new “Execute” modality. Addressing all this will put you even more underwater. All the more reason to get this started sooner and with more intentionality. Meanwhile, growth can begin to stall as you’re lagging in new features, competitive activity, and new marketing. You have no time to waste.

Measuring “success”

It’s easy to measure success in the forms of sales leads, closed-won rate, or sprint velocity; often the new processes and requirements of “Execute” lend themselves to measurement. This is one of the few advantages. But measuring success during “Exploit” can be difficult; maybe impossible. How do you measure progress when we expect fail at least half the time? We can protest “but we learned something,” but did we²? And how do you measure that? Not all important things can be measured, and we’re tempted to say this is one of them. But an explorer who wanders for years and never finds something, is not succeeding. As a result teams who have only known “Explore” often cannot make the transition to measuring the specifics of Execute.

² It can be hard to tell what we learned, like Edison who apparently didn’t learn anything from failures, otherwise he wouldn’t have said “all I’ve learned is one more thing that hasn’t worked,” and it wouldn’t have taken 1000 trials. But even the luminaries who talked about the Explore/Execute dichotomy have said that learning is slower in exploration than execution, and more sporadic, and that the lack of consistent learning is one of the challenges of that modality.

source

Different people, different skillsets

Consider the personality of the person who doesn’t want a map, is happy to work hard only to throw it all away because “that assumption turned out to be wrong,” and to ship everything at 70% quality and completion because it’s “good enough.” This all perfect for “Explore.” Compare with the person who loves having a clear goal, clear constraints, then designs a way to complete the mission, and executes that mission. This is perfect for “Execute.” But this isn’t the same personality profile. Sometimes people can make the transition; sometimes they can’t. This is so difficult to manage, especially when they were critical to your early success.

It’s most difficult when that person is you.

And always is.

Transitioning attitude and culture

It’s not just changing what you do every day, it’s a fundamental change in your attitude, and skillsets, and in the culture of the company.

It’s taking things that you’re proud of, and realizing those are good for discovering what to make, but not good at scaling something that’s already made. It’s time to be proud of something else.

This is the hardest part. To let go of those old ways, the “things that got us here,” and sometimes, even the people who got us here. Sometimes, you yourself don’t fit anymore.

This is going to be hard.

Printed from: A Smart Bear
https://longform.asmartbear.com/explore-execute/
© 2007-2024 Jason Cohen      @asmartbear