At our standup last Tuesday, someone suggested we could demo a feature that afternoon. We could walk through the experience we’d been building, and I could see why everyone felt good about showing it. I was already thinking about the remaining work as something we could fit around the rest of the week.
By lunchtime, we were arguing about an edge case that seemed obvious once we started discussing it. About four hours after describing the feature as “basically done,” we were trying to agree on how part of it should work.
So, the morning’s confidence had changed the way I experienced that conversation. We were learning something important about what we were building, yet I was already wondering how much time this would add. In my head, we’d moved on to finishing touches. Having to make another product decision felt like going backwards, even though answering that question was helping us move forward.
That reaction is the part of the “90% problem” I’ve been thinking about lately.
What someone else hears when I say “almost done”
When I tell a teammate that a feature is almost done, I usually mean that I’ve made the main idea work and can see a route to finishing it. I’m describing my confidence in the work as much as the work itself. My teammate has their own decisions to make, though. They might be figuring out when to start an integration or whether to offer a customer a demo. When they hear “almost done,” they have a reasonable basis for putting something on their calendar.
Meanwhile, I may still be carrying a fairly loose idea of what remains. I’m thinking I need a little more time to check things; they’re thinking they can start on Thursday.
Once someone else starts planning around my estimate, I feel more committed to it. A useful question from a colleague now comes with an uncomfortable second thought: how much will this change what everyone is expecting?
I can be genuinely interested in understanding the issue while also hoping the answer will fit inside the afternoon I’ve already mentally allocated to it. That puts a strange pressure on the conversation, because I’m trying to learn something and defend my earlier judgment at the same time.
Calling the remaining work “polish” makes this especially awkward. It becomes harder to explain why we need another discussion when I’ve already described what’s left as a few finishing touches.
AI helps me reach that confidence earlier
I’ve felt this with code I wrote myself, too. What feels different when I work with AI is how quickly I can reach something convincing enough to show a colleague.
That speed is genuinely useful. Having something we can try together gives us a much better basis for discussing the experience we’re building. A colleague can follow their own instincts, take a different route, and ask a question that changes how I understand the feature.
For example, imagine I’m showing someone how a user edits and saves a record. My colleague asks what should happen if that person’s access changes while they’re working. Now we need to decide what happens to their changes and how we explain the situation to them. We’ve moved from demonstrating an interaction to discussing what we owe the person using it. Depending on the product, answering that question could involve several people and some careful thought.
Getting to that conversation sooner is valuable. The difficulty comes when I’ve already used the demo to reassure everyone that we’re nearly finished.
I think this is where my sense of “90%” becomes misleading. I can picture the finished feature clearly enough that I start treating the remaining work as predictable. Then a colleague helps me see something more clearly, and I experience that discovery as an expanding workload.
Looking back at Tuesday, I can see how much the morning’s conversation shaped my expectations for the afternoon. We had a version we could discuss meaningfully, and that discussion helped us discover a decision we still needed to make. Somewhere along the way, I’d started expecting the discovery part to be over.
Giving my teammates a more useful update
I’ve started paying closer attention to what I’m inviting people to do with my progress updates.
When I say something is demoable, I want a teammate to feel comfortable trying it with me and helping me examine the experience. When I say it’s ready to ship, I’m asking them to place a different kind of trust in it. Keeping those expectations clear has become more important as I’ve been able to build the first version faster.
In practice, I’m trying to replace vague confidence with a description of what we understand and what we’re still deciding.
For a feature like the permissions example, I might say:
“We can demo how someone edits and saves their work, and I’m checking what happens if their access changes halfway through. Once we’ve agreed on that behavior, I’ll have a firmer estimate for release.”
That takes a little longer to say, but it gives my teammate something useful to work with. They can see what we’ve accomplished, understand the decision ahead, and perhaps help me resolve it.
It also changes how I feel when someone raises a concern. By making room for that discussion in the update, I’ve given myself room to learn from it. We can work through the question with a shared understanding of where we are.
What I’d say differently on Tuesday
I’d still be excited to show the feature. Reaching the point where colleagues can try something and respond to it is meaningful progress, and I want us to enjoy that. But I’d also be more careful about turning that excitement into a delivery expectation. I’d explain what we were ready to demonstrate and where I still wanted people to challenge my thinking.
The lesson I’m taking from that afternoon is about how I communicate uncertainty while I’m feeling confident. Those two things can exist together, and my teammates benefit from hearing both.
I’d like them to leave standup understanding what I’m excited about, what they can plan around, and where I could still use their help. That seems much more useful than asking everyone to interpret the same percentage.
When you tell your team something is “almost done,” what do you think they hear?
Top comments (0)