Crowdbotics will be at GitHub Universe on 10/29-10/30!

Find Us
Crowdbotics Logo

Customers arrow

Don’t take our word for it, see what our customers have to say.

About Us arrow

We are on a mission to radically transform the software development lifecycle.

Home Blog ...

Product Development

How to Translate Unclear Client Demands Into Specific Product Requirements

Successful product development requires a clear understanding of what the client is trying to build. If your client has provided vague product specs, here are some tips for turning them into useful development tasks.

6 October 2021

by Aman Mittal

The quality of a product is completely dependent on the process of how it’s built. Product development starts when a client specifies their requirements, and developing software requires the entire team to precisely define what that application is supposed to do.

Dealing with unknown or unclear requirements is one of the greatest challenges when it comes to managing a product. If the client is dissatisfied with the poor quality of the product or unmet expectations, this could force you to increase the cost of production to correct the product’s deficiencies. This often a result of not properly understanding a client’s requirements from the start.

In this article, we are going to describe how to overcome the common challenges of understanding when a client is not specific about what they want and how to overcome those challenges.

Challenges of Capturing Product Requirements

It can be difficult to translate a client’s “voice” into user requirements for a product they are seeking help with. It often starts with an interview with the client in which you discuss problems and seek solutions for them. Scheduling an informal, candid conversation is a good way to get some initial thoughts and ideas about their needs.

During the early stages of product scoping, keep an eye out for the following red flags that can derail a build:

Lack of technical literacy in the client

When clients provide their requirements, it’s common for those requirements to lack a focus on technical specifications. In this case, the risk is that the client’s expectations are not in sync with their own requirements.

Without complete knowledge of the process of product development and the architecture that goes into building it, clients often assume that complicated features will be trivial or forget to include key features entirely. You need to be sure that you are precise when having technical discussions with non-technical clients.

Poor or infrequent communication between the product manager and the client

Lack of communication is really the biggest mistake that any business in any sector can make these days. Sometimes, poor development outcomes can be attributed to a failure of communication between a product manager and a client.

A client has not fully thought through the project

A product’s requirements are based on understanding the difference between what is really required and what is a simple “nice to have.” A client’s ability to understand the difference between the two is not always reliable. It is important to explain these two types of requirements for the success of both the client and the product development team working on it.

Over-ambitious product ideas

A client’s vision for a product may be beyond the scope of their budget or even the capabilities of existing technology. As a product manager, it is essential to flag pie-in-the-sky ideas early on and make sure that all the requirements of the product are deciphered into clear, achievable goals.

High-pressure deadlines that prevent full scoping

Sometimes, in an effort to win a client’s business, development teams may rush the scoping process without conducting due diligence on the exact project the client is trying to build. This is rarely a worthwhile sacrifice, as disagreements over project scope will come back to spoil the relationship later on in the development cycle.

Constantly changing feature sets

Changing technical feature sets without accounting for the interrelationships with other features in a product leads to unfulfilled requirements, an increase in costs and time taken to develop the product, and poor overall quality of the product.

try our app estimate calculator CTA image

Importance of Capturing Specifications

A product’s specification is an important factor that is directly proportional to the end result and the overall quality of the product once the development process is complete. A product’s specification serves as the backbone of the entire digital product.

Software specification starts with user stories. It is important to identify the difference between good and bad user stories. If a poorly described user story is taken into the account, then the end result is not going to be as desirable. A bad user story fails to capture the exact behavior expected of the app. Some common elements of a badly written user story are:

Consider the following examples of poorly described user stories:

Example: “As a food service app customer, I need to save my list so that later I can save a copy or email the list to other users.”

A product manager or a team of developers presented with this story may think that the user story consists of simply saving a list. However, this would be a misinterpretation because the user story is made up of many pieces. A developer is likely to miss the point that the client wants to email the story and not just save a list of items in the application.

It might be improved in the following way: “As a food service app customer, I need to be able to save, copy, and email my list so that I can edit it again, check a received order against a saved list, and send the list to the restaurant from which I ordered.”

Yet the above “refined” user story misses a likely extension of this feature: what if the end-user wants to save the list of ordered food items such that they can use the same list to reorder the same items from the same restaurant in the future?

An even better way to improve this story is to divide it into multiple user stores such that it covers the missing point. It is often a good practice to split a large user story into multiple stories such that it can lead to a clear understanding of what features are needed to implement it.

The above format of multiple user stories is clear for any product manager or a developer to understand. They can now easily see that the client’s requirement does not stop just at saving the list of items, but also that the app’s user can reuse the saved list of items. With these user stories, they can work on extending the functionality to provide a complete set of features within the app.

Let’s consider another example of a poorly written user story, written from the perspective of a vague end user.

Example: “As a business owner, I would like to save a list of items that are highly profitable so that I can identify them and consider what to do about the underperforming items.”

This user story does not clearly define the business owner or any end-user. A business owner can be anyone, but it is important to know their specific role. The scope of implementing this user story in an application has no bounds. Clearly specifying the roles of app users enables more productive conversations between app stakeholders.

One way to improve the above user story is: “As a marketing manager, I have to consider how to spend a limited marketing budget. Therefore, I need a report of the most and least profitable items in order to highlight profitable items and consider what to do about the underperforming items.”

Best Practices for Helping Clients Specify Product Requirements

We’ve established how important it is to have a clear set of product requirements. At the same time, it’s important to understand that clients come from a wide range of background, so you may need to help them flesh out their product requirements properly.

Helping a client to specify exactly what they are looking for from their product should be the initial step of any product development process. There are some practices that you can follow to capture their product requirements.

A “Final Checklist”

Checklists are versatile in nature. Utilizing a checklist before a product’s development process begins could eliminate complicated pipeline steps later on. It also enables the interaction of different teams and departments to sustain proper coordination and communication as well as with the client. Here are some of the most important things to keep in mind before the process itself gets initiated in order to capture the client’s requirements.

Conclusion

Poor or unclear requirements may lead to project delay or failure and waste of resources such as time, effort, and money. Poorly specified requirements could also lead to missed project deadlines, and ultimately poorly designed and developed software in the end.

At Crowdbotics, we provide managed app development services by expert product managers. We take care to prepare highly detailed PRDs before commencing development and are accustomed to helping non-technical builders capture their precise product scope.

Get in touch with us today to learn about the technologies we use, the process of building an app, our expertise in your industry, and what other clients have to say about development services with Crowdbotics.