The 70% Done Lie

You walk up to your developer and ask, “How close are we to being done?” They think for a moment and confidently reply, “About 70% done!”

Fast forward two months later. You ask the same question. “About 70% done!” they say again.

Sound familiar? Welcome to what we call “The 70% Done Lie” – and it’s not because your engineers are trying to trick you.

The Problem With Percentages

When you ask developers “what percentage are you done,” you’re basically asking them to guess. And here’s the thing about guessing – it’s usually wrong!

Think about it like building a house. Your contractor might say the foundation is “done,” but then they discover the soil needs extra work. The walls go up quickly (yay, progress!), but then electrical work takes three times longer than expected because of old wiring they found.

Software works the same way. That “simple” login feature might seem 70% complete, but then your engineer discovers they need to add password reset functionality, email verification, and security measures they hadn’t thought about yet.

The Real Culprit: Missing Team Members

Here’s what I’ve learned after working with dozens of startups: when I hear “we’re 70% done” from a founder, I automatically look at their team roster. Nine times out of ten, they’re missing a Product Owner.

Without a Product Owner to map out all the hidden features and edge cases, you end up with incomplete requirements and user stories that are way too broad.

It’s like asking someone to “build a car” without telling them it needs to have working brakes, turn signals, or a way to put gas in it. Your engineer focuses on making the engine run, then discovers there are 47 other things needed before anyone can actually drive the thing.

Why 70% Is Everyone’s Favorite Number

Have you ever noticed that engineers almost always say 70%? It’s not a coincidence! Here’s what’s really happening in their heads:

• 10-30%: “I just started, obviously not done yet”

• 40-60%: “I’m making progress but still have a lot to figure out”

• 70%: “I’ve solved the main problem, but there’s still some stuff left”

• 80-90%: “I’m basically done but don’t want to promise too much”

• 100%: “Actually finished and tested”

The problem? Most of the time, they’re stuck in that 70% zone way longer than anyone expects because nobody told them about all the “stuff left.”

The Real Reason This Happens

Your engineers aren’t lying – they’re just working with incomplete information. And honestly, how could they know what they don’t know?

When developers start a task, they see the main problem they need to solve. Let’s say they’re building a shopping cart feature. They think: “I need to add items, remove items, and calculate totals. Easy!”

But then reality hits:

• What happens if someone adds the same item twice?

• How do we handle discount codes?

• What if their internet cuts out while they’re shopping?

• How do we save their cart if they close the browser?

• What about taxes for different states?

• How do we handle international shipping?

Suddenly, that “simple” shopping cart becomes a complex puzzle with dozens of pieces nobody thought to mention upfront.

A Better Way To Track Progress

Instead of asking for percentages, try using what’s called a sprint system. Here’s how it works:

Break big tasks into tiny pieces. Instead of “build shopping cart,” you’d have:

• Add item to cart button

• Display cart contents

• Remove item from cart

• Calculate totals

• Apply discount codes

• Handle tax calculations

• Save cart when browser closes

Work in two-week chunks. Your team picks which tiny pieces they’ll finish in the next two weeks, then you measure if they actually got them done.

Count completed pieces, not percentages. Instead of “70% done,” you get “5 out of 8 pieces completed this week.”

What This Looks Like In Real Life

Let me share a story from one of our clients. They had a developer working on their product for two years (yes, you read that right). Every month, when they asked about progress, he’d say “about 70% done.”

After two years and thousands of dollars, they brought us in to review the work. Want to guess what we found? Almost nothing usable for their MVP.

The developer wasn’t trying to deceive them – he genuinely thought he was 70% done. But without a Product Owner to create detailed requirements and break work into measurable pieces, nobody (including him) knew what “done” actually meant.

The Solution: Define “Done” First

Before any work starts, get crystal clear on what “finished” looks like. We call this a Definition of Done.

For that shopping cart example, “done” might mean:

• Users can add items to their cart

• The cart saves even if they close their browser

• They can remove items they don’t want

• The total price updates automatically including taxes

• Discount codes work properly

• The feature works on phones and computers

• It’s been tested by someone other than the person who built it

• Error messages show up when something goes wrong

Now instead of guessing percentages, your developer can check off concrete items. Either the cart saves when you close the browser, or it doesn’t. No guessing required!

Your Action Plan

Starting this week, try this approach:

1. Stop asking for percentages. Seriously, just stop.

2. Get a Product Owner on your team. They’ll help map out all those hidden requirements before they surprise you.

3. Break big features into small, testable pieces. If it takes more than a few days to build, it’s too big.

4. Set up two-week check-ins. What will be completely finished by then?

Remember: the goal isn’t to micromanage your developers. It’s to give everyone (including them) a clear picture of real progress and all the work that actually needs to be done.

The 70% Done Lie isn’t malicious – it’s just what happens when smart people try to predict complex work without complete information. By getting the right team members in place and changing how you measure progress, you’ll get better estimates, fewer surprises, and products that actually get finished.

Want to dive deeper into managing tech teams without the technical background? Check out our complete guide to tech terms that every business leader should know.

Coming Next Week: Creating a Backlog That Makes Sense - Organizing your tech to-do list for maximum clarity.