Modeling a Solution: The Object-Oriented Approach

Communicating product requirements clearly and unambiguously is the most important thing a product manager will ever do. The mismatch between what users want and what developers build often traces back to poor business analysis and unclear documentation.

Many organizations excel at developing good software products. Where they often fail is in developing the right software product. The ripple effect — where one change in business leads to many changes in project deliverables — causes time and cost overruns. The key to avoiding this is modeling the solution properly, with a step-by-step approach that ensures completeness, correctness, and clarity.

This lesson introduces you to the object-oriented (OO) modeling approach — a powerful way to represent business systems that reduces redundancies, improves communication, and aligns stakeholders and developers.

Why modeling matters more than stories or docs

You might wonder: why not just write user stories or plain text requirements? Because effective and unambiguous communication is the central role of a product manager. Stories alone often leave room for interpretation, leading to costly rework.

A business model is an abstract representation of a clearly delimited business area. It can take many forms — plain text, wireframes, pictures. But without a structured approach, the risk of miscommunication between those who know the business and those who build the software is high.

The object-oriented approach helps by using the same diagrams, concepts, and terminology as developers. This reduces misunderstandings and aligns everyone on the same mental model.

The product manager’s job: translating minds to machines

Your actual job as a product manager is to get inside the heads of your stakeholders to extract what they know about a piece of the real world — a business system — and then pass it on to developers who will simulate that system on a computer.

You want an approach that goes as directly as possible from stakeholders’ mental models to the IT solution. This approach must begin with how people think about the world and be broad enough to take the project from requirements gathering right through to software construction.

Object orientation starts with the simple idea that an object is the basic unit by which we organize knowledge. From this, it builds a powerful framework to understand and model complex systems.

Objects: the building blocks of business models

When you perceive the world, you don’t just take in a blur of sensations. You distinguish individual objects and have internal images of them. These internal objects model a segment of the real world.

You begin analyzing a business area by asking stakeholders to describe the business objects it encompasses. A business object is anything the business and the IT system must keep track of or that participates in business processes.

Examples of business objects include:

• An invoice
• A customer-service representative
• A phone call

Each object represents a concrete entity or concept relevant to the business domain.

Attributes and operations: what you remember about objects

Our internal representation of an object includes two key things:

• Attributes — the properties or characteristics of the object. For example, a shirt’s color and size. In OO terms, color and size are attributes; blue and large are attribute values.

• Operations — the functions or actions you can perform with the object. For example, a crayon’s operation is to scribble on walls.

Every object has its own set of attribute values and supports certain operations.

For example, an Account object might have:

• Attributes: balance, date last accessed
• Operations: deposit, withdraw, view transaction history

Operations usually change or query attribute values. For example, the withdraw operation changes the balance attribute.

Methods: how you carry out operations

You don’t just remember what you can do with an object, you also remember how to do it. For example, to place a call on your mobile phone, you first enter the phone number, then press the send key.

In OO terms:

• The operation is place a call.
• The procedure to carry it out is called a method.

As a PM, you ask stakeholders the procedures they follow for each operation and document these as methods.

For example, withdrawing funds might involve checking for holds, verifying sufficient balance, reducing the balance, and creating an audit trail.

Encapsulation: hiding complexity behind interfaces

Every day you use objects without knowing their internal structure. This is the OO principle of encapsulation: only an object’s operations are visible to other objects; its attributes and methods remain hidden.

When describing methods, don’t mention the internal details of other objects or how they perform their operations.

Encapsulation reduces dependencies. If methods or attributes of a business object change, you only need to update one part of the model.

Classes: categories of objects

You don’t model individual objects one by one. Instead, you group objects into classes — categories of objects that share the same attributes and operations but may have different attribute values.

For example, all iPhone X phones belong to the class iPhone X. Knowing this, you know:

• The attributes that apply to all iPhone X phones: serial number, phone number, camera settings
• The operations all iPhone X phones support: place a call, take a picture
• The methods for these operations are the same across the class

Most of your time will be spent defining entity classes relevant to the business, such as Account or Customer in a banking system.

Generalization: organizing classes into hierarchies

Sometimes you have classes that share some attributes and operations but also differ. For example:

• iPhone X and Samsung S8+ are different classes but both are kinds of Mobile Phone.

This relationship is called generalization:

• Mobile Phone is the generalized class (superclass).
• iPhone X and Samsung S8+ are specialized classes (subclasses).

Any attribute, operation, or relationship that applies to the generalized class also applies to its specialized classes. This is the OO principle of inheritance.

For example, if Customer OWNS Accounts is a relationship specified for the Account class, it also applies to Checking Account and Savings Account, which are specialized classes of Account.

Generalization helps you document common rules once and reuse them across subclasses, making requirements easier to maintain and extend.

Association: linking classes through relationships

Classes can be related through associations — links between instances of one class and instances of another.

For example:

• A Mouse is associated with a PC when connected.

Associations specify how objects of one class relate to objects of another, or even to objects of the same class.

As a PM, documenting associations is critical. Missing or incorrectly documenting associations can cause software to fail in supporting important business rules.

Aggregation: whole-part relationships

Aggregation is a special type of association representing a whole-part relationship.

For example:

• An Insurance Policy is an aggregation of a Basic Policy and Amendments.
• A Stamp Collection is an aggregation of Stamps.

Aggregation helps you model complex business objects made up of smaller parts.

You document which attributes, operations, and relationships apply to the whole and which apply to the parts.

Aggregation also enables reuse. For example, modeling a PIN as part of an ATM Card lets you reuse PIN requirements for a Credit Card system.

Composite Aggregation: stronger whole-part ties

Composite aggregation or composition is a stronger form of aggregation where each part belongs to only one whole at a time.

In composition:

• Parts are destroyed when the whole is destroyed (unless removed earlier).
• The relationship is exclusive.

Example:

• A Diamond Case Report Form composed of Modules.
• Modules belong to only one report form at a time.
• When the report form is deleted, its modules are deleted too.

If unsure about whole-part relationship types, default to aggregation or even association. The nuance is helpful but not critical from a PM perspective.

Polymorphism: one interface, many implementations

Polymorphism means the ability of objects or operations to take many forms.

Polymorphic objects

Consider a Fund class with subtypes like Asia Fund and Domestic Fund. The invest capital operation applies to all funds the same way, regardless of subtype.

At runtime, the Fund object behaves as its specific subtype.

Polymorphic operations

Sometimes specialized classes override methods of generalized classes.

For example:

• The accept deposit operation is defined in Fund.
• The Asia Fund class overrides the method to include supplementary charges.

This means one interface supports many implementations depending on the object’s class.

Polymorphism simplifies requirements by avoiding complex conditional logic. You document different methods at the appropriate class level.

Use cases and scenarios: capturing user requirements

A use case is a sequence of interactions with the system that produces a meaningful result.

A scenario is one specific path through a use case.

For example, in a web banking system:

• Use case: Make bill payment
• Scenario 1: Payment succeeds
• Scenario 2: Payment fails due to hold on account

Documenting use cases and scenarios captures user requirements fully. This forms the foundation for designing and building the system.

How to apply OO modeling as a PM

1. Identify business objects relevant to your domain.
2. Define attributes and operations for each object.
3. Document methods describing procedures for operations.
4. Group objects into classes and define class attributes and operations.
5. Establish generalization hierarchies to reuse common rules.
6. Model associations, aggregations, and compositions to capture relationships.
7. Leverage polymorphism to simplify operation variations.
8. Write use cases and scenarios to capture user interactions.

This structured approach reduces redundancies, minimizes ripple effects when business changes, and improves communication with developers.

The ripple effect and how OO helps

The ripple effect occurs when one change in business causes many changes in project deliverables, leading to overruns.

The OO principle of "one fact in one place" reduces this by minimizing redundancy.

When rules and requirements are documented in one location (e.g., the generalized class), you only need to update them once.

This makes requirements easier to revise and reduces errors.

The communication gap between business and IT

Many project failures stem from faulty communication between those who know the business and those who write software.

OO modeling helps by using the same diagrams, concepts, and terminology as developers.

This alignment reduces misunderstandings and accelerates development.

Test yourself: Modeling a payment system

You are the PM at a fintech startup in Bangalore building a digital wallet. Your stakeholders describe the following:

• Users can add money to their wallet.
• Wallets can be of types: prepaid, postpaid.
• Prepaid wallets allow instant payments up to the balance.
• Postpaid wallets allow payments on credit with a monthly limit.
• Users can transfer money between wallets.
• The system must record transactions and support refunds.

Question: How would you model the wallets, transactions, and operations using object-oriented principles? Identify classes, attributes, operations, and relationships.

Where to go next

• Master user story writing and requirement gathering: Discovery and Requirements Definition
• Learn to design effective business models: Business Model Design
• Understand Agile methodologies for product development: Agile and Scrum for PMs
• Explore product launch and go-to-market strategies: Taking Products to Market
• Develop stakeholder management and communication skills: Influencing Without Authority