Visible to members of this folder

Front 1-Pager template

[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.

Security & compliance

Would this project lead to new ways of collecting, processing or storing PII? PII includes but is not limited to: a person’s name, an identification number, location data, an online identifier. New ways of processing or storing PII include utilizing new third party services.

If Yes, ask compliance@frontapp.com about GDPR compliance validation.

Would this project require parsing new types of user inputs or other user provided content, or would it require modifying the way such parsing is done? e.g. adding SVG as image format for avatars, adding support for WhatsApp incoming messages, modifying the mail parser library.

If Yes, ask security@frontapp.com for guidance and point of attention that would need to be tested.

Timeline

Discovery/research phase (If project requires deeper research)

[PM + Designer + Research] Research kickoff: define what we know, what we need to know, methods, participant group, roles and responsibilities, timing

[PM + Designer + Research] Prep / planning: create detailed Project Research Plan and iterate on study materials

[PM / Designer / Research] Recruit participants

[PM + Designer + Research] Conduct research; include key stakeholders

[PM / Designer / Research] Prepare and share results / deliverable

Solution phase

[Engineer + PM + Designer (+ Research, Data when applicable)] Project kickoff; PM presents problem to be solved and compiles any existing research. Align on why we’re building the feature in question + brainstorm solutions to be explored in the product spec.

[PM + Designer + Research] Plan Exploratory research as needed.

[PM] Product spec

[Engineer + PM + Designer + Data] Product spec sync. Address any questions or feedback on the product spec. Brainstorm solutions to be explored in the design phase, and discuss engineering limitations or challenges to be considered. Align on timeline for design implementation.

[Designer] Design spec

PM and engineering looped into design reviews whenever possible

[Engineer] Tech spec

Implementation phase

[Engineer + PM + Designer] Design + tech spec sync. Consider any design system additions or updates that need to be made, and whether newly introduced components or patterns are consistent with the existing system. Align on timeline + intermediate milestones for engineering implementation, based on what we want signals on early.

[PM + Designer + Research] Plan Validation research as needed.

[Engineer] Engineering implementation

[Engineer + PM + Designer] Periodically review intermediate milestones (depending on project)

[Engineer + PM + Designer] QA / bug bash (via meeting or async). Document and resolve bugs that are blockers to shipping internally or to customers. Re-assess launch timeline. QA should include validation of the compliance of the solution and tests against security risks previously identified.

[Engineer + PM] Internal Beta + resolve issues from internal beta.

Release phase

[Engineer + PM] Define rollout plan, e.g. put on beta for 1 week, test on Front company first, use LaunchDarkly to roll out on beta customers.

Documentation

Help Center

Trello board

Pre launch post

Changelog

Canned Responses

[PM + Designer + Research] Plan Listening research as needed.

(If necessary) [Engineering + PM + Designer] Retrospective; was the project successful? What went well? What didn’t go well? What did we learn?

Go To Market Summary

PMs should complete this form to give marketing and support the information they need to prepare before the launch of this feature. This form should be completed no less than three weeks prior to the feature being released to 50%+ of users.

THE BASICS (WHO? WHAT? WHEN? WHY?)
QUESTIONS	DETAILS
What are we releasing? Succinctly, what’s the new capability we’re introducing?
Demo instance Will the feature be pre-released in a demo instance so the PMM team and Help Center team can test and capture screenshots? If no, please advise on how to get screenshots or if they are even needed.	Yes Target date: No Process to capture screenshots:
New or improvement? Do you consider this a *new feature* or an *update* to an existing feature?	New feature Improvement on an existing capability Feature improved:
Which Front editions will have access to this? Please include any legacy plans, along with our current lineup: Starter/Prime/Enterprise	Current Front editions Starter Prime Enterprise
Reference documentation Please include links to any relevant reference documentations. Specifically, for the Help Center team, they need the documentation to show the *how-to* for this feature, which will be used as reference for creating the Instructions section of the help article.	Design Spec Research Brief Productboard URL Other: 1-pagers: Other:

— GO-TO-MARKET —
QUESTIONS	DETAILS
For external announcement, what tier would you place this feature? And for Internal enablement, what tier would you list this feature as? Please reference the tiering guide.	External GTM Tier 1 Tier 2 Tier 3 Tier 4 Internal Enablement Tier 1 Tier 2 Tier 3 Tier 4
Who will find the value from this release? General user or admins Specific use case Teams with X or Y workflow	General user List specific characteristics, if applicable: Admin List specific characteristics, if applicable:
Why does this release matter to the respective audience(s)? What’s worth focusing on relative to the status quo? What current pain does it solve?
What are the game-changing differentiators of this release? In what ways are we delivering something new to the market or a product that other companies haven’t been able to deliver? Be specific, if possible, on how this compares to offerings of our direct and in-direct competitors.
What are the key limitations of this release? What aspects of this product could our customers, the press or industry analysts view as falling short compared to other products on the market? Be specific and candid.
Do we have any customers available for a quote/case study we can reach out to?	Yes List customers/link to customer list: No

— HELP CENTER —
QUESTIONS	DETAILS
Does this feature require updates to the help center? If yes, fill out the remaining questions. If no, skip this section.	Yes, the Help Center needs to be updated No
Will you need a help center link to direct to from the app UI?	Yes No
Are there specific FAQs you anticipate or other important information to include in the help article?	Yes List the specific FAQs/other important information below (please include links to sections from existing help articles/docs as necessary: Item 1 Item 2 Etc. No
Will this feature be visible in HQ for troubleshooting customer questions? If yes, please document where to find the tooling in HQ and how to use it	Yes No
Does this feature require any internal-facing content that’d live on Guru? If yes, please elaborate.	Yes No

Research

As you compile the spec, document the resources/research you did.

Front 1-Pager template
[Save your 1-pagers in Product > Specs > [Product Area] folder]
Goal
Problem
Metrics of success
Out of scope
Spec
Product spec
Design spec
Technical spec
Architectural / design decisions
Infrastructure / Resources
Mobile impact
Debugging & HQ
Security & compliance
Timeline
Solution phase
Implementation phase
Release phase
Go To Market Summary
Research

​​Goal

​​Problem

​​Metrics of success

​​Out of scope

​​Spec

​​Product spec

​​Design spec

​​Technical spec

​​Timeline

​​Go To Market Summary

​​Research