Execution > Strategy

A framework to help prioritize the many ideas that bounce around startups every day.

Startups are full of ideas. Some of them are big thoughts about the direction of the company. Some of them are small concepts about how to make the product easier to use. And then others are just fleeting notions that turn out not to have been all that good to begin with.

As a rule, there are more ideas inside a startup than could possibly be executed. So one of the hardest jobs for a founder (or product manager or anyone else with the power to set priorities) is where to focus that attention. When it comes to product, specifically, you’ve got feedback from customers, internal users, and your own roadmap to wrestle with.

What do you do with a good idea?

One reasonably simple rubric I’ve put together over the years is this effort/investment stack. The idea is that you can take any idea about the company and try to figure out where it sits and whether it’s possible to test the idea in the higher speed/lower effort layers of the stack before moving it down to actual functionality and eventually strategy.

A simple prioritization framework for product ideas. Ideally, things are tested at the top before they move their way down.

The first thing you'll notice is there are two axes. The idea is that the higher you are in the stack the faster things move and the lower the effort/investment is. By the time you get to the bottom—strategy—you are talking about low speed/high investment changes to the company and product.

Here are the layers of the stack from low effort/high speed to high effort/low speed:

Content/Marketing: the least effort/investment goes to the content/marketing. That’s not to say it doesn’t matter, but writing a blog post about how to use your product in a new way is even easier than writing documentation, updating the UI, changing functionality, or even jumping onto a new strategic direction. (Depending on how you handle things, documentation and content could easily be flipped.)
Documentation: documentation doesn’t need to work through the same process/timeline as product changes. Even a small in-app copy change might not go out until the next deploy, but an update to a startup’s docs can go out right now. What’s more, documentation generally offers more space and visual area to explore (you can use images, videos, etc.).
Product Copy: within the UI there is copy, and that’s even easier to change than UI itself. If there is a feature that people aren’t using, for instance, and there’s an opportunity to make it more clear with copy, that’s a great thing to do before redesigning how it works.
UI: ultimately the UI sits on top of the functionality, so it’s easier to change. A good feature idea that can live at the UI layer will be faster to deploy than one that needs additional functionality.
Functionality: you can think of functionality as the data model, features, and other core components that make the product what it is. I’ve always believed that SaaS companies are defined by the objects they initially design their product around. Salesforce will always fundamentally be about communication with customers because their objects are accounts and contacts while Mixpanel will always be about product managers because its core objects are dashboards and charts.
Strategy: these are the fundamental decisions around what the company does and how it operates, this is obviously the top of the stack and the thing that takes the most work to change.

Using these layers to make decisions

Here’s a relatively simple example of how we’ve recently used this framework to make a decision. This week we are launching some new very cool functionality that lets you see data change in real-time. We’re excited about it and it will open up a lot of new possibilities for our customers. We’ve been testing it and have found some exciting ways to use it with data from Hubspot. Someone mentioned that we should show this to customers in the app. That would be great, but it would be a lot of work: showing it to customers would require changes at the UI and maybe even functionality layers. (This is where product onboarding tools can come in handy, but that’s a story for another blog post.)

So how can we try this cheaper? To start, we can write a blog post or update our documentation to show off this feature. Since we already show use cases in our documentation, it makes a lot of sense to live there. From there, as we see how customers use the feature and whether they are excited about the same things we are we can start to nudge them in the direction with some in-app copy changes and eventually even include it in our onboarding flow (which we built custom and utilizes existing product functionality but operates entirely on the UI layer).

Why execution > strategy

So why does all this mean execution is more important than strategy? Because it’s a cheap way to test your strategy before you go all in. Frank Slootman, legendary tech leader and CEO of Snowflake, explains it like this:

No strategy is better than its execution. … You can go very, very far with world-class execution whereas you will go nowhere, no matter how brilliant your strategy is … so execution really needs to come first because strategy is not something you can navigate if you don't know how to execute. The other thing is when you become a strong executor, strategic questions start to crystallize and sort themselves really quickly—in other words, you will become a better strategist as you become a better executor. Execution is day-in-and-day-out, every moment of the day. Strategy is not something that you can touch and tweak every moment of the day—once you set it, you really have to stick with it. If you're changing your strategy at the drop of a hat, you're already way behind the eight ball.

Two really important points to pull out of that quote:

“When you become a strong executor, strategic questions start to crystallize and sort themselves really quickly.” This relates to some of what I wrote about in my Shape of Data post as it relates to tinkering. But fundamentally, the better you’re able to execute, the more quickly strategic questions can be asked and answered.
“Strategy is not something that you can touch and tweak every moment of the day.” This is why it exists at the top of the stack. Making a strategic change is a high effort/investment decision. It will impact the whole company and everything you do. You don’t want to do this often, and when you do you want to be really confident about it.

Ultimately the real point isn’t that execution is more important than strategy, but rather that they’re complimentary. Strong execution lets you test and validate bits of strategy before they become company-changing decisions. As you’re moving through life as a startup, there are tons of strategic questions to answer, and in my experience trying to figure those out from the bottom-up instead of top-down is a much more powerful approach. In the end, these layers help provide a simple guide as we’re making prioritization decisions that will ultimately shape the product and company’s future.