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:
There are a number of reasons that makes having a defined delivery date important:
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.
The same way as 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 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.
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, the 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 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 objetctives.
The second step is to understand that behind every product or feature there’s a result expectation. So, when we discuss about 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 product 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 about product and feature delivery dates, we should be discussing about 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?
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.
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:
You can also acquire the books individually, by clicking on their titles above.