Square’s PRD Template

Problem Alignment

Describe the problem we are trying to solve in 1-2 sentences. I should be able to read this alone and communicate the value/risks to someone else.

Why does this matter to our customers and business?
What evidence or insights do you have to support this?

High Level Approach

Describe the rough shape of how we might tackle the problem. I should be able to squint my eyes and see the same shape. For example, if the problem was “discoverability of new features”, then this might be “a notification center for relevant features”.

Narrative

Optional: Share (hypothetical) stories to paint a picture of what life looks like for customers today. Describe common and edgy use cases to consider when designing the solution.

Goals

Describe high-level goals, ideally in priority order and not too many.
Include measurable (metrics) and immeasurable (feelings) goals
Keep it short and sweet

Non-goals

List explicit areas we do not plan to address
Explain why they are not goals
These are as important and clarifying as the goals

🛑 Do not continue if all contributors are not aligned on the problem.

🟢 Complete the following table with “signatures” from all reviewers to move on.

REVIEWER	TEAM/ROLE	STATUS

Solution Alignment

✅ Draw the perimeter	🚫 Do not force others to identify scope

Key Features

Plan of record

List the features that shape the solution
Ideally in priority order
Think of this like drawing the perimeter of the solution space
Draw the boundaries so the team can focus on how to fill it in
Link out to sub-docs for more detail for particularly large projects
Challenge the size to see if a smaller component can be shipped independently

Future considerations

Optionally list features you are saving for later
These might inform how you build now

Key Flows

Show what the end-to-end experience will be for customers. This could be written prose, a flow diagram, screenshots, or design explorations. It will vary by project and team. Do not try to do this in isolation. Work with design and engineering to complete.

It is natural for this section to become more specific over time. It might start as a few annotated screenshots or stories. It might become highly detailed requirements with acceptance criteria. Adjust to the way your team operates. If you have a strong designer who enjoys going into every edge case, lean on them. If you have detailed engineers who prefer to have each scenario documented, go deep on acceptance criteria.

This will naturally change over time — that’s okay. When changes occur, document them in the Changelog and notify all contributors.

Key Logic

List rules to guide design and development
Address common scenarios and edge cases
It is often easier to write these out than rely on design to show every permutation

🛑 Do not continue if all contributors are not aligned on the problem.

🟢 Complete the following table with “signatures” from all reviewers to move on.

REVIEWER	TEAM/ROLE	STATUS

Launch Plan

Define the various phases that will get this product to market, the purpose of each phase, and the criteria you must meet to move on to the next one. Highlight risks and dependencies that can throw a wrench in timelines or progress (and ideally contingency plans). There is a table of example phases below.

Key Milestones

TARGET DATE	MILESTONE	DESCRIPTION	EXIT CRITERIA
YYYY-MM-DD	✅ Pilot	Internal testing with employees only	No P0 or P1 bugs on a rolling 7-day basis
YYYY-MM-DD	🛑 Beta	Early cohort of 20 customers	At least 10 customers would be disappointed if we took it away
YYYY-MM-DD	🛑 Early Access	Invite-only customers from sales	At least 1 win from every major competitor
YYYY-MM-DD	🛑 Launch	All customers in current markets	Measure and monitor

Operational Checklist

TEAM	PROMPT	Y/N	ACTION (if yes)
Analytics	Do you need additional tracking?		Work with [person] on logging
Sales	Do you need sales enablement materials?		Work with [person]
Marketing	Does this impact shared KPI?		Work with [person] on goal adjustment
Customer Success	Do you need to update support content or training?		Work with [person] on updates
Product Marketing	Do you need a GTM plan? (e.g. pricing, packaging, positioning,		Work with [person] with at least [x] weeks notice to kickoff workstreams
Partners	Will this impact any external partners?		Work with [person] on communication plan
Globalization	Are you launching in multiple countries?		Work with [person]
Risk	Does this expose a risk vector?		Work with [person]
Legal	Are there potential legal ramifications?		Work with [person]

Appendix

Changelog

List key decisions or updates you make for future reference. Include who was involved and link to notes doc, if relevant. Recommend moving this up top once approved so changes are more visible.

DATE	DESCRIPTION

Open Questions

Track open questions and answers here.

FAQs

Optional: Include an FAQ when helpful to answer high level questions so it is easier for people to grasp the point of the project without getting lost in the details of product definition.

Impact Checklist

Permissions
Reporting
Pricing
API
Global