Required field validator for Product discovery workflow

[serhat]

Is it possible to set Required field validations for Product discovery workflows as we do with JIRA?

When creating an issue I want 3 fields to be set as required fields

[Tanguy Crusson · Accepted solution]

Hi @serhat , it's not something that the product supports today. 

There's 2 related features though:

• if you create a view with a filter (e.g. "product = A and team = X"), and you create an idea from that view - then these field values will be automatically applied. 
• you can create templates for an idea's description - to standardize how ideas are defined (e.g problem definition and validation, etc.)

[serhat]

Thanks for the prompt response @Tanguy Crusson 

- Is this something in your roadmap?

- I find fields useful rather than raw description text since I prioritize the feature depending on the field values.

- I like your idea #1. But I want them required not optional if I understood correctly. I like to create ideas with the "Create idea" button.

[Tanguy Crusson]

It's not something that comes up frequently as feedback @serhat so not high priority today. Usually the teams we talked to looked for a more flexible/less structured way to capture information quickly as ideas - and refine them later if/when they decide to explore them in more details.

We definitely do plan to integrate better with the "create idea" button though, so it works the same from that dialog - but it's not there yet today

[Tanguy Crusson]

If you don't mind sharing: what are the fields you want to make compulsory?

[serhat]

product area

bucket

goal

[Will Morgenweck]

@Tanguy Crusson I wanted to share a few more use cases as to why the required fields would be a nice enhancement. Today we use Initiatives in Jira Software for capturing all the details about the particular feature or product. This is where the Product Manager does the bulk of their work before creating Epics.  In addition to the description, we have a handful of fields that capture Impact, Effort, target release, target first sprint, stakeholder validation, etc. All initiatives go through a review process for quality and prioritization before any of the work makes it to a dev team. Having the validation rules as part of the workflow helps enforce quality of requirements and also reduces approval churn. 

[Robert Barbosa]

I have tried using automation to validate a field before entering a Product Discovery status. It is more 'clunky' than the Jira Software experience, but was possible.

Our product managers collaborate with technical teams. We would like to capture a formal approval of a requirement or design, therefore this validation would be helpful in our industry.

[Bradley Davidson]

Any updates on this?
Or any ticket we can vote on?

This would be a good feature to add as many steps often require validation before moving forward.

[Joshua Heling]

We would find this very valuable in JPD. We were using a team-managed project to track our backlog ideas before moving to JPD, and it had transition rules requiring certain fields to be set before particular state transitions were available.

It's important IMO to have a very low-friction way of capturing ideas, but at the same time I don't want to let an idea get too far in the process before certain things are defined. In order to strike that balance, we used transition rules to check for definition of specific custom fields before a particular state change was allowed. For example, an issue can't transition from the "IN REVIEW" state to the "REVIEWED" state without having a defined "Desired Outcome" field. And similarly, something can't go from our "DISCOVERY & DEFINITION" state to "READY FOR DEV" without having a rough level of effort defined.