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/
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.
“
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
10.
11.
12.
13.
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
“
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/
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.
43.
44. A few notes on distributed teams
Meet in person. Now.
Be respectful of time zones.
Use the right technology.
Keep it human.
45.
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