Beyond Product Discovery: Off-label Use of Jira Product Discovery

One sure sign that you’ve created a great tool is that folks want to use it beyond its intended purpose. That’s the case for us and Jira Product Discovery, which completed Beta earlier this month.  

Don’t get me wrong – our PM loves how easy it is to collect and share product insights in JPD. Being able to assign weight to certain fields and create custom formulas makes it possible for us to identify the features that will be most impactful for our customers. Multiple views make it easy to keep things organized and once features are developed, we can easily rack their delivery status. Overall, we’re quite pleased with JPD as a product discovery tool.

So much so that we’ve taken things a little bit farther…

Beyond Product Management

As our company has grown from a start-up with a handful of people using a bigger handful of tools, to a mid-sized company with an ever-changing, ever-growing portfolio of tools, there’s a lot more to keep track of. We need to see at a glance:

• Which users have access to which services
• Which users should have access to which services
• What data (specifically PII) those services have access to

We’ve experimented with using JPD to answer those questions by creating two projects; one for tracking users' permissions and one for tracking personal data access.

The jury is still out on using JPD to manage personal data access. The relationship between products, sub-processors and the data they handle is complex and we may end up with another solution. However, we’re pleased with how our JPD Permissions Inventory project is working:

Why Do It in Jira

The big advantage of managing our Permissions Inventory in Jira is that we already use Jira. SSO means that when we sign in with our Atlassian IDs, we’re already signed in to the JPD project. We’re working in Jira so it’s quick and easy to switch to JPD, and features like mentions and notifications work the same way across our tool set.  More importantly, using Jira as opposed to an external tool means we’re not adding an another service that needs to monitored from GDPR/PII point of view (in this case, it would be the PII of our team members).  It’s a balancing act between using the best tools for the job and not bloating our list of sub-processors.

Why Do It in Product Discovery

So why a Product Discovery project? A few features make it a good fit for what we’re trying to do. First it’s quick and easy to create new fields, without burrowing into the Jira configuration. Our Permissions Inventory project has custom fields to track the systems, users, admins who granted the permission, etc.

‍

‍

The other feature that fits for inventory tracking is Views. We’ve created multiple board views that make it easy to see the permissions by service user, even grantor (which is nice for knowing who to ask when you want to get access to a system).

Could we achieve this in a traditional Jira project? Possibly. Team-managed projects make it easy to add create custom fields, but even they don’t allow for the easy grouping by custom fields that we can do in JPD.
‍

‍

JPD provides us with a visual, relational database – and the fact that it happens to be in a Jira product is a big plus.

Use Cases

Our use of JPD for tracking permissions is still evolving, but these are the use cases we’re currently designing the project to handle:

• Lookup
  The most common use case we imagine is that someone will want to lookup who has access to a given service
  ‍
• Add New User
  Another lookup type function is looking to see who is the “service owner” for a given tool. Having easy access to this information streamlines the onboarding process as the requests for access get sent to the right person. The hiring manager can look to see who owns the relevant services, then create a Jira issue to request access. Using either a checklist or subtasks easily see who made the request as well as when, by whom access was granted. When a service owner gets the request, they can check the People column to see if the hiree has been added, and if not, add them. Then they can add the appropriate services in the Permissions project, add the actual permissions, and link the access request issue to the appropriate record in the Permissions Inventory. This will ensure that there are complete, backed-up records of who has access to which services.
  ‍

‍

• Service Ownership
  Designing and implementing the Permissions Inventory project gave us the opportunity to review, formalize and document our processes, which turned out to be particularly relevant with regard to service owners. Having a quick view of who can grant/revoke access to a service makes it easy to see where we do and don’t have sufficient back-ups, if the lead service owner and back-up are likely to be on holiday at the same time, etc.
  
  We’re also keen to use the project improve the knowledge transfer if/when one of our service owner leaves the company.  The JPD record provides a place to store information about who is considered eligible for a service access and why. The Permissions Template organizes the description field into 1) an Overview 2) Practical Links and 3) Eligibility notes useful for structuring the information and prompting us to include the right data.
  
  This will be especially relevant when working with external users who we may want to grant limited, temporary or read-only access
  
  

• Auditing Access
  Since we’re using the JPD project to capture permissions eligibility (who should have access to the service), it gives us something to compare to the reality. Service owners can do periodic checks (we may even create automated reminders) to see if the access indicated in the Permissions project matches the reality.  Having an agreed upon source of truth for what access should be will make it easier to verify that we are walking our talk.

Our Permissions Inventory project is still in the proof of concept stage, but so far we’re pleased with using JPD to tackle an otherwise messy problem.

‍