Product owner

Product ownership as it is often interpreted requires a polymath, since a product owner is:

• Entrepreneur
• Business Expert
• Product Manager
• Internal Customer Representative
• Technology Expert
• User Experience Expert
• Subject Matter Expert
• Designer
• Communicator
• Decision Maker

Effective real-world product owners collaborate with their development teams to do most of this. 
But how does it work?

The product owner is a conduit between the client's needs and the crew able to fulfilling them.

When the work is simply too much for a single product owner, split it up between a strategic product owner and tactical product owner. Sometimes, these roles are named chief product owner and product owner.

Key Succes Factors

For success, a product owner must be:

1. Passionate—Obsessed with delighting users and customers, the product owner sparks enthusiasm in everyone, creating a yearning for the sea that builds great ships.
2. Empowered—Able to make decisions, guide and push back on stakeholders. Delays in decision making slow down the team.
3. Qualified—Experienced in the product domain, the development technology, process and practices, and core personal skills.
4. Available—Able to work with the development teams quickly, or customer to understand needs. When split across multiple initiatives, you are unable to fully focus.

Product Owner Crew

A product owner represents many constituents with a single voice. Busy product owners need not—and should not—act alone. Often, a product owner assembles a product owner crew that includes roles that might assist like:

• agile business analysts help to define business needs and elaborate them for the rest of the Team.
• agile architects help to secure the product's structural cohesion, consistency and completeness.
• Developers provide available execution paths and describe their respective costs and benefits.
• User Experience Experts and marketing resources help to elicit and explain end user needs and desires.

Sultans of Swing

As one of the three amigos, the product owner is a member of the sultans of swing.

Pushing for delivery can be just as lonely as leading a team. By working so closely together with both a {{p|flow master{{ and an agile coach you gain a multitude of benefits. One of the most important ones is focus, it allows you to focus on delivery of enhancements to the products you are responsible for because you know that the other two equally important aspects of team leadership are covered by the other to amigos.

Mystifying incidents of the past such as for example a sudden lack of commitment by an engineer for some time became a lot clearer with the added information from the agile coach on the personal situation of that engineer. The agile coach opens up entirely new ways of handling typical issues with the team. (Source: DevOps @ Spotify)

The second most important benefit I see is the typical thorny problem of avoiding (or repaying) technical debt. An open discussion between people representing the different interests involved makes it easier to approach this problem. Otherwise, it's just an internal debate in a single person's head.

Daily Scrum

As product owner, your primary goals during the daily scrum include:

• Listening!—This is your clearest window into detailed progress.
• Addressing Team Issues that fall within your sphere of influence.
• Gauge Visual Clues on the scrum wall like a flatliner on the burndown chart.
• Providing your own status and issues, where appropriate.

Product Owner Excellence

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.
	Drive collaborative product discovery …A broad, deep and cross product ownership team plans and facilitates product discovery. Business stakeholders, users, subject matter experts, and the development team participate in various activities of the discovery.
	Garden a comprehensive story map …the collaborative product discovery results in a solid story map that in turn is skimmed and flows into the product backlog.
	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.
You should	Identify key moments to present your results. ...starting with storyboard scenarios, demonstrate the evolving product at the end of each sprint during the sprint review meeting, soliciting feedback from key stakeholders. Keep everyone excited and interested. Decide on how the feedback will be reflected in the product backlog. Demo or die!
	Involve interaction design appropriately. …design the product around your users by professionals who master the art of interaction design and usability. Engineers excel in engineering, not in usability.
	Leverage and archive existing prototypes. …to use ideas and/or other results from earlier efforts, keep them around. Explore efforts—like market research—of others in the same area. It may speed up development.
	Perform regular usability tests. …regular and affordable usability tests where the whole team watches someone use your product are often eye-opening. Observe… Do they get it? Can they find their way around? Expect head slappers, shocks, inspiration, and passion. Brace yourself, yet do not panic.
You should not	Solicit feedback from too wide an audience. …pleasing everyone with your work is impossible. In fact, you should not even try. It wastes the time of your best clients and annoys our staff. Please some less to please others a bit more. Ask for forgiveness for focussing on those customers we’re trying to delight.
	Drown in detail. …perfect is the enemy of good enough.There are times later in development where you can determine detailed information or where it becomes the visual specification for the final product. Focus on relevant potentially shippable product and candid feedback instead.

Sources

• http://www.pragmaticmarketing.com/publications/topics/09/the-mythical-product-owner-1
• http://kasperowski.com/2010/11/my-product-owner-will-kick-ass.html

Entrepreneurship

• http://zenhabits.net/unknowing/