| name | unifying-concept-product-expansion |
| description | A framework for evaluating whether to bundle new products into a single app or ecosystem based on user mental models. Use this when planning a multi-product strategy, considering a "super app" approach, or diagnosing low adoption of cross-sold services. |
The Unifying Concept Framework for Product Expansion
A common mistake in product expansion is assuming that high engagement in one service (e.g., ride-hailing) automatically grants permission to sell any other service (e.g., financial top-ups or massages). This framework helps you identify the "unifying concept" that dictates whether a new product will feel intuitive to your users or create friction and brand confusion.
Core Principles
Identify the "Anchor" Concept
The success of a multi-product app depends on the single mental model the user has for your service.
- The Driver Concept: For Gojek, users viewed the app as "A person on a motorcycle who can do things for me."
- The Utility Concept: If a user views your app as a specific tool (e.g., "The way I get to work"), they will struggle to discover or trust unrelated services.
Test for Intuitive Discovery
Cross-selling fails when it requires heavy customer education. If a user doesn't intuitively associate your "anchor" with the new service, discoverability will remain low even with prime UI real estate.
The Application Process
1. Define Your Current Anchor
Identify the core physical or digital entity the user interacts with.
- Is it a person (driver, courier, stylist)?
- Is it a specific asset (a car, a house, a bank account)?
- Is it a specific action (sending a message, paying a bill)?
2. Map the "Permission" Radius
List potential services and ask: "Does the user believe the Anchor is capable of this?"
- High Permission: A driver can carry a person, a package, or a meal. (Low CAC, high adoption).
- Low Permission: A driver is not expected to be a masseuse or a financial advisor. (High CAC, low trust).
3. Conduct the "Discovery Gap" Audit
If an existing sub-service has low adoption, use this specific UXR sequence:
- Identify the Need: Confirm if the user actually needs the service (e.g., "Do you use prepaid phone minutes?").
- The Awareness Question: "Do you know you can do [Service X] inside our app?"
- The 'Why' Investigation: If they knew it existed but didn't use it, determine if the "Unifying Concept" is broken (e.g., "I didn't think a driver would be good at that").
4. Evaluate Design Constraints
Avoid the "Giant Grid of Buttons" trap. If you have more than six services, your UI will likely devolve into a menu that limits your ability to create a specialized, high-quality experience for any single service.
Examples
Example 1: Logical Extension
- Context: An on-demand motorcycle ride-hailing app (Gojek) wants to launch food delivery.
- Anchor: The Driver.
- Unifying Concept: "A guy on a bike who can move things."
- Result: High success. Users intuitively understand that the same person who gives them a ride can pick up a bag of food.
Example 2: Concept Breakage
- Context: The same app launches on-demand massages.
- Anchor: The Driver.
- User Reaction: Confusion. Users asked, "Is the driver going to come into my house and give me a massage?"
- Result: Failure. The user's mental model of a "driver" did not include "trained medical/wellness professional," creating a trust barrier that UI and discounts couldn't fix.
Common Pitfalls
- The "Strategy Deck" Mirage: Don't be swayed by "lower CAC" or "higher retention" metrics in pitch decks. These only manifest if the unifying concept holds.
- The Eyeball Fallacy: Assuming that 10 million users seeing a button equals 10 million potential customers. If the button doesn't match the user's "job to be done" for that app session, they will suffer from functional blindness.
- Ignoring Cultural Artifacts: Failing to see how users actually use your product. Gojek noticed users sending food as gifts to romantic interests and built "Far-Away Delivery" to support that specific cultural behavior.
- Over-Bundling: Adding services that require different trust levels. High-frequency, low-trust services (rides) rarely mix well with low-frequency, high-trust services (medical, legal) without a massive brand shift.
