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/

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

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

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

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

15. Stakeholder buy-in

16. Design by committee

26. Design by committee
In a hierarchy every
employee tends to rise to
their level of
incompetence
“
{The Peter Principle}

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

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

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

30. The user experience validation stack
http://www.uxbooth.com/blog/winning-a-user-experience-debate/

31. Last mile
problems

32. People issues

34. Silence vs.
Violence
Masking
Avoiding
Withdrawing
Controlling
Labeling
Attacking

35. Commit to seek mutual purpose
Recognise the purpose behind
the strategy
Invent a mutual purpose
Brainstorm new strategies
Making it safe

36. Delivery issues

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

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

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

41. Sell a team driven by:
Priorities
Action
Timelines
Meetings

42. A few notes on distributed teams
Meet in person. Now.
Be respectful of time zones.
Use the right technology.

44. A few notes on distributed teams
Meet in person. Now.
Be respectful of time zones.
Use the right technology.
Keep it human.

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

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

48. A roadmap to serenity
How to stay sane as a Product Owner
Rian van der Merwe
@RianVDM
rian@elezea.com