Templates & frameworks

PAR (Problem, Action, Result)

Credit: A well-known framework often mentioned in job interview articles. 

Why it's helpful: Ensure you're telling a clear, compelling story about your work and why it matters to the business and your users. 

When to use it: We found this particularly helpful for team demos - the time when our agile teams shared their work with the full company to promote shared understanding of wins, losses, and learnings. Also helpful for interviewing!

How to use it: 

  • Problem: "The problem we were trying to solve was (insert user and/or business problem) ... and we knew it was a problem because (insert qual or quant data)."

  • Action: What did you do about the problem? Describe hypotheses, tests (qual or quant), your problem-solving approach including designs and/or code, etc.

  • Result: What was the impact? Did you solve the problem? How do you know? Share metrics you moved (or didn't), and/or any insights you learned.

Note: Parts of this originally appeared in my blog post for Code Fellows.

People problems (aka Facebook's 3 question model)

Credit: Julie Zhuo's excellent talk "How a Facebook Designer Thinks" (highly recommend!)

Why: Make sure you're focusing on real, impactful problems - to avoid wasting time or effort. It also helps teams understand what they're building, for whom, and why. 

When to use it: Anytime you’re starting or working on a project. We used it on our roadmaps, when sprint planning, and in our feature and bug tickets.

How: 

  1. What is the people problem you’re trying to solve? Who are your users and what are their specific problems, needs, and goals? What problem are you focusing on?

  2. How do you know it’s a real problem worth solving? Teams’ backlogs are filled with problems and ideas! What qualitative (e.g. user research) and quantitative data (e.g. site analytics) do you have to show this problem is big enough that you should tackle it over all the other problems out there?

  3. How will we know when we’ve solved it? Make sure you have a clear idea of what success looks like for your users and your team. Agree on success metrics and go / no-go criteria before you start the (research / test / building the product) -- otherwise there are a host of biases that will color your perception after you've started.

Note: Parts of this originally appeared in my blog post for Code Fellows.

Describing the work (aka Jira ticket templates)

Credit: Not new ideas! These are the templates my team created for our needs. The goal was to get as much info up front as possible and avoid unnecessary back and forth.

Bugs

How we used this: this was a template in Jira, used by our team or by external stakeholders (e.g. the Sales Ops team) if they noticed a bug. 

Template:

  • Steps we need to reproduce the bug: Add the steps to reproduce the bug including relevant URLs and the browser used. Please avoid acronyms! (e.g. Salesforce not SF)

    • Steps =

    • URL =

    • Browser =

    • Attach screenshots including URL if possible!

    • Attach CSV (if applicable)

  • Expected behavior: Add the expected / usual behavior here

  • Actual/observed behavior: Add the bug that was observed. Include any error messages or explain any attached files or screenshots

  • Is this isolated or widespread? Is this affecting one, some, or all users? This helps us triage and prioritize.

  • What's the impact? What is the impact to end users, internal users, the business (revenue), etc.

 

Feature enhancements

How we used this: This was a template in JIRA, used by our team and especially by external stakeholders (Sales, Marketing, etc.) who were requesting new work from our team. 

Template:

  • What is the problem you're trying to solve or the goal you're trying to achieve? This is the most important part! If you have a specific way you think it should be solved, include that, but it is critical that we understand the problem and goal.

  • Impact to end users? How many users does this affect (isolated or widespread)? Describe the impact to users - consumers, providers, employees, etc.

  • Impact to the business? How will doing this work benefit the business? E.g. revenue, cost savings, etc.

  • Is there a cost savings / advantage to doing this work now vs. later? Will the problem get worse / better / stay the same over time? Will the opportunity change over time?

  • Definition of done / exit criteria: What does "done" look like?

 

Tech debt

How we used this: This was a template in JIRA, used mostly by developers and product managers, to describe new or existing tech debt. We would then discuss these in Backlog Grooming and decide what to do: won't fix or prioritize in our queue. 

Template:

  • Problem to solve / goal to achieve: What's the issue? What's the goal?

  • Impact to end user? If applicable, describe the impact to consumers and/or providers

  • Impact to business? E.g. developer time, stability, cost savings, revenue, etc.

  • Impact to developers? E.g. time, efficiency, frustration/happiness, etc.

  • Is there a cost savings to doing this work now vs. later? Will the problem get worse or take more dev time if we defer this?

  • Work to be done: If known, include high level description of the work

  • Definition of done / exit criteria: What does "done" look like?

Simple test plan

Credit: Not a new idea! But this was the template our UX & Product folks used at Avvo.

How we used this: Quick and dirty test plans which are then easy to share with anyone who needs to know what you're testing, why, and the result/learnings. 

  • Observations / Data: Include qual and quant. This can be lightweight!

  • Hypotheses: Based on the data, what is your hypothesis?

  • Test design: Can include content, design mocks, logistics of the test, etc. This can be lightweight - just a breadcrumb for future testing.

  • Success metrics and go / no-go criteria: Critical to define these before you start the test! Hindsight bias is real!! What success metrics are you tracking? What would need to happen for you to move forward with this path after the test (go / no go)?

  • Results: What happened? What did you learn? Don't forget to fill this out - it will help future "you," teammates, and tests.

DUHB (Data, Understandings, Hypotheses, Bets)

How we used this: As a decision-making framework across the company. It's a helpful guide through any big question/problem you are thinking about. I've used this in my personal life too! 

Credit: Cassondra Copeland & Kevin Goldsmith (both formerly at Avvo)

Template:

  • Data: Include qual and quant data, internal and external.

  • Understandings: What are your top insights out of the data? Can be lightweight (1-3).

  • Hypotheses: Based on those understandings, what are your hypotheses? Can be one or multiple, does not have to be 1:1 with understandings.

  • Bets/tests: What are some lightweight "bets" you can try out to prove/disprove your hypotheses before you fully invest in this direction? Can be one or multiple!

Project brief

How we used this: As product managers, we wrote these to get our team on the same page and to keep all project info/links in one place so it was easy for teammates or stakeholders to find the info they needed.

Credit: Not new ideas, but my Group Product Manager and I came up with this specific template for our team.

Template:

Background and problem to solve

  • Short description

  • What are the specific problems or pain points to be addressed?

    • Consumer

    • Provider

    • Company

  • Data: How do we know this is a real problem worth prioritizing?

    • As always, consider internal and external data, qualitative and quantitative data

  • Is there any history the team needs to know about? (past projects, past tests, subject matter experts, etc.)

  • Competitive landscape: What alternatives and/or best in class examples are out there?

  • Assumptions and/or hypotheses

Approach: Tenets, scope, success metrics

  • Project tenets

  • Scope and definition of done

  • How will we measure success? (learnings, metrics, revenue strategy, etc.)

  • What teams / systems will be affected? Any dependencies to call out?

Execution: Team, checklists, milestones

  • Core team

  • Stakeholders and informed teams

  • Milestones and/or checklist as appropriate

  • Project documentation (include relevant links such as test plans, decisions, designs, FAQs, etc.)

Results and analysis

  • Include final metrics, learnings, decisions (e.g. go / no-go, future versions), final product documentation, etc.

Feature announcement

How we used this: Internal announcement (often email) of new features or products.

Template:

Subject line: NEW - [feature/change] launching to [users group] on [date]

Hi there,

[Team name] is launching [new feature / change] on [day/time] which will [impact]. Details below!

  • Problem to solve & why it matters: Describe the problem to solve or the goal you were trying to achieve with this new feature. It’s usually most compelling if this is framed as a people problem (as a user, it is hard/frustrating… etc.). Make sure to include the “why” — what’s the impact of the problem/goal.

  • What’s new: Describe your new feature or change.

  • Timing: Especially important for teams like Sales, Customer Care, Marketing, etc. to know when this change will go live.

  • FAQ: You can include Q&A right in the email (if it’s really important that the full audience see them) or link to FAQs for those who want/need to know more.

  • High-fives: Celebrate your teammates! I always try to include the names of individuals and/or teams who helped make this possible.

  • Questions or feedback? Include the best way to contact the team (e.g. Slack channel, email alias, survey, shared document, etc.). It’s almost always best to use a shared channel to avoid one person being responsible (and a bottleneck) for receiving and sharing the learnings.

Thanks!
[Your name] & [team name]