Timeline prototypes - we need your feedback 💬

[Hanna]

Hi everyone 👋🏻

We hear from you how important it is to visualize product plans in a time-based view, which you can communicate to your stakeholders or teams.

We have 2 early ideas that we want to get your feedback on. 

We would appreciate it if you could spend ~30 min testing 2 Figma prototypes with simple tasks to complete and leave the feedback and suggestions under this post or reach me directly at hsazonava@atlassian.com.

Option 1 
https://www.figma.com/proto/Fksheulxlc3sQFumXrFE9M/Timeline-testing?page-id=31%3A8403&node-id=31%3A16636&viewport=306%2C322%2C0.05&scaling=min-zoom&starting-point-node-id=31%3A16636


Option 2
https://www.figma.com/proto/Fksheulxlc3sQFumXrFE9M/Timeline-testing?page-id=4%3A14274&node-id=33%3A23859&viewport=2290%2C202%2C0.19&scaling=min-zoom&starting-point-node-id=33%3A23859


⏰ No time to click prototypes? No worries, here are 2 screens representing the ideas.

Option 1 



 Option 2 



The feedback I'm looking for:

• When doing tasks what was unclear in the flow and wouldn't work for you using it in your work? What worked and you'd be using it?
• Which option (option 1 or 2, or specific parts of both options) resonates more with you? Why?
• What is crucial for you in a such view (which might not be presented in the prototypes)? Why?
• Any other feedback and suggestions that you might have 🙂
   

The prototype has the instructions to follow, and you can always ask questions here or directly.


Thanks in advance for your participation!

[LAL]

I have seen no use for roadmaps/timelines and been wondering why Atlassian is putting so much effort in them? All our project managers ask "Does it have excel functionality?" and thats the end of discussion.

[Hanna]

Hi @LAL 

Thanks for sharing this! Could you expand on what "excel functionality" they value? 

[LAL]

@Hanna Its the abdundance of controls/options that excel offers in addition to look and feel theyve grown accustomed to. Our roadmaps/timelines (Release schedules) are usually part of other documentation and since roadmaps/timelines on Atlassian products only serve one purpose (In addition to differing depending on Jira/Confluence and platform) these are seen as cumbersome with no additional benefits compared to tools like excel.

One concrete feature that our project managers insist on is watermarks/background images. Our roadmaps/documentation need sometimes to be plastered with our client's watermarks.

I tried suggesting just exporting roadmaps to images that they could add to any document they desire and edit afterwards but this was rejected outright as too difficult.

Id like them to start using roadmaps/timelines found on any Atlassian product (We use BitBucket/Jira/Confluence), but i havent figured out any selling point for these. We cannot allow our clients to access our systems and all delivered documentation needs 3 signatures (Release schedules included) which means basic image export is not sufficient on its own.

[Hanna]

Thanks for this context!

We also plan to allow for:

• Sharing views with non-Jira users (internal to the company, external), hopefully, it will help you with sharing it with clients without them accessing the system. 
  
  

The case with signatures is a unique one. In your company are Project Managers responsible for building roadmaps?

[LAL]

@Hanna Yes, project managers are the ones working with the client on roadmaps, timelines e.g. and the rest of us work on based what the PM and client have agreed to.

I know the signature is a unique case and i just mentioned it as a context. All documents related to SW development need to be signed and approved by QA (me), PM and designer (coder). This is due to EN standards we use.

Good to hear you're working on sharing functionality, maybe ease of sharing will finally convince them to drop excel.

[Oriol Fàbregas Pujol]

FYI - in my case, Figma links get stuck in the loading page (using Firefox)

[Hanna]

Hi @Oriol Fàbregas Pujol

Sorry to hear it doesn't load. I've checked Firefox and it's loading, but maybe something is on the Figma side.

Could you please try again and if it doesn't work then open the attached images? 

[Sophie Tessier]

For some projects, I need to plan by months (date), Q or by sprints. it's interesting to give flexibility on the timeframe. 

[Jeremy West]

Option 2 is probably my preferred, the ability to extend the idea time from the timeline view is much more intuitive and inline with competing product capabilities.

The only thing that would make this feature more valuable is a read-only publicly sharable view/link that can be distributed to interested stakeholders, customers etc. 

In saying that, I have no issue with the current roadmap presentation options and probably wouldn't use this view much, as above, a public roadmap is much higher on my list of features.

[Sophie Tessier]

I agree. Sharing option is a must 

[Tanguy Crusson]

Hi there, some clarification: we have 2 projects starting at the same time:

• Timeline view - which is one of our top requested features - 👉 that's where this post fits 👈
• Sharing views with non-Jira users (internal to the company, external) - don't worry we already know people want this, it's the top requested feature 🚀 It is going to take a while to solve though, as it's quite complex technically

In both projects we're starting with a spike to understand what is doable technically and also how we should design them. 

We'll start other threads to discuss the "sharing" project when we're ready to seek input from the community! 

[Nicolo]

So is the team rethinking the retirement of the public view and feedback? The one here.

[Tanguy Crusson]

@Nicolo Yes, we retired that implementation and have started another one. Initially it focuses on the internal use case (people from your company) and will eventually expand to people outside your company. 

[Zaher Agha]

@Tanguy Crusson Hello,

Circling back to the public roadmap feature, do you have an ETA ? and would it have the capacity for clients to comment / vote on features they like ?

[Tanguy Crusson]

Hi @Zaher Agha we don't comment on when things will ship, but this one is a project that is happening right now.

It's not so much "public roadmap" but the ability to share a view with people that may not have access to your Jira (and they can comment, vote if you have a voting field on the view, things like that).

Expect more details as we get closer to shipping something.

[David]

Is the idea of a timeline specific to the product discovery? What I mean is, when a timeline is set, does it represent the time spent during discovery, or is it meant to reflect the time up to delivery? Part of the reason I ask is because I'm not sure if there is a discovery roadmap/timeline that is separate from our development roadmap/timeline. These change so often for us that trying to keep them up to date is a chore so I wouldn't want to have to manage multiple timeline/roadmaps or create confusion about what each represents.

Based on what I'm seeing right now, I'm not sure I would use these feature. My struggles with product discovery are in organizing, reviewing and prioritizing many ideas. At this stage, I don't have a concept of a timeframe. I'm simply trying to go through the ideas, weed out the bad, add more information to the good ones in hopes of figuring out which ideas we should move forward with.

[Andrej Freeze _ greenique]

I can absolutely relate and agree to this. When it comes to ideas, I need a pool to collect them, which would be Jira Product Discovery. Finetuning that idea, getting some additional information and finding out "hey this is actually a product worth developing" is something i have never had to put on a timeline.

I'm afraid that the more features like this are coming, the more duplicates will be exist compared to other Jira Editions. E.g. Subtasks to track what's left to do in an idea, or to split responsibilities, iterations that they can be planned to for better timelines and timeboxes that they will be put into to plan ahead how we want to improve the idea.

This makes it very difficult for me to understand, why I should not simply use a Jira Software Project for Ideas and add calculated fields to it, that are displayed nicely.

[Dave Perini]

I like this set of visualization tools better than Jira's existing roadmap functionality, but agree that I wouldn't want two separate roadmaps within the same ecosystem.

It raises a good question about Product Discovery's market position: is it intended only to address capturing and evaluating ideas ahead of their development, or a product manager's toolkit throughout the product lifecycle?

I've been using it more as the latter, and use the Delivery links to monitor and report on the delivery progress of ideas well after they have been planned and passed to the engineering team for implementation.

[Hanna]

Hi David, 

Thank you for sharing your feedback! 
Jira Product Discovery wants to help PMs to communicate their plans with stakeholders and in the future do it externally, with customers or users, for example. Jira Software has many details that such a target audience doesn't want to interact with.

We know that it's a pain to maintain and keep it up-to-date  😔. If you could think of what can help you with that feel free to share your ideas with us.

These change so often for us that trying to keep them up to date is a chore so I wouldn't want to have to manage multiple timeline/roadmaps or create confusion about what each represents.

[David]

@Hanna A good many of the struggles we have is our own doing. I'm trying to get the rest of our team to see the value in Jira and how it can help, but we have to define our processes in order to do that and that can be challenging to get others on board.

In my ideal Jira world, The product discovery project would allow for direct input from our customer base. I want to expose the list of ideas so everyone can see them. Our biggest challenge is that each customer only sees what they submit, but not what all the other customers have submitted.

We struggle to get customers to realize that we have hundreds of requests and can't do them all. I would love to expose the list of ideas and allow for our customers to comment and vote on these ideas so they can have a voice in the priority of work we do.

Thanks for your help! 

[David Holman]

I'm with you on the collect and organize path. Jira already supports plenty of methods of planning objectives/features/initiatives. Product Discovery appeared to be something different: A way to assemble, structure, and report on feedback and ideas. With that as a unique view, we can associate the work items to these ideas.

Adding product feature planning and communication here will certainly diminish the value and usability of capturing ideas.

I was hoping this might stand in for Productboard's solution so I could do it all in one place. Unfortunately, it sounds like this is going the way of all Atlassian products: A little something for everyone but not great for anyone. No thanks.

Too bad. This solution was the first from Atlassian in a while to show some focus and promise 😞

[Paul Newell]

I think it would be helpful to have it more clearly defined in the original post what the AC differences where for these two prototypes, to me the feel really similar and I am not sure exactly what I am looking for.

A few notes:

• Dynamic groupings is a great idea, if/when this timeline view becomes sharable we would likely need to be able to preselect this so that external users see it in a certain way
• Agreed that dragging the Idea directly on the timeline is the better experience, but I always prefer having both options in cases where I want to be more exact I might prefer to manually enter the start end
• Customizing whether the timeline Y axis is quarter, year, month is tablestakes IMO

[Hanna]

Hi @Paul Newell

Thanks for this feedback and notes on the options! Indeed the options have a slight difference and a bit of clarification could help 🙂

The first option represents an approach with time units and date/month/quarter picker. Where it's possible to give an exact date when plans are defined and a bit more vague range like Q3, when things are not defined yet. 

The second option represents the idea of using a select/multi-select field to create any value that will represent a  "time" unit. It's up to you to decide if you build a timeline based on quarters or months or releases, but it requires a field with values.  

[Dave Perini]

I shared some thoughts on the purpose of a timeline view in Tanguy's thread, but here's my feedback on your prototypes! Thanks for sharing with us. :)

• I like how easy it is to add a timeline view from the sidebar, add ideas, and drag idea card edges to increase/decrease their length. I agree with Paul Newell's point that having both precise and loose controls to set length is valuable.
• It was easier for me to immediately understand prototype 1 because it defaulted to a common time scale that was easy to change (e.g. weeks vs. months vs. quarters).  I was initially confused in prototype 2 with choosing a field to base the timeline upon, but I did like the flexibility that provides once I understood the concept. Maybe you could prompt users to choose between time-based or custom field during creation?
• I like how easy it is to create groupings and can certainly see using them to represent different workstreams.

[Hanna]

Hi @Dave Perini

Thank you for sharing the feedback with us!

Did I get it right that you imagine these 2 options can live together in the product? Could you share when or why would you use the time-based and custom field option? 

Maybe you could prompt users to choose between time-based or custom field during creation?

[Dave Perini]

Yep! I think there are use cases for both options. For example, in the past I have created separate roadmap versions for different stakeholders:

• One that represents works in Quarters or Months for higher-level stakeholders
• One that represents work in Releases or Sprints for delivery teams

I'd prefer not to have to create custom fields to represent universal time concepts like Week, Month, or even Quarter (though some companies may differ on when quarters start/end).  But a custom field would be very helpful if I'm using a proprietary time range like Sprint or Release.

[Hanna]

Thanks @Dave Perini

It's very helpful for us!

[Jonathan Hau]

Perhaps it's because I've spent 50+ hours in a competitor tool called ProductBoard that I find the similarity to these prototypes oddly familiar and easy to use. 

• When doing tasks what was unclear in the flow and wouldn't work for you using it in your work? What worked and you'd be using it?

All of the tasks felt easy to use and familiar. I will likely use both options 1 and 2 for different purposes. I'd use "Group by Team" for example to let my own team within a domain (group of teams) see cross functional work in parallel across multiple quarters. While, using option 2 "Based on" for the purpose of doing more granular (segmented) work. 

• Which option (option 1 or 2, or specific parts of both options) resonates more with you? Why?

Given the nature that work efforts / initiatives at my company often span more than 1 quarter, Option 1 feels more valuable to me. The challenge with either of these views is what is represented by the bars? Does it represent when work begins? or when discovery / investigation begins? Does it represent when it's done / code complete / marketing has completed announcing it to the world? 

To me, these are always high-level estimations, which always mean there are caveats. 

• What is crucial for you in a such view (which might not be presented in the prototypes)? Why?

What is crucial is adding notes, asterisks, and/or other nuances (disclaimers, safe harbour act, etc). These visual roadmaps almost always means sales / customers will come back to us and say, "you committed to this, why isn't it delivered yet". So, we want to ensure we communicate that these are estimations that don't account for unpredictability in delivery.

• Any other feedback and suggestions that you might have

Context is crucial when viewing any roadmap like this. I find that even in small companies the person creating this view must explain everything upfront, otherwise stakeholders viewing a board like this doesn't understand what it's meant to represent. If there is a way to overlay a 5 second modal that is customizable by the editor of the board, it would help provide a viewer contextual information about what is being represented by a roadmap view.

Many of my colleagues will also ask, how is this any different from Jira Advanced Roadmaps (Plans), Miro Boards, or a spreadsheet? The difference is that this is a "Product-driven" view of a forecast into the future by quarters. This means, these are high-level estimates not meant to be commitments by engineering teams on delivery. 

[Hanna]

Hi @Jonathan Hau

Thank you for sharing! I followed up in the email. 

[Nate Dame]

Option 1 was slightly more clear - however, I like the "more composable" nature of option 2, where the timeline is dependent on a field options can create/edit (and fully control).

(Disclaimer: I only took a quick look :) )

[Pieter Bezuijen]

Hi @Hanna

Really nice that we can think along on this feature! 

Option 1 feels like a more intuitive approach for me personally. Currently I also use the 'Plans' feature within Jira to play around with timelines and roadmaps. And this feature feels like it's going the same directions. 

There is however an additional challenge for me personally. We use the product discovery to document lots of ideas, some quite big and others very small. Our list of ideas is already over growing over 100 ideas. As a product lead, I'm responsible on developing a logical roadmap out of the over 100 ideas for multiple platforms, where some ideas span across multiple pagetypes or even platforms and ideas can contribute to multiple goals. 

I'm looking for a way to more easily group multiple ideas into clusters where we can add a cluster to a timeline and break that down to see which ideas we can include in a given timeline.

I'd like to see a pagetype as a 'vertical column' in our online landscape and a 'theme' / 'topic' as a 'horizontal row'. Both would translate in clusters of ideas to pick up which I would like to group in some sort of roadmap or timeline. 

Does this make any sense in light of the discovery project type and forming timelines? Thanks!

[Oliver Murray]

1 - When doing tasks what was unclear in the flow and wouldn't work for you using it in your work? What worked and you'd be using it?

• I expected (and would prefer) a drag and drop function to resize on both. 
• it was unclear what data the "based on FY23" option would pull from. Sounds like I would have to set up values etc somewhere else and that could add more steps to the process or create unexpected upstream/downstream effects.

2 - Which option (option 1 or 2, or specific parts of both options) resonates more with you? Why?

• I didn't notice a huge difference but option 1 seemed somewhat more intuitive to me based on how I use JPD now. Partly as it keeps you within the page as per point 2 above.

3 - What is crucial for you in a such view (which might not be presented in the prototypes)? Why?

• I would like to be able to share a live view of current progress so anyone can view the board and see what we are working on currently at any point of the sprint.
• A job "done" completion ticker would be nice to have. Visual roadmap highlights in sync with workflow status perhaps. Keeps viewers in sync and confirms progress.
• As background - I currently I have a "now, next, later" column view per Q but as devs update this field every month, when you get to the last weeks of month 3 of the quarter, the board will look empty showing only "now" tagged tasks (current view filtered to show only Q-X tags - pre the next quarters planning session which I'll make a separate view for). Therefore a simple snapshot of our plans at the start of the quarter seems a safer bet and I'll probably take the data and create that elsewhere for visual synergy + paraphrasing reasons. 

4 - Any other feedback and suggestions that you might have 

• A vertical line showing the current date 
• I wonder if there could be ways to display the inevitable changes to the timeline (dotted lines perhaps) to show where things have been pushed back? or notify external watchers (a separate new feature req) so I don't have to manually keep every stakeholder up to date. Explanations may be needed for such changes -ideally also pushed to watchers. 
• Allow external viewers to watch particular items for progress updates. customise notifications they receive and what fields they have access to. EG changes to the end date +explainations as above
• As the timeline moves forward it might be useful to update "now, next, later" so they are kept in sync and don't rely on manual updates to custom fields. A simplified view of now next later tailored to a dept or project could then be built and self-managed. 
• Option to add rules based on the current date and task start / ends. 

[Hanna]

Hi @Oliver Murray 

Thank you for sharing the feedback with us!

[Riku_Kristersson]

Looks great! Option 1 was more intuitive but I was wondering what field it is using to get quarter information and is there possibility to choose the field like in option 2.

What is crucial for you in a such view?

• Option to see delivery status visually so that entire bar can be changed to look like progress bar. 
• Hide ideas individually or based on filter (I would like to choose what logic filter is using in other views as well - like "show ideas that have value x and not have value y". Option to use JQL search would be best)
• Some way to visualize dependencies (linked issues), example group by linked issues could be one way to create timeline that shows selected links like "depends on".

[Gabriella Addonisio]

I would like the ability to visually show stakeholders when we plan to start discovery of a project (e.g. we would be reaching out to clarify requirements and do research) and when we tentatively plan on doing execution/delivery of a project. This would also help me do capacity planning/work load balancing between PMs which is something often ignored. We spent so much time capacity planning for developers and not PMs