How to Translate Unclear Client Demands Into Specific Product Requirements

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.

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:

• A story is written from a product owner or client’s perspective.
• A story is written from a developer’s perspective.
• A story is too big or contains too many steps.
• A story has no value to customers or end-users.
• A story is highly dependent on other user stories.
• A story doesn’t share enough information.

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.

• As a food service app customer, I want to save and view my saved list items so that I can reuse the list for future orders, making ordering faster and more accurate.
• As a food service app customer, I need to copy the list of saved items so that I can use it as a starting point for creating another list.
• As a food service app customer, I need to email the list of saved items so that I can share it with someone in my network.

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 good way to start is to ask the client to share features from a different app that are similar to what they are looking for in their own app to be developed.
• Ask the client for mockups or drawings of exactly what they want in a feature. Make a detailed outline of how it can be implemented and share it with the client for feedback.
• Create a detailed Product Requirements Document (PRD) and walk through it with the client. A PRD must contain every explicit feature required for the release of the product. To support each feature, there should be an accompanying use case. This use case must illustrate that how an end user is going to utilize the functionality and a plan to test them. Also, if required, specify which the end-user environments are supported (such as mobile operating systems, processing power, memory, web browsers, etc.).
• Be precise with user stories and the features that are going to be used to implement those stories. Cite the specific features that you are going to leave out if a feature is build in a certain way.
• Ask the client their “why” behind including a specific feature. The end goal related to that feature or set of features should be clear and understandable from the beginning of the product development process. This also enables conversations to zero in on a specific set of features in a simpler way.
• List out what is expected of end users. Specify if there are any limits in the process that a client has to be aware of or any third-party elements required for the end product to be functional.

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.

• Start with a formal and an informal interview with the client to get their unique perspective on their product and understand their background.
• Have a clear set of user stories defined for each feature and the context in which the feature has to be implemented. Try to divide complex features into multiple user stories.
• Narrow down a client’s requirements to specifics and then discuss them with your entire development team.
• Maintain a proper communication channel with a client for validation and further context for individual features.
• List any assumptions that you or the client have made regarding the technical, business, or user features of the app.
• Make sure that deadlines are set in a feasible and achievable manner.

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.