Product owner
As product owner…
| You ought to | Own, elaborate and communicate the product vision
…business representatives best understand the business needs. It is next to impossible for teams to rely on their initial understanding of the domain. |
| Formulate the unity of purpose
…many teams have rocky beginnings as people struggle to work together.Team members may come from different backgrounds, with different experiences. Therefore, the product owner ought to instill a common product vision and unity of purpose in all members of the team. | |
| Limit yourself to tell what needs to be done.
…the team excels in mastery in their profession. You only have to tell them what needs to be done in order to get the best out of them—they know how. Of course, also tell them why, for whom, and when you need what. | |
| Explain why it needs to be done.
…understanding how each feature fulfills a need and creates value enables the team to discover utility and meaning in what they do. | |
| Order product backlog items according to market and user value.
…features are not all of equal priority, and their value is not always obvious up front. Features ordered primarily by ease of delivery may reduce the return on investment. | |
| Choose what and when to release.
…feature sets can be delivered whenever they are ready, rather than only at the end of the project, facilitating incremental funding, providing incremental ROI and yielding valuable feedback. | |
| Create and garden vibrant personas.
…achieve seamless alignment between vibrant personas and scenarios define outcome by making sure that a relevant vibrant persona exists and is used for each user who you target. Use your vibrant personas to make quick and wise design choices. | |
| Prepare and refine user stories until they are ready to build.
…user stories that meet invest criteria joined with an evolving ready to build lead to a comprehensive, yet flexible, product backlog that feeds the development team into flow. | |
| Groom the product backlog based on feedback and changing conditions.
…initial requirements are often far from perfect and change constantly and may not cover every need or even be needed. Feedback can inform conscientious product tuning rather than being ignored or addressed reactively. | |
| Keep a short, iterative, sustainable, and predictable design cycle.
…scrum’s short 2–4 week sprints are ideally suited to create a predictable and sustainable development rhythm, a cadence that may eventually become the pulse for the organization as a whole, for your market, even. Walk shoulder to shoulder with your scrum master to do so. Consider establishing a season beat. | |
| Perform acceptance tests to meet the criteria of ready to ship.
…ensure that stakeholders understand that the outcome of a sprint is not a finished product, yet make sure to get everyone’s consent on what’s considered done. Evolve that definition. | |
| You ought not to | Manage the work of others
...your job is to create a product that works as advertised and that people want to buy.The team creating it is an autonomous, purposeful lean machine of masters in their profession. Feed them with purpose. Do not (micro) manage them. |
| Tell anyone how to do their job.
…the team implementing your product vision displays mastery in their activities, knowledge, and skills. Let them work out how it’s done while you feed them with product vision and what needs to be done. | |
| Create your product in a vacuum.
…your work is interwoven with the work of every other team and is part of a larger whole. Involve cross-functional teams in your reviews and retrospectives. Keep an open mind and foster new ideas. | |
| Lose sight of the purpose behind your product.
…in agile settings, scope varies, so let scenarios define outcome to drive the required applications, features, user roles, dependencies in a collaborative workflow. |