You’re being chased by a hungry bear. Drop your fancy camping gear, or the bear will eat you.
– Amy Hoy
In early-stage companies the one thing that wil have the greatest impact on your success is how quickly you can learn. The most powerful concept I've used to optimize my work for learning is to - "reduce scope rather than extend deadlines".
This concept can immediately increase the value of your effort, skyrocket the velocity at which you ship value, and shorten the feedback loop that drives learning.
Have you ever been discussing how you'll approach a problem and whether in a conversation or a document found yourself creating a long checklist of "requirements"?
Just last week I was discussing some new customer feedback with a founding team and we started adding new features to a mental list. What we quickly realized when we started to talk about when we could ship those features though, was that while all the list items might be nice to have, actually solving the customer's problem could be achieved by creating something much smaller in scope.
Back to the story. Let’s break down the two sides of the concept:
The more time we spend before putting what we create in the hands of customers, the greater the opportunity cost of spending time creating something that doesn't add value for them.
If instead of combining everything we "could" create, we distill our solutions down to the smallest complete unit that provides value we can ship them incrementally ensuring we are learning and adjusting as we go.
My first introduction to this concept was way back in 2014 when Intercom's Des Traynor wrote about "starting with cupcakes". More recently WP Engine CEO Jason Cohen wrote about making things that are “simple, loveable, and complete”.
While these posts talk about using this approach in the context of building products, I believe it is equally applicable to all aspects of our daily work. Whether you're creating content, designing a new interface or writing code.
The most important things to remember when reducing scope are that what you make:
... must enable the outcome customers want.
... must be of high quality.
... can always be added to or updated later.
vs Extending deadlines
Estimating how long a project will take to complete is hard. You've likely done lots of research and thinking up front but the chances are that once you actually get in the weeds with the problem you'll uncover something you hadn't accounted for in your plan.
It can be tempting to simply expand the scope of your project and do more work to solve the problem but this leads to more work in progress that isn't adding value for customers. Amplitude's John Cutler writes about setting "work in progress limits" to help manage this risk.
Setting hard deadlines can be an effective forcing function to drive you to ruthlessly cut scope and shift focus to the value you're providing to customers rather than the internal facing effort you're exerting.
When setting deadlines ask questions like...
... what could we ship today/this week?
... can we push that "effort/feature/task" to a subsequent release?
... is there an alternative path that could provide value faster?
We need to remember that the work itself is not the goal. The goal is to add value for customers and help them achieve progress.