nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Any best practices how to separate Ideas from Experiments in one JPD project?

Niels Schultz_rlme94

Hello!

I'm a product manager working with two scrum teams on executing our product strategy. We are working with JPD to keep track of and organize our ideas and experiments around the opportunities we want to address as part of our strategy.

How can we best differentiate between an Idea and an Experiment?

How do you guys see the relation between the two? As One idea can contain multiple experiments, how do you see the hierarchy between them and how can we best create 2 boards:

1. Kanban board with the Ideas

2. Kanban board with the Experiments

How can we make this happen within one single JPD project?

Accepted answers

Ivan Ferreira_ael6cv

Hello @Niels Schultz

I think that you can just create a custom field to classify the Idea, being experiment or not.

Using this custom field, you can create a view to filter by this field. So now you have two views, one for "Experiment = Yes" and one for "Experiment = No".

You can also create a new issue link type "is validated by " / "is an experiment of"

Joris Roulleau

I've got a similar issue. In an ideal world I would like to organise my ideas in a hierarchical fashion as follows:

Outcome > Opportunity > Sub-opportunity > Solution > Experiment.

That is to say, for me, experiments must belong to an opportunity: they exist to either validate that opportunity, or the technical solution to deliver that opportunity.

I saw a workaround to mimic a parent-child relationship of sorts, but I don't think it will scale well, so I'll wait for some kind of true parent-child capability to be released (I understand it is on the JPD roadmap) to really organise my ideas in the way I want.

This wait is not all bad, though, as it forces me to think hard about what I really need and not over complicate things.

For the time being, I've taken the following approach:

- Outcomes are a field (similar to Goals)

- Opportunities and sub-opportunities are my ideas in JPD (I have a custom field to note if an idea is one or the other)

- I may add in an opportunity description or comments potential solutions and experiments, but these are pretty loose at this stage

- If the idea is prioritised, I will refine solutions and experiments in linked Jira Software tickets

Our terminologies may be slightly different, but ultimately, I assume an experiment is something you do (be it a technical spike or a fake it before you build it approach to gauge interest, for example), and as such is suitable for tracking in Jira Software.

Denis Paul

In our setup we use "experiment" as one workflow step. But of course that doesn't work in a more complex context as described by Joris below with multiple possible solutions etc.

Helena Jeret-Mäe

I spoke with head of product for JPD today because I am facing the same issue. Currently, there are workarounds but we don't have a way to create proper hierarchy using objects that are NOT ideas. Basically to get this solved, we'd need access to (data objects) we can define as assumptions and experiments and configure them accordingly, and the ability to build a hierarchy.

I'll also tinker with workarounds until there are better solutions.

The good news is that they are working on it

All comments

Ivan Ferreira_ael6cv

Hello @Niels Schultz

I think that you can just create a custom field to classify the Idea, being experiment or not.

Using this custom field, you can create a view to filter by this field. So now you have two views, one for "Experiment = Yes" and one for "Experiment = No".

You can also create a new issue link type "is validated by " / "is an experiment of"

Joris Roulleau

I've got a similar issue. In an ideal world I would like to organise my ideas in a hierarchical fashion as follows:

Outcome > Opportunity > Sub-opportunity > Solution > Experiment.

That is to say, for me, experiments must belong to an opportunity: they exist to either validate that opportunity, or the technical solution to deliver that opportunity.

This wait is not all bad, though, as it forces me to think hard about what I really need and not over complicate things.

For the time being, I've taken the following approach:

- Outcomes are a field (similar to Goals)

- Opportunities and sub-opportunities are my ideas in JPD (I have a custom field to note if an idea is one or the other)

- I may add in an opportunity description or comments potential solutions and experiments, but these are pretty loose at this stage

- If the idea is prioritised, I will refine solutions and experiments in linked Jira Software tickets

Joris Roulleau

Thanks for the tip on issue link type. That sounds useful.

Denis Paul

In our setup we use "experiment" as one workflow step. But of course that doesn't work in a more complex context as described by Joris below with multiple possible solutions etc.

Niels Schultz_rlme94

Tnx Joris, this helps! 🙏

So if I understand correctly, you don't create a single 'idea' in JPD for every potential solution or experiment? You just add this info as part of the description of the (sub-)opportunity.

How does this work for you? In my experience I think it's really great that we can move every separate idea through the discovery/delivery workflow and also fill our prioritization matrix (impact vs uncertainty)

Niels Schultz_rlme94

Another thought that I am curious to hear your take on is this:

In my view/experience, an 'experiment' does not always have to have a technical component. For example testing an assumption can sometimes be as simple as running a quick survey, asking 5 customers or doing some kind of desk research.

I would really like one board for all experiments so the team can have a weekly experiment stand-up where we discuss 1. experiment-proposals 2. running experiments and 3. share learnings/next steps of finished experiments.

Helena Jeret-Mäe

I'll also tinker with workarounds until there are better solutions.

The good news is that they are working on it

Niels Schultz_rlme94

Hi Denis, where do you write your description of the experiment (We believe that, therefore we will, we measure, we are right if...)? As part of description of the idea or in a comment or somewhere else?

Niels Schultz_rlme94

I like your suggestion to create new issue link types, I will look into it 🙏

That might do the trick at this point

Joris Roulleau

@Niels Schultzthat's right, right now I shy away from creating a new 'idea' for a potential solution or experiment. My original intention was to create these as separate ideas and connect them hierarchically to the (sub)opportunities. However, since that's not really possible at present and solutions/experiments tend to exist and develop in Jira Software anyway (as part of delivery discussion), I opted for simplicity and add them in the description of the opportunity idea, before they make it as a delivery item.

It's early days for me, I'm still finding out what works. I'm focussed on providing transparency and prioritization for opportunities, with defining and prioritizing experiments being more informal at the ideation stage.

I agree experiments are not always technical, but for me most would/could exist as a Jira Software task alongside development tasks. One reason why I don't mind this set up is that it's akin to a todo list and makes me progress an idea that's been prioritized, rather than sit on it and get distracted with something else.

No doubt there are some kinds of experiments this is not well suited for, for example if you run some kind of experiment and want to measure the results in two months' time. I guess it depends what you do. The desk research type, I would do informally as part of developing the idea, other experiments that require some kind of action I'd track in Jira Software.

I like your idea of an experiments stand-up, retros etc. I think as was suggested by others you don't need a separate board for it, you could use "experiments" views based on a custom field.

Denis Paul

We write a comment with the rules and for bigger experiments we link our UX ticket which lives in Trello

Tanguy Crusson

Hi there: you can now start creating custom product hierarchies (e.g. Opportunities-Solutions, parent-child and more) using a feature from the Jira Product Discovery Premium plan.

About the feature:

Custom product hierarchies

About the JPD Premium plan:

Welcome!

It looks like you're new here. Sign in or register to get started.