Your job as a product manager is to get inside the heads of your stakeholders and extract what they know about the business system — then pass it on to developers in a way that can be simulated on a computer.
Modeling a solution is the central communication act you will perform as a product manager. The actual job is not just to gather requirements, but to translate messy, incomplete stakeholder knowledge into a precise, shared representation that developers can build against.
Many organizations excel at building good software products. Where they fail is often in building the right software product. This mismatch between what users want and what developers deliver frequently traces back to poor business analysis and unclear requirements. The ripple effect of one small business change cascading into many project deliverables causes delays and cost overruns.
Right modeling provides a step-by-step procedure that ensures completeness, correctness, and clarity of requirements documentation. Using object-oriented (OO) techniques minimizes redundancies by enforcing the principle of “one fact in one place,” making requirements easier to revise and reducing miscommunication between business and development teams.
Why modeling matters more than just writing stories
You might wonder: why not just write user stories or plain text requirements? Because communicating effectively and unambiguously is the most important thing a product manager will ever do.
Stories and text are often ambiguous, incomplete, and open to interpretation. Modeling forces you to structure knowledge explicitly, exposing gaps and assumptions early.
A business model is an abstract representation of a clearly delimited area of business. It can take many forms — plain text, wireframes, pictures, diagrams. But whatever form it takes, the goal is to build a shared mental model that connects business reality with the IT solution.
The object-oriented approach: starting with objects
Object orientation begins with a simple observation: when you perceive the world, you don’t just take in a blur of sensations. Instead, you distinguish individual objects — things you recognize, name, and think about.
These internal objects model a segment of the real world.
You start analyzing a business area by asking stakeholders to describe the business objects it encompasses. A business object is something the business (and the IT system that automates it) must keep track of or that participates in business processes.
Examples include:
- An invoice
- A customer-service representative
- A call
The product manager’s job is to identify these objects clearly and comprehensively.
Attributes and operations: what you remember about objects
When you think of an object, you remember two things:
- The values of its attributes (properties)
- The operations you can perform on it
For example, consider a shirt object. You know its color is blue and size is large — those are attributes and their values.
Similarly, you know what you can do with a shirt — wear it, wash it, fold it. Those are operations.
In a business context, take an account object:
- Attributes might include balance and date last accessed
- Operations might include deposit and withdraw
Operations usually change or query attribute values. For example, the withdraw operation reduces the balance attribute.
But not all operations directly affect attributes. For example, view transaction history displays information about related transaction objects but may not change the account's attributes.
Methods: how you perform operations
You don’t just remember what you can do with an object; you also remember how you do it.
For example, to place a call on a mobile phone, you:
- Enter the phone number
- Press the Send key
The operation is “place a call.” The procedure you follow to do it is called a method.
As a product manager, you ask stakeholders to describe the methods they use to carry out operations.
For example, for the withdraw operation on an account, stakeholders might say:
- Check if there is a hold on the account
- Verify sufficient funds
- Reduce balance
- Create an audit trail
You document this procedure as the method for the withdraw operation.
Encapsulation: hiding complexity behind interfaces
You use objects every day without knowing their internal structure. This is encapsulation — only an object’s operations are visible to other objects; its attributes and methods remain hidden.
When documenting methods, you don’t mention the attributes or methods of other objects. This separation means if the internal workings of an object change, you only update one part of the model.
Encapsulation reduces complexity and makes models more maintainable.
Classes: grouping similar objects
You don’t just model individual objects; you categorize them into classes.
A class is a category of objects that share the same attributes and operations, though each object has its own attribute values.
For example, all iPhone X phones belong to the iPhone X class:
- They share attributes like serial number, phone number, camera settings
- They support the same operations like placing calls and taking pictures
- They follow the same methods for operations
Despite the name “object-oriented,” most of your time will be spent defining classes, not individual objects.
Classes related to the business are called entity classes.
Examples in banking:
- Account entity class
- Customer entity class
Relationships between classes: inheritance and generalization
Classes can relate to one another in several ways.
Generalization and inheritance
Sometimes, a set of objects are only partially alike. For example:
- iPhone X and Samsung S8+ are different phone models
- Both are kinds of Mobile Phones
Mobile Phone is the generalized class (superclass). iPhone X and Samsung S8+ are specialized classes (subclasses).
This “is a kind of” relationship is called generalization.
Inheritance means a specialized class automatically adopts the attributes, operations, and relationships of its generalized class.
For example:
- Mobile Phone can receive a text message
- Therefore, iPhone X and Samsung S8+ can also receive text messages
This allows you to state rules once at the generalized level, simplifying documentation.
Other terms for generalization
| Generalized class | Specialized class |
|---|---|
| Superclass | Subclass |
| Base class | Derived class |
| Parent | Child |
How to apply inheritance
Identify subtypes of a general class. For example:
- Checking Account and Savings Account are specialized classes of Account
- Document attributes and operations common to all accounts at the Account level
- Document specialized attributes and operations at the subtype level
This reduces duplication and makes future changes easier.
Associations: linking classes
Another relationship is association, which connects objects of one class to objects of another.
For example, a mouse is associated with a PC when connected.
An association at the class level means objects of one class may be linked to objects of another.
In business modeling, associations represent rules like:
- Which mechanics serviced which equipment
- What maintenance schedule applies to each piece of equipment
Missing or incorrect associations can lead to software that fails to support critical business rules.
Aggregation: whole-part relationships
Aggregation models relationships where one class is a whole made up of parts.
For example:
- An insurance policy is an aggregation of a basic policy and its amendments
- A stamp collection is an aggregation of stamps
Aggregation lets you reuse parts in multiple contexts.
For instance:
- Model an ATM card as an aggregate with a PIN as a part
- Later reuse the PIN requirements for a credit card system
Composite aggregation (composition): stronger whole-part
Composite aggregation, or composition, is a stronger form of aggregation.
In composition:
- Each part belongs to only one whole at a time
- When the whole is destroyed, its parts are destroyed too (unless removed earlier)
Example:
- A Diamond Case Report Form composed of multiple Modules
- Each Module belongs to only one Case Report Form
- Deleting the Case Report Form deletes all its Modules
If unsure, model the relationship as aggregation or simply as an association — this won't break the solution but may lose nuance.
Polymorphism: one interface, many implementations
Polymorphism means the ability to take many forms, applied to both objects and operations.
Polymorphic objects
Consider different Fund subtypes: Asia Fund, Domestic Fund, etc.
- Fund is the generalized class
- Subtypes have their own idiosyncrasies
An operation like invest capital works on all Funds the same way at the class level, but the actual method executed depends on the subtype.
Polymorphic operations
An operation like accept deposit might have:
- A default method at the Fund level
- An overridden method in the Asia Fund subtype to handle supplementary charges
This means the same interface (operation) can have multiple implementations (methods) depending on the object.
How to apply polymorphism
Define operations for generalized classes that all subtypes support.
Provide default methods for these operations.
If subtypes require different procedures, document specialized methods at the subtype level.
This avoids complex conditional logic in documentation and code.
Example
Cars use the same interface — an accelerator pedal — to change speed, even though the internal mechanics differ. Drivers don't have to learn a new interface for each model.
Use cases and scenarios: capturing user interactions
A use case is a usage of the system that produces an observable, usually meaningful, result.
Use cases are documented as diagrams or text that outline the series of steps in an interaction, including alternate flows.
A scenario is one path through a use case — one way it might play out.
Examples in Web banking:
| Use Case | Examples of Scenarios |
|---|---|
| Make bill payment | 1. Payment succeeds |
| 2. Payment fails due to a hold on the account | |
| Stop payment | Various ways a stop payment can be requested |
| Order checks | Different flows for ordering checks |
During behavioral analysis, you identify and document use cases and their scenarios. These form the user requirements.
Use cases drive the whole development process. Each release implements a planned set of system use cases to deliver real value.
Test your understanding: modeling a simple business domain
Pick a simple business domain you know well — e.g., a local grocery store, a taxi booking app, or a school management system.
- Identify at least five business objects involved. For example, in a taxi app: Driver, Rider, Ride, Payment, Vehicle.
- For each object, list key attributes (properties). For Driver: name, license number, rating.
- For each object, list operations you can perform. For Ride: book, cancel, complete.
- Identify classes and any inheritance relationships. For example, Vehicle could be a general class with Car and Bike as subtypes.
- Identify associations and aggregations. For example, Driver is associated with Vehicle; a Ride aggregates Payment details.
- Write down at least one use case and two scenarios illustrating alternate flows.
This exercise helps you practice translating domain knowledge into an object-oriented model.
From the field: Why Indian startups must master modeling
Where to go next
- If you want to learn how to validate your models with real users: User Research Methods
- If you want to translate requirements into concrete user stories: Writing Effective User Stories
- If you want to manage agile development processes effectively: Agile Product Management
- If you want to deepen your understanding of product discovery: Product Discovery Fundamentals
- If you want to sharpen your communication skills for cross-functional teams: Stakeholder Management and Communication