Company Product Teams Forum: Product Day Program

A product team forum connects the portfolio, cross-team dependencies, and leadership decisions. We break down the Product Day agenda, roles, preparation of materials, and work after the event.

A company's product team forum, or internal Product Day, is needed for issues that no longer fit into a single team's meetings. At it, participants assemble the overall portfolio picture, identify cross-team dependencies, discuss constraints, and record decisions. The value of such an event is determined by its working outputs: a portfolio map, a dependency register, a decision log, and a clear continuation.

At Aventura, we are responsible for the event design of the forum: the agenda, the script, participant routes, the venue, the technical infrastructure, and capturing the outcomes. Product data, priorities, and the right to make decisions remain with the client. This division should be established before choosing speakers and halls.

When does a company need a product team forum?

In short: A forum is needed when several teams depend on shared platforms, data, channels, experts, or management decisions. A regular sync is no longer enough: each team sees only its own area, while conflicts over priorities and resources remain between departments.

The first sign is that one team's decisions create consequences for others. A new release requires platform enhancements, data access, legal approval, sales support, or a change to the shared customer journey. If these connections are discussed in separate calendars, the big picture falls apart.

The second sign is that management has to compare initiatives after a series of separate reports. Teams present their roadmaps and metrics, but use different formats. As a result, time goes into translating and clarifying the source data. Portfolio decisions get postponed to a closed meeting whose logic participants learn about later.

The third sign is that the dispute requires authority above the team level. A team can clarify a hypothesis or the order of tasks on its own. A decision to reallocate a shared resource, stop an initiative, or change commitments must be made by the responsible manager. The GOV.UK principles for agile delivery suggest making decisions in a timely manner, at the right level, and with the right people involved. For a forum, this is a useful boundary: the agenda includes issues that cannot be resolved in a regular team meeting.

A forum is premature if the client has no shared goal, selection criteria, or people with decision-making authority. A large hall won't fix unprepared data. First, you need to gather the contradictions and determine which of them require joint work.

The boundary with Demo Day, a hackathon, and a strategy session

The gist: The name of an event does not determine the format. Demo Day showcases prepared results, a hackathon gives time to create a solution, a strategy session chooses a direction, and a forum connects the current portfolio, teams, constraints, and next steps.

A single Product Day can include a demo, a working session, and an executive talk. There still needs to be one center of gravity. Otherwise participants get a long program with different promises: some are asked to show their work, others to come up with something new, and still others to agree on resources.

In Scrum, the Sprint Review is described as a working session to inspect the result and discuss further adaptation. It is not meant to be limited to a presentation. This principle is useful for a forum as well: a demo should provide material for a question or decision, otherwise it turns into a parade of screens.

If the main task ends with showing prepared projects and a decision on each, it is better to use a separate corporate project demo day. For a professional community that compares practices and documents, it is useful to see how an enterprise technology forum is structured. A product forum differs in its subject matter: it connects permanent cross-functional teams, product signals, roadmaps, and shared constraints.

Decisions that need to be made by the end of the day

Output: Before assembling the agenda, you need to write down the decisions for which the teams are meeting. For each question, define the expected level of outcome: a final choice, a recommendation, a list of missing data, an assigned action, or an escalation.

The phrase "synchronize the teams" does not give the scenario writer a workable task. It is worth breaking it down into specific questions. Which initiatives require a shared resource? Where have two teams promised incompatible deadlines? Which dependencies create a critical risk? On which topics does management need to confirm the choice?

We start with a decision map. It includes the subject of discussion, the preparation owner, participants, the person with approval authority, and the acceptable outcome of the forum. If a decision cannot be made in the room, you need to honestly determine what the forum will prepare for the next step.

It is convenient to divide the questions into four groups:

1. The team decides on its own and communicates the outcome to others.
2. Several teams agree on a joint action.
3. A manager confirms the priority or resolves the conflict.
4. The question requires additional data and gets an owner for follow-up.

Not every dispute has to end with an answer the same day. Sometimes a quality outcome is to record what data is missing, who will collect it, and when the participants will return to the choice. This is more useful than a formal vote without information about cost, risks, and commitments.

Atlassian's material on decision-making describes the problem of repeated discussions when roles remain unclear. For the forum, the conclusion is direct: participants must know where they contribute, where they form a recommendation, and who approves the outcome. The mechanics of voting collect a signal from the audience, but it does not replace the right to decide.

Participants and roles

In short: Participants are chosen based on their contribution to the decision. The forum needs owners of product context, technical constraints, user data, commercial commitments and shared resources, as well as leaders who can confirm the next step.

A forum for product managers only will give an incomplete picture. A product bet may depend on architecture, research, analytics, support, sales, marketing, operations, finance or legal constraints. The GOV.UK Service Manual links the work of a digital service to a multidisciplinary team and the involvement of people who actually make decisions.

The composition depends on the agenda. There is no universal list of roles. We suggest going through each block of the programme and answering three questions: who confirms the source data, who sees the consequences of the decision, and who has the authority for the next step.

HR and internal communications help gather the audience, explain the purpose and report the results back to participants. They must not replace the owners of product decisions. The event team also does not set priorities for the CPO or portfolio owner.

We separately appoint an owner for each decision and an owner of the forum itself. The former is responsible for the content of the question. The latter pulls together the programme, versions of materials, access and changes. This separation reduces the risk that organisational tasks and product conclusions end up in one overloaded role.

We post breakdowns of programmes, moderation and production decisions in Aventura's Telegram channel.

What to collect from teams before the forum?

Working principle: Each team prepares a comparable pre-read, not an arbitrary presentation. It should include the problem or opportunity, target audience, data, expected outcome, constraints, dependencies, and one specific request to other teams or management.

Materials should be collected before the staging rehearsal. If one team brings metrics and options, another brings a release history, and a third brings a promotional video, they cannot be compared. Editing in the last week will not fix the lack of a common question.

We take a team profile on one or several short pages:

• product goal or problem;
• user or internal customer;
• signal: metric, research, feedback, or commitment;
• previously made decision and considered alternatives;
• expected outcome;
• risk or uncertainty;
• dependencies on teams, platforms, and shared functions;
• specific request for the forum;
• acceptable level of material disclosure.

In such a package, a roadmap is needed as a means of linking goals, initiatives, and expected outcomes. Product School and Aha! describe a roadmap as a way to convey the big picture and connect strategy to work. For the forum, a release calendar is not enough. Participants need to understand the basis for the bet, the expected change, the constraint, and the decision point.

We put the facts that can be read in advance into the pre-read. GitLab's public handbook describes live-doc meetings and the connection between synchronous conversation and shared documentation. We are not suggesting copying one company's process. The practical principle is useful: it is better to leave time in the room for questions, conflicts, and editing the decision.

It is convenient to fix the list of materials, audience, streams, and constraints in a technical specification for a corporate forum. Based on it, we calculate the program, venue, equipment, navigation, and team composition.

Architecture of the Product Day program

In short: The program moves from a shared framework to working sessions and a shared wrap-up. Participants first understand the goals and selection criteria, then work on their own track, and finally see the decisions, owners and next steps.

At Aventura, we build forum and seminar organization around participant action. First, we identify where people listen to the shared context, compare initiatives, work through dependencies, watch demos and make decisions. Then we select rooms, the stage, screens, network and the transition schedule.

A working route might look like this:

1. A shared framework from leadership: goals, selection criteria, constraints and the day's questions.
2. A brief portfolio overview: a shared map of initiatives and connections.
3. Thematic sessions: product bets, user signals, technical constraints.
4. Dependency clinic: working with critical cross-team connections.
5. Demos on the topics where a live demonstration supports the point.
6. A closed window for sensitive decisions, if needed.
7. A shared decision point: what has been decided, what requires data, who continues the work.

The main stage is needed for context that everyone should hear in the same way. Detailed work goes better in small rooms or at work tables. The finale brings participants together again, but not to repeat all the presentations. The facilitator shows changes in the overall picture and names the next steps.

Parallel tracks require a route. Each participant should have a clear logic for choosing, and organizers need room capacity, transition time and a way to return results to the shared log. If one group's work does not make it into the final wrap-up, it remains a local conversation.

For a large-scale business event, we connect content, logistics and technical production in business event organization. The client retains substantive ownership of the product agenda and approves all conclusions.

Working formats instead of a series of presentations

In brief: A presentation is justified when it quickly creates a shared context. Comparison, risk review, and alignment of actions require working formats: a roundtable, a clinic, a decision review, a portfolio map, a failure review, or collaborative work on a document.

A series of presentations is convenient for the schedule, but it barely changes how teams work. Each speaker shares their own story, questions are cut short, and the connections between talks remain in the listeners' notes. As a result, the forum looks packed, even though decisions only emerge after the event.

We choose the format based on the action needed:

Reviewing a failure requires safe moderation. We discuss the decision and the conditions, looking separately at what was known at the time of the choice and what became clear later. We do not turn admitting a mistake into a ranking of departments.

For a complex case, the moderator receives the question, available data, and boundaries of the discussion in advance. Their task is to keep the conversation within the scope of the request. If participants dive into implementation details before the problem is agreed upon, the moderator brings them back to the initial choice.

How to Run a Portfolio Review?

In short: A portfolio review compares initiatives using a single template. The team presents the goal, expected outcome, rationale, constraints, dependencies, and the decision request. Beautiful slides and the number of features shipped must not substitute for substance.

The review starts with an overall map. It shows product areas, initiatives, shared platforms, and major dependencies. Then teams dive into only those items that require input from other participants or a management decision.

For each bet, seven fields are enough:

1. What problem or opportunity the team is considering.
2. Who it matters to.
3. What data confirms its relevance.
4. What outcome is expected.
5. What constraints and alternatives are already known.
6. Who the next step depends on.
7. What decision is required at the forum.

The facilitator does not ask the team to defend the entire roadmap. They ask questions about the contested area. If there is enough data, the designated manager confirms the choice. If the rationale is weak, the team gets a task to validate it. If the conflict concerns a shared resource, the question moves to the decision window with the owner of that resource.

The antipattern for this block is a parade of green statuses. Participants hear that everything is on plan, but they don't see stopped hypotheses, the cost of delay, or requests to other teams. We suggest ending each review with one of clear statuses: continue, change, stop, validate the data, or escalate.

The decision secretary writes the wording right on the screen or in a shared document. Participants see the text and can correct any ambiguity before moving to the next question. The final record must be understandable to someone who was not in the room.

Dependency clinic and cross-team connection map

Answer: A dependency becomes actionable when both parties, the owner, the required action, the consequence of delay, and a checkpoint are specified. A line between two cards without these fields shows a connection but does not define further work.

In its dependency mapping methodology, Atlassian suggests identifying dependencies and risks in advance, assigning owners, planning risk mitigation, and defining a feedback rhythm. For the forum, this is the basis for a separate working session.

Before the event, teams enter known connections into a shared register. At the forum, participants review critical dependencies, identify those missing from the discussion, and clarify the action. We do not promise to remove every blocker in the room. If there is no authority or data, the outcome becomes an escalation path.

A dependency card includes:

The map must have an owner after the event. A photo of the wall does not replace the register. All cards are transferred to the digital environment where the team already conducts product work. The customer chooses the tool format.

During the session itself, it is useful to bring together people from both sides of the connection. If one side is absent, the discussion quickly becomes an assumption about others' capabilities. Such a question is recorded as open and is not presented as an agreed plan.

The role of leadership and the closed session

Guideline: Leaders are needed in the segments where their authority changes the outcome. A welcome address does not replace participation in choosing priorities, resources, and the escalation path. Sensitive issues can be taken into a closed room, but the logic of the decisions must return to the teams to the extent permitted.

Before the forum, we align the calendar of decision-makers with the agenda. If the CPO, CTO, or business leader is present only at the opening, contentious issues will again be sent “for approval”. That is why decision windows are scheduled at confirmed times and the pre-read is sent to the leader in advance.

A broad audience can discuss user signals, dependencies, execution options, and consequences. Questions about personnel, confidential data, investment limits, or a not-yet-announced strategy may require a closed group. The boundary is set by an access matrix approved by the client.

The closed session must not turn the entire forum into window dressing. After it, the teams receive a clear status: a decision has been made, the issue is postponed until data is available, a separate meeting has been scheduled, or the priority has changed. Details can be limited, but participants need to know what to do next.

For each decision, it is useful to keep the rationale to the extent permitted. The phrase “management has decided” quickly loses context. A note such as “the priority is confirmed due to a shared commitment; Team A is updating the plan, Team B is checking the dependency” helps execution and reduces repeated disputes.

How to design a hybrid event, a demo, and a technical backup?

In short: Remote participants must be able to ask questions, work with documents, and influence decisions. Every live demo needs an agreed backup, and the rules for recording, showing roadmaps, and accessing materials are approved before the technical run-through.

A hybrid Product Day cannot be put together as a broadcast of the stage with a passive chat. W3C recommends taking into account participants' needs, audio quality, subtitles or transcripts, descriptions of meaningful visual information, and accessibility of materials in advance. Questions from the room must be repeated into the microphone, otherwise the remote audience misses part of the conversation.

For distributed teams, we create a single digital source of truth. It holds pre-reads, working templates, a decision log, and approved materials. Each room needs a person who monitors the remote loop and brings questions back into the discussion.

If a company needs full-scale hybrid event organization, we build the studio and in-person tracks separately: connectivity, audio, screen sharing, voting, group work, and handover of results. A single platform does not solve this task automatically.

We check the live demo as a production chain: environment access, product version, account, network, cables, source switching, interface scale, and permission to show data. For backup, an agreed recording, screenshots, or a static walkthrough are suitable. The replacement must support the same point for which the demo was included in the program.

It is useful to go through the junctions in a technical rehearsal of the event. It checks final files, transitions between streams, access rights, backup, display of restricted data, and transfer of the decision to the shared log. A rehearsal of a talk without these junctions does not show the forum's readiness.

Recording rules are determined in advance. Participants are notified about the recording, and the necessary consent is obtained according to the client's rules and applicable law. The client also sets access, retention period, and permitted use of materials. A person must know the mode before the discussion of a sensitive topic begins.

Artifacts, metrics, and the next step

In brief: After the forum, working documents and a follow-up calendar remain. What is worth evaluating is the movement of decisions: whether owners have been assigned, dependencies updated, missing data collected, and whether participants have returned to the checkpoints. Guest impressions complement this picture but do not replace it.

The minimum package after a Product Day includes a portfolio map, a dependency register, a decision log, a list of open questions, and approved materials. For each entry, the log specifies the wording, rationale, owner, follow-up participants, missing data, access mode, and checkpoint.

An outcome has four states:

1. The decision is recorded and confirmed by the participants.
2. The owner has accepted the next action.
3. The action is completed or updated by the checkpoint.
4. The product or business result has been validated by the owner within the company’s operational loop.

A forum can deliver the first two steps well. The rest depend on regular management after the event. That is why you cannot credit a single day with accelerating product launch, growing a financial metric, or increasing engagement without the client’s data.

After the event, it is useful to check organizational metrics: whether the working groups reached the stated result, whether there was enough time for decisions, whether materials were available, and where problems arose with sound, transitions, or access. These observations help improve the next cycle but do not prove product impact.

We start preparing a new forum with a short brief. It needs the business challenge, team composition, a map of contentious issues, decision rights, access mode, and the expected package of documents. After that, we assemble the program architecture, venue, technical plan, roles, and budget.

Sources

• Scrum Guides: the official Scrum Guide
• Atlassian Team Playbook: dependency mapping
• Atlassian Team Playbook: decision-making and roles
• GOV.UK Service Manual: multidisciplinary team
• GOV.UK Service Manual: governance principles for agile delivery
• Product School: product roadmap
• Aha!: product roadmap guide
• W3C Web Accessibility Initiative: accessible events and presentations
• GitLab Handbook: all-remote meetings