Hi Ross, it’s a fair question and definitely a common one! Keep in mind that we’re not suggestion you don’t have dates on anything, just not on your roadmap. You should also have a release plan, which outlines the dates, dependencies, resources, etc. for the upcoming releases. It’s like a mini project plan for what’s immediately in the pipeline.

Now how you (or your development team) manage this will depend on your chosen development style. If you’re following agile methodologies, you might have a backlog of stories that are approved, estimated, and ready to be picked up for development in the next 2-3 sprints. If each sprint is 2 weeks and is followed by a release, then you would have a working plan for what’s going to be released over the next 4-6 weeks. If your team is using a Kanban board with releases every few days, you might have a release plan of just a couple weeks. If waterfall is more of your thing, you might be mid-project and have a plan to release in a couple months (though this latter one gets harder and harder to manage, especially if you’re not putting in the upfront time to do the project management work of estimating, buffering, and planning in detail to get it out…. it’s the reason so many companies are moving to more agile approaches!)

So for the very short term, you should have a release plan of sorts (it could be as simple as a ‘To Release’ pile that gets stacked up in your Trello board, or something more structured in JIRA). The release plan is essential as you still need your marketing team to be prepped for a launch, your support team to be trained on how to support, your sales team ready to start selling, etc. However, they usually don’t need to see _beyond_ those initial few weeks where you can provide (at least some!) certainty on dates.

Beyond the release plan, and in a different document altogether, is your roadmap. The Current term column of your roadmap will show broadly what’s in development and coming up to be released (we even pull through the exact status of each ticket so you can see the progress in real-time). But the Current column, which might be anywhere from 2-4 months of overview, will include a broader picture of what’s coming up: It doesn’t just show what’s in development at that moment, but also looks at everything that’s being planned, analysed, designed, and prepped for development too.

So don’t do away with dates altogether – these are essential to knowing when something’s going to go live. But until it’s really gone into development, you won’t have a clear picture of when it’ll come out, so when it comes to roadmap, give yourself that flexibility in your product so you can react to changes in the market, competition, or based on how customers reacted to what you just made live in your last release! It means that the conversations around the release plan are tactical (how do we get this out, what can we do to unblock this obstacle?), while conversations around the roadmap are strategic (are these initiatives going to move the needle, are they in the right order based on what we’ve seen in the last 6 months?)

Two documents, with two different purposes.

You’ve got the right tactic in place here, I would think. If you are being forced on a timed delivery, you need to be flexible with the level of detail that’s going into each initiative. Over the course of your career, you might actually be seeing the same trend we are, where companies are realising that they need to move faster and therefore have to embrace a more agile approach. Enter ‘Lean Enterprise’ or ‘Lean Startup’ methodologies, which aim to give companies a framework for doing so.

And yes, don’t be afraid to have multiple versions of your roadmap! Different stakeholders have different needs and should be communicated to in a different way. Your internal roadmap (for your inner circle, like the product team, devs, ops, support, etc) might have a lot more detail and show internal-only initiatives, whereas the roadmap you share with execs or customers will be higher-level in detail and will likely hide a bunch of initiatives that are internal-only.

This is always a tricky one, but it comes down to a couple key facts: If you’re given a fixed date to release something, you either have to be flexible on scope (and potentially deliver a lighter version of the new ‘gifting’ feature), or start planning and preparing for the launch well in advance, with plenty of buffer. If the project launch is mission critical, then your company will have to invest more in the resources and time to plan the delivery…. this, as you probably can imagine, gets costly, and slows down a company enourmously (not least because of all of the excess buffer that’s having to be added in, just to be sure you start on time to finish by Launch Day). However, a company that’s spending all of their time trying to make sure something critical and complex is delivered on time is almost certainly not moving as fast and solving problems through quick iterations in the same way a startup would. This is how big companies get disrupted 😉

If you do neither of these (being flexible on scope but not putting in the required planning), then the other side of the ‘Iron Triangle’ is at risk: Quality. When Launch Day arrives, your rushed project is a mishmash of half-tested features which just might fall apart when pushed live.

Now in your case, it’s likely that this ‘gifting’ feature isn’t as mission critical to the company so as to require an army of planners, or isn’t so fixed in scope due to the complexity of the problem your solving so as to prevent you from creating a simplified version that could still be released in time if the delivery falls behind schedule.

The reality is that estimating and planning for software is inherently very difficult, as the end product is usually loosely defined and the process of coding, designing and launching a product (or even just a feature) is not an exact science. The unknowns in the process result in uncertainty in timings, and so your best defense against this, if you want to remain agile, is to be flexible on scope and aim to deliver in small, usable parts rather than big-bang launches.