You just missed your target release date and the vice president of sales is on the phone with your boss right now, expressing his displeasure at your tardy delivery. To make matters worse, your development team is subtly refusing to provide an updated delivery target by saying ”things are just too mushy yet to give a date.” But, the product was due for general release yesterday! How can it possibly be that mushy?

It’s starting to feel like you’re working AGAINST your own team. You’re butting heads with their manager, and you’re not getting anywhere. They seem to be dug in, refusing to promise delivery on any particular date.

You had planned to spend the upcoming two weeks reviewing requirements for the next release. Instead, you resign yourself to spending at least that much time putting out the fires caused by late delivery. Sales already knows, and you’ll have to deal with that. And marketing will need to adjust their promotional plans. Some customers, who were expecting delivery on this date, need to be notified of the delay and you are not looking forward to making those phone calls.

Does this sound familiar to you? Does this phenomenon occur with your product team?

First, take some comfort in knowing that you are not alone – this happens to many product managers, and none of us really appreciates it. Second, understand there are ways to avoid it (most of the time, anyway).

There are many factors which affect scheduled delivery. Over the years, I have watched this situation many times, and unlucky enough to be that panicked product manager occasionally. While there are many contributing factors, I have come to believe that there is one core issue which affects nearly all delays in software releases. The issue is one of TRUST.

Picture this: It’s early in the release cycle. You’re discussing requirements with your boss and the VP of marketing. You describe the problems you intend to solve in this cycle, and answer lots of questions on content and your logic regarding priorities. You really know your stuff, so the questions aren’t too scary for you. You’re feeling confident, because you’ve done your homework and you KNOW these requirements are right.

Somewhere in that conversation, you get asked a subtle yet dangerous question. ”When’s this going to be ready?” It’s thrown in there like your boss is a media person; the dangerous question mixed right in with the easy ones that make you feel smart. How do you answer?

Many of us, especially early in our careers, make the mistake of throwing out another (seemingly) confident answer, based on whatever we know at that point in time. “Well, I talked to Dave the other day, and he said this should be pretty easy.” Or better yet, “Like it says in the requirements, delivery is targeted for January 23rd.” This is a natural reaction, if you think about it – we all want to know the answers, and we’re proud of our ability to provide the necessary information. However…

You have just trodden into a deep quagmire. Dave, the manager of your development team, had shared that information with you in a casual conversation. His engineers had not looked at the requirements yet, but in his opinion this shouldn’t be too hard. The requirements weren’t approved yet, or even reviewed for that matter – so the January 23rd date is pretty much a fantasy generated from your imagination, and some market knowledge too, but are you the one who will code it?

Now you’ve given an impression that it shouldn’t be that difficult to get this out the door in January. 

Later on, reality will set in. Development will review the requirements, and you’ll discover that you need to set a few of the market problems aside for now, in order to come up with an agreeable timeframe. Your engineers, testers, and writers will study the problems and start learning how long it will take to solve them in an agreeable manner. Eventually you will come up with a solid, predictable plan for delivery. Chances are, it will not be January. 

The problem, though, is your boss and the vice president of marketing have already shared your opinion with the organization and everyone is now expecting a January delivery. Even if your team can deliver by mid-February, it will still appear to be late to some people.  Essentially, you have inadvertently set your team up to fail.

Carl Sandburg comes to mind here, with a poem I think I learned in the 6th grade. The title is “Primer Lesson”.

Look out how you use proud words.
When you let proud words go, it is not easy to call them back.
They wear long boots, hard boots; they walk off proud; they can't hear you calling--
Look out how you use proud words.

As a product manager, the best way to help yourself get reliable, predictable delivery targets is to learn how to say “I don’t know” when this conversation comes up. Early in the release cycle, you simply must avoid giving impressions of a delivery timeframe. Once you talk about it outside your team, that impression will stick, and it will almost always be damaging.

There are secondary ramifications, as well. Imagine being an engineer on this team. The date was set without your commitment. You feel animosity toward your boss (you figure he must have been the one who committed the team), and each weekend while you work, you consider the fun things your product manager is doing while you’re working toward an unrealistic release date. You will never trust that product manager again, no matter what she says. You swear you’ll never discuss delivery dates with her – no promises made means no promises to break.

When you are managing product, it is your responsibility to let the team study the problem BEFORE you give impressions of delivery dates. Notice that I’m not saying commitments here. I don’t think most product managers try and make promises in this area. I’m saying that you really need to be strong. Truly avoid giving even the smallest impression of when something will be delivered, as impressions can be powerful and damaging. Let your team commit to their date, then announce it confidently, and work with their manager to hold them accountable for it. 

Avoiding communication about dates until you have your team’s commitment is the best way to build trust with your engineers, testers, and writers – and that trust is essential for providing predictable delivery on a consistent basis.

Stacey Weber is a consultant at Pragmatic Marketing. She has more than 7 years of experience in software product management. During that time, she developed a focused interest in the improvement of requirements gathering, analysis, and review. She has led efforts to increase market focus, improve roadmap planning, and increase the effectiveness of requirement reviews with development teams. Contact Stacey.