B.O.O.M Step 1: Initiation Phase in Product Management

The Initiation phase is where a project moves from a vague idea to a concrete proposal. Your actual job as a Product Manager here is to identify and analyze the business requirements that justify pursuing the project. This means working closely with stakeholders to understand the business goals, the workflows that will be affected, and the scope of the solution.

Without this clarity, the project risks drifting without purpose or clear value. The Initiation phase sets the foundation for everything that follows.

Your goal in this phase is not to design the solution but to establish what the business is trying to achieve and who is involved.

The Initiation phase grows the project from idea to proposal

During the Initiation phase, the project is still a bare-bones concept. You will work to outline the main aspects and reasons for pursuing it. This is the phase where you:

• Interview stakeholders to establish the business rationale and scope
• Collect initial high-level requirements
• Identify business use cases representing end-to-end workflows affected by the project
• Begin drafting the Product Requirements Document (PRD), capturing these initial findings

The PRD you start here is a living document. It evolves as the project progresses but acts as the contract between business and developers.

The Initiation phase typically takes a few days to a few weeks depending on project size. For larger projects, it might stretch to months.

Conducting interviews across project phases

You will conduct interviews at multiple phases:

• Initiation phase: Focus on stakeholders to establish business rationale, scope, and initial requirements.
• Discovery phase: Meet users and stakeholders to discover and document detailed business requirements for the system.
• Development phase (iterative projects): Continue gathering requirements as the solution is built.
• Final Verification & Validation (V&V) phase: Validate that the software meets stakeholder needs.

Each interview type serves a different purpose depending on the phase. Early interviews are broad and exploratory; later ones focus on detailed workflows and validation.

You will also hold review sessions with stakeholders to verify that requirements documentation is correct and complete.

Identifying business use cases as the foundation

A core activity in the Initiation phase is to identify business use cases. These are the end-to-end business processes your project will affect.

A business use case is a specific workflow representing an interaction a stakeholder has with the business to achieve a goal. It may involve manual steps, automated processes, or both, and can span extended periods.

Focusing on these use cases early ensures the project keeps the business perspective front and center. You avoid building a system that solves technical problems but misses business value.

Understanding stakeholders: business actors and workers

Stakeholders fall broadly into two categories:

• Business actors: External to the business, such as customers or suppliers.
• Workers: Internal employees or representatives, like customer service agents.

An association in a business use-case diagram connects actors with the use cases they interact with — for example, initiating or carrying out a workflow.

You will map these relationships visually to understand who is involved in each business use case.

Planning interviews to analyze workflows

Once you have a business use-case diagram mapping stakeholders to processes, plan interviews focusing on subsets of these use cases.

Invite all relevant stakeholders, including:

• Those directly involved in the workflow
• Off-stage stakeholders who have an interest but do not interact directly, such as regulators or senior management

The purpose of these interviews is to analyze the workflow — the sequence of activities and who performs each.

Document workflows either through text descriptions or activity diagrams. Use formal templates if you are improving business processes broadly; otherwise, informal text plus diagrams usually suffice.

Documenting workflows with activity diagrams and swimlanes

Workflows can get complex. Use activity diagrams with swimlanes to clarify:

• The sequence of activities
• The actors responsible for each step
• Transitions between states of business objects

For example, an invoice might pass through states like Created, Due, Paid, and Written Off. Each state change corresponds to business rules or actions.

Swimlanes partition the diagram by actor, showing who performs each activity. This makes roles and responsibilities explicit.

Business objects and states

Business objects (like invoices, cases, orders) have lifecycles with identifiable states. Ask stakeholders what statuses they use to track these objects.

Changes to state are important because the business treats objects differently based on their state. For example, a "Paid" invoice triggers different processes than a "Due" one.

Activity diagrams connect states and activities with object flows, indicating inputs and outputs of activities.

Baselining the Initiation phase deliverables

At the end of the Initiation phase, you will have:

• A rough but clear business case
• Business use-case diagrams mapping actors to workflows
• Initial workflow documentation, possibly with activity diagrams
• An early version of the PRD capturing these business requirements

You baseline the PRD here — saving it as a reference point under change control. This ensures any later changes to scope can be managed carefully.

For agile projects, requirements are generally not baselined unless they are actively being developed.

Preparing for the Discovery phase

Discovery is where most of your time will go after Initiation. It involves deep requirements analysis and detailed documentation.

You will:

• Investigate each system use case thoroughly
• Refine and update the PRD based on new information
• Collaborate with analysts and developers to ensure clarity

The Initiation phase sets the stage for Discovery by ensuring you have a shared understanding of business goals and key workflows.

The role map and system use cases

Once business use cases are clear, you identify system use cases — the user goals the IT system must support.

Actors for system use cases are the users or external systems interacting with the IT system.

You create a role map to standardize actors across the project. This helps when multiple people analyze or design system use cases.

System use cases focus on what the user wants to achieve with the system, keeping the team user-centered.

Generalization in actor modeling

Actors may have overlapping or hierarchical roles:

• Partial overlap: Two actors share some capabilities but also differ. Use an abstract generalized actor to represent the shared part.
• Complete inclusion: One actor can do everything another can and more. Model the lesser role as generalized, the larger as specialized.

Generalization simplifies diagrams and clarifies relationships between users.

Organizing system use cases into packages

For large projects with many use cases, group system use cases into packages.

Common grouping strategies:

• By primary actor (e.g., all admin-related use cases)
• By business use case (e.g., all use cases supporting "Make a Claim")

Packages act like folders, helping organize and manage complexity.

Documenting system use cases

Each system use case describes a user task or goal when interacting with the system.

Use-case diagrams show:

• Primary actors who initiate interactions
• Secondary actors who the system interacts with during the use case
• The use case itself (often shown as an oval)

Connections use UML association lines with arrows indicating who initiates.

You may have multiple primary actors for a use case if more than one user role can start it.

The PRD as the contract

The Product Requirements Document (PRD) is the central artifact capturing requirements.

It evolves from Initiation through Discovery and beyond but always serves as the contract between business and developers.

If a requirement is not in the PRD, it is not part of the project scope.

Your job is to ensure the PRD is complete, correct, and unambiguous.

The PM’s guiding principle: focus on impact

Not every B.O.O.M step is required for every project. The guiding principle is:

If it won’t make a difference to the outcome, don’t do it.

Focus your effort on what advances the project’s goals and clarifies requirements.

Test yourself: Planning Initiation interviews

You are a new PM at a Series A fintech startup in Bangalore. The company is considering building a loan management system. Your CEO wants you to lead the Initiation phase.

• How do you identify which stakeholders to interview first?
• How do you map business use cases and actors?
• What documentation will you prepare to baseline before Discovery?

Where to go next

• Learn how to analyze and document system use cases: B.O.O.M Step 2 - Discovery Phase
• Master user research techniques for product discovery: User Research Methods
• Understand how to write effective PRDs: Writing Product Requirements Documents
• Explore UML diagrams for product managers: UML for PMs
• Prepare for iterative and agile projects: Agile Product Management

PL alumni now work at Razorpay, Swiggy, Flipkart, PhonePe, and 30+ other companies.