India has been a major power in computer software, but lot of companies struggle to develop software products. I have seen a lot of start-ups struggle with new product development and after several months or years of efforts product development projects are canceled.
The major problem with Indian IT companies is that they lack proper product management skills and fail to properly manage the product requirements. In this blog, I have listed the basic steps in managing requirements to ensure new product development success - particularly for start-ups.
All product development starts with identifying product requirements. The job of product manager is to define the product requirements and work with engineering and project management office to implement it.
Successful new product development is not an easy project and there is always chances of mistakes or missteps. From experience, I have noted down few mistakes that must be avoided in all projects.
The most common problem is that of project overruns. Often the project costs more than the initial estimate and/or takes more time to complete. To avoid getting the blame for the overrun, some teams try to release a half baked product. Which results in a much bigger problem of fixing the issues after the product release.
In this blog, I have listed the basic steps in managing requirements to ensure project success.
1. Document the minimum set of requirements that has to be met to ship the product.
2. Avoid misinterpretations of product requirements.
3. Do not 'Overbuild'
4. Define 'quality parameters' as part of product requirements
5. Define compliance as part of product requirements
6. Keep a close eye on project team coordination
7. Build an agile product development process
8. Avoid excessive changes to product requirements
9. Ensure Executive involvement
10. Ensure a Beta test program with a real customer.
Document the minimum set of requirements that has to be met to ship the product.
Before starting the development project, the first step is to document the requirements in ways that can be clearly understood by the team. If needed, use visuals or animation or mock-ups to make people understand the requirements.
These requirements must also be prioritized into "must have", "Good to have", "Bonus" etc. The final product cannot be released if it does not meet the "Must Have" requirements. Once the "Must Have" requirements are identified, then work on estimating the time & resources needed to complete the project.
Product managers & all stakeholders must review the product to check if all the must-have features/requirements are met before proceeding with the product release.
Avoid misinterpretations of product requirements
Understanding product requirements is always a challenge. Often times, the requirements are documented in plain text. Which can be misinterpreted, leading to chaos/confusion at the time of product release.
There are several levels of requirements that must be documented. Starting at the high-level of the product concept, Architectural details, and down to user interface design requirement.
The best solution is to document the requirements using visuals - either in terms of visuals or animations or mockups. In addition, one can create user personas to illustrate the end user requirements.
During the development process, ensure that the entire product development team has a common understanding of the requirements.
Do not 'Overbuild'
A common problem with building new products is to add loads of bells and whistles into the product or build capacity/capability which is far in excess of user's real requirements.
Another manifestation of this problem is to add too many features. In most cases, there is just one customer who needs that particular feature! This leads to adding too many features which confuses customers.
Overbuilding a product costs money, time and resources - all that for features that customers do not want!
So care must be taken to ensure that the final product actually has what is needed.
Define 'quality parameters' as part of product requirements
Quality of the product must be defined in the product requirements. The quality is as perceived by the customer. For example, Mean Time Between Failure (MTBF) of the finished product must be defined in the product requirements. In case of software, the system stability, or memory growth must be defined in the requirements. The quality parameters such as "response time" or "resource utilization" etc. must be defined as part of the product quality.
Define compliance as part of product requirements
Just like quality parameters, the product compliance requirements too must be documented in the product requirements. Often times, I have seen that the requirement document makes only a passing reference to compliance adherence - and does not dwell deeper into the actual technical details of the requirements. Such high level description is a perfect recipe for disaster - as it opens up the field for misinterpretation of requirements.
Keep a close eye on project team coordination
Today, distributed project teams have become a norm. Even startups out source some segments of projects. In such cases, the team coordination becomes a major hurdle, leading to miscommunications and project over runs. Any signs of poor coordination is a red alert on things going wrong in the project.
As part of Product management oversight on the project, it is important to keep a close eye on the team coordination and take proactive steps to improve team coordination. Product management must work with project management and engineering teams to constantly monitor team coordination and take corrective actions as necessary.
Build an agile product development process
In today's rapidly changing world, it is important to be agile - not just in project management, but also in Product management. Agile product management helps in modifying the end product to meet the market needs - even when the project is under execution.
Agile product development allows product managers to fine tune product requirements and meet customer's changing requirements.
Avoid excessive changes to product requirements
While agile product development helps, excessive changes are detrimental to the product development. Especially, when changes are made to sections of the project that is already built/coded. So any change in product requirements must be validated and vetted by all stake holders. As a thumb rule, a project should not have more than two changes to requirements - to sections that is already completed, and any change must be approved by the change request management committee - a.k.a. stake holders.
After the second change request, any subsequent change requests must have an executive level approval.
Ensure Executive involvement
New products are part of the overall business strategy. So the top executives must get involved in new product development and provide strategic inputs when required. Top executives must also oversee the project and provide active project governance. In case of startups, when the founders themselves are deeply involved in the project - the board of directors must provide the higher level governance.
Ensure a Beta test program with a real customer.
Beta testing the new product with the customer solves a lot of problems in the product development stage and also improves customer satisfaction and user acceptance. Getting customers to test the product before release will help uncover functional bugs, design gaps and other user environmental issues which could not be found in the internal testing cycle. Often times, developers use simulators for testing - which does not reflect the actual customer environment. So the Beta test helps identify those bugs or even design flaws - which can be fixed quickly.
Remember: the cost of fixing a bug in beta testing is lot cheaper than fixing it after the product release.
Closing Thoughts
Project success is also dependent on managing requirements. Product Managers must keep a tight control on product requirements. Many Indian software startups try to build a perfect product and try to please as many customers as possible or try to add too many features/requirements. This leads to an unwieldy projects - which eventually fails. In this article I have described 10 main points product managers must follow to ensure new product development project a success.