Modeling a Solution: Object-Oriented Business Modeling for Product Managers

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:

1. Enter the phone number
2. 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

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:

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

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