The more often people ask “When?”, the less likely you are to be working in an Agile organisation.
If we’re building a software product using an agile model, then every day we’ll have the latest version ready, with all the most important features complete and the team working on the next most important. The choice is always with the organisation, they can launch what they have, or wait for another iteration.
If the conversation is always “When will it be finished?”, then you are thinking about projects, about things that don’t evolve with feedback, and most of all, something that has a fixed view of what’s considered good.
It’s much better to get that initial launch out early, and start to update quickly based on the actual activity of real users. That validates the assumption you made early on, or disproves them really quickly. It means that you waste the smallest amount of effort as you correct quickly.
I usually find that Marketing are a major asker of “When?”, there’s often a longer lead time with some channels, and they want to plan in a fixed way to account for these timelines. They aren’t able to move away from these processes, so you have to find some ways to mitigate the questioning.
There’s two techniques that I’ve found to be helpful (and that also work with anyone asking When?).
First up, move away from specific features. Switch up the conversation, and show what problems are being solved for your users. This lets you focus more on the overall value of the package, and sell the solution rather than any particulars that might not yet be complete.
Second, if features are important, take the conversation back to what’s already been done. Show off everything that’s available today. If you are experimenting with features before they reach prime-time, then you can use some that are nearly ready to go. Give the Marketing team early access, particularly to winning experiments that you are working to turn into full features. With the range of access, they’ll be able to slot features into various materials depending on their own lead time needs.
Do these, and you’ll start to wind down the “When?”, and get back into the agile swing of things.