How to approach writing requirements

Hello!
My name is Konstantin.
Most of my professional life I was in charge of making new apps happen related to web development:
– Make a new website
– Make a new app
– Make a new feature for an app
– Make something that will solve the problem of a client.
In the beginning, my inner developer wanted to jump straight to creating a new piece of software and ask questions later.

Over time I’ve learned that there are requirements for a piece of software and it is a good idea to collect them first and write the app according to those requirements.

At some point, I’ve figured out that collected requirements often don’t reflect the real needs of users, even if you ask them directly.

It happens because end-users are very likely to be unaware of what they need, how to express it or maybe not even interested in telling anyone about their needs.

Long story short – it is hardly possible to get all the requirements from end-users.

If you, as a developer, team-leader or even CTO, were in such a situation, then hear me out, there is a way to help you.

Imagine you need to write a new application or a new part of an existing app.
Nobody knows exact pieces for this new thing, and there are only broad expectations or pain point that needs to be solved.

Let’s visualise it with an example.

You work in a company, where employees have some repetitive task that requires much manual work.
Without automation, a large part of the work time is wasted.

Automation can save time that people can use to do more valuable tasks: answer more support tickets or bring more new customers.

I have explored and tried three approaches to writing requirements and solving the pain point of business users:

1. Sitting alone in a room and imagining what these people might need and getting requirements from my head.
2. Going to those employees, asking questions, writing answers down. Developing application with short feedback loop until they are satisfied.
3. Not collecting requirements nor developing the app. Instead, looking for an existing app that claims to solve this pain point and start using it ASAP. Next step is observing the usage of the app, collecting feedback and problem reports from employees, making notes of any issues. Deciding if the app can stay or it is not a good fit. With all this information it is possible to choose between using the SaaS and replacing it with an in-house developed app.

Let’s go through every option.

Writing the app without talking to users
Most of the times it is a terrible idea, especially if you are not familiar with the specifics of the job.
You can end up with an application that is built by developers for lawyers, doctors or drivers.
This approach is the easiest way to make an app that makes the lives of employees worse.

Asking end-users about requirements

Sounds good thing to do, right?
For my experience – NO!
Most likely end-users are not familiar with software development.
They never thought of what makes their experience enjoyable.
Their old habits dictate what features should be included in the app.
Relying on old habits prevents any progress and any automation.
Instead, they might ask for a more comfortable way of doing their manual tasks because that’s what they know.
Also, automation is usually perceived as something that is putting their job at risk.
I had projects that have failed due to actions of business users, that made everything possible to make their bosses abandon automation project.

If employees are busy with their manual tasks, it means they have KPIs to meet and spending time answering your questions only takes away their valuable time. In short, they will not tell you anything at all.

There is an opposite situation when users decide to talk to you.
Surprisingly, this also can be a problem and might not lead to an efficient solution.
Moreover, when they do talk to you, they will tell you to include every feature that they can imagine.
Two things cause this:
1) since you are developing a custom solution they don’t want to forget any idea they had. Because if they have a sense of a feature, why not to request it?
2) people are consumers of everyday B2C apps.
They have no idea what goes into building VC backed freemium or free apps they are so familiar with(Gmail, social apps, other stuff).
Their requirements might sound like “see how they did it in Gmail, and do the same for us, what’s the problem?”. Not useful.
Plus it is not always needed.
Also crazy long to build, expensive, and not needed if it is an app for internal use and employees are usually trained to use internal apps.
They don’t have to like the app to do their job.
Have you ever seen internal banking apps? There is no such thing as UX.

Choosing an app that is the best fit for solving the pain point and observing it’s usage by employees

Most of the time it is the most optimal option.
1. First of all, you start solving the problem right away.
2. You throw the app to users, and they use it. SaaSes exist to immediately address the issue, save time at the cost of a monthly subscription. Even if it is not the ideal solution, which probably never exists.
3. An off-the-shelf solution already has some features and approach to solving the pain point. You can quickly assess how good is this approach and see what features are needed and which left unused.
4. The company is already more efficient and earning/saving money. These savings can be used to fund building such an app in-house.

So. In this case, you immediately have a working solution, feedback data, that converts to decisions whether to build the app in-house and what exactly to build.

The downside is the cost of off the shelf app, training and probably some integrations.

Have a great 2019!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.