Realizing product outcomes with ideas, from inception to delivery
In Jira Product Discovery, the main object you work with in your product backlog is “Ideas”. To support a process of continuous validation and learning, we use ideas as long lived objects — an idea does leave the backlog when development starts, but lives on throughout iterations of discovery and delivery, up until it delivers the required impact.
Successful product teams adopt an experimental mindset — they keep iterating the idea over time by adding more context, user feedback, specs and design. At each stage of the idea lifecycle, they assess what worked and what didn’t, answering key questions and validating their assumptions to make sure that their investments match the feedback and validation they receive.
Ideas from big to small
Although the name of the object you use in Jira Product Discovery is “ideas,” they can represent product ideas, opportunities, problems, solutions, and more. A product backlog can be designed to hold ideas of many different shapes and levels of granularity.
It’s important to define these categories, and have everyone participating in the process agree on them. This will prevent the product backlog from becoming a mixed bag of items, from super-large to super-small, with no framework to classify and compare them.
Boulders, Rocks, and Pebbles: One way to classify ideas
On the Jira Product Discovery team, we organize ideas into three levels: boulders, rocks and pebbles.
Boulders, rocks, and pebbles.
- Boulders: A large investment with potentially big payoff but high uncertainty, too
- Example: Big new bet, new product pillar, large engineering project.
- Rocks: Medium sized investments with fewer risks
- Example: New features, new onboarding experiments, redesigns based on feedback
- Pebbles: Small, typically straightforward investment
- Example: Small UX improvements, “paper cut” fixes
- Example: Small UX improvements, “paper cut” fixes
Our team uses separate views to discuss these different categories of idea:
View of Boulders in Jira Product Discovery.
View of Rocks in Jira Product Discovery.
View of Pebbles in Jira Product Discovery.
Attributes of an idea
In Jira Product Discovery, every Idea is complete with a one-line summary, a detailed description, insights like customer feedback, and links to Jira tickets for the Idea’s delivery.
An Idea in Jira Product Discovery.
Delivery panel on an Idea in Jira Product Discovery.
To be as useful and actionable as possible, every idea in the product backlog should be complete with these attributes:
Attribute | What is it? |
|---|---|
| Summary | What is it? A one-liner about the idea. |
| Description | What is it? A more detailed description of the opportunity, problem, solution. |
| Fields | What is it? The different facets of the idea: which goal it contributes to, its stage, what part of the product it touches, information to help prioritize it, like impact or effort, links to specs or designs. |
| Insights | What is it? Insights captured across all channels as they come through: key learnings from user feedback, snippets from customer conversations and research reports, or product analytics that clearly articulate why this idea is important. |
| Delivery | What is it? Links to delivery tickets in Jira (epics or initiatives) for the delivery work to actually ship the product idea. |
It might take time to gather all this information for every idea. Initially, the idea might enter your backlog with a 1-liner summary, such as an insight gathered in conversation with a customer. Over time, you’ll collect more insights about it based on user interviews, feedback from sales or support, or changes in company strategy.
A one-liner with a piece of user feedback.
With user feedback and analysis of potential impact.
With a validated solution and delivery well under way.
There are two ways to describe Ideas: directly in Jira Product Discovery, or by linking Confluence to your team’s Jira Product Discovery project.
In Jira Product Discovery, write a summary or definition in the idea’s description field. Use one of the provided templates, or create your own, to provide a consistent formula for describing problems, solutions, hypotheses, and more related to the idea.
If your team also uses Confluence, you can link the idea to Confluence pages: either in the idea’s description, or by using custom hyperlink fields. The benefit of this approach is that you can leverage all of Confluence’s collaboration features, like inline comments.
The content of the description itself will depend on the type of idea and its stage.
The idea lifecycle
Equally important to the content of an idea, is how it evolves over time. That’s why it’s important to define clear stages for each idea to move through during its lifecycle. Having a common vocabulary to describe the stages of the idea lifecycle makes every conversation more productive, both within the team and with stakeholders.
At Atlassian we use four stages: Wonder, Explore, Make and Impact. At Atlassian, everyone knows what each of these stages mean. For each stage, we know what type of work the team is engaged in, what kind of questions to ask, and what type of help the team might need. This consistency holds true for discussions within the team, with other teams, or with senior leaders.
When building Jira Product Discovery, our team used this approach to develop, validate, and deliver our ideas. For each lifecycle stage, we’ll explain how our team put it into practice.
Wonder, Explore, Make, Impact
Before moving into this lifecycle, every idea starts in the parking lot. At this stage, they’re usually just one-liner summaries, with the insight that led to their creation. Those insights could have come from a workshop, a research report, a discussion with a customer, or been shared by a sales or support person.
Once active work has begun on the idea, it follows the four stages:
- Wonder: Discuss the problems or opportunities the idea could address, who they’ll impact, and their importance.
- Explore: Ideate potential solutions until finding one that’s validated by customer feedback.
- Make: Build the solution, and iterate on it until it satisfies the needs of enough customers.
- Impact: Launch the solution, measure results, and keep improving until it delivers the outcome you want.
Idea stages for the Sirius team in Jira Product Discovery.
A board view of ideas in the Jira Product Discovery team per idea stage.
This isn’t a waterfall model — these stages are not necessarily linear. For example, it’s very common for an idea in Explore to go back to Wonder, as testing solutions teaches us more about the problem. It’s also expected that you’ll abandon some ideas, if you don’t find a solution that fits after a few tries.
In the following sections, we’ll illustrate each stage by showing how our team followed them when we were building Jira Product Discovery.
If you’re curious about that process, watch this talk for even more details:
Wonder
The Wonder stage is about validating a problem or opportunity.
In this stage, you’ll usually rely on qualitative interviews with customers. From this research, your team will get clear on the benefits and outcomes the idea aims to deliver, measured in terms of value to customers and the business. They’ll also craft a hypothesis for how to measure success.
For ideas in this stage, you can use Jira Product Discovery’s “Problem definition” template, or create your own.
“Problem definition” template in Jira Product Discovery.
Throughout the Wonder, Explore, Make and Impact stages, capture learnings from research and customer conversations into the idea’s Insights section:
The Insights field for an idea in Jira Product Discovery.
Wonder in action
Here’s what the Wonder stage looked like when we were building Jira Product Discovery. The original idea for this product came from:
Interviews with product managers using Jira for software delivery
Analyzing research from Atlassian’s own Research & Insights team, and analyst firms like Gartner and Forrester
Examples of product development best practices, like Marty Cagan’s blogs and Teresa Torres’s book.
Collecting these insights gave us confidence that:
- PMs were struggling with many things, from prioritizing effectively to convincing everyone of their roadmaps
- PMs were looking to Jira to solve these pain points, but were having limited success because Jira wasn’t designed for that purpose
- PMs were stuck in delivery, focused on outputs like shipping features when they could be taking a discovery-first mindset and delivering outcomes
- Product management was becoming a key function, even beyond tech companies. So, we believed this was a big opportunity and there would be strong demand for a solution.
Our landing page for Jira Product Discovery.
We were especially focused on validating our hypothesis about demand, as this was our riskiest assumption. If we were wrong, we’d create a product that only a few companies would buy.
So before writing a single line of code, we created a web page advertising the product.
The results confirmed our hypothesis: 3,000 people joined the waitlist in a fortnight.
Explore
In the Explore stage, we conceptualize, test, and validate solutions for the problems or opportunities identified in Wonder.
We know that many product ideas will fail — this is just part of the process! To identify these less promising ideas sooner and make way for the good ones, Marty Cagan proposes that product managers address four key risks. Use these when evaluating possible solutions to the problems and opportunities you’ve identified.
- Is the solution valuable to customers? If it’s not — let’s say, they already have access to better alternatives — you risk people not using the solution you’ve built.
- Is the solution usable and inutitive? For users to get value from the solution, it needs to be simple to access and use. If there’s a high barrier to getting value, you risk launching a feature with low usage.
- Is this solution technically feasible? No matter how promising an idea, your engineers must have the skills and technology necessary to make it work — or you risk needlessly draining resources.
- Is the solution viable with the business’s resources and constraints? It will likely take a few different iterations to get your solution right. You want to ensure that the business is prepared to invest or you risk spending time on an idea that gets abandoned.
Your team’s goal is to minimize the risks as efficiently as possible, and avoid over-investing based on gut feel or falling in love with a solution. This commonly happens by shipping a feature, then iterating or studying how it performs. Instead, use lower-lift techniques like creating prototypes in Figma and showing them to customers to get early feedback before you start writing code.
If you do decide to ship a feature, try building a live prototype with a lot of limitations, testing it with a small group of early adopters, and iterating fast. This way you don’t have to think about all corner cases. If the idea doesn’t work out for them, you’ll learn why much faster, and keep iterating until it does — or discard the idea if it doesn't land.
If you have large areas of uncertainty, do a technical spike as part of the Explore stage. This type of implementation is meant to help you understand your team’s own constraints; what’s technically feasible, and where the areas of technical complexity are.
For ideas at this stage, you can use Jira Product Discovery’s “Solution definition” template, or create your own.
Solution Definition template in Jira Product Discovery.
Within your product backlog, link all documents, specs and designs related to each idea, so you have them at your fingertips for discussing the idea with your team and stakeholders. We recommend creating ‘hyperlink’ fields on each Idea to keep track of each asset (one pager, design).
Here's a demo for how to do so:
Explore in action
When we were creating Jira Product Discovery, we used the following techniques to validate our solutions with customers:
First, we showed PMs slides with different possible solutions, to understand which resonated best. Through these conversations, we learned a lot about our customers' struggles and what they valued. That’s how “prioritization” became Jira Product Discovery’s first pillar.
💡 Slides are great for this stage of validation: they’re easy to create, test and change.
Next, we created prototypes in Figma, showed them to users, and asked how the solutions would help them. The first prototype we tried this with was a solution meant to help PMs use stakeholder feedback to prioritize.
While there was definitely interest, PMs felt there was too much effort required in setting it up before they could get value. So, we threw the idea away.
After collecting multiple rounds of such feedback, we explored the solution which would become what Jira Product Discovery is today: a collaborative space for discussing product ideas.
At this stage conversations with users changed drastically. Many were asking when they could get access, since the tool would help them so much. That’s when we knew we were on the right track.
After collecting multiple rounds of such feedback, we explored the solution which would become what Jira Product Discovery is today: a collaborative space for discussing product ideas.
At this stage conversations with users changed drastically. Many were asking when they could get access, since the tool would help them so much. That’s when we knew we were on the right track.
Make
In the Make stage, teams build and validate the solutions they settled on in Explore. This is when the bulk of the development work happens.
The outcome of this phase is working software — either a new product or feature, or improvements to an existing experience — that has proven it can deliver on expected outcomes, has been adopted by enough customers to prove its value and is ready for all customers to use.
When delivery starts, either in this phase, or during Explore, you’ll connect the idea to Delivery tickets in Jira (we recommend Epic-level or above). Track delivery progress from within Jira Product Discovery and get a bird’s eye view of progress across all product initiatives and teams.
The relationship between an Idea and delivery work in Jira.
If multiple teams are involved in delivering an idea, and they’re working in different Jira projects, you can link all their delivery tickets to the Idea in your product backlog.
An Idea delivered by three different Jira squads.
You can then track the progress of the delivery from within JPD and get a bird’s eye view of progress across all product initiatives and teams.
Dashboard of product work in flight.
For more information, you can have a look at our webinar on "How to connect discovery and delivery in Jira" in the Resources section.
Remember, it’s very unlikely that the solution will deliver on expected outcomes immediately. Instead, ship early and often to customers and keep iterating until it’s good enough. Keep adding insights from customer conversations to the idea based on what you learn. The way you’ll measure success will differ based on the type of idea: new feature, growth initiative, etc. Make sure everyone knows this, and that your plans allow for iterations.
Make in action
When creating Jira Product Discovery, and when adding important new features to the product, we tested and validated them with progressively larger groups of customers. In some cases, this process took a few weeks, in others it took a few months.
| 0 → 10 customers | During the Explore phase, we iterated with a small number of pre-selected customers. We worked very closely with these customers to shape the solution together. We kept iterating until we got confirmation from them that the solution solved the problem they were facing. |
| 10 → 100 customers | We then progressively gave access to more customers. This helped us identify different scenarios we may not have considered initially.We kept iterating until we had 100 active customers using the solution. |
| 100 → 1000 customers | We then gave access to more customers, until reaching 1000. Then, we look at usage numbers from product analytics, support tickets, and inbound feedback. Based on our findings, we improved the UX or fixed bugs. If usage numbers were too low to be useful, we’d look at the feature’s discoverability. |
| General availability | Finally, we got support enablement, sales enablement, operational dashboards, performance and scalability improvements ready to go. |
When we work on solutions like this, we usually shape them in a separate Confluence page we call a “Live feature document”. This is a very lightweight page that we open every time we meet as a team, to discuss the scope of the current iteration. We update this document frequently, as we learn more about what’s easy or difficult to ship. It’s not focused on individual tasks, but on the product experience — which is what we want everyone, from product to design to engineering, to align on.
Live feature document in Jira Product Discovery.
Impact
In the product model, everything starts and ends with outcomes. Teams prioritize ideas so that they can get to an outcome, and after delivering, continue monitoring progress towards these outcomes. This informs updates to your goals and strategies, and how you prioritize your next moves.
Even after a solution has shipped, it’s never really “done”: as soon as you introduce a feature, it’s now part of your product. You need to keep improving it to make sure it’s value to users, and that people aren’t finding it confusing or hard to use. Make sure to keep track of what customers ask for, what they say about new features, and how often they get brought up in support tickets.
Impact in action
On the Jira Product Discovery team, we do this with monthly and quarterly reviews, in which we compare the impact we achieved with what we set out to do. Sometimes we’re happy with the results and change very little, sometimes we reset the roadmap to try something different.
Here’s one technique we use: after we’ve shipped a solution, we create a corresponding improvement idea where we collect insights including:
- Inbound feedback from users
- Signals that the feature is or isn’t solving the problems it was built for in feedback, surveys and interviews
- Usage data from product analytics to understand if the solution is actually used. If it’s not, there might be discoverability issues, or just less excitement about the feature that we had planned for.
View for tracking customer feedback on previously shipped ideas in Jira Product Discovery.
We look at this data regularly, and each team allocates budget to feature improvements. Both new ideas and improvements to existing ones appear on each team’s roadmap:
The progress of an idea
Jira Product Discovery does provide a set of fields to show the progress of delivery tickets on an idea. But we don’t believe this is necessarily the best way to communicate progress to stakeholders. Whether an epic’s tasks are 60% or 80% done doesn’t reveal how much progress the team is truly making.
Here’s a more impactful way to communicate progress to stakeholders: mark each idea as on track, at risk or off track (via a field) and provide commentary (in the idea’s description). This is a very simple collaboration primitive, but is highly effective at communicating to stakeholders where you need help.
View communicating progress to stakeholders in Jira Product Discovery.
More details on one idea in the progress-sharing view.
If you’re an Atlas customer, you’re already familiar with this approach. Watch the video of how to connect Jira Product Discovery ideas with Atlas projects in the Resources section. This tells a better and more accurate story than the views below, which measure progress as percentage of Jira tickets delivered:
A Jira Product Discovery view showing progress by tickets delivered in Jira.
More details on one idea in the ticket-focused progress view.
What’s next?
By using Ideas as a vehicle for carrying solutions through ideation, validation, and into delivery, product teams can keep their people organized and focused on outcomes.
In the rest of this handbook, we’ll explain in detail how to use a product backlog to:
- Set up feedback channels and gather insights to validate ideas
- Prioritize the ideas that can make an impact
- Create roadmaps your teams and stakeholders can rally behind
We’ll give examples for how we do this in the Jira Product Discovery team, using Jira Product Discovery and other products.
Product backlog
Effectively manage product backlogs to prioritize ideas, enhance collaboration, and drive product development.
Feedback & insights
Learn how integrating insights into your product development process can enhance decision-making, align with customer needs, and drive successful outcomes.
