What is An ‘Execution Plan’?
In a tweet, Sam Altman said “It’s common to have a vision; it’s rare to plans.” This is so true. One problem though, what does it mean to have a plan?
An annotated twitter thread.
A plan is not “what are you going to do”. That’s still a vision. Most everyone thinks a plan is a detailed list of what you will get done reported in a kanban. One way to think about this is to first make sure you have a strategy, but what’s that?
At the company level there is Mission, Vision, Plan, Tactics. See how plan is one part of this. Combine these and you have a strategy. Conflate them or fail to differentiate and you have a mess.
Mission — how do we see the world as a better place b/c off what we do. Why do we exist. The world can be better for many reasons. World can mean “world of IT people struggling w/ X” as much as “cure a disease”, in this context. “Inspiration”. A mission is something that a company has.
Vision — Connect the mission to something concrete a product, service, goals that can be written down. Vision is aspiration. Visions can look like high fidelity visualizations (get it) articulated by design. A vision is something a product has.
Note: One trick is that the word “vision” is often used when speaker/listener are not in agreement on the time scale or level of abstraction. That’s the origin of this framework for me :-)
Plan — a plan is an operational framework that allows work to happen. It is an organization, resource allocation, set of processes. It is everything that determines success. More in a bit. A plan is a tool for creativity NOT a substitute for one.
Tactics — details of the plan at the individual or job function. The key thing about tactics is that the people doing the work own picking, executing, measuring them. Tactics include architecture, tools, dependencies, schedule, and more.
Only when you have all of these do you have a strategy. You might think you do but as the initial thread indicated, chances are you won’t execute. Now let’s double-click on a plan.
Key to plans, is (wait for it) PLANNING. Planning is a process. It takes time. It takes effort. It is not one assertive person dominating a channel or a whiteboard and gen’ing up a deck faster than anyone else. Plans are checks and balances against reality. For better or worse, plans are not “exciting”—the end result is exciting. True story: almost no exec I ever worked for was “excited” by a plan but could easily get excited by a demo.
A plan is like a news story. There is a lede, and then it goes on to say who, what, when, where, why, and how. But getting to this point requires iterating with the whole team/company so there is a shared understanding.
More than anything for a plan to be successful it needs to be shared.
STORY. Windows, Office used to have plans that would get distributed as memos to the whole team and also to the other teams (like Windows, Office, Tools, etc.) Planning itself is collaboration.
By the time we distributed those memos, themselves a product of several authors working together, the whole of the team was well-aware of not only the contents but their specific contribution (to the plan and then the product). Planning is working as a team.
Teams outside would see the memo and assume literally a single person (me?) just wrote the whole thing and it land on the team. The perception was that anything coherent and with so much detail had to be the work of one, not a “committee”. It was weird to me :-)
Part of the fun history here is that the team as a whole had absorbed the plan (and accountabilities associated with it) so others trying to tweek or randomize the plan would be met with a bit of “but we have a plan and understand what we’re doing”. Everyone wants to be an editor, it turns out (See Leading is Not Editing).
“Universally” there’s a perception/misunderstanding for plans to be both good and coherent they must come from one enlightened genius forcing it through a team. Likewise, any plan created by many people would be a sea of compromise.
That simply isn’t true. While in times of true crisis requiring instant action, one person can/must drive change, an execution plan taking years of the work of smart people needs to engage, enroll those smart people and early.
Genius plans are super rare. Teams are not.
Who. It might seem obvious, but first part of planning is making sure the right people are involved. At a startup you need to have sales involved early even if you think they will just accept the brilliance of the Eng team, for example.
What. What are the specific problems being solved? Not what are the features 1st. Starting from problems, then scenarios, and then a hierarchy of features. List your problems solved (X), scenarios (Y) and fill in a feature grid.
The what is an outline. It is almost always 3–5 “buckets” labeled with problems and then 3–5 “marquee” features. Marketing sees this and should think “I can turn this into positioning”. In fact the blog/PR writes itself.
When. Timing is life. Plans collapse when management (or sales) says now and prod/eng says 6 mon. and no one is entirely honest. Key: individuals doing work say how long. Key to a plan is leadership sets time constraint then work scales.
PS: If you’re coordinating plans across two orgs, then timing is the only universal language — and it is a language of commitment. Two teams can only work together if they share high integrity timing — two functional teams or client/back end, etc.
Where. Not geography it’s organizational statement. Who and what functions are responsible for what. Most startups don’t need to worry, but when big you align a team around a plan, not the other way. Remember, you will ship an org chart.
Why. Why for a plan is the definition of success. Will this create a new category, sustain the business, enable a new sales model, extend product in new directions, compete?
How. All along the team is deciding tools, architecture, processes to hit the ground running. Eng might test out a new runtime or tools. Finance/sales might iterate on pricing models <> features. Everyone is thinking execution cadence.
If you consider these and spend time to develop, you can write this down. In fact above is literally an outline of a memo. This memo is not “news” to the team, but distills the plan to a memo not just posterity but to insure “same page”.
Imagine having all this for when a new team member shows up. Not only do you tell them what to do, but they start being able to spend 20 minutes and know the whole backstory for what is going on. What a great recruiting tool too.
You might enjoy this post on “Rightsizing your product plan, but not your vision”
Want to learn more about this? Good news, there’s a whole book. https://smile.amazon.com/One-Strategy-Organization-Planning-Decision/dp/0470560452?pldnSite=1 // END
PS: Here’s a more detailed (and prettier) hierarchy as posted by Dustin Moskovitz that is quite nice!
