Wednesday, September 2, 2009

Say No in a Delightful Way [Tanya Berezin]

We’ve all been there: your product manager comes to you with a great feature idea. You – the engineering manager – know your team is already stretched implementing the other great features scheduled for the next release. You offer to prioritize the new feature against others already scheduled and the two of you agree on a reasonable scope for the release.

It’s all very logical but doesn’t feel good. The product manager is disappointed with you: you always seem to throw cold water on his ideas. And you are annoyed, too: you wish the product manager would let you focus on delivering what’s already agreed on. Time to try something different.

Do you know why the product manager is excited about the feature? Find out: have her walk you through her thinking – what customer need does the feature meet? How many customers might need it? Is the need urgent? Are we going to make more money from it?

As you think through these questions together, the PM begins to see that you both are genuinely interested in making the product better for your customers. All of a sudden, you seem a lot less rejecting – a win for your relationship. In addition, if your PM is inexperienced and has no answer to these questions, you’ve just taught her how to be a better product manager. And if this conversation leads you to conclude that the idea isn’t as hot as it seemed at first, the extra work for your team has been headed off, never to come back.

Let’s suppose you, too, are now a believer. Are you sure your customers will be as enthusiastic as the two of you? With a little ingenuity you can find a way to test the feature with customers without needing any engineering work upfront (think low fidelity prototypes, user surveys, etc.) Thus, you and your PM have moved forward with the idea while your engineers still haven’t been handed any extra work.

(This isn’t as much work as it may seem – many times, I’ve done both of these steps in a 30 minute meeting. Last time, as the PM left my office, eager to get started, she said: “I came to ask for engineering time and you just said ‘no’ to me, didn’t you? But I couldn’t be happier. How did you do that?”)

OK, you’ve tested the feature with customers and they seem really jazzed about it. Is now the time to have the re-prioritization discussion we started with? Not quite yet; instead, can you think of a different way to meet the customer need using the features you already have? All the research you’ve just done may give you ideas on how to do that. If you do, the extra work for the new feature may never need to be done.

If after all this you are still convinced that the new feature is worth the extra development effort, then you should put it in your backlog and prioritize. But this time, the prioritization discussion will feel very different: the product manager won’t feel thwarted and you won’t feel jerked around. In fact, you’ll be delighted with each other!

Tanya Berezin is a successful software development leader who consistently delivers complex, bet-the business, need-it-yesterday projects. She enjoys building high-performing teams who delight customers with easy to use products. Find more information about her at http://www.linkedin.com/in/tanyaberezin

2 comments:

David Skyberg said...

Amen!

You are pointing to what I consider to be a classic software leadership anti pattern. The "It's my job to say no to product management" anti pattern.

Product management and software engineering are two sides of the same product development coin. The PM and the engineering manager should be very close partners working together to identify market need and develop products to fulfill those needs. The closer we work together, the more likely we are to share a common understanding of the market needs, the appropriate solutions, and the capacity of the build team to deliver.

Tanya Berezin said...

David,
thank you for your comment. As you point out, "pushing back" on product management is part of being a good engineering leader. I find that some engineering managers take it too literally and say no to just about everything; others say yes to too much. The right balance is based on user and business needs - never on ego.
Tanya