Email
Favorite
Favorited ×
Download
Embed
Private Content
Copy and paste this code into your blog or website Copy Customize Close
We have emailed the verification/download link to "".
Login to your email and click the link to download the file directly.

To request the link at a different email address, update it here. Close
Validation messages. Success message. Fail message.

Check your bulk/spam folders if you can't find our mail.

Tweet

Loading…

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

The Product Owner's Guide to Saying No

by alexpukinskis on Jul 12, 2010

945 views

From the Agile Roots conference in Salt Lake City, June 2010. Agile Product Owners are under a lot of pressure. On one side, customers, stakeholders, and users provide a constant stream of requests a...

From the Agile Roots conference in Salt Lake City, June 2010. Agile Product Owners are under a lot of pressure. On one side, customers, stakeholders, and users provide a constant stream of requests and demands. On the other side, developers own their estimates and commitments. It’s easy to take on too much work and resort to heroic prioritization to try to make things fit. This talk is targeted at Product Owners, Product Managers, business stakeholders, or technical managers who are struggling with too much work.

Accessibility

View text version

Categories

How-to & DIY

Tags

agile product manager product owner pm

Upload Details

Uploaded via SlideShare as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

File a copyright complaint

Statistics

Favorites: 2
Downloads: 0
Comments: 0
Embed Views: 0
Views on SlideShare: 945
Total Views: 945

I was here last year and gave a talk about product councils. Was anyone here for that talk?I talked about how stakeholders get addicted to constant change, talked about “Getting Drunk on Agile”.
And then I talked about how form a product council, how to get your stakeholders together on a regular basis in one room, how to use a Kanban to flow your requirements, and how this would make your stakeholders happy.This year, I’m here to talk about something different. I now believe that
If you worry too much about hurting your stakeholders’ feelings you will build crappy products.
I was talking to my brother a few days ago, and he reminded me of this somewhat famous email.
Someone was asking for a kernel debugger, and they were arguing that it would make things better, and they could add new features faster. Does anyone know if there now is Back in 2000, LinusTorvalds was commenting on this.
And, in fact, the majority of my job, involves saying no in different ways
This talk is divided into 4 parts, with 60 slides. Hopefully we’ll go quickly enough to finish on time with time for questions.
Who owns quality? What behaviors lead to quality?
Why did Linus feel it was so important to say no?Why do I think it matters?
Your product will get better and you’ll make more money.
I asked our coach this the other day as I was preparing the talk, and she said “the team” owns quality.
That means all kinds of different people.
Developers have a certain responsibility for code quality, because the rest of us can’t see it; we can only see its manifestations.
The level of doneness of a feature is obscured from executives.
PO has to own quality too. Executives aren’t talking to users every day – they don’t know the details. All they see are the symptoms. Executives are trusting the product owner to make good decisions about quality.
It’s very easy to end up in this situation where you have lots of partially completed work. So you need to say no.
easy answer – say no to everything37 signals approachDon’t even keep a list.But what do you work on?Jeff Patton alluded to this earlier. If we could just know which features are never going to be used, we could choose not to build them.But there are some techniques that can help.
Moscow prioritization is the tool I use most.It works great for featuresand for projects within a productand also initial product planning.
If you don’t know, this is how it works.You separate out those features that are rarely or never used and don’t build themAgile 101 stuff.Must Haves – can’t go without.Should Have – embarassing. etc.You can ship with just the must haves
There is danger in skipping the should haves.
The “Could Haves” are important too. It’s always tempting to move on to the next feature, the next product.
Some things are easy to say no to. Out there – no demand. Things that don’t add much value. I want integration with this tool that nobody else uses for this purpose. You can
Personal pet features. There are a bunch of things I really want in our product. Bulk delete is a good example.
Some things are actually really well aligned, but they’re not in the top 3. They’re not on your roadmap for right now, or for this year.The question is not, “Is this thing an incredible opportunity”. The question becomes, “Is this the best possible opportunity?”
Who remembers the dragon from the beginning?
RQM story
because how you say no is important in getting away with it.
Watch out for your spouse.
The fact is, you are working on other stuff that’s great.Ask for feedbacketc.
It’s not that you’re never doing their feature. It’s just that you’re not doing it NOW.After 8 years, kernel debugging finally went in in 2008.
If you’re struggling with quality, do this one thing – make a list of the top 3 most painful items to stop doing, and figure out how to do them.

2 Favorites

Murali Veeraiyan , MBA Student at Kellogg School of Management Tags pm 1 year ago
Anupam Kundu at ThoughtWorks 1 year ago

The Product Owner’s Guide to Saying No — Presentation Transcript

the product owner’s guide toSAYING NOAlex Pukinskis
product councils make stakeholders HAPPY
stakeholder happiness is theWRONG GOAL
great products come fromSAYING NO
4parts
where does QUALITYcome from?
whySAY NO?
how to knowwhat toSAY NOto
how toSAY NO
start doingPAINFUL PRIORITIZATION
PART 1
Who owns quality on an Agile team?
(Dirty Kitchen photo)
Sample Definition of Done
Why does making everyone happy lead to crappy products?
an infinite number of GOOD IDEAS
a smaller infinite number of GREAT IDEAS
it feelsGOODto sayYES
PART 2
HOW TO KNOWwhat toSAY NOto
say no toEVERYTHING
Must HaveShould HaveCould HaveWon’t Have
there isVALUEbefore you’re done
VS
popular, nonaligned features
is this the BEST POSSIBLE THINGto work on now?
is this in theTOP 3?
PART 3
how toSAY NO
5tips
Listen
LISTENING
is part of saying no
don’t listen too much
What expectations are you setting?
Can I have a cookie?
theREDIRECT
great products come fromSAYING NO
your product willTHANK YOU
Moscowhttp://www.flickr.com/photos/thisisbossi/2913641673/sizes/l/