How to use Handovr to write a product requirements document

This article describes how you can use Handovr to write your next product requirements document for your software engineering team.

What is Handovr?

Handovr is a tool for software engineering teams that rethinks how product requirements documents should be done. Most companies (especially smaller companies) find writing documentation a tedious process, something that gets put aside because it requires too much time.

Product requirements Handovr example

This article is about how to use Handovr on your next project, and what better way than to explain by example. What you'll learn by the end of this article:

  1. How to use Handovr to write a product requirements document
  2. 4 reasons why Handovr will save you and your team time

Step-by-step guide on how to use Handovr to write a product requirements document (PRD)

1. Create a new project

If you haven't already, sign up to Handovr and create a new team, or log in. When you're all setup and logged in, create a new project to get started.

2. Upload your idea with a sketch or hi-fi design

Sketches are a great, easy way to start communicating your idea to the rest of the team. Upload your sketch by taking a picture and dragging it onto the project canvas area.

Product requirements document sketch lo-fi example

A designer can then transform your sketch into beautiful, high fidelity designs. You can update the image by clicking the mountain icon on the toolbar located above the design.

Product requirements document login screen hi-fi example
All your requirements will stay connected to the design, so you can update the design whenever you want without the stress of losing where you are at.

3. Create the style of specification your team uses

Click the "add specification" button, this will create a new specification template for you to edit.

Click "edit template" to bring the template attributes into view.

Product requirements Handovr template example

For this example, we'll create a "user story" template with acceptance criteria. You may want to add a template for each type of customer archetype for instance (e.g. as a product manager, as a software engineer) so your product requirements are consistent every time.

4. Annotate your designs with product requirements

Fill out your specification template, adjusting the template if you need to as you go.

Below you can see how the specification communicates:

  • What customer the specification is for
  • What the user story aims to achieve with the outcome
  • Functional requirements (acceptance criteria) that software engineers will be required to implement for the feature to be considered complete

5. Share your product requirements with the team and receive feedback

Sharing the requirements early on with the engineering team will help identify anything missing from the specification. Did you notice something in this example? We guarantee 9/10 software engineers would ask the following question:

Where does the "Forgot your password" button link to?
Product requirements Handovr example

Go ahead and address any feedback you receive on your product requirements. Once all stakeholders have signed off the document, schedule it for development and get building! Your developers can now use your product requirements as the bible during the development phase.

4 reasons why Handovr will save you and your team time

1. Helps you be more specific and straight to the point

Using templates and specifying exactly what your requirement refers to helps you communicate your requirements more concisely (at the end of the day, that's all your engineers want).

Short, concise specifications take less time than long form product requirements documentation.

2. Visual = higher engagement = more questions, earlier

We've heard it time and again, communicating ideas visually is more engaging than plain text. Most often, product managers end up bringing the team in the meeting room and present a document, talking through each section (boring!).

Presenting designs with annotated requirements drives engagement which means the team will more likely raise things you've overlooked the first time round.

3. Centralised source of information

Save you and engineers time from going back and forth between design and product documents by putting it all in one place.

4. Templates drive consistency across your projects

If you have more than one product manager on your team, it helps to define a framework for your team to follow when creating product requirements.

As a developer, you can request to add a section to the template that specifies the final copy for every project.

Either way, when a team decides that they want to have a required section on the specification, templates help authors elaborate on those areas each time without forgetting.

Start creating product requirements

Hope this article helps you create simpler, better product requirements documents. If you don't already have an account, you can sign up here.

For any feedback, requests or if you just want to chat, email me at