Embedded Files
The first milestone has been achieved! We have a set of requirements in great detail which describe a proposed solution to a clear business challenge. Essentially, the product team has the first set of Product IP in the bag. The documentation in itself already has value in its own right.
The next step is to now turn the vision into a reality which require the engineering Team (or the development / SCRUM team) to join the party.
It is imperative that all team members understand the business challenges as well as the propsoed solution. Typically developers like to be told what to do and do it, focussing on the small white box - yet do not understand the overall picture which is bigger than just that white box.
A Product Owner must therefore discuss the whole document with the team, enabling the team to understand the business problem as well as the desired business solution. Empower and motivate the team to think outside the box and challenge status quo. Ask questions and have necessary discussions around the solutions roadmap and vision, discussions around the flexibility, scaleability, and maintainability of the product as well as its intended environment, user base, devices to be used on, etc. Defining the technical core elements at this moment is the building block (from an architectural perspective) which although in theory may be re-visited, will never be re-visited!
Discuss everything possible outside the solution (the NON-Functional Requirements) that would be required to actually use the solution with ease, ensuring performance, uptime and robustness. Such discussions and brainstorming shall enable technical leads to start envisaging the core architecture, the building blocks to HOW the solution is to be built.
Unfortunately, many companies and product teams think about the core of the solution, the architecture potentially a bit to lite. Not because they may not care, but because they may not have the full picture. Truth be told, no one would really have the full picture. The Product Owner, nor key stakeholders would know what is to be defined in 6 months from now, let alone 12 months. BUT we must always envisage and vision where we see the Product - which again, should come to light during the feasibility study workshops.
Going through the requirements with the team shall in real time provide the tech lead and product owner to break down the requirements into EPICS, User Stories, and Tasks within JIRA (I've always used JIRA, but the same concept also applies to other similar tools - start with the big tasks/modules/features and logically break them into smaller chunks, such as simple tasks). Providing granular detail instills clarity across the team as well as enables a more accurate estimation of the task (the length of time required to achieve the task per resource). Typically, aim to breakdown a task between 0.5 - 5 days per task. If more effort is required, keep trying to break this down further if at all possible.
Fulfilling this exercise shall provide a clear plan to the development plan of the product. Furthermore, the company shall be provided with a clear cost/investment pertaining to the solution.
In theory, this exercise will get better as the PM keeps going through such cycles, getting better and better every time, learning from lessons learnt in the past. Such an exercise will never be nailed 100%, since there are always going to be missing elements - but this is what the product journey is all about, nurturing a solution from its infancy up to its maturity.
Google Sites
Report abuse