By Stacey Weber
The fictional product manager – we’ll call him Pete – starts work early one Monday, eager to find out how the team is progressing with requirements analysis, design, and (his real goal) scheduling. Pete knows that most of the team isn’t in the office yet – but he gets an email from engineer Ed and picks up the phone.
Ed answers, also glad that someone else is working. They chat a bit, then Pete changes the topic back to work.
“How’s the requirements analysis going? I can’t wait to find out how long v2 is going to take.”
Ed is fairly new to the team, and he enjoys talking with Pete. He replies, “We’re thinking it’ll be about six weeks.”
“That’s awesome! What else have you got going on? Are you going to the agile training next week?”
They hang up, with Pete feeling confident and happy. A calendar reminder pops up, and he joins his weekly check-in with his boss, Brad.
Brad always saves the niceties for the end of the meeting, and quickly jumps in. “How’s the schedule coming? Any idea when we’ll see v2 hit the market?”
Pete pleasantly replies, “Funny you should ask. I was just talking to one of the engineers, and he said they’re thinking it’ll be about six weeks.”
Brad expresses his pleasure. They finish the meeting, and Brad jumps onto his weekly executive status meeting. He’s finally got something good to tell the group! Everyone will be SO excited to know that v2 is only going to take about six weeks.
Neither of them will realize their mistake for a few weeks, when the official schedule is published….and the v2 general release is scheduled for fifteen weeks out. The first call that Product Manager Pete gets is from boss Brad, whose memory for the original date is very clear and marked on his desk calendar.
“You told me six weeks, two weeks ago! By my calculation, that is an eleven-week slip. What in the H-E-double-toothpicks is going on over there, Pete?”
Brad looks bad, because he’s going to have to tell the executives the new date. He hopes that maybe they forgot his proud proclamation….it has been a few weeks ago.
Brad’s angst flows downhill, as evidenced by his phone call to Pete…..who also looks bad.
In the grand scheme of things, though, guess who looks worst of all?
No matter what the development team does at this point, they’re going to look like they took longer than they originally said. They haven’t even STARTED the work yet, and it already looks like a failure. These are the kind of situations that development teams remember – a time when they tried so hard and got so far; but in the end, it didn’t even matter. (Linkin Park reference was intended.)
The issue is that Engineer Ed is fairly new to the team. He had not been burned by early commitments yet – so he was comfortable having a conversation about the schedule. The team really had settled on six weeks…..for the actual coding. Ed gave a coding estimate, and Pete was so happy to hear it that he never bothered to question or validate what he heard. “Code Complete” is not the same as general release. We need to think about testing, rework, and integration time – not to mention organizational readiness and market preparation. While Ed gave an honest answer, Pete should have ignored it.
By repeating a date that he hadn’t validated, Pete set expectations that could never be met. If you want your development team to trust you more as time goes by, you’ve got to be clear and honest about product’s commitments to the organization. Whether you’re pressed for information on schedule or content, always respect that commitments are made by those who do the work.
Never make delivery commitments without your team’s support.