Extreme Product Management is meant to articulate the role of product management in embracing Extreme Programming. XPM is not about managing the sprints and iterations; when building products (not one-time projects), product managers need to operate strategically and bring in market facts.If I'm interpreting her correctly, Nelson is concerned about product managers getting sucked into overly tactical activities such as micromanaging individual iteration deliverables.
I agree. As I've written, product managers often face this problem; there is a tendency for executives to make all of the strategic decisions and relegate the product manager to doing tactical outbound and implementation work. Consequently, companies' strategic decisions are made in a vacuum, without the benefit of market research and sound marketing principles.
Nonetheless, while a product manager should not be managing product development iiterations, I do believe she should be involved in each iteration that results in a user- or buyer-demonstratable deliverable. And, in general, the team should be structuring iterations so that most iterations result in such a demonstratable deliverable.
Indeed, I wrote late last year:
The crux of the matter is that you should be able to demonstrate at the end of an iteration how a customer would use your product to address customer problems. So "working version" doesn't mean one that is ready for sale to the customer, but just one that is ready for demonstration. For a software product, that demonstration might include showing some hard-coded mock-ups in place of screens developers haven't yet implemented.Think of the product manager's involvement in these iterations as an ongoing dialog with developers about what matters to users and buyers. This dialog benefits developers and avoids the hazards of BUFR.