Shape More, Estimate Less

Stop Estimating Chaos—Start Shaping Clarity

Let me guess: someone asked for an estimate this week, didn’t they?

It always starts innocently enough:

“Hey, can you give me a quick estimate for this project?”

It sounds harmless. But hidden in that simple question, there is a can of worms just waiting to explode all over your roadmap, your priorities, and your engineering team’s sanity.

If you’ve been around long enough in tech, you’ve probably lived some version of this drama. The characters may vary, but the scene is all too familiar.

The Broken Conversation

For context:

• PM here could be a Product Manager, an internal stakeholder, or even an executive. They usually represent the “what” and “why” of a project.

• TL stands for Team Leader (or Tech Lead), the engineering voice responsible for guiding the team on the “how” and “how long.”

Let’s drop in on a typical exchange:

PM: Hey! I need an estimate for the Y project.

TL: Seriously? We’re already swamped with the X project.

PM: This comes straight from leadership—I need it tomorrow.

TL: Fine. We’ll see if we can squeeze it in.

(Next day)

TL: It’ll take around 4 weeks.

PM: Four weeks? That’s too long. It should only take two.

TL: Then why did you even ask? Just pick a number next time!

PM: Don’t get defensive. Leadership expects it in two weeks, so make it happen.

TL: Not my problem if leadership can’t handle reality.

PM: This attitude isn’t helping anyone.

Sound familiar?

What Went Wrong?

The PM just wants to keep things moving. The TL is trying to protect their team from being crushed under impossible expectations. Leadership needs velocity. Engineering needs clarity. But instead of pulling together, everyone ends up pulling apart.

Team Leader Mistakes

• Started with defensiveness instead of curiosity or alignment.

• Didn’t clarify trade-offs, just dropped a number with no reasoning.

• Reacted emotionally, escalating conflict instead of managing expectations.

Product Manager Mistakes

• Demanded an estimate without having the work clearly defined first.

• Used urgency as pressure, not as context for collaboration.

• Challenged the estimate without understanding how it was made.

• Treated the estimate as a commitment, not a conversation starter.

This happens because we’re often trying to answer the wrong question. We think we need better estimates. But we actually need better “shaped” work.

The Estimate Trap

Estimates have always divided the software world. Some see them as essential for planning. Others view them as unreliable guesses wrapped in false confidence.

The #NoEstimates movement, championed by

Vasco Duarte

, challenges the need for estimates entirely. It argues that estimating delivery dates based on early lists of features or stories leads to waste, misalignment, and mistrust—and that teams are better off delivering value incrementally.

But most experienced engineers and product leaders agree:

The real problem isn’t estimates—it’s how they’re treated.

Too often, estimates become promises. As if engineering had a simple formula:

estimate(feature_or_project) => duration_in_days

But estimating without shaping the work is like guessing how long it takes to build a house without knowing if it’s a cottage or a skyscraper.

You get vague input. You throw out a number. That number becomes the expectation. And when reality doesn’t match? Blame, fire drills, and broken trust follow.

Deadlines Aren’t the Enemy

There’s a crucial distinction:

• Estimates ask: “How long will this take?”

• Deadlines say: “We’re willing to spend this much.”

Think of a deadline as a budget of time and resources.

“This idea is worth two weeks of our time. What’s the best value we can deliver within that budget?”

That shift in mindset reframes deadlines from pressure into strategic investment. You’re not guessing. You’re deciding how much to spend and asking what’s achievable within that limit.

It leads to:

• Smarter prioritization

• Scoped-down, realistic outcomes

• Team autonomy

• More predictable delivery

Instead of asking, “How long will Feature Y take?”, ask:

“We have a two-week budget—what’s the best version we can build with it?”

This approach avoids over-promising based on shaky assumptions.
It empowers teams to make thoughtful trade-offs and deliver with confidence.

Cooking Analogy: Estimate vs Deadline

You’ve got 1 hour before a meeting and want to eat something healthy.

Estimate mindset:

“This curry looks good—how long will it take?” The recipe says 45 minutes. Halfway in, you're missing ingredients. You run out of time.

Deadline mindset:

“I’ve got 1 hour—what can I cook that’s healthy and doable?” You scan the kitchen, make a stir-fry or salad, and show up fed and on time.

Deadlines don’t lower the bar—they sharpen your focus.

In product work, the same principle applies:

• Fix the time, shape the scope → momentum and clarity

• Fix the scope, estimate the time → stress and misalignment

What Is Shaping, Anyway?

If you’ve read Shape Up by Ryan Singer, this concept will sound familiar. But even if you haven’t, it’s pretty intuitive:

“Shaping is work that happens before the cycle begins, to set boundaries on what the team will be asked to deliver. It involves defining the problem, roughing out the solution, and addressing risks before committing to build it.”

— Shape Up, Ryan Singer

The Three Properties of Shaped Work

Shaped work has three essential characteristics:

• Rough: It’s intentionally unfinished, giving designers and developers the flexibility to apply their expertise and handle real trade-offs during implementation.

• Solved: Even though it’s rough, the core solution is thought through at a macro level. There’s enough direction to guide the work, and foreseeable risks have been addressed.

• Bounded: It includes clear limits. It defines what not to do and fits within a specific time frame—known as the “appetite.” This helps keep scope in check.

These traits give the team room to make decisions while staying aligned with the problem and constraints, reducing risk and increasing focus.

The Four Core Steps of Shaping

1. Set boundaries: Decide how much time the idea is worth (the appetite) and define the core problem you’re solving.

2. Rough out the solution: Sketch a high-level approach without diving into detailed specs or wireframes.

3. Address risks: Identify edge cases, technical unknowns, or gaps that could derail the project or lead to open-ended work.

4. Write the pitch: If the idea still looks viable, summarize it in a short pitch that outlines the problem, the solution, key constraints, and any identified risks.

Shaping Together: Product, Design, Engineering

Shaping isn’t a solo mission. It works best when Product, Design, and Engineering shape the work together—before it ever hits the development cycle.

Each role brings something valuable:

• Product Managers bring context and priorities.

• Designers bring user empathy and interaction thinking.

• Engineers bring constraints, edge cases, and technical trade-offs.

This collaboration helps surface blind spots early. It prevents scope blow-ups later. And it leads to a better solution—because everyone helped shape it.

As Fred Brooks famously said:

“Plan to throw one away; you will, anyhow.”

Shaping helps you throw away the wrong idea before any code gets written.

Why Shaping Matters

In simple terms, shaping is about scoping the work before it reaches the engineering team. You’re not asking engineers to build—or estimate—something that’s undefined. You’re giving them a solvable, constrained problem.

It’s not waterfall. It’s not months of documentation. It’s just enough structure to move forward with confidence.

Instead of asking, “What will it take to build Feature Y?”, you ask:

“Here’s the user problem, here’s how much time we’re willing to spend, and here’s a rough idea of how to solve it.”

This flips the conversation from guessing to collaborating.

Fixing the Conversation: Two Better Ways Forward

Estimates and deadlines often drive the conversation around software projects. But without clear boundaries and defined scope, they lead to confusion and friction. So how do we fix it?

Here are two clear, collaborative ways to handle this:

Approach 1: Appetite-Driven (Shape Up Method)

Start by setting a fixed time boundary—your appetite—and then shape the project accordingly. This approach doesn’t rely on estimating how long work might take. Instead, it scopes the project to fit within your defined timeline.

PM: We’re looking to tackle Problem Z with Project Y. Leadership values delivering something impactful in about two weeks. Can we shape this together to see what’s achievable?

TL: Great clarity. Given our workload with Project X, let’s review priorities and see what fits within two weeks.

(Next day)

TL: We’ve shaped something valuable that fits into two weeks, but it means deferring some features. Here’s what’s feasible…

PM: Excellent. I’ll present this scoped version to leadership.

This conversation aligns the team around a realistic goal and shared constraints, making collaboration easier.

Approach 2: Shaping First, Estimating Second

Alternatively, shape the solution first, then estimate the effort needed. Here, estimation happens only after you’ve collaboratively defined the work clearly.

PM: We want to address Problem Z with Project Y. Could you help shape the solution so we can estimate it accurately?

TL: Absolutely. Let’s first define what success looks like and break down the main components clearly.

(Next day)

TL: After shaping the solution, we estimate roughly 3 to 4 weeks, depending on certain implementation details. We’ve also identified some potential risks.

PM: Perfect. This gives us clarity to prioritize and adjust scope accordingly. Let’s move forward.

This approach ensures estimates are realistic and rooted in a clear understanding of the work.

Both paths prioritize clarity and collaboration, helping your team replace guessing games with structured, meaningful discussions.

Final Thoughts

You don’t need better estimates. You need better shaped work.

Whether your team prefers working within a fixed time box or estimating after shaping, the real game-changer is clarity:

• Clarity on the problem.

• Clarity on constraints.

• Clarity on what success looks like.

Shaping gives you that:

• It replaces guesswork with grounded conversations.

• It turns conflict into collaboration.

• It creates space for engineering and product to work as partners—not opponents.

So the next time someone says, “Can you estimate this real quick?”—pause. Smile. And ask:

“Can we shape this first?”

Because the fastest way to deliver value isn’t rushing to a number. It’s understanding the work well enough to make a real bet.

P.S. If this resonated, forward it to your favorite PM, TL, or anyone who still believes shipping starts with a number. Let’s shape smarter, together.

---

Enjoyed the article? Hit the ❤️ button and share it with others who might find it helpful. Subscribe to support my work and stay updated on future issues!