Classic Product Management Guide PMBOK teaches that:
- The quality of work is constrained by the project’s budget, deadlines and scope.
- The project manager can trade between constraints.
- Changes in one constraint necessitate changes in others to compensate or quality will suffer.
While managing schedule and budget were relatively straightforward, our “scope” was pretty complex. It looked like in the image below.
Our developers were picking user-stories to implement every 2 weeks during sprint planning. As a PM I always tried to find better ways to deal with that “scope” that contained so many unknowns and dependencies (not to say that it was changing every second week). After years of trial and error, my PMBOK triangle looked like that:
Product Managers produce great functional requirements, but many details can not be foreseen upfront.
Actual User Journey almost never looks as the one we imagine.
Actual research helps to uncover gaps in the:
- Domain Knowledge
- Requirements
- Design
- Implementation
Thorough upfront design and validation are more expensive and time consuming than the traditional process of doing design-development cycles. Many design deliverables need to be discarded and it can be seen as a “waste” by some people. But it’s not a waste, it is a saved engineering effort on the big picture, if the final goal is to release the product that users like and want.
Some product teams prefer it to do the other way around, which results in much greater costs, as it not only involves design change, but also change of the code and QA, change of design system patters, change of documents, not to mention the experience that end-users get.
User-centric approach costs more and takes longer in the initial phase, but it is very rewarding later.