Project Management for PMs

Company Vision

The vision is established by the CEO or founder. They set the long-term direction and overarching purpose for the company. This vision typically outlines where the company aims to be in the next 2, 3, or 5 years.

The vision serves as a guide for the entire organization, providing a clear destination that informs all strategic decisions and actions. It ensures that everyone in the company is aligned with the long-term objectives and understands the ultimate goals they are working towards.

Goals

Goals are specific targets that the company aims to achieve to realize its vision. These goals are more concrete and measurable than the vision.

An example of a goal might be to “increase new users by 5% this year.” This goal supports the broader vision by focusing on a quantifiable objective that can be tracked and measured.

Goals are decided by the company’s executives. They take the abstract vision and translate it into specific, actionable targets. These goals are often further broken down into metrics to facilitate tracking and measurement.

Initiatives

Initiatives are broad activities or projects that the company undertakes to achieve its goals. These are the high-level plans that outline what the company will do to reach its targets.

An example of an initiative might be to “translate the product into three additional languages this year.” This initiative directly supports the goal of increasing user growth by making the product accessible to a broader audience.

Releases

Releases are groupings of new features or functionalities that are launched to users at a specific time. They represent the tangible output of the company’s initiatives and are delivered in a coordinated manner.

Continuing with the translation initiative, a release might occur in February where all three new language options are made available to the public.

Epics

Epics are large bodies of work that can be broken down into smaller tasks or user stories. They are comprehensive projects that include multiple features or functionalities aimed at solving a significant user problem or achieving a specific business objective.

Examples of epics include “translate the app to Spanish,” “implement photo sharing in direct messages,” or “allow users to upgrade to a pro membership.”

Epics are critical for organizing and managing complex projects within product management. They start with a statement of the problem to be solved and outline the features or functionalities intended to address that problem.

Product managers use various tools such as minimum viable products (MVPs), customer interviews, and wireframing to make informed decisions about what features to build. These tools help ensure that the product development efforts are aligned with user needs and business goals.

Typically, a product team works on 3–5 epics per quarter. The exact number depends on the company’s size and the complexity of the epics. The effort required to complete an epic can vary, and this impacts how many epics a team can handle within a given timeframe.

Epics can be both user-facing and non-user-facing. User-facing epics might include features that directly impact the end user, such as “translate the app to Spanish” or “implement photo sharing in direct messages.” Non-user-facing epics involve internal improvements or technical upgrades, like “migrate data to a new database.”

An epic usually takes longer than one sprint to complete. Sprints are typically short development cycles, so anything that spans multiple sprints is considered an epic. If a piece of work is smaller and can be completed within a single sprint, it is categorized as a user story rather than an epic.

Creating and Managing Epics

Most project management software allows teams to create epics and add features to each epic. This software helps organize and track the progress of epics and ensures that all team members are aligned on what needs to be done.

Epics are accompanied by detailed documentation, often referred to as an Epic Spec Sheet or Requirements Document. This documentation outlines what the epic entails and why it is important. It serves as a reference for the entire team and ensures that everyone understands the goals and requirements of the epic.

Epic Spec Sheet (Requirements Document)

The purpose of the Epic Spec Sheet is to provide a comprehensive description of the epic, making it clear to all team members and stakeholders what is being built and why. It ensures transparency and alignment across the company.

Sections:

Introduction

• Summary: The introduction provides an overview of the feature(s) and explains their purpose.
• Metrics: It outlines the goals and metrics the epic aims to improve.
• Supporting Documents: This section may include links to additional documentation, such as marketing plans or legal requirements.

Product Requirements

• Details: This section delves into the specific features or functionalities being developed. It describes the performance criteria, language availability, and data storage needs.

Design Requirements

• Collaboration: Developed collaboratively by the PM and designers, this section emphasizes the design aspects of the epic.
• Content: It includes design specifications, high-resolution display requirements, wireframes, and design prototypes.

Engineering Requirements

• Technical Details: This section, filled out by engineers, covers the technical specifications needed to support the epic. It includes details like database requirements, API endpoints, and inter-team collaborations.

User Stories and Acceptance Criteria

User stories and acceptance criteria are crucial elements of the product development process, residing under epics. They transform high-level features into actionable tasks for developers.

User Stories

A user story is a simple, clear description of a feature from the perspective of the end user. It outlines what the user wants to achieve and why, without delving into how the functionality should be implemented.

Structure

User stories follow a specific format:

• Template: As a [user type], I want to [action], so that [benefit].
• Example: As a user, I want to send pictures in a direct message to my friends, so that I can share my favorite photos with them.

Purpose

• Clarity: Provides a clear understanding of the desired functionality from the user’s perspective.
• Focus: Keeps the development team focused on the user’s needs without specifying technical solutions.
• Communication: Serves as a communication tool between product managers (PMs) and the development team.

Role of Product Managers

Product managers (PMs) are responsible for writing user stories. Their goal is to define what the user needs and why, leaving the technical implementation to the developers. This separation ensures that the development team can use their expertise to determine the best way to achieve the functionality.

Acceptance Criteria

Acceptance criteria are a set of conditions that a feature must meet to be considered complete. They provide detailed requirements that ensure the feature works as intended and meets the user’s needs.

Structure

• Template: Given [context], when [action], then [outcome].

Example:

• Given I am a user and I click the add picture button in the direct message, I am presented with a pop-up window to choose the file I can upload, submit it with the upload button, and see a preview of the uploaded image.
• Given I am a user who has successfully uploaded a photo from my computer, when I click send, the image is sent to my friend through the direct message and it appears in the chat.

Purpose

• Specificity: Provides precise details on how the feature should function.
• Testability: Facilitates testing by defining clear conditions that must be met.
• Quality Assurance: Ensures that the feature works correctly and meets the user’s needs before it is considered complete.

Workflow in Project Management Tools

User stories and acceptance criteria are managed using project management tools like JIRA. These tools help organize and track tasks, facilitating smooth workflow and collaboration among team members.

Key Components

Backlog:

A repository for tasks and user stories that are planned for future work but are not yet being worked on.

Sprints:

Time-boxed periods (commonly two weeks) during which specific tasks from the backlog are worked on. At the end of each sprint, progress is reviewed, and new tasks are planned for the next sprint.

Tickets:

Represent individual tasks or user stories. They include all relevant details, such as user stories, acceptance criteria, and any additional information like wireframes or design specifications.

Statuses:

Tickets move through various statuses such as “to do,” “in progress,” and “done” to track progress.

Example in JIRA

Backlog Management:

• Backlog: Contains all planned tasks.
• Sprints: Tasks are moved from the backlog into sprints for active development.

Creating a Sprint:

• Start Sprint: Define the duration (typically two weeks) and select tasks to be included.

Active Sprints Area:

• To Do: Tasks that are ready to be started.
• In Progress: Tasks currently being worked on.
• Done: Completed tasks.

Ticket Details:

• User Story: Describes the feature from the user’s perspective.
• Acceptance Criteria: Specifies the conditions for feature completion.
• Attachments: Can include wireframes, design mocks, and other relevant documentation.

Engineer Workflow:

• Engineers pick up tasks from the “to do” column, move them to “in progress” while working on them, and then to “done” once completed.

Quality Assurance (QA):

• Some teams include a “QA” or “Testing” status before “done” for additional validation.

Epic Management

Epics are high-level containers that group related user stories and tasks. They provide a broader context and ensure that all related tasks contribute towards a larger goal.

Components of an Epic

Introduction:

• Purpose: Provides an overview of the feature and its objectives.
• Example: “This feature will allow users to send photos to each other through direct messages.”

Product Requirements:

• Details: Specific functionalities based on user needs and data.
• Example: Users can initiate a photo message, select a photo from their device, and preview it before sending.

Design Requirements:

• Wireframes and Design Specs: Include detailed design specifications, often created by UI/UX designers.
• Example: The photo preview should be 300x300 pixels.

Engineering Requirements:

• Technical Specifications: Define the technical aspects and requirements for implementing the feature.
• Example: Create a scalable photo database capable of storing 100 million images.

Epic Workflow

Epic Spec Sheet:

Contains all relevant details about the epic, including introduction, product requirements, design requirements, and engineering requirements.

Creating and Managing Epics in JIRA:

• Backlog Screen: Epics are visible and can be managed directly from the backlog.
• Epic Details: Clicking on an epic shows all related user stories and tasks, along with their status.

Assigning Tasks to Epics:

• Tasks are linked to epics to ensure they contribute towards the larger goal.
• Engineers and designers can refer to the epic spec sheet for context and guidance.

Software Estimation and Roadmapping

Estimating the time it takes to complete a software project, is crucial for effective planning and execution. This estimation process is closely tied to road mapping, which outlines the timeline and milestones for a project. Before diving into road mapping, it’s essential to understand the challenges and methodologies involved in software estimation. Unlike replacing a car engine, where the task is straightforward and has been done multiple times, software projects often involve new and unique challenges.

To grasp the complexities of software estimation, consider a real-world analogy involving mechanics and custom cars.

Familiar Task

• Scenario: A mechanic is asked to replace an engine in a BMW.
• Expertise: If the mechanic specializes in BMWs and has performed this task multiple times, they can accurately estimate the time needed (e.g., six hours or one day).

Unfamiliar Task

• Scenario: A mechanic is asked to work on a completely custom-built car.
• Complexity: Since the car is unique and built from various parts, the mechanic cannot give a precise estimate without first understanding its intricacies.
• Estimation Challenge: The best approach is to give a conservative estimate, such as a week, and adjust it as the work progresses.

Challenges in Software Estimation

• Uniqueness: Each software system is unique, often built with different technologies and approaches.
• Constant Change: Software codebases change frequently, with multiple engineers modifying the code.
• Complexity: Software systems have many interconnected components, making it hard to predict the time required for changes accurately.

Velocity and Sprint Planning

To achieve more accurate estimations, teams use the concept of velocity, which is integral to Agile methodologies like Scrum.

Sprint Planning

• Sprint: A time-boxed period (e.g., two weeks) during which a set amount of work is completed.
• Sprint Planning Meeting: Engineers estimate the effort required for user stories (tasks) in the upcoming sprint.

Story Points

• Measurement: Engineers assign story points to user stories based on their difficulty, not time.
• Scales: Different teams use various scales (e.g., 1–5, Fibonacci sequence) to rate difficulty consistently.

Calculating Velocity

• Completion: At the end of a sprint, the number of completed story points determines the sprint’s velocity.
• Example: If three user stories with a total of 15 story points are completed, the velocity is 15.

Averaging Velocity

• Long-Term Accuracy: By averaging the velocities of several sprints, teams can better predict future work completion rates.
• Estimation: This average velocity helps estimate the time needed for future tasks based on their story points.

Using Velocity for Estimation

• Short-Term: Use recent velocity data to predict the workload for the next sprint.
• Long-Term: Average velocities over multiple sprints to forecast the time needed for future tasks more accurately.

Adjusting Estimates

• Continuous Improvement: Regularly update and adjust estimates based on actual performance and changes in the codebase.

Roadmapping in Agile Development

Roadmaps provide a strategic overview of the planned work and goals over time. However, they are often inaccurate due to the nature of Agile development, which focuses on adaptability and iterative progress.

Traditional Roadmaps

• Inaccuracy: Predicting work several months in advance is difficult.
• Agility: Agile methods prioritize flexibility, making it hard to commit to fixed deadlines.
• Fixed Dates: Roadmaps with quarterly or monthly milestones are common but often inaccurate due to the dynamic nature of Agile development.
• Executive Expectations: These roadmaps cater to executives and investors who prefer seeing structured timelines.

Agile Roadmaps

• Flexibility: Agile roadmaps focus on priorities rather than fixed dates.
• Buckets: Tasks are categorized into near-term, midterm, and long-term priorities, allowing for adjustments based on project progress and external factors.

Practical Roadmapping Approaches

Near-Term, Mid-Term, Long-Term

• Near-Term: Immediate tasks to be completed in the next few weeks.
• Mid-Term: Upcoming tasks for the next few months.
• Long-Term: Future goals and tasks without a specific timeline.

Communication and Flexibility

• Executive Expectations: Communicate the inherent uncertainties in roadmaps to stakeholders.
• Adaptability: Adjust the roadmap as new information and priorities emerge.

Prioritizing Work in Product Management

Prioritization is crucial for ensuring that the most valuable and critical tasks are completed first. It involves balancing various factors like business needs, user benefits, and technical constraints.

Prioritization Methods

1. Assumption Testing

• Definition: Focuses on validating the riskiest assumptions first.
• Process: Assign scores based on risk and importance, then prioritize tasks with the highest combined scores.

2. BUC Method (Business Benefits, User Benefits, Cost)

• Scoring: Assign scores for business benefits, user benefits, and costs.
• Calculation: Add benefits scores and subtract the cost score to determine the priority.

3. MoSCoW Method (Must, Should, Could, Would)

• Must: Essential tasks that cannot be deferred.
• Should: Important tasks that should be done but are not critical.
• Could: Desirable tasks that can be done if time and resources permit.
• Would: Tasks that can be deferred or are nice-to-have.

4. Contextual Prioritization

• Dynamic Factors: Adjust priorities based on market conditions, technological advancements, and internal company changes.
• Risk-Taking: Encourage creativity and risk-taking when possible, especially in companies with the financial stability to support it.