Crowdbotics will be at GitHub Universe on 10/29-10/30!
Find Us
The Crowdbotics platform leverages AI and systematic code reuse to help you build better applications faster and with less risk.
Don’t take our word for it, see what our customers have to say.
By Industry
Everything you need to be successful with Crowdbotics.
Use & Learn
We are on a mission to radically transform the software development lifecycle.
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
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.
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:
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.
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 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.
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.
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.
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.
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.”
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.
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.
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.
