​​

Gear Stream

  • The Big Pivot
  • Our Approach to
    Transformation
  • Our Book
    SURGE
  • SurgeMaker
    Platform
  • Executive Briefs On
    Agility & Digital Innovation
BLOG COMPANY CONTACT
MEMBER LOGIN
Home / Agile Product Management / Responsibility Three: Managing scope and communication

Responsibility Three: Managing scope and communication

By Brad Murphy

Posted in Agile Product Management Tagged as Agile, communication, market requirements, scope

This post is a part of a series discussing Agile Product Management responsibilities. Click here to start from the beginning.

Agile teams meet their requirements and complete user stories as and when relevant backlog items come up. This means that Agile product managers must release the correct data at the correct time and only to the correct people, with recognition of the appropriate technical mastery to complete each task.

Agile product managers should be able to switch gears at a moment’s notice, moving easily from the minutiae of technical details to overall strategic issues, as the situation requires. A Product Manager has the vital responsibility of determining market requirements and properly communicating them to development teams.

To this end, the established method is to employ a Market / Business Requirements Document (MRD or BRD). However, we must update our traditional preconceptions of an MRD/BRD if it is to meet the demands of an Agile product team. This means that we must identify and overcome the following traditional barriers to good MRD/BRD writing:

  1. MRD/BRDs can be difficult to write with the correct level of detail. When a Product Manager writes too much, the document becomes bloated and is, more often than not, ignored. However, should the Product Manager write too little, he runs the risk of glossing over or entirely neglecting important product information. To combat these perils, a Product Manager may end up doing both; reducing content but increasing length (a.k.a. writing too much about too little).
  2. MRD/BRDs must also address many different levels of technical comprehension. Without focus, every reader of a traditional MRD/BRD ignores, or even skips out, entire sections they feel are irrelevant. This means that finance, sales, operations, and development personnel all have their own sections in the traditional MRD/BRD but are expected to comprehend the whole document.
  3. MRD/BRDs can also be poorly maintained, getting out of step with their own goals: high-level market requirements remain more or less unchanged, but detailed feature specifications have to be frequently re-examined.
  4. MRD/BRDs could also suffer from being created, but not consumed. Normally, there is a lot of focus on the creation of an MRD/BRD for a new project, but continuous editing and review is less of a priority. Product managers have to go through the motions of making an MRD/ BRD, fully expecting that whole sections of their work will be discarded or ignored by various departments.

Now that we’ve gotten the barriers out of the way, my next post will explain how to create a good MRD/BRD.

Search

Recent Blog Posts

  • Why OKRs – And Why Now?
  • Why Google is an Epic Digital Company (and why you want to be just like them)
  • When Agile becomes (Fr)Agile, or Why You Need to Think of Agile Like Pants
  • Stop Trying to Check the ‘Agile’ Box
  • How to become invaluable to your organization

Categories

  • Agile Industry Trends
  • Agile Management
  • Agile Product Management
  • Agile UX
  • Corporate Culture
  • Gear Stream News
  • Implementing Agile & Scrum
  • Uncategorized

Post Tags

Agile agility Build Management business executive business management capabilities cloud cloud factory cloudsourcing collaboration command and control communication culture customers DevOps disciplines ecosystem enterprise innovation IT Kanban Lean Lean IT management market requirements measurement micro management networks Nokia ona organization organizational outsource outsourcing product release planning Risk roadmap scope Scrum software stakeholders statistics surge Transformation
The Big Pivot - Surge - The Surge App Platform - Surge Services - Research Notes Agility & Innovation

© Copyright 2009-2023 Gear Stream, Inc. All Rights Reserved.

Twitter/Facebook/Linkedin/Google+/RSS