There could not be less emphasis on writing good quality requirements, but is it enough?
As a product manager, once I identify the initial requirement from customers (or proxies), I first need to estimate whether fulfillment of this requirement is in scope. In other words, do I have the resources to deliver and satisfy the requirement?
If not, does it make sense to refine the requirements further? Perhaps yes, perhaps no. A requirement may be broken down into smaller chunks, and it may be possible to deliver a smaller chunk, satisfying some of the needs.
The approach I would take is to time box the entire process. After initial need (unrefined requirement) gets in, I would get an initial estimate of resources from engineering team and using past experience. Getting a estimate is also a cost, and time boxing the process will fix the cost of getting estimates. That would give me an indicator of whether to proceed further or not.
Providing ample visibility about resource estimates to customers (internal or external) at determined checkpoints is also a good way to make sure that product manager is always on valuable requirements that have both quality and feasibility.
From another blog,
Key: Product Release
Key: Product Backlog
As a product manager, once I identify the initial requirement from customers (or proxies), I first need to estimate whether fulfillment of this requirement is in scope. In other words, do I have the resources to deliver and satisfy the requirement?
If not, does it make sense to refine the requirements further? Perhaps yes, perhaps no. A requirement may be broken down into smaller chunks, and it may be possible to deliver a smaller chunk, satisfying some of the needs.
The approach I would take is to time box the entire process. After initial need (unrefined requirement) gets in, I would get an initial estimate of resources from engineering team and using past experience. Getting a estimate is also a cost, and time boxing the process will fix the cost of getting estimates. That would give me an indicator of whether to proceed further or not.
Providing ample visibility about resource estimates to customers (internal or external) at determined checkpoints is also a good way to make sure that product manager is always on valuable requirements that have both quality and feasibility.
From another blog,
It may seem like an obvious conclusion, yet how many times have you seen it happen:
- Requirements left out because they are infeasible, resulting in disappointed users --“Why didn't you tell me I couldn't have what I wanted?”
- Requirements sent to development which are infeasible, putting the development team in a no-win situation--“Why did you commit me to building what I know can’t be built with the constraints I have?”
Key: Product Release
Key: Product Backlog
Posts
1 comment:
Great point that raises an important but often neglected tool in the requirements toolbox,
"We must be candid with our users; if they want something they can’t have (for what they are willing to pay), we must tell them."
Frequent conversations with the business and the users are often neglected. Funny, we seem to have lost the art of talking.
Post a Comment