How do I write PRDs and user stories today, and how did I get there?

The beginning

I got into product management unintentionally and unofficially. As a co-founding CTO of a software startup, I practiced product management with know that it is product management: I decided what our app would look like, how it would behave, and supplied developers and designers with instructions on what to build next. At the time, while working with experienced mentors in a startup accelerator we were part of, I came to learn that all these practices are commonly known as Product Management.

When I started to look for my first ‘official’ PM position I knew I needed to catch up with proper terminology and improve my practices, and I did so. However, I did not strictly follow any format when communicating product requirements to developers, designers, and QA.

This worked ok for more than a year. Often, during retrospectives, developers and QA noted that not all the tasks were clear enough and that they had to go back to me for clarifications. As a squad, we tried to reduce the frequency of such miscommunications in different ways. We succeeded to some degree, but once in a while, someone was complaining about not-clear-enough tasks. It looked like such miscommunications just come with the territory, and there is not much more that we could do.

A new dev-lead

In March 2020, a new dev-lead, Shay, joined the squad and the company. Coming from a large corporate with experience as a Scrum Master, he gently insisted that by the time Jira tickets get to developers and QA, tickets should follow a strict format with two parts. The first part should be in an ‘As X I would like to Y’ format. That is the User Story, and its role is to give context to the people delivering the work. For example:

‘As a new user, I would like to sign up to the app using email and password or my Google account.’

This User Story format is not limited to UI interactions. It also applies to many other types of user's interaction with the product:

• Working with APIs: ‘As a user with API access, I would like to create a new order via REST API by providing the following details: name, due date, and a list of items. I would like to get back an Order-ID for future tracking.’
• Using internal products: ‘As a support agent, I would like to know the last 100 actions each user performed in the system.’
• Developer from within the company: ‘As a developer, I would like to use the pricing service to trigger a new purchase for a user, suppling the user ID and the requested product.’

The second part is the Definition of Done (DoD), and follows the pattern: ‘This is done when…’ This part should include a list of statements, each of them is very clear and can be easily tested, so developers and the QA can apply them directly as acceptance tests. Following the mentioned examples, a DoD for the first user story may be:

1. There are input fields for email and password, and ‘Sign up’ and ‘Sign up with Google’ buttons, following the attached design.
2. When a user supplies an email and password and clicks ‘Sign up’ a new user is created with the supplied password.
3. When a user clicks ‘Sign up with Google’ the Google sign-up sequence is initiated.’

Note that this DoD does not include all the relevant behavior. For example, it does not state anything about the user creation flow or the sign-up with Google flow. There are a few different reasons for that. First, these flows may be already active in the system, so developers just need to make sure the flow is initiated correctly. It also may be that there is another ticket to developing these flows. As a product manager, I always try to breakdown deliverables as much as possible into independent parts. I will elaborate on this point later on.

Pressure builds quickly

So I had to work with a new dev-lead in a new method. To add to that, two weeks after we started working together the whole country went into severe lockdown due to COVID-19 breakout. We had to manage this ticket-formatting change while everyone are getting used to working from home, instead of sitting at one desk. If that wasn’t enough, two days after the lockdown started, one of the company’s largest clients communicated that what was previously only a general timeline for delivery is now a hard deadline and that if we don’t deliver the feature within a month, that client won’t purchase any new services from the company. So this transition did put a lot on the line.

It worked. It did require me as a product manager to be very specific and to commit to the requirements I write. It required developers and QA to verify they understand requirements before the sprint starts. And if we as a squad discovered that something is not clear, or does not fit with the design, or any other issues, we had to go back to the drawing board and quickly decide what to do, so we can start the sprint one time. But once we were done with the planning, we all knew that there was a very high chance that the scope of the sprint will be done on time.

Following up with the success

We stuck to this method, and I implemented it in the second squad I was responsible for. And just a few weeks later, this method allowed us to plan and execute an integration of two complex features into one to deliver much new value to our users.

The essential implication of this ticket writing method on me as a product manager is that I must making have requirements at this format by the time the squad needs to execute. This means that I should communicate my initial thoughts on new features much more early in the process. Back when I allowed requirements to be vague, I tended to communicate the overall goals, intentions, and design decisions quite late in the process. If you are allowed to change requirements later, nothing pushes you to get the team involved beforehand.

Today, when I have a vision of upcoming features, I start a series of ‘kickoff’ meetings with the squad. At these, I share the goals, the high-level requirements, design, and breakdown of deliverables. We get feedback, identify points we missed and raise concerns, and get back to the drawing board with these insights. This way, when we get to the execution phase, we already have very solid requirements in a clear and actionable format.

Not forcing a solution

Lastly, one major benefit of writing requirements in this format is creating a clear separation between the need and the solution. People with entrepreneurial or technical attitudes tend to ‘think fast’ and jump directly to envisioning a solution when thinking of a problem. The downside of this attitude is that they may not completely understand the problem they’re trying to solve. Jumping too early into designing the solution would miss critical understandings and insights about the problem. Writing down requirements in the format of ‘As X I would like to’ followed by a definition of done, does not discuss the solution in any way. It forces you as a product manager to analyze and present the problem in a very clear way, before moving to the phase of designing the solution.