Product requirements documents, downsized

Nobody likes writing bloated, ultra-detailed product requirements documents. Turns out nobody likes using them, either.

Dan Radigan Dan Radigan

Building a great product requires tons of research and comprehensive planning. But where do you start? Product managers often start with a product requirements document (PRD). 

A product requirements document defines the product you are about to build: It outlines the product's purpose, its features, functionalities, and behavior.

Agile product requirement documents | Atlassian agile coach

Next, you share the PRD with (and seek input from) stakeholders - business and technical teams who will help build, launch or market your product.

Once all stakeholders are aligned, the PRD serves as a compass, providing clear direction toward a product's purpose while creating a shared understanding among business and technical teams.

Gathering requirements in an agile world

What does the requirements gathering process look like in an agile world? It sounds tricky - and it is. But don't worry. At Atlassian, we know all about creating PRDs in an agile environment. Here are a few things to keep in mind:

Agile requirements are a product owner's best friend. Product owners who don't use agile requirements get caught up with spec'ing out every detail to deliver the right software (then cross their fingers hoping they've spec'ed out the right things). Agile requirements, on the other hand, depend on a shared understanding of the customer that is shared between the product owner, designer, and the development team. That shared understanding and empathy for the target customer unlocks hidden bandwidth for product owners. They can focus on higher-level requirements and leave implementation details to the development team, who is fully equipped to do so – again, because of that shared understanding. (Boom.)

Creating a shared understanding among teams


  • When conducting customer interviews, include a member of the design and development teams so they can hear from a customer directly instead of relying on the product owner's notes. It will also give them the chance to probe deeper while the topic is fresh in the customer's mind.
  • チームの活動として、顧客のペルソナを明らかにして活用しましょう。チームメンバーにはそれぞれ固有の視点や考え方があり、ペルソナが製品開発にどのような影響を及ぼすのかを理解する必要があります。
  • チームスポーツのように協力して、課題に優先順位を設定し、バックログのグルーミング (手入れ) を行いましょう。全員が共通の認識を持ち、プロダクトオーナーが作業に優先順位を設定した理由を理解する絶好の機会となります。

Want to give it a try? Sign up or log into Confluence >>

Create a customer interview template to document your customer insights. Follow our tutorial to get started on conducting valuable customer interviews:

  • エンジニアリング作業を開始する前に、プロジェクト全体の細かい仕様が指定されている。
  • 作業を開始する前に、徹底的なレビューとすべてのチームからの厳格な承認が必要とされている。
  • デザイナーと開発者が要件の更新時期を把握していない。
  • そもそも要件が一度も更新されない (全員が要件を承認したため)。
  • チームが参加することなく、プロダクトオーナーが要件を記述した。 

これまでに、エンジニアやデザイナーと、ユーザーストーリーについて話し合いました。議論を重ね、さらにいくつかの側面を検討する必要があるという結論に達しました。 仮定事項を具体化し、全体の構想における位置付けについてよく考え、未解決の疑問を管理する必要があります。次に何をすればよいのでしょうか?

1 ページにまとめたダッシュボードで要件を簡潔に管理する

When writing a requirements document, it's helpful to use a consistent template across the team so everyone can follow along and give feedback. At Atlassian, we use Confluence to create product requirements with the product requirements document template. We've found that the section below provides "just enough" context to understand a project's requirements and its impact on users:

1. プロジェクトの仕様の定義
We recommend including high-level direction at the top of the page as follows:

  • 参加者: 誰が関与するのか? (プロダクトオーナー、チーム、利害関係者など)
  • ステータス: プログラムの現在の状態 (目標どおり、リスクあり、遅延、保留など)
  • リリース目標: プロジェクトの出荷時期
Agile requirements | Atlassian agile coach

2. チームのゴールとビジネス目標 

3. 背景と戦略的適合性

Agile product requirements | Atlassian agile coach

4. 前提条件

5. ユーザーストーリー

Agile requirements stories | Atlassian agile coach

6. ユーザーインタラクションとデザイン

7. 疑問点

8. What we're not doing 
Keep the team focused on the work at hand by clearly calling out what you're not doing. Flag things that are out of scope at the moment, but might be considered at a later time.

Pro Tip:

The agile manifesto reminds us that we can be flexible with how we create requirements. Some teams do user story mapping exercises to identify problems and solutions. Sometimes the full product triad (product owner, developer, and designer) visits a customer and then brainstorms solutions to a particular problem that the customer mentioned.


No matter how requirements are born, it's important that the team considers them to be one of many ways they can define and communicate customer problems. See our section on agile design to learn how product owners can use Keynote and Powerpoint to mock up real experiences as requirements. 

Example of a one-page PRD

Here's a look at a fully fleshed out product requirements document that we created using Confluence. Remember, no two product requirements will be exactly the same. Use this example to understand the different elements that should be included in your PRD, but not as the definitive way to do it. 

Example Product Requirements Document | Atlassian agile coach
Product Requirements Document | Atlassian agile coach

Want to give it a try? Sign up or log into Confluence >>

Once you're in, choose the product requirements blueprint and then follow the tutorial below to help you get started setting up your requirements:

Key takeaways from the one-page approach:

このブログから何かしら教訓を得ようとするなら、「何を」ではなく「なぜ」を理解しましょう。「なぜ」を追及することは、チームに最適な解を探すのに役立つからです。ここでは、1 ページにまとめたダッシュボードを使用するアプローチの利点と課題について説明します。

1. One page, one source
Keeping it simple. The product requirements document becomes the “landing page” for everything related to the set of problems within a particular epic. Having something that is the central go-to location saves your team members time in accessing this information and gives them a concise view.

2. 優れたアジリティ
One of the awesome things about using a simple page to collaborate (verses a dedicated requirements management tool) is that you can be agile about your documentation! You don’t have to follow the same format every time – do what you need, when you need it, and be agile about it. Chop and change as needed.

3. 適度なコンテキストと詳細
We often forget how powerful a simple link can be. We embed a lot of links within our product requirements documents. It helps abstract out the complexity and progressively disclose the information to the reader as needed. Linking detailed resources may include such things as:

  • フィーチャーの背景、検証、コンテキストを知るための顧客インタビュー
  • 類似するアイデアを提案しているページやブログ
  • これまでの話し合いでの資料、技術文書および図
  • 製品デモのビデオや、外部ソースからの他の関連するコンテンツ

4. ストーリーの活用
I see a lot of customers do this as well. Once the stories have been roughly thought out and entered as issues in Jira Software, we link to them in our page (which, conveniently, creates a link from the issues back to the page as well). The two-way syncing between Confluence and Jira Software means we automatically get to see each issue's current status right from the requirements page.

5. 集合知
Capturing product requirements in Confluence makes it easy for other people in different teams to contribute and make suggestions. I’ve been amazed at the number of times someone from another team jumped into the conversation with a comment providing great feedback, suggestions, or lessons learned from similar projects. It helps a large organization feel like a small team.

6. リソースの充実
Visio、Gliffy、Balsamiq のようなツールで作成した図を使用すると、チームに問題が伝わりやすくなります。その他のイメージ、ビデオ、ダイナミックコンテンツを組み込むことができます。

7. コラボレーション!
The most important aspect of all this is getting everyone involved. Never write a product requirements document by yourself – you should always have a developer with you and write it together. Share the page with your team and get feedback. Comment, ask questions, encourage others to contribute with thoughts and ideas. This is especially important for distributed teams who don't often get a chance to discuss projects in person.


どのようなアプローチにもマイナス面はあります。ここでは、私たちが経験した、また顧客において観察された 2 つの主な課題について説明します。

1. 文書の陳腐化

2. 不参加
「意見を出すように仕向けるにはどうすればよいのか?」、「どうすれば、イントラネットにもっと多くの仕様やストーリーを書き込ませることができるか?」といった疑問に対し、単純な答えはありません。Wiki の定着化手法は組織によってさまざまです。役立つリソースは多くあります。奥深い文化の問題もあるかもしれません。



Once a project's requirements are reasonably well-baked, we recommend linking the user stories in section 5 above to their corresponding stories in the development team's issue tracker. This makes the development process more transparent: it's easy to see the status of each piece of work, which makes for more informed decisions from the product owner, as well as downstream teams like marketing and support.


Don't track the user stories that come from project requirements in one system and defects in another. Managing work across two systems is needlessly challenging and just wastes time.

Remember, be agile in your evolution of requirements for a project. It's okay to change user stories as the team builds, ships, and gets feedback. Always maintain a high quality bar and a healthy engineering culture – even if it means shipping fewer features.