Skip to content
Delivery Management

Why Target Dates are your Friend

What are “target dates”  in Delivery Management?

Target dates answer the question: “So when do we think this [feature or product] will be shipped?” They refer to the estimated delivery timeline for a project, taking into account various factors such as the project’s scope (including complexity), availability of engineers, and business priorities. These dates help in planning and tracking the project’s progress, ensuring timely and efficient delivery.

At a high level, the organizational dynamics around target dates sometimes look like this: 

  1. Business leadership asks team leads (Product Manager, Engineering Manager or Tech Lead) when something will be delivered. 
  2. Team leads ask the team (ICs) when they think something will be delivered. 
  3. The team pushes back on committing to a delivery date because “there are too many unknowns” and they don’t want a date they’re not confident in held against them. 

Challenges with Target Setting (& why they get a bad rap from teams)

As many of us have experienced, obtaining target dates comes with challenges. When priorities are unclear, whether across multiple deliverables or within the scope of a deliverable, determining when to slate in new work is difficult.

Moreover, when priorities are unclear, or tradeoffs are not acknowledged, teams can end up over-committing, leading to missed deadlines and unmet expectations. Failing to recognize the active trade-offs that are being made to achieve an accelerated target date can result in poor expectation-setting, causing teams to feel the weight of unfair expectations and undermining leadership’s confidence in the project’s success. Even if teams haven’t experienced these challenges at your organization, there’s a pretty good chance they’ve experienced them elsewhere. 

As a result,  teams who don’t know the intention behind target dates tend to assume they will be used against them in performance evaluations if they fail to deliver when they said they would. 

If teams don’t know why dates are being asked of them, don’t have access to planning tools or business plans where these dates are shared or referenced, or don’t know the implications of what will happen if they don’t meet the dates they gave… it’s safer for them to not give one at all. 

How to make the Target Setting Process Better (& why we should set them)

As a Product Manager, I’ve fallen prey to these challenges. I’ve accepted working without target dates for what I thought was the good of the team. The result, however, is always the same: expectations from sales, marketing, and leadership are wildly different from reality, communication breaks down, business leaders get angry, impatient when something isn’t being delivered according to their launch expectations, or caught off guard and don’t know the ramifications for customers when something ships faster than they expected. And everyone is left picking up the pieces. I’ve come to realize that target dates can and should actually be used  as a helpful tool for prioritization and team empowerment. 


Without target dates, priorities are unclear. If nothing has a target, then there are no priorities. Without priority, trying to develop everything everywhere all at once can lead to unnecessary chaos due to a lack of clarity, and eventual burnout due to context switching and teams second guessing whether they are working on or investing the right amount of time on the right things. 

It’s not just that target dates give us clarity, but the practice of determining target dates does too. When I ask the team how long something may take to deliver, this is a good test for us to evaluate the investments we’re making to deliver customer value. 

If, in the beginning of a project, the team predicts a timeline that’s longer than anticipated, this is a great chance to dive in and ask questions. Based on responses, we may determine that:

  • There’s scope we can cut (we’re less confident in the value than we thought) 
  • There’s uncertainty we can address (unanswered questions around scope or technical approach are leading to inflated timelines) 

Asking the question “when do we think we can deliver this?” can lead to some productive next steps in defining and refining the deliverable’s scope. 

Near the middle or end of a project, if we’ve set a target and we’re approaching it, it’s also a great check-in point to determine if we really need the remaining scope, or if we can release what we have now in order to accelerate learning from customers and save features for a later iteration. If every piece of the work is truly foundational, then we reassess whether to move our targets if we’re able. 

At a higher level, setting target dates also helps us communicate upwards to stakeholders more effectively. Stakeholders need to understand the “what” and the “why” we’re building things, but they also need the “when.” It helps them give appropriate feedback and make business decisions accordingly. Rather than receiving a firehose of feedback about everything all at once, communicating what the team is focusing on now and next provides more focus and timely feedback. 


So how can we continue to encourage teams to set target dates in a productive way? How do we make sure target dates are used for us rather than against us?

First off, given that target setting can come with some emotional baggage, we need to create a safe environment for target setting. One way to go about creating a safe environment is to make target setting a collective responsibility of the team. If we’re wrong, we’re wrong. There’s no throwing under the bus the one brave soul who coughed up a target date in a meeting. Collective ownership of the target setting process provides a safety net and empathy to understand that everyone is always operating to the best of their ability with the context and knowledge they have at a given moment in time. 

Another way is to remind ourselves that targets are the team’s goals, not deadlines. If we don’t hit our goals, let’s retrospect together and understand why so that we can improve our estimates in the future. We can’t improve what we don’t measure. We should use target setting as a mechanism to encourage failing fast and learning from it. 

Lastly, we can structure work into shorter increments so that it’s easier to set targets. The less defined work is, the more unknown unknowns, and the more difficult it is to determine timelines. Scope of work should be clear. Teams and stakeholders alike will better be able to predict delivery if Epics and Initiatives represent smaller periods of time. Breaking down the work so that teams can set targets at smaller timescales introduces more milestones teams can push towards to celebrate progress along the way. It also allows teams to feel the progress they’re making against their work. Teams may find it hard to celebrate making 2% progress week over week, but completing 20% of a deliverable’s scope feels like something much more worthy of celebrating. 

Once we’re feeling good about the targets we’ve set, then gut check these with stakeholders to confirm whether this matches the level of investment anticipated for the value the team is looking to create. 

Start setting healthier expectations today

So how can we start setting targets with our teams if you don’t already?

At your next team planning meeting, identify the deliverables your team is actively working on. Pull them up on the screen and ask the team “When might we ship this deliverable?” If it’s straight forward, enter the date in the “Due Date” field on the Epic (or better yet the “Target Date” field in Jellyfish, which is linked to due date). If the team can’t confidently set a target date on the deliverable, find out why. Is scope unclear? Are priorities unclear? Would the work benefit from being broken down further?

At the next planning meeting, check in on those target dates. Are they still realistic? Why or why not? What have we learned since our last planning meeting that’s made us change our minds? Have new complexities emerged?

If we’re not tracking towards our initial targets, figure out why, then figure out what you can do. Should you cut scope so that the time invested matches our initial intentions? Or is it worth delaying the release? 

Repeat this process regularly, proactively communicating decisions to stakeholders so that everyone can remain aligned and in sync. Happy target date setting!