Product Management
Requirement Writing
154 people are learning this skill right now!
Requirement writing includes 1) communicating the meaning and background of a project (via specs, one pagers, or product requirement documents / PRDs) and 2) explaining tasks (which can be stand-alone or within a project), including as User Stories or Job Stories.
Learn Requirement Writing with the Practica AI Coach
The Practica AI Coach helps you improve in Requirement Writing by using your current work challenges as opportunities to improve. The AI Coach will ask you questions, instruct you on concepts and tactics, and give you feedback as you make progress.Project / Epic Documentation
To ensure a successful software development project, it is crucial to have clear and concise documentation of the project and its objectives. This documentation should include a high-level overview of the project, known as an epic, which outlines the project goals and requirements. This epic should be regularly reviewed and updated throughout the project to ensure that it aligns with the project's evolving needs and objectives.
On Writing Product SpecsGaurav argues that especially at larger companies, writing a comprehensive spec (in the vein of Amazon & Ben Horowitz) has the benefits of moving critical thinking up front, communicating efficiently, and raising Accountability. Gaurav then provides an in-depth example.
How to Write a Spec: Asana’s Spec Template & Spec TrainingAsana's project template is more detailed than the Atlassian team poster. It starts with sections for Background, Problems, Goals, Vision, and Hypotheses, and then digs into a proposal with concept mocks.
Great One PagersJohn explains how to focus on problems rather than narrowly-defined solutions in a project one-pager, and provides 17 different possible sections to include.
Atlassian Team Playbook: Project PosterAtlassian's project poster template focuses on understanding: 1) What problem you're solving and why it matters to customers 2) Assumptions that guide the project, and how they've been validated
Task / User Story Documentation
In addition to the epic, it is important to have detailed documentation of the tasks and user stories that make up the project. User stories should be written from the perspective of the end user and should clearly outline what the user needs and how they will interact with the software. Tasks should be broken down into smaller, manageable pieces and should be assigned to specific team members to ensure that everyone is working towards the same goals.
A Framework for Modern User StoriesThe traditional user story is written as: "As a <persona>, I want <goal/desire> so that <benefit>" Jon builds on this format by adding User Scenarios, in order to provide more detail to anyone building a user story.
Delivering Value with User Stories - the Ultimate Conversation StarterDarien adds more details on how to write user stories and use them as conversation starters, with elements such as: 1. Value statement 2. List of functional requirements 3. List of acceptability requirements 4. Simple spec 5. Wireframes/mockups
How We Accidentally Invented Job StoriesPaul argues that the persona aspects of user stories ("As a <persona>") are too specific and do not actually map to behaviors. Behaviors can span demographics, so Intercom introduced a new format based on behaviors: [ When _____ ] [ I want to _____ ] [So I can _____ ]
GitLab's User Story Mapping Training VideoJames and the team at GitLab explain how user story mapping with an example in this video. It includes how to think about the flow of user stories in a time-based sequence, and how to prioritize within the user stories.
PRD Templates
Product Requirements Documents (PRDs) are an essential tool for ensuring that everyone involved in a software development project is on the same page. PRDs should include detailed information about the project, including user stories, tasks, and acceptance criteria. There are many different PRD templates available, and it is important to choose one that aligns with the specific needs of the project. PRDs should be regularly reviewed and updated throughout the project to ensure that they accurately reflect the project's evolving needs and objectives.
