Today’s Product Management Haiku: Requirements
Recognize problems
Worth solving and define when
Those problems are solved
New Around Here?
Subscribe to the feed to receive future updates; follow me on Twitter to keep the discussion going!
For More Requirements Talk
Check out Agile Market Requirements by Steve Johnson and Requirements Document Alphabet Soup by Michael Shrivathsan. And special thanks to Dr. K for reminding me about Crime SuspenStories.
Customers consider their Time To Return (TTR) along with their Total Cost of Ownership (TCO)-based ROI.
Defining when a requirement is to be implemented brind us to our own Time To Requirement (TTR)–ouch, acronym conflict, cultural divide. We don’t think in terms of the vendor TTR, because we are so focused on defining releases.
Feature-driven design and portfolio management force us to think in terms of minimal-marketable feature (MMF), the number of iterations needed to get the MMF released, so we approach our time to requirement point of view, but only so far. A TTR view would provide us with a geography. Such a geography could show up a faster path in the navigational or GIS sense.
@David Locke – I feel like I’m talking with Geordi La Forge! Are you saying that focusing on the customer’s point of view, in terms of when they’re going to start realizing value from a feature, would better inform when a requirement is met?