Roadmap to serenity - How to stay sane as a Product Owner

5,006 views
4,636 views

Published on

Product Ownership can be fun, but it can also drive you to insanity. This talk will cover experiences, tools and tips to be an effective Product Owner when working with a variety of teams and personalities, with some specific focus on distributed teams.

Please see the blog post about this talk at
http://www.elezea.com/2010/11/product-manager-sanity/

Published in: Technology, Business

Roadmap to serenity - How to stay sane as a Product Owner

  1. A roadmap to serenity How to stay sane as a Product Owner Rian van der Merwe @RianVDM rian@elezea.com
  2. Distance Joy Starting line The stride Last mile begins Finish line First mile done
  3. Project timeline Starting line The stride Finish line Sanitylevel First mile done Last mile begins
  4. The Product Owner represents the voice of the customer. He/she ensures that the Scrum Team works with the right things from a business perspective. The Product Owner writes customer-centric items (typically user stories), prioritizes them and then places them in the product backlog. “ The Product Manager is responsible for delivering measurable business results through product solutions that meet both market needs and company goals. “
  5. First mile problems
  6. Aligning the team
  7. These have their feet firmly planted in the mud of the practical world, and yet stretch far enough to stick their head in the clouds when they need to. Furthermore, they simultaneously span all of the space in between. …rise above the specifics of a particular problem to think about them in a more abstract, and in some ways, more general way. “ http://www.businessweek.com/innovate/content/jul2009/id20090713_332802.htm
  8. Head in the clouds Communicate a vision Show how you plan to get there And I do mean SHOW (yes, use pictures) Remain flexible Be in the details Communicate clear expectations, then trust Don’t hover! Learn what you don’t know Feet on the ground
  9. For creative thinkers, [there are] three key motivators: autonomy (self-directed work), mastery (getting better at stuff), and purpose (serving a greater vision). All three are intrinsic motivators. As creative thinkers, we want to make progress, and we want to move big ideas forward. So, it's no surprise that the best motivator is being empowered to take action. When it comes to recommendations for creative leaders, [authors of a recent study] don’t mince words: “Scrupulously avoid impeding progress by changing goals autocratically, being indecisive, or holding up resources.” In short, give your team members what they need to thrive, and then get out of the way. http://the99percent.com/articles/6943/what-motivates-us-to-do-great-work “
  10. Stakeholder buy-in
  11. Design by committee
  12. Design by committee In a hierarchy every employee tends to rise to their level of incompetence “ {The Peter Principle}
  13. Design by committee The Dunning–Kruger effect is a cognitive bias in which an unskilled person makes poor decisions and reaches erroneous conclusions, but their incompetence denies them the metacognitive ability to realize their mistakes. The unskilled therefore suffer from illusory superiority, rating their own ability as above average, much higher than it actually is, while the highly skilled underrate their abilities, suffering from illusory inferiority. This leads to the situation in which less competent people rate their own ability higher than more competent people. It also explains why actual competence may weaken self- confidence: because competent individuals falsely assume that others have an equivalent understanding. “
  14. Product should be a dictatorship, not consensus-driven. There are casualties, hurt feelings, angry users. But all of those things are necessary if you’re going to create something unique. The iPhone is clearly a vision of a single core team, or maybe even one man. It happened to be a good dream, and that device now dominates mobile culture. But it’s extremely unlikely Apple would have ever built it if they conducted lots of focus groups and customer outreach first. No keyboard? Please. -- Michael Arrington “
  15. Design by committee The sensible answer is to listen, absorb, discuss, be able to defend any design decision with clarity and reason, know when to pick your battles and know when to let go. “ Respond to every piece of feedback Note what feedback is being incorporated Explain why feedback is not being taken Use the UX validation stack
  16. The user experience validation stack http://www.uxbooth.com/blog/winning-a-user-experience-debate/
  17. Last mile problems
  18. People issues
  19. Silence vs. Violence Masking Avoiding Withdrawing Controlling Labeling Attacking
  20. Commit to seek mutual purpose Recognise the purpose behind the strategy Invent a mutual purpose Brainstorm new strategies Making it safe
  21. Delivery issues
  22. It’s important to know the business inside and out and have a clear trajectory where we’re headed. But there is a point where planning becomes overplanning. All that time spent planning is time spent not doing. http://tomfishburne.com/2010/10/waterfall-planning.html “
  23. I’ve been working on a way to balance the benefits of Gantt charts (ability to input dependencies and adjust an entire schedule with the push of a button) with the best way to communicate project schedules to clients. Most people can’t read a Gantt chart, and no client should have to. Gantt charts are more useful for planning next steps than providing an at-a-glance project status anyway. “ http://weblog.muledesign.com/2010/10/project_managers_not_calendar.php
  24. Meetings may be toxic, but calendars are the superfund sites that allow that toxicity to thrive. All calendars suck. And they all suck in the same way. Calendars are a record of interruptions. And quite often they’re a battlefield over who owns whose time. “ http://weblog.muledesign.com/2010/10/the_chokehold_of_calendars.php
  25. Sell a team driven by: Priorities Action Timelines Meetings
  26. A few notes on distributed teams Meet in person. Now. Be respectful of time zones. Use the right technology.
  27. A few notes on distributed teams Meet in person. Now. Be respectful of time zones. Use the right technology. Keep it human.
  28. A few notes on distributed teams Meet in person. Now. Be respectful of time zones. Use the right technology. Keep it human. Trust each other.
  29. A few notes on distributed teams Meet in person. Now. Be respectful of time zones. Use the right technology. Keep it human. Trust each other. Don’t stop talking, especially if you disagree.
  30. A roadmap to serenity How to stay sane as a Product Owner Rian van der Merwe @RianVDM rian@elezea.com

×