Paul’s 3rd Postulate of Product Management

He might give you an optimistic estimate...This is the 3rd in my series of The Postulates of Product Management. Closely related to an earlier post about accuracy in scheduling, this also deals with Development:

Development’s initial estimate of time to develop a product or feature will be at least 50% aggressive or 50% conservative.

The fun thing about Product Management is you have to figure out which it is.

Developers generally have good intentions. Usually they’re not out to get you and want to forecast their time accurately because it (can) make their job easier. If I know I can trust a developer based on my past experiences with their estimates, I’m less likely to ping them for regular updates. Programmers hate that because each interruption to their workflow (drive-by meeting, phone call, IM chat, email) takes approximately 15 minutes to recover from and rebuild the mental model required for programming. Joel on Software writes:

We all know that knowledge workers work best by getting into “flow”, also known as being “in the zone”, where they are fully concentrated on their work and fully tuned out of their environment. They lose track of time and produce great stuff through absolute concentration. This is when they get all of their productive work done. Writers, programmers, scientists, and even basketball players will tell you about being in the zone.

The trouble is, getting into “the zone” is not easy. When you try to measure it, it looks like it takes an average of 15 minutes to start working at maximum productivity. Sometimes, if you’re tired or have already done a lot of creative work that day, you just can’t get into the zone and you spend the rest of your work day fiddling around, reading the web, playing Tetris.

The other trouble is that it’s so easy to get knocked out of the zone. Noise, phone calls, going out for lunch, having to drive 5 minutes to Starbucks for coffee, and interruptions by coworkers — ESPECIALLY interruptions by coworkers — all knock you out of the zone. If you take a 1 minute interruption by a coworker asking you a question, and this knocks out your concentration enough that it takes you half an hour to get productive again, your overall productivity is in serious trouble.

As a programmer in a prior life I can attest to the truth of this statement. So try to leave your programmers alone as much as possible.

The problem with estimates from programmers is that they are human, and as much as they’d like to deny it, their emotions do affect their ability to give you good scopes of work, even with well written requirements. Programmers don’t like routine issues that they’ve solved in different products, bugs (except for the rarest breed of programmers), and UI enhancements. In fact, most programmers secretly (some openly!) seethe at their end-users for being “dumb” enough to require that STUPID user interface fix.

On the other hand, most programmers enjoy new problems they haven’t conquered before. This leads to overly pessimistic estimates on routine or cost reduction/quality improvement products and features, and overly optimistic estimates on new and exciting products and features.

To solve for this problem, well written requirements are a prerequisite. Once you have those, if you feel like you’re being given too aggressive or conservative estimates, drill into each requirement. Ask “For this requirement, how are you going to implement that?” If you get hand-waving, dismissal “oh that’s easy, that’s nothing, I can do that in 15 minutes,” or furrowed brows and “that will take 4 months MINIMUM” than your PM BS detector should start to go off. Optimistic estimates are usually easy to disarm because the developer in their excitement may have forgotten parts of their estimate and you can redirect their energy.

Pessimistic estimates are more difficult because developers can play The Game with you for as long as they want and you can never win because you’re on their turf. When I feel The Game coming on from a developer, I try to short circuit it by first showing them that I know they are playing The Game with me and then relying on a personal connection I have made with him/her in the past. It’s amazing how fast you can disarm someone with:

C’mon Sergio, remember Feature X from Product Y two releases ago? That wasn’t so different than this. I feel like you’re giving a lot of pushback on this feature – can you help me understand why? …By the way, I’ve had a lot of positive feedback from customers on Feature Z that you proposed the other day

As always, I am interested in how you solve for this issue, please comment below.

Previous Post Next Post

No Comments

Leave a Reply