To add a field or not to add a field (best practices)

[Michael Mackuliak]

Hi all – looking to tap into the collective wisdom of this community.

I oversee and help govern our JPD setup, and from time to time, I get requests to add new fields. I try to keep the bar high for what gets added—we’re already sitting at 38 fields (including the standard system ones like assignee, updated, etc.).

What I’m currently missing is a clear framework or decision tree to help guide what’s truly worth the added complexity for an idea, and what’s not. Does anyone here have a set of principles or criteria they use when deciding whether to introduce a new field?

Appreciate any insights!
Thanks,
Mike

[Hermance NDounga]

Hey Michael, 

I will chime in just to provide you with insights partly as a Jira Product Discovery PM, but also as a former Jira admin. 

So first, you need to know the limit of fields in a project is 200, so 38 fields is not what we'd consider a lot, that's actually quite a small number if i'm doing an empirical comparison of what I could see during my customer interviews. 

But now what is really going to matter is: How many project to you expect in the future, and how much time are you ready to dedicate in "maintaining" your project set up. 

If your company has 4 products, and you're planning to introduce maybe 1 or 2 more in the next 5 years, you can have much more fields. 
If you are creating a new project per product area and you have such request like every month, stay in control. 

In both case, I suggest to use global fields as much as you can, so you can simply reuse a field across your projects (and if you have only one project now, it's still very likely you'll have a second tommorow, and managing 74 fields is already not the same story). 
As we will also soon release the Copy Project Configuration feature, it means that you'l be able to spin new projects easily - if you have global fields you are sure you're remain with 38 fields and not 38 times x 

Now, as a previous Jira admin I'd consider three things (because I didn't like to have many fields personally):

Reuse existing fields as much as you can
Sometimes you're being asked for a new field just because an existing one doesn't have all option needed, and for that, in JPD you can play with formatting. For exemple you can add some custom smileys in front of options to indicates if they belong to team A or team B. You can even create automations that nudge a user if they used an option they aren't supposed to use eg. When idea edited , IF team = team A and custom field edited = forbidden_option THEN comment/slack user "Hey there the option "forbidden option" is only for Team A! (that would actually also signify maaaybe the needed options don't need to be differenciated but anyways)

Combine usage as much as you can

For exemple, instead of having a select field for "Interested customers" and a slider field to measure the impact the feature would have, use the select field and add a weight for the customers/customer category. Instead of having a checkbox for "Designs ready" and an hyperlink where to link the designs, get rid of the checkbox, and eventually send a nudge if the idea moved to "In progress" while the hyperlnk field is empty. 

Create fields for "something" :D 

As a rule of thumb I'd say if it's a data that will be used to group by, sort, filter, be used in a formula... I would say it deserve a field. Following the two previous rules tho ! But for exemple if all ideas don't have a project poster (because they are too small, because it's not a mandatory deliverable etc..) then that's something that can be added in the description, don't create a dedicated hyperlink for it. 

I hope I provided you with some exemples that clarify it a bit for you. 

Best Regards,
Hermance
Product Manager @ Jira Product Discovery

[Kim Euker]

I agree with you on not adding too many fields. 

Some guidelines for adding a new field

• As suggested above, it that field has a universal use, that is a great idea for a new field.
• Does that field require searching on its contents.  That may lend itself to a new field.
• Is this a field managing assets.  Then you have to have a new field.
  What you don't need here though is a field for every related piece of data coming from that asset.  So, that is the one field that provides access to everything rather that 20 fields to micromanage every piece of data from the asset.
• The data can appear in a form and not require a field so that is not a strong enough reason for me to create a field.  
• Can this data be managed or used a different way?  
• Does this data need to be viewed (and changed) by the user?

[Oksana Pearce]

I receive a lot of requests for new fields.
But I have a standard screen schema that is used by all engineering projects. (80 plus)
If that field is needed for all of them then I will add the field.
Reviewing the request & communicating the decision is what is normally needed.
Most of the time you can resolve the request without adding new fields. :-)

I also look at the value & its use.

I prefer not to have too many fields.