Delivery date is another source of conflict between business and tech

In the same that discovery seems to be a source of conflict between business people and product development teams, as I explained in the article Why business people hate discovery, the term delivery date also seems to generate some conflicts. On one side, business people are constantly asking for a delivery date for a product or a feature. On the other side, the product development team has many difficulties setting a delivery date due to many reasons. Let’s better understand both sides:

Why we need a delivery date

There are a number of reasons that makes having a defined delivery date important:

• Some events don’t change and if the product or feature we are working on is supposed to be used prior to this event, it is very important it is up and running by then. For instance, if we are working on some new features that will improve user e-commerce shopping experience, it is important that it is available a few weeks prior to the Christmas shopping season and, ideally, prior to the Black Friday shopping season.
• There are some regulatory dates that also don’t change. Some examples are IRS tax filing deadline, new invoice layout determined by the government, etc.
• Company events. For instance, suppose your company has an annual conference for its customers every October which is a perfect date for announcing new releases and new features. Ideally, the product development team should work to deliver the product or feature prior to this date.
• Marketing campaigns also have set dates to start. If this is a campaign to announce a product or a feature, we definitely need this product or feature ready prior to the campaign launch date.

Certainly, there are more reasons why a product or a feature needs to be delivered by a certain date. In all of these cases above it is clear that there are fixed dates that can not be changed and we need to figure out a way to deliver something prior to the fixed date.

Why it is so difficult to set a delivery date

In the same way that there are a number of reasons that makes having a defined delivery date important, there are also many reasons why it’s difficult to set a delivery date:

• The product development team is new or has new members so the product development capacity is still unclear. The team needs to work together for some time in order to better understand its pace. It’s the Tuckman’s stages of team evolution that I mentioned in the article on team structure. And there can be changes in the team also, like people leaving to join other teams or people changing functions. This can also impact the ability to set a delivery date, since the team does not know its product development capacity, and this capacity will change over time as people on the team get to know each other and how to work together.
• The bigger the product or feature to be delivered, the more difficult it is to estimate a delivery date. The team may be able to break down the feature or product into many small chunks that can be easier to estimate a delivery date, which could be a few days or weeks. The smaller the thing that needs to be developed, the easier it is to be more accurate in estimating its delivery date. The issue here is that by breaking down the product or feature into smaller chunks we can better predict what’s closer to be delivered, but things that are more distant are harder to predict a delivery date.
• Changes in scope are another source of delay and uncertainty on delivery dates. If the scope is increased or, even worse, unrelated work gets higher priority, the original delivery will need to be changed.
• Technical debt can be another source of delays, especially if it's unknown or undocumented technical debt. When we encounter a technical debt that prevents us to deliver a feature or a product, we may need to spend extra time to fix that specific technical debt, which will certainly generate delays in the delivery date.

The examples above make it clear that there are a number of factors that can negatively impact the delivery date of a product or feature. Again, this is not an exhaustive list. I’m pretty sure you can list more reasons that impact our capacity to set delivery dates.

There’s a very good article from the team at Apptio with a diagram that maps many things that impact positively (green, like focused work), negatively (red, like multi-tasking), or positively to some extent (yellow, like technical debt).

Product development speed is a complex matter, that’s why it’s so difficult to estimate delivery dates.

So, what should we do?

On one side, business people are constantly asking for a delivery date for a product or a feature and there are very good reasons to need a delivery date defined. On the other side, product development is a very complex matter and the team has many reasons why setting a delivery date is so difficult. So what should we do?

The first step is to understand that business people and the product development teams are parts of the same team and, as such, must have the same objectives, achieving the company goals while solving a problem for its users. For this reason, they should work together to achieve these objectives.

The second step is to understand that behind every product or feature there’s a result expectation. So, when we discuss a product or feature delivery date, we are actually thinking about when we will benefit from the expected results that this product or feature is set to generate.

The thing is that more often than not we end up talking so much about the new product or feature and its delivery date that the expected result becomes less discussed and, consequently, forgotten.

I already mentioned that products and features are means to an end and not the final objective. They are vehicles to achieve the goal of delivering value, and results, for customers and for the company.

So, instead of discussing the product and feature delivery dates, we should be discussing results delivery dates and how we can get to these results by this date. Sometimes there’s a simpler product or feature to be built that will enable us to achieve that result faster. Sometimes there’s no need to build a product or feature, but a change in a process can yield the expected results.

Looking through the results delivery date perspective, there are two possible situations:

1) if there is any fixed date (Christmas, Black Friday, company event, regulatory date, etc.), the date is already given. And the expected result too. Christmas, Black Friday the expected result is more sales. Company event, normally the expected result is engagement, cross-sell and/or upsell. regulatory date, the expected result is compliance. With this information in hand, we should ask ourselves what can we deliver before the given date to achieve the expected result?

2) if it’s something new, with no specific date, again the conversation revolves around the expected result. What result is expected of this something new? Is there any expected date for us to obtain this expected result? Or the sooner the better? With the answers to these questions above in hand, we should ask ourselves what can we do to achieve this result in this period?

Summing up

• The delivery date is another source of conflict between business people and the product development team. On one side, business people are constantly asking for a delivery date for a product or a feature and there are very good reasons to need a delivery date defined. On the other side, product development is a very complex matter and the team has many reasons why setting a delivery date is so difficult.
• To address this conflict, the first step is to understand that business people and the product development team are parts of the same team and, as such, must have the same objectives, achieving the company goals while solving a problem for its users. For this reason, they should work together to achieve these objectives.
• The second step is to understand that behind every product or feature there’s a result expectation. So, when we discuss a product or feature delivery date, we are actually thinking about when we will benefit from the expected results that this product or feature is set to generate.

Product development advisor

I’ve been helping several product leaders (CPOs, heads of product, CTOs, CEOs, and tech founders) extract more value and results from their digital products. Check here how I can help you and your company.

Digital Product Management Books

Do you work with digital products? Do you want to know more about how to manage a digital product to increase its chances of success, solve its user’s problems and achieve the company objectives? Check out my Digital Product Management bundle with my 3 books where I share what I learned during my 30+ years of experience in creating and managing digital products:

• Startup Guide: How startups and established companies can create profitable digital products
• Product Management: How to increase the chances of success of your digital product
• Leading Product Development: The art and science of managing product teams

You can also acquire the books individually, by clicking on their titles above.