A Quick Toss Over the Wall -- Never Cool

This morning, I came across an interesting post. In it, Luke Hohmann of Enthiosys writes:

"Note also that we reject the notion that product management is somehow external from the development organization. Indeed, we're shocked when we hear of product management practices that assume the product manager can simply deliver an MRD to their development team and walk away, assuming that the process used by the development team does not affect product management. If you're a practicing Agile Product Manager, you're definitely not writing an MRD and walking away. "

I’d like to go a step further, and say that any product manager who understands technology and wants to succeed (and keep their job) is not writing any sort of requirement document and walking away.

Regardless of the development methodology in use, Product Managers need to describe and prioritize requirements for the team. In your first publication of the requirement, provide relevant context to help the team understand the market’s need. Tell them who the target persona is, what problem they’re experiencing, and how frequently this situation occurs. Sit down and review it with the product team. Make yourself available for questions during this period – they’re trying to understand the requirement and may need your help in that process. If your team finds a gap in your research and asks for more information, get it for them. As you get better at writing the requirement with appropriate context, your team will have fewer questions….allowing you to spend more time in the market, finding problems that will provide future revenue opportunities.

Throwing a requirements document over the wall has never been cool – it leaves the team in the dark, grasping around trying to figure out what is truly needed. Whether your team is agile or not, provide prioritized requirements with good context. Review with your team, and ensure that they understand the true market need. Two-way communication early in the cycle will help reduce the questions your team runs into later on – so be available, and work with the team until they understand the requirement well enough to design features and organize the iterations or sprints.

Then, walk away – while the team is building this release, go back to the market and continue researching. By the time this release is done, you’ll be ready with the next set of prioritized, context-rich requirements.