If you are a non-technical startup founder who wants to hire a remote team to build your product, one of the most important documents that you should write is the App Product Requirement Document. The quality and depth of that document have a great influence on the success of your project.
Statistics show that more than 70% of custom software development projects end up in failure. The primary reason behind the failure is the lack of clear communication.
As the founder, you might have a clear picture of what you need and how the app should look like. But that is not enough. The question is whether your development team (either in-house or remote) has understood what you exactly want.
Just having some calls and communicating what you need wouldn’t work. Software development is a complex process. You should always be over-communicating. Yes, I repeat, over-communicate!
In this article, I will explain the template we use to gather requirements from our customers when they approach us with an application development project. The document is not technical at all. It is all about storytelling! Just tell what your app needs to do as simple stories.
This is really important, and it is the first thing that you should do. Who is going to use your app? Btw, Throughout this article, I will be explaining using the example of an e-learning app development project.
So in your e-learning app, students are the primary users. So let’s list Student as our primary user. Now write a brief description of what the student will do. For example – Students will use this app to view courses, purchase them, view course contents, submit exercises, post on discussion forms etc
Next is the Teacher. Your app should allow teachers to log in and see their student’s progress, monitor their activities, and ensure they’re on track. So list Teacher as the next user.
No, You, the founder is a user of this app too, right? Without you being a user, how can you log in to a dashboard and see how your app is performing? You want to see how many students have registered, How many of them have purchases a course, etc.
So, yes, we need an Admin User. But think, Is it just you who will be the admin? What if you have some support or billing staff who needs restricted entry and view only a subset of the data that you can see. (Then you’re the super admin). Let’s define that too. For example – Billing admin, who can only see financial reports, upgrade/downgrade student accounts, etc.
Can you serve all your users with a single app? Or do you need separate apps for them? Identifying this seems difficult, but it is not. Let’s say in your e-learning app, you have students, teachers, and admins. Of course, for the students and teachers, we should build a mobile app. But what about you, and your staff?
You and your staff being administrators, and probably looking after reports, and huge lists of data organized in table views, a web-based dashboard might be more suitable for you.
List down different apps that you need to build as part of this project. For example –
If you want to become a founder, you need to be a great storyteller. You might have heard this multiple times. It’s true. Everyone likes to listen to stories. Your users, employees, investors, everyone!
So why not write stories on your app product requirement document too?
Hopefully, you already know what an Agile User Story is. It is one of the best ways to define product requirements for any project, not just for app development.
The idea is to explain what the end-user (not always you) needs from the app, and why they need it. No jargon and Nothing technical. Just think from the perspective of the end-user and explain the features like simple, plain stories.
For example, instead of writing User Authentication Feature for Students, write a story –
As a student, I want to login to the app using my mobile number and password, so that I can start learning!
This story itself explains everything! Make sure to detail the story by including more details such as – the password input should be validated in real time, wrong user credentials should show an error message etc.
Sometimes, you find a lot of user stories describe different areas of the same feature or a module. These stories can be grouped together, and it is called Epic.
I hope you’ve now understood a better way to write an app product requirement document in the form of stories, and by defining the user types. Don’t feel overwhelmed. The idea of this article is just to help you document the idea you have in your mind in a better way. So that your development team exactly knows what you’re trying to build.
You can download the Free template I’ve built and use it for defining your app development requirements while communicating with your product development team next time.
Download Free Template – https://logi.dev/product-requirement-spec-template
Logidots is a product development company that works with startup founders to turn their ideas into apps.
Build Better Software, Faster.
All rights reserved 2021