I Can Deduce the Requirements Myself

A few years ago a product manager handed me a
three hundred page product spec assuming I could derive our training requirements from it. The interaction went something like this. “Please get the content for the training from this spec.”
I responded, “There’s only one month until the release deadline. I need specific topics and content scope, not an un-marked product spec.” Seeing his reluctance to do anything more, I added, “Please highlight the content you think is important, and return it to me by end-of-day Friday. We cannot start the design work until that is done.”
Ok. I’ll admit that was a CYA move. That’s why after spending the weekend studying the product spec, I independently came up with an outline that I thought should meet the product group’s goals. A Monday morning meeting was intended to review the outline and mark-ups from the product manager, and to answer some questions, but the product group was not available! As a tactic to rescue this project, I had the design team meet with a technologist, who had volunteered his perspective. We managed to produce a storyboard that should make a quality training title. I interpreted continued silence from the product group as an indication of approval. And as the eventual release of the training title triggers no reaction from the product group, I imagine the project a success.
So-called successes that result from taking the requirements into one’s own hands are high-risk ventures for sure. But what else was I to do?

Advertisements

About Bruce

Please see my LinkedIn profile: https://www.linkedin.com/in/certified-scrum-professional-scrum-master-bruce-bartram-563b915
This entry was posted in Requirements. Bookmark the permalink.