Breaking Out of Stuck
Over the last few months, I’ve received dozens of emails from readers asking me how to get their idea or project unstuck.
I’ve done my best to answer everyone’s question individually, but for every person who emails me directly, I can be sure there are two or three others with the same problem who haven’t spoken up.
So today I want to talk about getting a project unstuck – and layout a specific framework for doing just that.
This framework works for virtually any type of project in any industry, and I’m certain it can work for you, whatever your sticking point.
A Caveat: No, there’s no one-size-fits-all solution for every problem.
My intention isn’t to give you the answer.
My intention is to give you a framework for approaching problem sets so you can systematically improve your chances of getting unstuck and getting your book, business, blog, whatever to the next level.
If you have any critiques or comments on my framework, leave me a comment below – even the best framework or system can be improved!
1) Identify your Endstate and Mission
The endstate is essentially your ultimate goal. It’s the final situation you want to create for your project.
Think of it this way: in a perfect world, what would your project look like when it’s finished and shipped?
Why is the endstate so important? Because without it we have no guidance or direction for our mission, and the mission is exactly how we reach the endstate.
A good endstate is measurable, tangible and detailed enough to allow us to craft our mission.
- In the Army, an endstate might look like: Alpha Company gains control of bridge X so friendly forces can pass through without enemy interdiction.
- If you’re writing a book, a good endstate might be: physical print in the hands of readers.
- If you’re creating a software business: repeat customers pay for our subscription based software.
Objectives and the Scope of an Endstate
Being too big or too small with your endstate can hurt your plans here.
While it’s good to set your sites high, there are diminishing returns when you start setting impractical endstates relative to what you’re capable of achieving. That’s why it’s important to remember that an endstate is composed of multiple OBJECTIVES.
Objectives are those mission-critical events that lead us to the final endstate.
There are progressive objectives in just about any scenario, and each objective is the result of hitting smaller objectives along the way.
In the Army, when you lay out progressive objectives, each one laying the foundation for the next, they call it nesting.
Nest Your Missions
The endstate for the military in the European theater of WWII was Allied control of Europe. This meant the mission, vaguely speaking, was to defeat the Axis power. Obviously, if you’re a lowly company commander, this endstate doesn’t help you much on the ground, does it?
That’s why in the Army they ‘nest’ their missions; they identity major objectives that must be met to meet the endstate, and they continue to break these down into smaller missions for lower units. So as a Company accomplishes their mission it feeds into the Battalion’s mission, which feeds into the Brigade’s mission, etc.
Each unit’s mission must nest with the higher unit’s mission.
In this way, if I’m a company commander and I execute my mission successfully (securing the bridge), this allows the Battalion (one command level higher) to meet their mission (secure the southwestern region)
Applying this to the world of entrepreneurship or art is simple: if you’re setting your endstate way beyond your capacity, that’s okay, but remember – you can only execute the mission at your current level.
So go ahead, by all means set your endstate as having your book published in 50 countries and languages across the world. But this isn’t your mission. You need to keep backward planning (see below) until you get to an actionable mission for the level you’re at (which, most likely, is publishing a book on Amazon and getting digital copies in the hands of readers).
2) Backward Plan
Backward planning means identifying every objective that must be met to reach your endstate and planning from the endstate backward to your present situation.
Backward Planning and Underpants Gnomes
Backward planning is effective because you’ll never end up with a giant gap of uncertainty – every objective will lead to the next, which means you’ll never be at a loss for what to do.
If we’re not detailed with our backward planning, it can often lead to massive gaps. This is the reason most people’s projects get stuck – instead of backward planning and creating a detailed, step by step roadmap for what to do, they end up with an Underpants Gnome plan.
In the second season of South Park, there’s an episode about underpants gnomes. Underpants gnomes are gnomes that sneak into peoples rooms at night to steal underpants. But they don’t do it for that reason – they have a plan:
Step 1: Collect Underpants
Step 2: ?
Step 3: Profit
When we set unrealistic or impractical endstates, or when we try planning toward an endstate months or years out without meticulously working backward, we’re usually left with an Underpants Gnome plan. Instead of establishing strict, actionable objectives, we have an idea of what we want (Collect Underpants), and a general goal (profit), and nothing in between to get us there.
You can avoid an Underpants Gnome Plan by aggressively chunking and thrashing your plan (see below).
Chunking means breaking up your plan into actionable, bit-sized pieces with estimated time requirements and unique ship dates for each chunk.
The idea behind chunking is to identify every single step along the path to your endstate in a clear and precise manor. By identifying a ship date for each ‘chunk’ we eliminate procrastination or missing deadlines. By estimating (as accurately as possible) the time requirement to complete each chunk, we avoid the possibility of hitting a massive, insurmountable objective half way through our project (stuff like that can cripple a project).
Chunking is more art than science, but it starts with getting really, really detailed in your plan by identifying:
1) Facts – what are the facts of your project? If you’re bootstrapping a software company, a fact might be that you have one engineer on your team capable of coding the product. If you’re writing a book, a fact could be you have very little money to outsource editing. Facts are important for identifying limitations and restrictions (which affects your timeline and the chunking process)
2) Assumptions – what are you taking for granted or hoping/guessing will happen throughout the plan? A common assumption: I can do it all myself. This is almost never the case, no matter what the project.
3) Limitations and Restrictions – this is where you identify where facts or assumptions will limit or restrict your planning. So if you have one engineer to code the product, this limits the ability to start on the next product until the first one is done (without negative side effects).
A good rule of thumb for chunking: break everything down into objectives that take several hours or less to complete.
“Write Book” is a bad chunk. Breaking it down into parts – Table of Contents, Outline, First Sentence, First Chapter, Title, etc. – is much more effective.
You want to be able to accomplish a piece of your project every day to maximize momentum and keep your project moving forward.
4) Thrash (ongoing process)
Thrashing is the process of removing everything but the essential.
Very few products require more than a few features. This is especially true when you’re first starting out and you’re trying to prove an unknown (i.e. sell a new product to a new market). The fewer features you have, the more you can focus on what matters – and the less likelihood your project will go over time and budget (the killer of all startups).
But there’s an even better reason to strip your product/service/idea of extraneous fat (read: unnecessary features): it is necessary for idea validation.
Idea validation is determining what features you need based on iterative testing with users.
Ultimately, idea validation is about product/market fit – are people willing to pay for your product or service. In a matter of speaking, idea validation determines whether what you create has a reason for being created.
This is the biggest hurdle for most aspiring entrepreneurs to get over – sometimes the idea you have isn’t as good as you think it is. But the only way to find out is by testing it in a market. The only way to do that is by selling it to your customer.
If your customer doesn’t want it, time to think of a new solution.
If your customer likes it but there’s a holdup (cost, features, whatever), then you can continue to test new variations of the same idea.
The goal here is to test a decent sized audience so you’re not relying on just one person’s input, who could very well be the anomaly if you had taken a larger sample size.
Taken from the principle of lean starting, if ten people love what you make (and pay you for it), you’re probably onto something.
Thrashing Throughout the Project
While I mentioned thrashing as step 4 in this framework, it’s really an ongoing process that begins the moment you have an idea and doesn’t stop until you’ve shipped.
There are always things you can cut, slash, limit and refine. This is not a bad thing! Think about it – probably the best things in this world (product, service or art) are probably great at one thing, not okay at a bunch.
Your job is to be excellent at one thing. Go for depth, not breadth. Leave mediocre for the try-hards.
This is a really simple breakdown of the framework I use when I start a new project. I didn’t include all the details here because they’re usually not the most important part. What’s important is a clear vision and an idea of the path or roadmap to get there.
That’s the purpose of this framework – to help you focus on what really matters.
If you found this helpful, you should definitely check out my guide and workbook on starting, finishing and shipping projects: The Gunslinger’s Guide to Starting and The Gunslinger’s Workbook.
In that guide and workbook, I go into more detail and give you a workbook to actually frame your project. I’ve received some great feedback, so if you’re stuck with a current project of looking to start a new one, grab it (it’s free).
I hope you find this framework practical.
Leave a comment below and let me know what steps you’ve taken or what framework you’ve used to ensure the success of your projects. And if you’ve found yourself stuck, let us know where and why, so we can work out a solution.