Open Design Docs

Product Spec

A well-written product specification is crucial for aligning teams and ensuring successful product development. This document should be completed prior to project kickoff and aligned cross-functionally.

Problem Overview

Describe the problem (or opportunity) you’re trying to solve.

  • Why does this matter to our customers and business?
  • What business needs, research, or customer feedback, if any, led to this project?
  • Do any previous projects relate to this one and, if so, how did they go and what did your team learn?

High-Level Approach

Briefly describe how the team might solve the problem. This should be enough for the reader to imagine possible solution directions and get a rough sense of the project’s scope. For example, if the problem is “discoverability of new features,” the approach might be “a notification center for relevant features.”

Goals and Success

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

Deliverables and Constraints

List the deliverables that need to be handed off to engineering. Note any constraints the team should be aware of before starting the project. This could include Figma files, prototypes, animations, or illustrations.

Target Audience

Describe the target audience or persona critical for project success. Are there any insights into relevant audience demographics to produce the best work possible? Defining your target audience early can also prevent scope creep.

Project Timeline

A project timeline gives the team a clear idea of key dates and important milestones. The timeline should include:

  • Kickoff
  • Wireframe review (if necessary per t-shirt sizing)
  • Product review (for medium to large projects)
  • Design review
  • Handoff
  • QA
  • Launch

Additional Resources and Stakeholders

Link any relevant documentation your team might need. Include any stakeholders from other squads that need to be involved in the project. Consider whether these stakeholders should be at the project kickoff as well.

Please bring this to Product Review prior to proceeding for all medium or large-sized projects.

Problem Alignment Approval

List any Shipping Dept member who needs to approve the Problem Alignment. This could be a manager, cross-team PM, or executive. Each person will check their name off once they have approved.

  • Name 1
  • Name 2
  • Name 3

Solution Alignment

Key Features

Provide an overview of what we’re building. List features, with priorities if relevant. Discuss what you’re not building (or saving for a future release) if relevant.

Key Flows

Show the end-to-end experience for customers. This could be written prose, a flow diagram, screenshots, or design explorations. This will become more specific over time. Embed the Figma file here, not just links.

Open Issues or Decisions

Keep track of open issues or key decisions here. Document these so people know the discussions have happened and there’s strong awareness of the tradeoffs.

Launch Plan

Define the phases (if necessary) that will get this product to market, the purpose of each phase, and the criteria to move on to the next one. Highlight risks and dependencies that can affect timelines or progress (and ideally contingency plans). Below is a table of example phases.

Solution Alignment Approval

List any Shipping Dept member who needs to approve the Solution Alignment. This could be a manager, cross-team PM, or executive. Each person will check their name off once they have approved.

  • Name 1
  • Name 2
  • Name 3

Appendix

Get unlimited free access

Essential resources for design leaders

Leadership guides and templates
Exclusive design case studies
Regular updates with new content
We respect your privacy. No spam, ever. Unsubscribe anytime.

Get unlimited free access

Essential resources for design leaders

Leadership guides and templates
Exclusive design case studies
Regular updates with new content
We respect your privacy. No spam, ever. Unsubscribe anytime.