Product Forum

The Product Forum is a team-of-teams structure that co-ordinates integration of a Product or Product family.
The Product Forum is a self-organizing, often democratic, group that balances competing voices and concerns, owns high level Requirements and Architecture, runs the high level release stream and performing integration activities for the product.

Rather than impose a hierarchy of decision making from a Programme or Project Manager downwards, the Product Forum is a “middle-out” virtual team in the middle of all stakeholders balancing concerns of Product Customers, Business Customers and Business Leadership with Programme and Project Delivery teams. An alternative management structure for cross team working (or managing a large/complex team) the Product Forum can be thought of as an agile alternative to traditional Programme Management.

The Product Forum practice can be used to run any kind of team, but is different from traditional hierarchical management methods in that it embraces multiple opinions, enables group decision making, is extremely responsive to change and actually does integration.
Management and control practices such as traditional Project and Programme Management are often based on the “manager” knowing how to build the solution and organizing others to do so. When working in high complexity projects, knowing the answer isn’t possible – and is an unfair expectation to place on a person. Similarly, when working in a team-of-teams to integrate a Product Family there are simply too many moving parts in terms of people and their interactions to autocratically control it all in a predictable fashion. In these cases, the Product Forum provides a practical alternative.
Product Forums can be made organically by teams coming together to serve a common Customer need or in a designed form in place of a “thin/reduced” programme team. Do not implement a Product Forum under a Programme to co-ordinate multiple delivery teams, that’s duplicating the programme layer.
A Product Forum is appropriate:
  • In situations where multiple competing stakeholder groups with different agendas are required to work together
  • In situations where multiple product groups need to collaborate on a bigger outcome
  • Where there is a conflict in direction, resource management/ownership or scope between collaborating groups
  • System of systems development
  • High complexity development where the solutions is very unpredictable

Sitting in the middle of the H-Model the Product Forum is the connective tissue between high level scoping requirements, architectural context, integration, releases, management and acceptance.

Structure

The Product Forum is a virtual team formed from representatives of contributing teams and stakeholders related to a piece of work. The specific composition of a Product Forum will alter over time, and for each activity meeting, as different decisions are made.

As a virtual team the Product Forum uses the Team Forming practice to establish its purpose and decision making dynamics (ranging from autocratic to democratic).

Membership of the Product Forum includes Customer and User representation, contributing resource groups, technical and people management, enterprise analysts and architects. To be most effective it needs to have the least possible number of people actively contributing (a forum of 40 competing voices is going to have a lot of difficulties) however there are certain positions that must be filled.

A good rule of thumb is that, for a large project, the forum should be around 7 to 15 people, if 30 want to turn up then half of them should be on an observational gallery unable to interject in the proceedings. The people who should come can be thought of in the following ways:

  • Facilitator (like the speaker in a political context best if it’s someone independent from the project)
  • Customer Representatives (2 or 3)
  • Resource Management and Technical leadership from each contributing group (2 each)
  • Architect – the person or people responsible for guiding the overall system or solution architecture.

People can be elected by their groups to the forum, membership could be rotated, the organization could appoint membership or the least busy from each group could attend. We suggest that the last two are not good options for selecting membership if good decisions are to be made! Of course, depending on the agenda of the Product Forum, different representatives may attend. Presence can be physical or virtual however the best decisions and communications occur when people are physically present.

Avoid filling a Product Forum with “managers” and “talkers” – instead it should be full of “doers” and “deciders”. Use of the Product Forum practice does not prevent any communication directly between contributing groups, it only provides a vehicle for that conversation when it’s relevant for the wider project.

Functions

Since a Product Forum co-ordinates work and/or multiple teams it performs similar functions to a traditional programme team. The forum works to de-conflict sources of disagreement before they occur and relies on open and honest communication across the following functions:

Communication
  • Seizes its autonomy and self-organizes its internal structure – often articulated through a team charter
  • Communicates, both internally and externally, radiating information and being open and honest about progress and impediments
  • Provides a vehicle for knowledge sharing and conflict resolution by bringing people together
  • Stakeholder and Relationship management
  • Communicating its decisions
  • Acts as a Bubble Up target for contributing teams
Project Integration and Release
  • Actually does the Product Level integration and test activity against Integration Scenarios raising the level of done of the product as a whole
  • Combining the output of contributing team’s integration and test activities into a larger product by performing cross-team integration and test activity against Integration Scenarios raising the “level of done” of the product as a whole
  • Manages acceptance testing and drives acceptance test driven development
  • Exposes Releases to higher level integration streams or user environments
Decision Making Processes
  • Understands the decisions it needs to make and makes them autocratically or democratically as appropriate
  • Defines the direction of the project in a planning, architectural and cultural context
  • Ensures System Architectural choices align to Solution Architecture and Enterprise Architecture
  • Manages scope (using Integration Scenarios and change management practices)
  • Does release planning and elaborates Solution Architecture
  • Resource profiling for the work as a whole enabling resource management between the Product Forum and contributing groups

Implementation

The members of the Product Forum will need to meet, either physically or virtually, on a regular basis to make decisions.
Product Forum members will need to make decisions on requirements churn, scope issues, quality checks, acceptance testing and transition activities on a regular basis. Since the Product Forum performs integration of contributing teams work, they will benefit significantly from co-location, at least initially while build processes are being automated. If a Product Forum desires continuous integration or deployment it is best served by continuous communication.
Having a common physical space for this group to do its work is ideal. However, if a Product Forum cannot be physically co-located then creation of a virtual team space is critical. A virtual collocation space, supported by tooling such as social business software, version control, chat etc. helps maintain team identity when physically distributed.
The Forum tends to contain strong opinionated people and so can act to focus internal political difficulties and personal conflicts. Managing these is a delicate process so we recommend facilitation from an experienced software, agile and business coach.

A word of warning

Often competing leaders in an organization will not wish to attend a Product Forum due to personal or political conflicts. This is a symptom of people being unwilling to work with each other. Such unprofessional behavior will not be solved by processes, tools and plans. In these situations, we recommend changing the people. If that isn’t possible then interventionist mentoring can work, although this can be a difficult process for all concerned.
We’ve seen implementations of Product Forums that didn’t include all of the relevant stakeholders (in one case excluding Programme management and Architectural resources). These attempts at forums do not work as they do not have enough coverage of contributing specialisms, or opinions. Their decisions are always undermined by the excluded parties and so they become fruitless talking shops.
Another problem we’ve seen is Product Forum’s that do the planning and architectural elements but not the integration work. The value of any project is measured through working software, and so these Forum’s do not create value, they talk about other people making it. By removing responsibility for delivery these “managerial” forums are actually just traditional programme teams using some new language to hide their command and control tendencies.
Product forums must contain User and Customer representatives. Their membership avoids excessive layers of management and bureaucracy by bringing the customers’ needs into discussions around changes and priorities.
Avoid filling a Product Forum with managers. Other than the Customer or User representatives, members should all have a strong technical background being able to sketch the architecture and invoke the build.
If a Product Forum isn’t actively producing Releases, measured in weeks or continuously, then it’s not a real Product Forum.