[Save your 1-pagers in Product > Specs >[Product Area] folder]
Product Manager: Name[of main PM]
Designer: Name[of main designer]
Engineer: Name[of main engineer]
Link to Jira Epic:[Should be the main tracking Epic, not individual tasks]
Goal
What is our high level goal for this project? e.g. drive core feature engagement, increase NPS.
Problem
Describe the problem we’re solving and why we’re solving it. Is there a target user or use case in mind? Explain all facets of the problem and how if affects different parts of Front. A well understood problem should be easy to articulate.
Metrics of success
[Loop in data@ when you write this section!]
What does success look like? What are the expected outcomes? This should include:
Qualitative success. e.g. customers using Front for support can now get back to clients who have been waiting the longest; customers automatically have their inbox history imported and no longer have to email support for it.
Quantitative metric, where possible. e.g. median convo load time is <400ms; 30% of enterprise plan customers use it; greater % of customers invite at least 1 teammate within 14 days.
Out of scope
What are non-goals?
Spec
Specification for what we will build. Depending on the nature of this project, some or all of these 3 specs may apply.
Decide which of the 3 types of specs are needed for a given project. As a general guideline, if it’s customer visible, it will need at least a product spec. If there are UI changes, it will need a design spec. If it’s an infrastructure project, it may only need a technical spec.
If the spec is short, write it below. If the spec is long, link to a separate doc.
If applicable, specs should define behavior on all platforms(Desktop, Android, iOS)
If you’re not 100% if your changes will impact mobile, please ask the mobile team!
Product spec
Written by Product Manager. This should describe the app behavior that the user will experience when interacting with the feature. This may include low fidelity mocks to suggest design options. If applicable, it should also describe ideas for future versions(V2+) of this feature and even the long term vision. It should be clear that these are beyond V1 scope.
Design spec
Written by Designer. This should include high fidelity mocks and notes to describe the precise design behavior when a user interacts with the feature.
Technical spec
Written by Engineer. This should include:
Key technical decisions and architectural choices, including any technical unknowns or dependencies(enough detail for review by tech lead or other engineers)
Plan for alerts and monitoring
Security and compliance
Architectural / design decisions
Typically, most decisions will be made in partnership with your tech lead. However, should you or your tech lead need additional guidance or broader consensus, e.g. if the decision could impact other teams, start a discussion in the Eng Architecture inbox in Front to get cross-team #collaboration on the decision.
Infrastructure / Resources
Are new DB tables needed? Are modifications to existing tables needed?
If Yes, please follow guidelines in our data schema template. Inform your data team partner of the changes in the #data-general slack channel.
What is the estimated impact on our existing infrastructure components?
Will new components or resources be required?
Will current resources need to be resized or updated because of larger storage footprint? Involve the infra team if capacity planning help is needed
Mobile impact
Please involve the mobile team if new routes and/or new attributes are added to JSON. Mobile uses typed languages and local databases, so an early architecture discussion could save time!
Debugging & HQ
Please think about how you will be able to debug this feature, the kind of information you will need to add in HQ, and if there is any runbook needed, to help your peers at Front troubleshoot issues when they are on-call.
Goal
Problem
Metrics of success
Out of scope
Spec
Product spec
Design spec
Technical spec