Product Managers: Ready, Set, Go! Who Can Write the Longest Requirements Document?

There are contests:

  • The Super Bowl

    what can you Hemi contest

    Tim Kowalec, 2005 finalist of Chrysler Group's "What Can You Hemi(R)?" Contest

  • The World Cup
  • The World’s Strongest Man

And then there are other ‘smaller-scale’ contests:

  • Fastest to chug a glass of milk

At the workplace, contests run the gamut:

from the noble:

  • Let’s raise $10,000 for the Red Cross.

To the aggressive:

  • Double our revenues in one quarter.

To the strange:

  • Longest requirements document get a prize.

Sadly, I lived this last goal. And I am not proud of it. There is, however, much learning that came from this experience.

Earlier in my career, it wasn’t strange to see my fellow Product Managers and I spending multiple weeks writing lengthy, epic requirements documents for highly-dynamic, frequently changing interactive online projects. In the early 2000s, this wasn’t out of the ordinary.

We’d spend weeks writing use cases, documenting flow, sketching out prototypes, addressing change control boards.

If a colleague wrote a document that was 50 pages, then 51 pages was the benchmark. This wasn’t a ‘corporate/endorsed’ goal per se, yet we took it pretty seriously. If we needed to snap another screenshot, map out another sequence of events to get to 51 pages then it happened. We had the quality vs. quantity scale confused.

Surprisingly, we still delivered stakeholder value (or at least we thought we did?) through these text-heavy masterpieces. We presented our masterpieces (page-by-page!) in long meetings; the developers were able to understand the site structure; the designers visualized a look and feel that mapped to our vision. Management would be shocked to know how much time we flitted away in these meetings. Sadly, we knew no other way.

This crazy contest of expanding requirements documents isn’t the point here. That was a symptom of bad management, demotivated employees, unclear goals, lack of understanding or some odd mix of the four.

The point is that there’s a better way today to deliver stakeholder value, utilize your talented and gifted team, and inform stakeholders. In hindsight, if only I had a way to turn back the clock and redo all those projects with a more ‘enlightened’ perspective.

It’s agile.

Agile development isn’t just about holding a standup or moving stickies on a whiteboard. It’s a different way of thinking about your teams, products and services.

I have a new contest for today’s workplaces: Deliver value in the most efficient way possible.  If you’ve embraced agile, you’re winning this contest every day.

Dan Naden
VersionOne

  • New to agile? Or are you experienced with agile, but believe you’ve hit a wall?Ask us how we can help. We can help you clear the path for your teams to get back on track.
This entry was posted in Agile Adoption, Agile Benefits, Agile Development, Agile Management, Agile Marketing, Agile Methodologies, Agile Project Management, Agile Teams, Scrum Development. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>