Product Managers: Ready, Set, Go! Who Can Write the Longest Requirements Document?
There are contests:
- The Super Bowl
- 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.
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.
- 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.