Due dates for projects can be a moving target - especially bigger projects that are farther out. How do you think about communicating what's on the roadmap while always managing expectations with sales/support about when they'll actually ship?

Here’s how I keep it real without killing momentum: Timeframes instead of timestamps: I anchor features to quarters, not dates. It gives just enough clarity without setting false precision, because nobody wants to re-announce a feature every time a sprint slips. Be formal with sales: We have a specific deliverable called "sales enablement" that lays out how sales and support should discuss a feature with customers. We have to be this formal about it because things get too confusing any other way ...Read More

Balancing transparency about product roadmaps with the reality of shifting timelines can be extremely challenging. No one wants to hear that the feature they are eagerly anticipating has been delayed. That being said, transparency is king here, even when you are telling someone something they don’t want to hear. To start off with, depending on who I am communicating to (like Sales or customers), I try to use a tiered confidence system rather than specific dates for anything beyond the current qu ...Read More

Be straight up with other teams, like sales and support, from the get-go. Instead of hard dates, talk about the overall vision of where the product is heading and the strategy or the general plan to get there with intermediate milestones. Think of these milestones as checkpoints; you can give rough estimates for when you expect to hit them, but make it clear these aren't set in stone. The most important thing is to keep the communication flowing. As you learn more and things shift (which they al ...Read More

We use Agile sprints to manage big projects and track deadlines for each sprint to ensure on time delivery. 3 reasons in my opinion that breaks the deadline timeframe delivery Poor Planning - Having an unrealistic plan is sure shot way to failure. Make sure you always plan effectively, and if you don’t feel you’re being given the time or necessary level of detail to do so, raise HANDS. Poor Estimation - Breaking down the requirements into smaller pieces of tasks and building features to achieve ...Read More

Always put a buffer on what things will ship Be ruthless in regards to prioritization. Ship features/products that provide enough value to customers where they’ll try it, use it, and continue to use it, and to where the line of conversation/feedback is open between you and them (even if it’s littered with bugs and/or missing functionality). Feedback/validation is paramount, you should be ruthless in fixing those bugs and building the missing functionality, as a fast-follow. Be nebulous with time ...Read More