How to really understand user requirements

When we’re starting out as junior engineers, we’re mostly told what to do. We’re given both the “what” and the “how” of a solution, and we’re expected to just implement it.

As we grow in our role, it starts becoming more and more important to understand the business reason behind what we’re building. A senior+ engineer is expected to go a step further and come up with the right problems to solve.

A crucial skill that helps with the above is understanding user requirements correctly.

Why is it important?

Picture credits: pmac-agpc.ca

Remember this meme? It’s been around for ages and is STILL relevant because it’s ridiculously easy to build the wrong solution if we aren’t paying attention.

What normally happens is that our users describe the solution rather than the problem they’re having (for e.g., “We need a website that allows us to export data into a report”). And as engineers, we jump at the chance to start building something, because we LOVE doing what we do best - building!

Unfortunately this process is quite likely to lead to unimaginative, mediocre results. The solution will be somewhat useful, but it will fail to delight the customers.

As software engineers, we need to build the skill to understand the business problem behind the user requirements, rather than simply proceeding to build the technical solution described to us.

Isn’t this a Product Manager’s job?

While having a good Product Manager can help with this process, requirements can still be lost in translation when communicated to you, the engineer. You’re writing the design and the code, not the Product Manager.

We engineers make several trade-offs while designing the system and while writing code. Imagine how much you can accelerate this process if you understood the business problem well - you’d know whether to choose strong consistency or high throughput without having to ask someone else for each such decision!

It is very hard to progress past junior / mid-senior roles if you consider understanding the business problem “not your job”. A senior engineer helps make tech decisions and advises the engineering manager by combining their deep technical skills and knowledge of the business.

OK, so how do I do this?

Let’s jump straight into some tips and tricks to capture the “real” user requirements.

Ask “why” several times

When given prescriptive technical requirements by the user, uncover the business problem by repeatedly asking “why”. Let’s look at the following conversation between Jane, a software engineer and Lisa, a business user:

Jane: Hi Lisa! I want to understand your needs for the new system we’re developing. Can you tell me about any specific features you think are necessary?

Lisa: Sure, one thing we really need is a way to export our sales data to Excel.

Jane: That sounds important. Why do you need to export the sales data to Excel?

Lisa: Well, we usually run several reports and perform some complex calculations in Excel.

Jane: I see. Why do you prefer doing the calculations in Excel rather than directly in the system?

Lisa: The current system doesn’t support the specific calculations we need. We have to customize our reports frequently based on different criteria, which Excel handles well.

Jane: Understood. Can you explain what kind of calculations and customizations you typically perform in Excel?

Lisa: We often calculate sales trends, project future sales, and create detailed pivot tables to analyze sales by different categories and regions. The system should allow us to generate these reports directly without exporting to Excel.

Jane: That makes sense. Why is it important for you to generate these reports directly in the system?

Lisa: It would save us a lot of time and reduce the risk of errors when transferring data. Plus, it would ensure everyone has access to the most up-to-date information.

Jane: So, if I understand correctly, you need robust reporting and analytical capabilities built into the system to replace your current Excel processes. This would include trend analysis, sales projections, and customizable pivot tables, right?

Lisa: Exactly. That would make our workflow much more efficient and reliable.

Jane: Great, thanks for clarifying. This gives us a much better idea of what we need to implement. I’ll make sure our team focuses on building these features into the system.

By repeatedly asking "why," Jane uncovered the underlying need for robust reporting and analytical capabilities within the system itself, rather than simply fulfilling the initial request to export data to Excel.

Speak their language, not tech jargon

This applies to most situations, to be honest, but ensuring you avoid technical jargon when you speak with users (who are most likely non-technical) will make it more likely for users to share deeper business details with you, since they’re more likely to make a connection with you and see you as one of them.

Please don’t say “To accurately capture the user requirements for the new module, we need to define the data schema, establish the API endpoints, and ensure the frontend UX aligns with the wireframes, all while adhering to the existing microservices architecture and maintaining compliance with the latest GDPR protocols.” to a non-technical business user.

Spend time with your users

I understand that this might not be possible in every situation, but if you can, please spend time personally with your users. Shadow them for a day or two, ask them to show you how they do their day-to-day job. You will be viewing their work from a software engineer’s lens and will likely come up with several ideas to solve the issues they’re facing.

Even if all you can manage is a 30 minute call now and then with your users, it is still worth it!

You always have a customer

Don’t dismiss the above ideas if you don’t have direct access to your customer. You will have access to someone who is coming up with (or conveying) the requirements - treat them as your customer. They could be your management, your product manager, other teams in your org or even your tech lead. You always have someone to practice the above strategies on.

Feel empowered to come up with the “how”

Once you’ve learnt about the underlying business problem, trust your skills as an engineer to come up with the solution. You know your trade best, don’t rely on others to tell you what exactly to build. Even if you’re given prescriptive technical requirements, feel free to take a step back and come up with your own solution. If it is different than what you were asked to build, you can make a counter proposal. This is how you can start practicing “advising” your stakeholders - an essential skill to be promoted to senior.

I’m sure there are many more ways to get good business requirements. Let me know in the comments!

❤️ My favorite things this week

• I’ve been reading Building a Second Brain by Tiago Forte - a book about building your personal knowledge-management system outside your biological brain. I’m really excited about this as I’ve been struggling to keep up with the firehose of information coming my way from some excellent tech newsletters. Keep an eye on my LinkedIn as I will be sharing insights from the book over the next couple of weeks!

• I found this excellent article that explains the logic behind LLMs without inundating you with mathematical details.