The Product Champion Role

Key ideas#

Why the role exists#

The vision document is the key artifact for defining a product (see The RUP Vision Document). Someone has to write it, keep it current and defend it. Leffingwell and Widrig’s answer is the product champion. Job title does not matter: product manager, project manager, marketing manager or IT project lead can all fill it.

What the champion does#

The authors’ list of duties, grouped here for use:

• Vision and scope. Own the product vision and protect it. Check that specifications still match it. Manage changes in priorities and in the feature set. Resist feature creep.
• Stakeholders. Lead elicitation until requirements are complete enough. Resolve conflicting requests. Find compromises that give the most value to the most stakeholders. Manage everyone’s expectations.
• Communication. Be the official channel between customer and developers. Negotiate with management, users and developers. Balance what the customer wants against what the team can deliver in the time available.

In software product companies#

Here the champion usually comes from marketing or product management rather than engineering, because that function is closest to the customers who decide the product’s success and is accountable for revenue. The authors recommend a clear split: the product manager decides what features are needed and why; the development manager decides how to build them. Each person owns what they know best.

In internal IT departments#

This is harder. There is no marketing function, all stakeholders are internal departments with conflicting needs, and nobody is clearly authorized to decide for all of them. In a case the authors describe, the solution was two-part:

1. Appoint a champion, for example the project lead, to own the vision document and the process of eliciting and prioritizing requirements.
2. Set up a change control board (CCB), a small decision body, made up of managers from the affected departments. The champion prepares and presents recommendations; only the CCB can add or remove features.

The authors sum it up as champion plus change control board. The board’s procedures for assessing change impact are covered in Managing Requirements Changes.

Without a champion#

Requirements drift, schedules slip, and decisions get made poorly under deadline pressure, because nobody takes responsibility for hard calls or for deciding when to stop. The authors tell of a marketing manager who could ask for a new feature at any time and never heard “no”.

Two roles with the same name#

Wiegers and Beatty also use “product champion”, but for a different role:

• Wiegers and Beatty: one champion per user class; a real user who brings that class’s needs to the analyst and validates the requirements. See User Classes and Product Champions.
• Leffingwell and Widrig: one champion (or small team) per project; the owner of the overall vision who arbitrates between all stakeholders and negotiates scope.

A project can, and often should, have both: several user-class champions feeding needs to one project-level champion who decides.