Getting Things Done 'On Time'
How Prioritizing Completion Over Perfection Helps Us Be More Efficient And Productive
Every product team faces the challenge of balancing ambitious goals with the reality of finite resources. As the bar for “good” rises, the list of requirements grows and teams are asked to deliver more with less time. As a result, many fall into the trap of over-promising and under-delivering. Tight deadlines challenge every team. Getting work done on time demands relentlessly focusing on the essentials instead of chasing every nice-to-have. When teams focus on what truly matters, they conserve their energy for solving the right problems. Shipping a finished product is more important than a “perfect” one. This does not mean sacrificing quality, but rather delivering a viable solution first and then refining it later.
Why Most Estimates Are Bad
We make most estimates based on incomplete information and inaccurate assumptions.
An estimate predicts how long it will take to do something based on known variables. Its accuracy depends on how many variables the team accounts for and how accurately they account for them. Bad estimates are simply the result of teams underestimating the impact of uncertainty. Even their “conservative” estimates are often too optimistic. They assume most things will go smoothly. However, unexpected issues always emerge, extending the time it actually takes to get things done.
Product teams need estimates to plan their work. Predictability helps them effectively deploy their efforts and resources to accomplish their objectives. Estimates also keep them accountable to their stakeholders. However, when the work involves any degree of uncertainty, estimates are almost always wrong. Sometimes by a little. Sometimes by a lot. This makes the work unpredictable, which makes it harder to achieve sustained productivity.
The problem isn’t that you’re not working fast enough. It’s that your expectations were never realistic to begin with.
— Wes Kao, Cofounder of Maven
The Variables That Impact Estimates
Three types of variables influence how long something will take:
Known knowns: Things that take a predictable amount of time and can be accurately accounted for (with a small margin of error). For example, Task A will take 2 hours.
Known unknowns: Things that take an unpredictable amount of time and can be approximately accounted for (with a large margin of error). For example, Task B could take 2-8 hours.
Unknown unknowns: Things that have not been accounted for at all. For example, Task C was completely unexpected, and completion time is unknown.
It’s often the unknown variables (#2 and #3) that derail projects: Teams incorrectly assume they have all the information needed to make an educated guess. So, they come up with a seemingly “good” estimate, only to find that things take much longer than expected.
Bad Estimates Create A Vicious Cycle
When estimates are consistently wrong, teams keep over-promising and under-delivering.
Teams estimate how long something will take, and make delivery commitments to stakeholders. However, when the work begins, they encounter unexpected issues. The “quick,” “simple,” and “easy” tasks turn out to be complex and challenging. They are blocked from working on tasks because of dependencies (e.g. Task A must be done before Task B). As everything takes longer, the pressure, stress, and anxiety increase. The deadline is inevitably missed, upsetting stakeholders. The team rushes to deliver, using more resources in the process. They provide longer estimates and under-promise on the next project (in case things go wrong again). Stakeholders are unhappy and demand the teams “work faster” and “get more done.” The team reluctantly “adjusts” their estimates, and the cycle starts again, perpetuating more dysfunction, frustration, and distrust.
If Most Estimates Are Bad, Why Bother Estimating
Plans are useless but planning is essential.
We need estimates to plan out the work—what needs to be done and how. While it’s tempting to think a “perfect” plan will protect us from failure, the reality is that things always go wrong. However, the process of planning helps us figure out what we can realistically achieve within a specific timeline. It surfaces assumptions, dependencies, risks, and trade-offs. Plans must be flexible. Instead of treating them as a step-by-step guide, we should treat them like a compass that directs the team’s efforts. While we can certainly get better at time management with enough knowledge and experience, we can never be certain that things will go as planned. Even the best plan only reduces uncertainty. It does not eliminate it.
You May Also Like: Time Management
What Can We Do Differently
Understand How Much Uncertainty The Work Involves
Start by asking some basic questions:
Do we fully understand what needs to be done and why?
Are all the stakeholders aligned on what needs to be delivered?
Have we done this work before (worked on a similar feature, project, etc.)?
Are we familiar with all the elements involved (tasks, processes, tech, etc.)?
Do we have everything needed to do the work (context, skills, resources, etc.)?
Can we dedicate our entire focus to this work (there are no other commitments)?
Are the scope and deliverables likely to stay the same as we do the work?
Do we know all the potential issues (problems, constraints, risks, etc.)?
Do we have a clear strategy to deal with potential issues?
Have we fully evaluated and understood the complexity?
If the answer to one or more of these questions could be NO, any estimates the team comes up with will likely be wrong. Therefore, they must account for these factors in their estimate. It’s also important to highlight these points of uncertainty to stakeholders, so they understand how reliable the team’s estimates are. The greater the uncertainty, the lower the estimate accuracy. The best option for a project with a high level of uncertainty is reducing the scope to limit uncertainty or running experiments to gain more information before committing to the project. Even if the team can confidently answer YES to all these questions, things can still go wrong.
Understand The Team’s Limitations
Recognize constraints to deliver real value instead of chasing perfection.
Teams have finite resources that need to be used wisely. Unrealistic goals inevitably lead to disappointment or even disaster. When defining requirements teams must be explicit about what is essential and what can be cut if there’s just not enough time. This should be discussed early on so there are no last-minute debates. Teams (and their stakeholders) could certainly argue that their entire list of requirements is essential. However, in reality, they don’t know what the customer’s “ideal” solution is until they get something in their customer’s hands and get real feedback. Adding every little thing they think matters is rarely worth it.
While stakeholders might not like what teams can realistically deliver, they will certainly appreciate consistent delivery. Teams must manage stakeholder expectations so it’s clear why “just adding XYZ” is not as straightforward as it seems. They must honestly map tasks against available hours and engineering capacity. Not everything can realistically be squeezed in before a deadline. Good product teams consistently deliver solutions for real and immediate problems. That’s what makes the product valuable to customers right now. If customers can’t see the point, they won’t wait around until you’re done “perfecting” things.
Set The Appetite, Not The Estimate
Focus primarily on what you want to get done.
Setting the appetite is an alternative to estimates introduced by Basecamp. An appetite is a time budget. Instead of estimating how long something will take, teams define how much time they are willing to spend. Estimates start with a design and end with a timeline. However, appetites start with a timeline and end with a design. There’s a subtle but powerful shift when teams move from "How long will this take?" to "What can we achieve in this time?" This framing encourages teams to design solutions that fit within the time constraints.
Setting the appetite is also called “fixed time, variable scope.” The fixed time box forces the team to prioritize what is critical and make the appropriate tradeoffs. If something doesn’t fit the timeline, they don’t prolong the work, they rethink the scope. There is still some margin of error with this approach. Sometimes, teams still need extra time to get everything done. However, they will likely need less additional time than the traditional approach because their focus is delivering a finished product, not sticking to the initial scope. A finished product is usable and useful to the customer, not necessarily “perfect.”
An appetite is like a budget. Not "we think it'll take 4 weeks" but "we're only giving it 4 weeks"… Then the team tasked with the work has to get creative and figure out the 4-week version of that feature. There is no 6, 8, 10, or 12-week version when the appetite is 4 weeks.
— Jason Fried, CEO of 37Signals
Example of Setting The Appetite
Imagine a team building a dashboard for their app. If their stakeholders want a finished dashboard in 2 weeks, then that’s the appetite. They ask “What type of dashboard could we build in 2 weeks?” This forces them to be deliberate about scope. They focus on the version of the dashboard they can finish within the timeline, instead of predicting how long an “ideal” dashboard would take. If a week into the work they realize they this version won’t be finished in time, they reduce the scope by leaving out non-critical elements. Without the pressure of the fixed scope, they can make these trade-offs. If the scope wasn’t variable, they would have to include the additional elements, which would mean working past the deadline.
How Setting The Appetite Helps Teams
Every feature shipped creates additional value and new insights. Shipping a rough but usable version gives users immediate value. As they interact with the feature, teams get feedback and insight into what is and is not resonating. This helps them figure out what additional improvements and fixes are actually needed. A product that solves a real problem right now, even clumsily, is always better. This also creates momentum. The more “reps” a team has building and releasing completed features, the better they get at consistently delivering.
Perfect is a moving target but done is a decision. Teams must remember that “Good” is relative. They can always make something better. However, they need to consider what “good” looks like in the context of the time and effort they are willing to invest right now. Chasing perfection just stalls real progress, delays feedback, increases rework, and erodes morale. The marginal benefit of building a “perfect” version rarely justifies the delay. It’s more productive better to ship something now and improve it later, instead of waiting until you have built something ideal.
Conclusion
Focus on getting more things done, not getting achieving “perfection.”
Every day, there are things we have to do, and we need estimates to plan, manage, and spend our time effectively. Despite our best efforts to bend time to our will, our ambitious goals often collide with tight deadlines. By prioritizing completion, product teams use time more effectively. They align on outcomes rather than perfect outputs. This mindset accelerates how fast they can deliver value, gain insight, and make improvements, making them more responsive and resilient over time. True productivity requires moving away from trying to get everything done to getting the right things done. We can only achieve real progress by balancing what we want to do and how long we have.