A product manager asks: How long will it take to build this feature?
The two most frequent origins for this question are as follows.
- The product manager wants to assign priority and would like to understand how long the feature takes to implement.
- A customer wants a feature and would like to know when he can get it. Sometimes this comes from sales who would like to sell a feature that doesn’t exist.
Assigning feature priority based on how long a feature takes is a mistake, and trying to sell a feature that doesn’t exist should be allowed regardless of how long it takes to implement.
Let’s examine a few possible answers to the “how long does it take” question.
The feature is beyond our capabilities.
I give this answer every time I see a big gorilla of a feature that I don’t understand or that I understand too well. It represents a change in direction and a massive investment. We go into a room and whiteboard the feature, break it down to tasks, divide and fail to conquer. The product manager gains understanding of how hard the problem is. At best, he leaves with a bitter taste in his mouth. Sometimes he quietly thinks we’re a bunch of clowns that can’t deliver anything. The natural reaction is to ask how many people would it take to implement this, which eventually turns into a nine pregnant women problem making one child.
I got interrupted, pulled into a room and had to invent the innards of a really big feature that I don’t even fully understand. I am unhappy that I can’t deliver this ever in my team’s life, but somewhat relieved that I could defend myself. As a fallout, there’s a very unhealthy tension created by this exercise.
We’ll either start negotiating the feature set down (see next paragraph) or the customer will be told that he can’t get the feature. The latter almost never happens, because sales people would never leave the customer disappointed (it hurts their quota). The answer is likely to be that this is on our roadmap – an answer that the product manager could have given in 30 seconds.
The feature will take a very long time to implement.
In most cases I’ve seen the product manager begin to negotiate the feature down to a reasonable functional set in order to bring this ridiculous unacceptable estimate into submission. We go into a room and whiteboard the user experience, break the feature down to smaller subtasks, divide and sometimes even conquer. The product manager has gained understanding of what it takes to build something. In 99% of the cases the feature is cut in pieces, without having any impact on the feature priority.
How do I feel? I got interrupted, pulled into a room and was asked to invent the innards of a feature that nobody will be working on (at least not in this sprint), on-the-fly. I am unhappy and have probably missed something really important while discussing this. I also kept thinking that I need to get back to those important things I am working on right now.
The feature will take a couple of days.
This is the good news. The product manager happily goes away. The feature priority hasn’t changed. Also, nobody is going to be working on this feature until the next sprint. This is a travesty, we’ve achieved nothing.
I hope you can see the trend. In all cases I will come out unhappy with the interruption and the PM will get no information that influences feature priority. This is because features, priority and implementation are independent variables.
Are you still asking why you shouldn’t set a feature priority lower if it’s really big and not so important? If it’s not so important, just lower its importance in the backlog. As a product manager in an agile organization you’re not setting the order of execution, you’re setting priority. Priority is an indication for the development team of what’s important to the customer (or the company or the organization). You must learn to trust your development team to pick a balance of achievable low hanging fruit and big feature investments overtime.
As an engineer, I recommend product management folks follow these rules of thumb.
- Learn to never ask an engineer for how long something will take, instead set feature priority and product direction.
- If you have a deadline for a feature (a demo to an investor or something contractual), express it in those terms. The team understands and will do its best to build it. Check in on the progress by running the product yourself and attending sprint demos, not by demanding status e-mails.
- If a customer wants to pay for a feature, sell it now for a lot of money. Loop in the development manager so that he can tell the team, align the ducks and make a date. Nothing speaks better about priority than money in the bank.