My primary focus is on ISVs. I’ve not worked within internal IT organizations. In that context, before Scrum, a Business Analyst or similar role would be responsible for defining requirements and working with Dev to get the application or product completed. Scrum calls that role Product Owner. Now who is the Product Manager in an internal IT org? Does that role equate to the old Business Analyst? Possibly. It seems to me that the role definitions would be simpler in the internal IT world.

In the end, what will work best is to use some common sense and ensure that the end goals are kept in mind and decisions are made that align to those end goals.

Saeed

In commercial software, *sometimes* the product manager is the subject matter expert, and sometimes they’re really great business people, Marketers (in the 4-Ps sense) and “voice of the customerS” (capital ‘S’ intentional).

For internal IT application development, the Product Owner represents an internal “customer” with a consistent process and infrastructure as a target.

For commercial software, the Product Manager represents THE MARKET – both current customers and potential new customers – and the variety of business processes, preferences, and infrastructures that implies.

As Rich says at Enthiosys, sometimes you can have a PM that is also a PO, but sometimes you can’t. Educating our Engineering teams on product management is an ongoing process, and one that takes on additional importance now. We have to help them, and the rest of our organization, understand how to apply Agile methods to commercial software development.

-Linda

Keep up the posting frequency on your blog as well. Lots of good content related to Marketing.

Saeed

There’s much to agree with in here, so I’ll focus my comments on where I see things a little differently:

- Scrum’s key value is most definitely NOT in its definition of roles to support a development methodology. Its genius is giving all of us business veterans a lighter, more realistic project management framework that recognizes results improve when you break large, long projects into short iterations that inspect and adapt along the way. This adaptive approach works equally well for planning a tradeshow, writing a whitepaper or burning down your backlog of sales tools.

Dean Leffingwell says it best in his “CIO Playbook:”

Know where you are every day with Scrum
- or -
Think you know where you are on your well-formed plan
and discover that you are very wrong, very much later

- Given adaptive management approaches are better than predictive methods whenever you have unknowns, the rest of the business absolutely needs to “bend and accommodate.” If development is finally able to deliver customer value faster, what is preventing your company from experiencing the revenue gains? Is it because Marketing can’t adapt to the new pace? Support? Sales? A lame install & update process?

Put it another way, if your #1 competitor is consistently delivering new features in half the time you are, how long do you think that is tenable?

Agile may have started out as being about development, but it’s quickly becoming about the whole enterprise.

Thanks, and I’m glad you found the info helpful.

Saeed

This has been a great series of blogs. Thank you very much. Very timely for our organization as we struggle with the move to Agile. I am definately going to point my Development team and my management to these blog posts.

It is very true in our organization where Development appears to want everyone else to adapt to Agile.