Product owner

From Pearl Language
Revision as of 14:43, 14 March 2012 by Martien (talk | contribs) (Added some sources.)
Jump to navigation Jump to search

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?

Key Succes Factors

For success, a product owner must be:

  1. Empowered—Able to make decisions, guide and push back on stakeholders. Delays in decision making slow down the team.
  2. Qualified—Experienced in the product domain, the development technology, process and practices, and core personal skills.
  3. 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:

  • Business Analysts help to define business needs and elaborate them for the rest of the Team.
  • 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.

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.
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

Retrieved from "http://pearllanguage.org/index.php?title=Product_owner&oldid=208"