🤔 Question to product managers: what would you use a timeline for? ⏰

[#1]

Hi everyone! 

We talk to product managers using Jira Product Discovery all the time, and receive feedback constantly about the product, it's awesome and we love it. It's a huge source of inspiration for our roadmap. Today, as @Hanna as posted in this community post, we've started to unpack one of these frequent requests: a "timeline view".

Now based on the early feedback on this post I'm going to do something that any good product manager probably shouldn't do 😬 I'm going to ask: "I've got a hammer, who has nails?" 😂

Today in Jira Product Discovery we support 3 types of views: list, board, matrix. If we added a 4th one, timeline: 

• Would it help you?
• If so, how? What would you use it for, with whom, and for what purpose?
• If not, how does seeing this in the app make you feel? 

Thank you so much for your response and your continued engagement in this community forum! We're building a better product because of it. 

Cheers,

Tanguy
(if we haven't met them, hi! 👋 I'm the head of product on Jira Product Discovery)

[Atul]

Not sure, but I don't have a timeline view?!

[Dave Perini]

My stakeholders would love to see ideas visualized on a timeline view to better understand when they might be delivered.  It's easier to read than a board view to get a sense of what ideas are being delivered in parallel vs. sequentially.

For me personally, sharing a timeline can sometimes create more "busy work" because it often gets misinterpreted as being set in stone. Any ideas I add to a timeline further than 6-8 weeks are very likely to change by the time we get there, but a 6-week or shorter timeline feels weak.

It would become more worthwhile for me to create/maintain a timeline if it helped me set better expectations with my stakeholders; for example, if the view visually represented the decrease in confidence/accuracy the further out you go.  For example, a time scale that increases exponentially or gets more vague.

I do like how a timeline view would do a much better job of visualizing work being done in parallel vs. sequenced. Also, I would prefer to see a delivery timeline in Product Discovery vs. traditional Jira projects because it would allow me to see upcoming ideas that have not yet been shaped out in tandem with work in progress.

[Bruno S_ Rosa]

I Think is a great add to the Product View.

It makes it easier to define expected advances to product designers, which is the maximum deadline for the handoff to take place.

[Jillian Coutu]

I'd use a timeline for a few reasons:

• to show how long something is taking.
  • Sometimes huge technical lifts take a long time, but don't really get great fanfare.
  • Opportunity to nudge people to break something down further. (aka -- to big..)
• to visualize the impact of dependencies.
  • if other work needs to finish 1st, it's easier to piece out how delayed the other work will be and / or when it will be delayed. you can also possibly help break that into less risky items.
• to look ahead to planned work to help remove impediments and help it start as planned

[Chris Timms]

A timeline tool would be very useful at adding context in replanning or re-prioritisation. i.e., "we want to bring something in, what do we have to move out, and what else will it affect?" the current views do not provide that clarity for that.

Do I think my team would use it often? No, because as @Dave Perini mentioned the time added to managing the stakeholders that would assume locked in dates would probably add more overhead than is worth it to expose. Currently we communicate in Quarters, which seems to strike a balance between coordinating with Ops/Sales/Support and allowing us flexibility with schdeuling.

-C

[Dan Marshall]

It would be helpful to be able to embed the timeline view in Confluence. That way, as Product works through the Ideas, the view would update automatically. Currently we are using Roadmap Planner on Confluence and have to keep it manually aligned/reconciled with the Ideas progress. We find that Ideas for us will often map to more than one Project for delivery, making the other Confluence Roadmap options too constrained for our use case.

[Diluk De Silva]

Timeline would be very useful - for now I've had to workaround using custom fields to something close to this which is very clunky. But having this natively would be super useful and to be able to share it with other business units 

[Andrej Freeze _ greenique]

I'm not too certain that a timeline would be used within my context, until a product is actually being developed / delivered. A use case of how product discovery is intended to be used in different parts of the product lifecycle and how it changes from one phase to another will be very helpful for me.

Maybe I simply havent't read the appropriate posts for this yet :) Will make sure to look around. But for any stages that do not involve developers yet, I don't actually need a timeline. 

[Michael Buechele]

Within our context, the timeline view might rather cause more confusion than clarity:

• The timeline of the ideas is directly influenced by the delivery issues (the issues linked in the delivery tab). Unfortunately, not the other way round ;-)
• If more delivering issues are linked to an idea, the timeline will get outdated very quickly.
• We already use the development roadmap that shows all the delivering epics in a timeline that is related to sprints and releases. This is maintained by the dev team and therefore very accurate.

Rather than having to define a new timeline from scratch, I would prefer to see more information about the delivering issues and their expected delivery time (sprint, release). Maybe a timeline could even be created automatically.

Apart from that feedback, I would still love to experiment with the timeline view and we might probably still find a valid use case ;-)

[Chris Timms]

On more reflection, I'd probably want to know how the JPD dates would interact with dates from Epics? As others have said, engineering drives the actual delivery of tasks. What if you don't use dates, only story points for work measure in JS? How do you keep any of the delivery data in sync? Would a product version of the same data constantly be in lag? Or if there was sync and the engineers change dates which affect the rest of your plan, how suitable is it then as a tool to visualise time if you are always sanitising it?

A lot of what I like about JPD is that it is self-service and enables any stakeholder to come in, review the views and get in context updates. A timeline view is something that would probably be hidden and published.

- C

[sharon.prajzner]

To me, this looks similar to the roadmaps function.  I don't like that function because of how difficult it is to put a card where I want it, how it performs/is viewed, and it's measurement units, not because of how it looks. 

We want to measure time in release cycles (3 weeks), and we want to illustrate a Quarter it will start and End, with project cards that overlap quarters and string to tie as dependencies.

From what I see here, that will not be supported, and it will not be very helpful. 

[Minesh Patel]

I like the view, but I for one would never let anyone see a road map with a timeline.  It’s always bit me later. 

if they want to see how we doing on the now items then the roadmaps and epics that are on the dev board shows the progress and items that are next should have epics written up and should reflect there.

Just saw this and it resonated with this discussion to some extent 

https://twitter.com/aakashg0/status/1547592067555045378?s=21&t=oz0ruzr5bh4ozZna_8uagA

[Pieter Bezuijen]

Just commented on Hanna's post :) I think it would be a great addition! For me personally, it would have the most value when we could also assign a timeline to clusters of ideas. See also my post for some explanation on that: https://community.atlassian.com/t5/Jira-Product-Discovery/Timeline-prototypes-we-need-your-feedback/td-p/2077454#U2080154

[Jonathan Hau]

To me, the timeline view would cause a bit of confusion. The main reason is because we currently have setup our board view by quarters, so it is essentially a quarterly forward looking timeline (4-6 quarters into the future).

I would support offering this feature, but only if I had the ability (as an administrator) to hide/disable it. Would want to test it and see how we could leverage it before opening it up to all of my team to use it.

[Ally Akbarzadeh]

A timeline view is a critical feature for us, and a key reason we would still drop JPD in favour for Aha, Roadmunk, etc.

Key use cases:

• generating roadmaps for internal stakeholders (sales, board, etc) on our plans
• generating different external roadmaps for different customer segments
• communicating broad roadmap priorities to non product teams within the organisation

Key requirements:

• make it easy / simple to create great looking "boardroom ready" roadmaps. Roadmunk (in particular) has this as a core strength. (Atlassian products, historically, have a bias towards overly complex, delivery roadmaps, not high level, good looking summary roadmaps).
• allow us to configure time granularity (months, quarters, half yearly) and swimlanes
• solid export to PDF / PNG and embedding / sharing options

[Alex Long]

This view type would be so useful +1 from me!

[Jake Holman]

Coming in way late on this post, but this has just come up as we mature our use of JPD with a growing startup. I don't know if timelines - as they have been presented - are really the right solution to problem we're facing. So figured I would share this and hope it's helpful?

The problem

We'd like to introduce more medium-term planning with our client, and get them used to the idea that planning should be more than just planning what engineering are delivering!

I'll use quarterly planning as the example, since I imagine it's the most common cadence of this type of planning. For simplicity, let's imagine we're planning the next couple of quarters. We don't want to only plan what will be "done", but what we are doing within those quarters and to which high level milestone we want/are likely to achieve.

Timelines as a solution?

A timeline might be helpful in facilitating medium/high-level planning with cross-functional teams - this might be different per organisation but for us that would be product, design, development, and delivery.

If our milestones are Problem Discovery, Solution Discovery, Development, User Testing, Release then we're going to want to plan out where within each quarter we expect each idea we have prioritised to land. We're going to want to visualise that (bad wireframe follows):

This allows us to better plan around capacity, resourcing, dependencies, etc. by applying the context of what we'll be doing within a given quarter.

So are timelines the solution? I don't know. I could actually achieve the above in the current "board" view if I were able to have a "Milestone" field in different states depending on the "Quarter" field - but I can't currently.

[Lars Morten Nygaard]

Yes, it would be a great addition, if not an essential view in order to keep all Product Management tasks in one tool.

Primary target audience for the timeline view would probably be the engineering department, in order support their resource planning. Secondly it would be Sales/Marketing, in order to know when to start preparing the market for new and exiting additions to our offering.

Seeing the prototype makes me feel great, a perfect first take on this feature.

[Matthew Allen]

Would be great to see this, veen if the present an aspiration view of products coming up in a quarter and present an order of priority across teams (we currently do this in Excel today) - Stakeholders like it.

So as long as we have a timeline can be date driven, or quarter driven (or others as suggested), my only would be, when is it coming :) ?