Agile Product Management

This was a great post, so am pasting this word to word :

Source :

http://media.emm.adhost.com/adhost_5377/Pivot%20Point%20Content/7-08PivotPointFeature.htm

Agile Product Management - The Rosetta Stone

What should you do differently to become an Agile Product Manager? Not much, as it turns out -- but you may do some things more frequently than you’re used to. Let’s take a look at how Agile development methodologies impact the five main areas of Product Management: Planning, Building, Launching, Maintaining, and Retirement.

Planning
Overall, the organization still needs good methods, such as Robert Cooper’s Stage-Gate™, to help prioritize product ideas and projects. Agile methods promise to deliver higher productivity for the same cost, but you still need to choose the projects with the best strategic fit.

The planning cycle includes building a business case, determining a market and product strategy, positioning the product for success, and setting a long-term product roadmap. To create these deliverables, you’ll still need to do a thorough market analysis. Can you do it in an “agile” way? It depends on your organization’s tolerance for risk, and the size of the project. Some organizations can move forward on smaller projects and do their analysis in parallel. For larger investments, most organizations want to have a more complete picture of the opportunity before they start development.

As you complete your analysis, the deliverables you create may be labeled differently in an Agile organization. What we think of as product positioning, Agile teams call their “vision.” Your near-term roadmap becomes a “release plan.” And “sprint plans” may roll up into a Product Plan that details how the organization will execute on the next market release.

Building
Along the way, you’ll begin collecting requirements and tracking them in an Agile backlog. Today you probably refer to that as your “enhancement list.” Individual requirements get written as “user stories,” which put the requirements in context. You’ll still need to gather non-functional requirements; you’ll still need to prioritize; and you’ll still negotiate what’s in each sprint. You’ll still supply some product specifications, in the form of acceptance criteria.

But what we really like about Agile is that it embodies what we’ve taught for the last nine years – that a good requirements process is collaborative. What’s hard for Agile Product Managers, and for Agile developers too, is to trust this new collaborative process. To not write every single detail down in advance and then toss it back and forth across the wall – but instead, to write some user stories and then talk about them. Together. At the same time, preferably face to face. Every day!

That’s the real revolution of Agile – not the two-to-four week sprints, not pair programming or test driven development (TDD) – but the conversation between the people who hold the product vision and the people who are executing on the product vision. The revolution of trust within the team – no more finger-pointing, no more scape-goating.

(Here’s a secret: Any development methodology can be successful when this collaboration and trust exist between Development and Product Management!)

Product Launch
So in Agile, you won’t know exactly which features will make the release until just a few weeks before the release. Doesn’t that pose some problems for getting launch collateral ready? Come on… get real. You don’t know that information with much certainty today!

With Agile, you’ll likely know with greater certainty which features are really finished and ready for release, because they were completed in a prior sprint. All that remains is the functionality included in the final sprint, and as each story is completed, you can make sure it’s included in the collateral.

The potential exists for functionality to be released to users in smaller chunks. Marketing communication strategies need to be discussed early in the planning process to take into account potential interim releases and their impact on the competitive landscape, customer adoption, and market timing.

The real change is that the Development team may need to get used to the product “sitting on the shelf” after it’s complete, so that Marketing can time the release for the greatest impact, and adequately prepare the market, the users, and the sales teams for the launch.

Maintenance
This phase comes in two flavors: maintenance on the product itself and, in commercial software, sustaining marketing activities over the life cycle of the product.

Product maintenance is simply another pass at the backlog. But, just like today, there needs to be resource allocated to emergency bug-fixing, and enhancement projects must be authorized from a business perspective.

Sustaining marketing continues to be part of the Product Manager’s or Product Marketer’s role, to whatever extent it is today. Agile development doesn’t have a lot of impact here, but we can learn from the Agile process and apply it to how we develop, field, and test our marketing programs. (More on this in a future newsletter.)

Retirement
You still need to create the business case for removing a product from the market. Agile methodologies can’t impact this directly. But if the Agile team’s job is done well over the lifetime of the product, you may find that fewer products need to be taken off the market due to lack of sales. The successful ones should last longer in the marketplace because the team can be more responsive to market needs and changes.

In summary, the tasks that product managers do over the lifecycle of the product don’t change. Their name, form, or frequency may change, but executives still need the same solid data on which to make good business decisions, and it still takes a collaborative team (product management, marketing, sales, support, and development) to produce great products.