|
|
|
*This document is part of the ['Organization'](/handbook/organization/Organization) chapter of the Sinergise Operational Handbook.*
|
|
|
|
|
|
|
|
----
|
|
|
|
|
|
|
|
## Product Owner Role
|
|
|
|
|
|
|
|
As the teams now assume many responsibilities that are traditionally held by project managers, the responsibilities and workload of the product management role is considerably lower than that of a typical project manager.
|
|
|
|
|
|
|
|
Responsibilities not assumed by the teams will fall under the product owner role:
|
|
|
|
- understanding and representing the customer’s needs
|
|
|
|
- act as the primary user of the product
|
|
|
|
- interpreting high level requirements and conveying them to the teams
|
|
|
|
- high-level communication with the customer
|
|
|
|
- aligning teams’ priorities with customer’s priorities
|
|
|
|
- setting priorities on the level of user stories or use cases, i.e. selecting work to be done and work to be deferred
|
|
|
|
- aligning teams' priorities with other product owners
|
|
|
|
- management should be involved when consensus between product owners cannot be achieved
|
|
|
|
- planning milestones and estimating effort to achieve the milestones with the teams
|
|
|
|
- aligning customer’s expectations
|
|
|
|
- coordination of product work between multiple teams
|
|
|
|
- accepting implemented requirements (features, documentation, etc.); has a final saying when requirements are done (well enough)
|
|
|
|
- clearinghouse of information on the product; keeps the whole product in their head so that people can use them as a resource to check decisions against
|
|
|
|
- communicating status to the management and the customer
|
|
|
|
|
|
|
|
The product owner is NOT responsible for:
|
|
|
|
- setting technical direction
|
|
|
|
- delegating work to individual team members
|
|
|
|
- setting priority on the level of (implementation) tasks
|
|
|
|
|
|
|
|
If the product owner has other roles on the product or in the team (dev, coordinator, etc.), they might be responsible for the above in other roles, but should be careful to avoid any conflict of interests.
|
|
|
|
|
|
|
|
Additional responsibilities of the product owner do not warrant an explicit compensation scope modifier, as the responsibility area and scope should be implicitly increased by assuming these responsibilities.
|
|
|
|
|
|
|
|
Product owners are assigned by the management and should ideally be picked from one of the teams working on the product.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## Products instead of Projects
|
|
|
|
|
|
|
|
Even though majority of our work is scoped and funded as projects, scope and requirement changes always creep in, usually after the all-or-nothing delivery when reacting to these changes becomes costly and stressful.
|
|
|
|
|
|
|
|
As we believe it is not necessary to be building a product in order to organize software development in a product-mode, we want to focus our operations on being product-aligned, rather than from project-aligned.
|
|
|
|
|
|
|
|
Even when it is not possible or sensible to convince a client to work in a product-mode, we can internally work in this mode and validate results.
|
|
|
|
|
|
|
|
See the [teamwork guidelines page](/handbook/organization/Organization-of-Teams#teamwork-guidelines) for pointer on executing this in practice.
|
|
|
|
For a rather long, but detailed explanation with an example, see [Martin Fowler's post on this topic](https://martinfowler.com/articles/products-over-projects.html).
|
|
|
|
|
|
|
|
|
|
|
|
### Projects:
|
|
|
|
- have a clear definition of what needs to be delivered and a clear delivery schedule
|
|
|
|
are of temporary nature
|
|
|
|
- after completion the project group moves to work on another project
|
|
|
|
- released in all-or-nothing deliverables
|
|
|
|
- validated by formal approvals
|
|
|
|
- difficult to evaluate intermediate results
|
|
|
|
- unavoidably followed by iterations of change requests and bug fixes
|
|
|
|
- traditionally managed with waterfall methodologies
|
|
|
|
|
|
|
|
### Products:
|
|
|
|
- have a rough definition of what and when needs to be delivered
|
|
|
|
- have no clear completion date (think of maintenance and support phase)
|
|
|
|
- are owned by stable, long-lived teams
|
|
|
|
- released in increments
|
|
|
|
- fast feedback allows to fail fast and react quickly
|
|
|
|
- embrace changing requirements
|
|
|
|
- usually managed with agile methodologies
|
|
|
|
- product development is a continuous process of improvement of the product through the delivery of new features
|
|
|
|
|
|
|
|
----
|
|
|
|
Document history:
|
|
|
|
|
|
|
|
|Date|Author|Change Description|
|
|
|
|
|----|------|------------------|
|
|
|
|
|2021-04-30|mkadunc|Migrated and adapted from [the original reorganization PDF](https://git.sinergise.com/operations/docs/-/blob/master/reorganization.pdf)| |
|
|
\ No newline at end of file |
