I have a question please re the pricing structure for contributors vs creators.
We have multiple Jira Product Discovery projects one per team as our product suite warrants this as a opposed to culminating all ideas into one discovery project.
If I were to have two creators per project this would mean that I would have 10 creators in total, is your pricing model based on.
Total number of users with creator level access?
Or number of users with creator level access per project?
The reason I ask is your pricing model states that you can have 3 creators = free, but does not define as far as I can see if this is total or per project.
Maybe this piece of advice will be of handy for those who need public portal to collect ideas from customers. This app can be integrated with Jira Product Discovery as well. You can create a public or pivate portal (to restrict it, for example, only for your company by domain), and ideas captured on this portal go automatically to the mapped Jira Product Discovery project.
It is based on the number of creators in your site, not per project. So if you have 10 creators over multiple projects, it is still equal to 10 creators.
Having users across both discovery projects as below will only result in a single charge.
Share views with other teams and gather their feedback using fields and votes to receive feedback from internal teams
It indicates that the view can be shared with "anyone who has a link". This feature is not available to me. When will that get released to general audience? Thanks!
Could you please clarify if this pricing model is valid for all Jira plans? If a company is a Premium customer would they still need to pay $10 per creator, per month? I understand that the pricing is progressive but if we would like to give the opportunity to everyone in the company to create ideas it could get very pricy and unattractive and there is a fine line between adoption and pricing. I truly hope Atlassian figures it out in the best way for both sides.
First of all thanks for the updates and be actively reading us. JPD has been an awesome finding so far. It contributes a lot to collaborate over all the ideas we receive across the organization, which can get very messy if not managed well. However I agree with everyone else on contributors creating new ideas, so they can truly contribute.
In our case, most of the ideas come from outside the Product Team (sales, support, etc.) and it's not affordable to have 40+ creators, that should stick to the Product Team. Otherwise we'll have to create an intermediate repository of ideas and JPD will lose part of its value.
To build on at least one comment here -- I would want to know if it is possible to restrict people with creator licenses from creating projects similar to Jira Software. Managing like a Jira Software project admin is OK, but we do not allow anyone to create projects in JS but admins. This could be a huge mess if everyone create anything they want.
Would also be interested if any Discovery features overlap/are redundant with Jira Software or Jira Service Management.
Great news @John McKiernan but contributors should be able to submit ideas, otherwise aligning people from customer success and sales (where the actual contributed content is coming from) would be a pain.
So I keep seeing comments about contributors being able to submit ideas (as opposed to insights).
I'm going to be the one to disagree.
I don't want anyone outside of my team being able to create 'ideas' in my JPD backlog. I DO want anyone to be able to create an INSIGHT.
I'd love to see JPD adopt what other similar systems offer, which is a way (preferably multiple ways) to submit insights and have them sit in a sort of inbox. That way, we can attach those insights to ideas.
Why? Because it isn't up to the sales person, the support person, the customer, to tell the product team the solution. I want to hear all about their problems, and what they love and what they don't like and why. But, as the product manager, I want to be able to organize those insights attached to ideas the way I want to (straight up ideas, opportunities vs solutions, features and sub features, I love that JPD keeps it open so I can organize that and think about it the way I want to).
Otherwise, you will end up with a very messy set of idea boards.
@Krystal O'Connor - valid points, but I believe that with the right set of options and flexibility in JPD, the needs of different types of teams can be supported without restricting the product. There's valid arguments for both sides.
I agree with the desire to maintain organization and control over the idea backlog, but many teams believe that allowing contributors to submit ideas can bring new ideas (that don't already exist JPD), valuable insights, and help to engage and motivate the team.
Contributors (including CSMs, sales, support, and other team members) often have valuable insights and perspectives on the needs and desires of the target audience. By allowing them to submit new ideas (as well as insights and comments on existing ideas), we can tap into this collective knowledge and potentially come up with more creative and relevant solutions.
One approach to supporting both types of teams could be to provide flexibility in the system, such as allowing team members to customize their JPD settings to allow or disallow contributions from certain groups or individuals (if the JPD team adds this; (cc: @Tanguy Crusson). This would enable teams to adapt their JPD project to fit their specific needs and preferences, while still allowing for the possibility of leveraging the collective knowledge and perspectives of the entire team.
In addition, to avoid the messy idea backlog issue you mention, there could be some sort of a review process for ideas submitted by contributors, where a designated team member (i.e. product manager) can review and decide which ideas (from contributors) to move forward with and how to organize/categorize them. This can help to maintain control over the backlog while still allowing for contributions from a variety of sources.
Regarding your following point: "Why? Because it isn't up to the sales person, the support person, the customer, to tell the product team the solution. I want to hear all about their problems, and what they love and what they don't like and why.":
That might be the case for some teams, but again different teams have different processes and needs when it comes to product development. While one team may prefer to focus on capturing insights on existing ideas in JPD and leaving the solution-finding solely to the product team, other teams may find value in allowing a wider range of contributors to submit new ideas (which may or may not mention a particular solution, but there's no harm in allowing that to be included along with the problems/the why/etc; the product team does not have to go with the solution mentioned by contributor/customer).
In short, if the JPD team can provide flexibility and options, it's possible to support the needs of both kinds of teams. 🤜🤛
I agree with everything you are saying. I think what I'm looking at though is that bucket of 'ideas' is actually insights (which is not how JPD is operating currently).
One of the things I dislike (heavily) about JPD is that insights can't be created unless they are attached to an existing idea. I think this is backwards. The insights come before the idea does. The idea often comes from those insights. (I mean, that's the process... in theory... but the lingo of the vocabulary here makes it a little confusing)
I want insights to come in and be bucketed and I can then attach them to an idea (or whatever you want to call it) which actually would achieve what you and I are both saying. That's what I'm advocating for.
That way sales, support, etc can all submit anything and everything they want, and we as PMs or whoever is owning this piece of the process can attach that to the appropriate 'ideas' (features, opportunities, whatever you want to call it).
I think we're both actually saying the same thing in what we ultimately want, which is what I'm getting at. And yes, 100%, the flexibility to use it and setup your processes the way you want is so important. I feel that this part isn't there yet, because I don't have that ability to have a free flow of 'insights' without attaching them to 'ideas'.
Atlassian Team members are employees working across the company in a wide variety of roles.
January 3, 2023 edited
Thanks for the feedback everyone. What we recommend, if you want to implement a feedback inbox, is what is on the FAQ:
How can we use Jira Product Discovery to collect feedback from customers/users and other teams (support, sales, customer success, marketing)?
In this first version of Jira Product Discovery, we’ve focused on some the jobs that help a PM do their job: prioritizing ideas and opportunities, creating and sharing roadmaps that stay up to date, and capturing feedback from a bunch of different places (interview notes in Confluence/Google Docs, conversations in Slack/Teams). But for now we assume the PMs have existing channels they use to receive feedback, and we help them send this feedback to ideas in Jira Product Discovery.
We have only partially tackled the job of creating a direct feedback channel between customers/users or other internal teams (sales/support/customer success/marketing) with the product team. We have plans to do more there, but for now these are the options that you can use to do that with the product today:
Share views with other teams and gather their feedback using fields and votes to receive feedback from internal teams
In the Jira Product Discovery team we use #1 for receiving and discussing feedback from users (the little "Send feedback" button in the Jira Product Discovery left sidebar creates a Jira Service Management ticket) and #2 to discuss feedback with internal Atlassian staff. We definitely wouldn't recommend #3 - not to say that you can't do it, I know a few teams that do, but that quickly becomes unmanageable and in my opinion sets the wrong expectations.
I wanted to follow-up on my original feedback on the JDP pricing.
We, PMs have been waiting for a long time to have a more seamless integration with Jira when it comes to the Idea collection process and Atlassian finally took steps in this direction which is highly appreciated.
I assume many companies would like to give the opportunity to almost everyone to contribute product ideas and some individuals would be more prolific than others. If Atlassian goes with the announced prices it could become quite expensive to enable everyone in an organisation to create ideas. Given some individuals would rarely create ideas it won't be worth paying the price but it is also not fair to take away this opportunity for them. Not wanting to discriminate anyone companies might resolve yet again to other ways of reporting ideas and then importing them to a JDP which voids the whole concept of having a seamless idea process in Jira.
At the end it may happen that Atlassian may lose customer base for the JDP and the companies would still have an Idea Workflow which breaks because of using multiple tools... I truly hope Atlassian would put more consideration into the pricing model for the JDP.
That said the JDP is far from production ready in my opinion, lacking key capabilities and having performance issues. I have already discussed those over various support ticket but would like to mention them once again for anyone who might be considering using this project in the near future while it is still in its beta version.
We have imported 1500 ideas in the project and have about additional 10 custom fields configured. The project is very slow to work with, the views open slowly, crash in some cases or are not responsive, it is frustrating. The single/multi select fields where we have imported hundreds of values are extremely slow to select and edit either.
Move between two JDP projects doesn't work because the values from source to target are not propagated, despite the exact field match (name, type). This is very unfortunate because we imported all ideas to an Archive JDP and wanted to set-up a clean JDP and move the "old" ideas into it on per need basis but it doesn't work right now.
Cannot create different Idea types
Cannot set mandatory fields.
JDP - Zendesk integration works one way. When an insight is created from Zendesk the Zendesk ticket appears as a link in Jira but there is nothing in Zendesk indicating that there is a linked Idea to this Zendesk ticket. On the other hand the classical Zendesk - Jira Software Project integration doesn't work the same way for JDP.
JDP doesn't support the field type enabling creation of values on the fly (e.g. the Labels field in the software project).
I am sure you are working hard on the JDP and hope we will soon see it living up to its full potential!
Atlassian Team members are employees working across the company in a wide variety of roles.
January 3, 2023 edited
@Jeny Stoeva I think it may be worth us chatting to understand a bit more what you're trying to do. What we suggest you track in Jira Product Discovery is high impact ideas/opportunities/solutions - something that would be at the epic level or above in Jira Software speak. Basically: boulder-sized investments that you can compare and prioritize for your product to make an impact.
We're using Jira Product Discovery to envision Jira Product Discovery (meta 😅) and have ~300 ideas in the project after 2 years (much lower than your 1500!). On the roadmap we have 20 - one idea in there was "Timeline view", another one is "feedback/insights collection and management".
I appreciate the instructions on how to export ideas if we decide later that JPD doesn't meet our needs, but it is unfortunate to hear that the insights linked to those ideas cannot be exported too. This is very concerning as it will likely cause a lot of rework and potential loss of data if we decide that we need to go in another direction. It would be great if you could address to help ease our adoption of the tool.
@Tanguy Crusson Thank you for the quick response. That is encouraging to hear.
One other item I noticed in regards to insights is that the insight impact value pulls when you add the custom field, but the insight label value does not pull when you add the custom field. Is this a bug? My team would find value in seeing those label options when viewing a List View versus having to go into each idea to see the label associated with linked insights. Thank you.
@Tanguy Crusson I use the label feature to note the source of the insight such as "interview", "2022 survey", etc to help me identify trends and weight for the linked idea.
I would gladly jump on a call to explain our use case for JDP and it will help you understand why we have so many ideas :) Please let me know how we can organise it.
I am sure we are not the only customer who would need to handle bigger number of ideas. 1500 might or might not be a lot, it is all a matter of perspective. I would expect any Jira project to be able to fluently handle more than 1500 issues either way.
121 comments