Sit back and enjoy a cup of coffee while listening to a great, 30 minute, presentation by Barbara Nelson, Pragmatic Marketing instructor. Citrix is hosting a free webinar for (well, for everyone, I guess), in exchange for contact information. Barbara presents a great overview of the strategic role of product management, and Pragmatic’s framework. For people who’ve previously attended the PPM training, this is a good refresher – for other folks – if you want to know why product managers should be doing strategic work, check this out.
Inside Out is Backwards – Feature Focused or Goal Driven
Kathy Sierra has another great post on the problems people face when using products. One of the sources of the problems is when engineers think “from the inside out” and focus on features or capabilities. People have goals, and they want to achieve goals, not use capabilities.
The Impact of Change and Use Cases
Market requirements change. These changes impact the use cases that support the changing requirements. Functional requirements change. These changes impact the use cases that they support. How can we leverage use cases to manage these changes? And how can we manage changes to use cases?
Communicating A Release Schedule With Use Cases
We manage release schedules with project management. We manage customer expectations with consulting skills. How do we manage customer expectations about release schedules? With Use Cases. Background We started a series of posts exploring why we apply use cases as part of product management, identifying 8 goals for which use […]
Communicating Intent With Implementers
Giving a functional spec to developers and testers is not sufficient for creating great software. To a developer, a spec is only the what and not the why. And for a tester, the software requirements specification is neither. Use cases provide the why that explains the intent of the system for the implementation team.
Communicating Intent With Stakeholders
We can build a prototype of what the stakeholders don’t want, and then get feedback and fix it. Or we can review use cases of what we intend to build, confirm that each stakeholder wants it, and build it right the first time.
Four Assumptions of the Apocalypse
Business Analysts often start with four erroneous assumptions when eliciting requirements. 50% of errors in software projects are caused by requirements errors. These four faulty assumptions, presented by James A. Ward, can exacerbate the error-prone process of gathering requirements.
Verify Correct Requirements with Use Cases
The next piece in the puzzle of how and why we apply use cases to product management. Verification of requirement correctness.
Product Managers Play Tug-of-War
63% of product managers report to marketing and 24% report to development. 22% of requirements managers report to marketing with 55% in the development organization. These reporting structures can over-emphasize the needs of new users and super-users, while shortchanging the needs of the majority of users. Product managers will constantly be playing tug-of-war to get time to do the right thing.