Imagine a powerful stakeholder wants something big delivered as soon as possible. You’re the miserable soul tasked with making it happen. The CEO walks by your desk and asks: “When do you expect it to be done?”
The question that sucks all the energy out of the room. It’s like asking for the wedding date when there wasn’t even a first date.
You pull a number out of your ass: maybe… (long period of silence)…
6 months?
Dang. You hesitated to answer. You pray they don’t notice. Examining their squinty and judgmental gaze they definitely did notice. You won’t get away with it.
The CEO eyes you sternly: “What do you need to give a better estimate?”
PM: “A group of developers and some pizza.”
CEO: “Fine. Come see me when you know more.”
We can visualize what’s happening as follows:
Giving an estimate for a huge roadmap item is kinda like guessing how long it will take to excavate the unknown animal that is buried in this extremely large glacier.
The reality is that nobody really knows, but that’s not considered an acceptable answer. You don’t know the size of the animal, you can’t see where it is buried in the cloudy ice. In short: you’ve got no fucking clue. There could be a wooly mammoth buried inside or a tiny shrew. You don’t even know which of the two you’d prefer to be in there.
You need more information to give a better indication on timelines. You find a meeting room and rally some unfortunate developers to extract estimates. Yes… extracting estimates is apt because they don’t want to give them, because they know they will be held accountable once they turn out to be wrong.
To be able to give estimates, your developers demand clarity and certainty. Which you can’t give… yet, because who knows what the hell is buried in the middle of the milky-white glacier? They plead with you that they can’t give estimates without this clarity but you push them to make up numbers regardless.
Everyone is happy the estimation meeting is over. The developers walk out of the meeting room more miserable than you. They gave the darn numbers you asked for, but they believe they are completely meaningless yet make their lives miserable. They know from experience their wrong guesses will backfire and create lots of preventable obstacles for them in the future.
Their estimates are grounded in a gazillion assumptions that won’t hold true once what’s inside of the glacier is revealed.
The end result looks something like this:
Everything looks neat and tidy. Marie Kondo would be proud. This is something you can present to your CEO without hesitating.
The reality is that you’re making shit up about what’s buried in the glacier and where it’s buried, without really knowing for sure. But it’s better than nothing and it looks great on a PowerPoint slide.
You go back to the CEO and flash him a beaming smile: “We expect it will take 9 months.”
Oh oh… he flinched. He doesn’t look too happy.
CEO: 9 months? That’s way more than 6 months. I want it to take less than 6 months.
PM: …. Okay let me get back to you.
You get the band back together with a singular mission: to reduce the scope. One developer grunts: “Are wasting our time on this estimation bullshit again? At least the pizza tastes good.”
This time the meeting is over quickly, as slicing and dicing is much easier than inventing the full scope when you have too little information:
After some back and forth with the developers you agree on 5 months of work. Brimming with energy you knock on the door of the CEO and say that you expect it will take 5 months.
CEO: “Great, let’s get cracking!”
You begin working on it and those 5 months turn out to be 12 months. The CEO isn’t happy, but they frustratingly know this is what usually happens.
So it goes.
The question is: where did this all go down-hill? What can you do so it doesn’t go this way?
The Worst Approach To Estimating Big Roadmap Items
If you ask AI what you should be doing to arrive at a time estimate for a big project, this what they usually propose:
This is the lazy and incompetent approach for meeting timelines on a big roadmap item.
It’s the most common approach used by millions of Product Managers all over the world. I’ve used it a gazillion times. Everybody knows how to do it and has done it before.
There is only problem with this approach: it absolutely doesn’t work. In fact, it only makes things worse.
Why doesn’t it work?
The reason is pretty simple: estimates don’t change the amount of work something takes. Even descoping something doesn’t change the amount of work something takes, you’re just going to do less work.
Descoping is the worst way to make a project fit on a shorter timeline, because you’re completely having the wrong conversations and skipping the crucial conversations you should be having.
Descoping is about making the scope of what you’ve already decided to build smaller. There are many decisions and assumptions already baked in. You’re descoping from an anchor, which means it’s really difficult to break free from the initial anchor with all its wrong assumptions and suboptimal decisions.
A much better approach is to think about how you could design a smaller system. You basically go through the four abstraction levels of refinement together to figure out the simplest problem and solution that could work.
#1. Problem to solve
You go back to first principles: what makes solving this problem hard? Can we reframe the problem to solve a different problem that’s easier to solve but produce the same or better results?
What’s the smallest problem we can solve to reach our goals?
#2. Functional solution
What’s the smallest functional solution that could solve the problem?
What from the solution could we leave out? It’s better too add too little and find out you need to add more later, because anything you add earlier you don’t need is time you’ve already wasted and never get back. Plus the solution will contain unnecessary complexity that will likely never be removed.
#3. Technical Realization
What makes building the solution hard? Could we not build the hard part and skip it entirely? What would it take for us to do that?
What is the real thing that makes it hard from a technical perspective? Could we off-load the work to another team, or buy / adopt something to do the heavy lifting for us?
#4. Slicing of Work
How do we set-up the initial milestones so that we learn the most and set ourselves up for early disappointment and early learning?
Projects that are delivered on time show quick progress. How can we slice the project so we already have something that works after one Sprint instead of 3 months?
If your project only shows something that works after a few months, you’re setting yourself up for failure.
Stop Lazy Descoping With the Cheese Grater
Descoping is like grabbing the cheese grater to make a project simpler. You only touch the surface and shave some skin-deep stuff off to make your project smaller.
You stay in the same paradigm and you will never figure out a 10X or 100X better solution (if it even exists).
When you’re descoping something, you’re descoping the system you’ve already decided to build. Maybe you’re simply building the wrong system and it’s far too complex for the problem you’re trying to solve.
You will never find this out by descoping, as that’s the lazy, automatic pilot approach to meet timelines. You’re not talking about the real-world problems or constraints that actually make the problem you’re trying to solve hard.
You’re simply trying to fit what you’ve already decided to do in a smaller box.
Cheese Grater descoping means you will will be anchored in the surface level and descope only from the outside, instead of talking about the real-world reasons why it’s so hard to cook a giant turkey (it’s thermodynamics baby).
Maybe you should give one developer a month to build a prototype with AI to address the biggest uncertainties and risk. By doing so you could actually figure out a much simpler solution you could deliver within a month.
We’re always in such a rush to run and to deliver, that we forget to slow down.
Instead of descoping, walk through the four layers of abstraction and reason from first principles.
Talk about the real-world reasons and constraints, instead of staying on the surface level by performing lazy descoping on automatic pilot.
Remember: better estimates don’t change anything about the amount of work. It will take the same amount of time, regardless of your estimate.
Trying to estimate better means you will never figure out a 10X or 100X better solution, as all you’re doing is staying at the surface level of the work
You’re too busy trying to count the hairs of a wooly mammoth you can’t see because they are hidden in a milky glacier.
Stay anchored in the reality of the work, not the estimation fantasy you’ve concocted to provide the false certainty your stakeholders are craving for.
It is fine to throw away work to build a simple system that works.
Not throwing away the work frequently means trying to build a complex system from scratch that works.
That is a fool's errand due to Gall's Law.
Interesting. I work with several teams and one does this fairly consistently and produces more predictable and quality results. They kept calling it 'discovery' which first made me a bit chary till I saw that it was a 'working' definition, so to speak. Frequently included a POC as well.