As a product manager, one of your key responsibilities is to bridge the gap between the user's needs and the engineering team's technical capabilities. A well-written user story can serve as a powerful tool to effectively communicate the requirements and expectations to engineers. In this blog post, we'll explore the essential steps that a product manager should follow to write a good user story that empowers engineers to deliver high-quality products.

1. Understand the User's Perspective

The first and most crucial step in writing a user story is gaining a deep understanding of the user's needs, pain points, and goals. Engage in user research, conduct interviews, and analyze user feedback to uncover valuable insights. By empathizing with the end-users, you'll be able to identify the core features and functionalities that will address their problems effectively.

2. Define the User Persona

To ensure that the user story resonates with the engineering team, it is essential to establish a clear user persona. A user persona represents a fictional character that embodies the characteristics and behaviors of your target audience. By providing specific details about the user, such as demographics, goals, and challenges, you paint a vivid picture for the engineers, helping them understand the context and purpose of the user story.

3. Follow the INVEST Principles

User stories should adhere to the INVEST principles to be effective. INVEST stands for:

  • Independent: stories might be grouped into epics, but each story needs a distinct start and end point, and each story should be executable by an individual developer
  • Negotiable: good user stories focus on goals and constraints but leave the "how" to the discretion of the developer; the dev can work out details with the product manager rather than be micromanaged by someone who doesn't even code.
  • Valuable: each story need not have a result obvious to the end-user, but each story must advance toward some particular goal.
  • Estimable: stories must be concise and straightforward enough that, with practice, devs and product managers can estimate how much work is required.
  • Small: stories should not take longer than the unit of time used to measure them. Put another way, if work is measured in sprints, then no story should take more than one sprint to complete. If it does, it's too big. Break it down.
  • Testable: the result of each story should be some change to the system that can be tested and validated.

By incorporating these principles into your user stories, you ensure that they are independent from other stories, open to negotiation for further refinement, deliver value to the user, can be estimated for effort and complexity, broken down into smaller manageable tasks, and testable to validate their implementation.

4. Utilize the "As a... I want... So that..." Format

The "As a... I want... So that..." format is a widely adopted structure for user stories. It provides a concise and structured framework that captures the user, their goal, and the expected outcome. By using this format, you can clearly articulate the user's perspective, the desired functionality, and the underlying motivation behind it. For example, "As a frequent traveler, I want to be able to save my payment information securely so that I can book flights quickly and easily." This gives everybody looking at the story basic context for understanding what follows. Acceptance criteria should tie back to this initial statement.

5. Prioritize and Refine User Stories

Once you have a collection of user stories, it is essential to prioritize them based on their impact and value to the user. Prioritization allows the engineering team to focus on the most critical features and deliver them incrementally. Additionally, engage in continuous refinement and iteration of user stories in collaboration with the engineering team. This iterative process helps to clarify requirements, address any ambiguities, and ensure alignment between product management and engineering.

6. Include Acceptance Criteria

To ensure a shared understanding between the product manager and the engineering team, user stories should include clear and concise acceptance criteria. Acceptance criteria define the conditions that must be met for a user story to be considered complete. They outline specific scenarios, expected behaviors, and success criteria that allow the engineering team to validate their implementation. Well-defined acceptance criteria eliminate ambiguity and enable more accurate estimations and testing.

I really like to use the MSCW format (pronounced "Moscow") because it forces me, the product manager, to think about goals and constraints, leaving the developer with a free hand to solve the problem. MSCW format means specifying criteria under four headings: Must Haves, Should Haves, Could Haves, and Won't Haves. For example, I might put the following criteria under these headings:

"As a user I want a way to manually update my user settings so I can keep it up to date at my discretion."

- A user settings panel
- An easy way to edit each user-specific, writeable field
- Clear indication of fields that are read-only
- A way to save changes that requires confirmation

- Follow all existing design standards

- Can dispense with confirmation modal if UX team thinks it unnecessary

- Profile pic; this will be on the Profile page.

7. Foster Collaboration and Communication

Effective collaboration and communication between the product manager and the engineering team are crucial for successful implementation of user stories. Encourage an open and transparent environment, where engineers can ask questions, seek clarification, and provide feedback. Regular meetings, such as sprint planning sessions, stand-ups, and retrospectives, facilitate collaboration and allow for continuous improvement.


Crafting user stories that effectively communicate user needs to engineers is a vital skill for any product manager. By following the steps outlined in this guide, you can write user stories that provide developers everything they need to succeed, both parameters for success and freedom to experiment and problem-solve, while ensuring the final result matches your expectations and fulfills the needs of your users.