The building is the operating unit

A resident can like the idea of recycling and still live inside a system that makes recycling fail.

That was the useful lesson from the Dubai recycling service-design case I worked on during my MBA. The project was academic in structure, coordinated with a real company, and the practical question was simple on the surface: why does apartment recycling break down even when people say they care?

The obvious answer is awareness. People need to care more, read the instructions, separate waste properly, and build the habit.

Awareness mattered, but it was not the operating unit.

The resident was the visible user. The building was the unit that had to work.

That distinction changes the product problem. If you design only for the resident, you optimize reminders, bins, messaging, and convenience at the apartment level. Those things can help, but they do not answer what happens after the resident acts. Who collects the material, keeps it separate, has access, pays, proves the service worked, and absorbs failure when the handoff breaks?

In an apartment building, the recycling service was not just a resident behavior problem. It was a chain between residents, cleaners, property managers, the recycling operator, and the payer. Each group needed something different from the same service, and the service had to survive movement between them.

This is why the building became the operating unit.

The building had the shared infrastructure, the cleaning routines, the management layer, the service contract, and the repeated handoff. The resident could participate, but the resident could not make the system work alone.

The design move was a tagged reusable bag, small enough to sound ordinary and practical enough to matter.

The bag became the common object that carried state across the system, not just a container. The resident used it to separate material. The cleaner could identify it quickly. The property manager could see participation and recovery patterns. The operator could track collection. The payer could understand whether the amenity was being used and whether the service justified the spend.

One object gave different actors a shared way to interact with the same workflow.

This shared operating layer is often missing in B2B2C products. Founders design for the person who touches the product, then discover that adoption depends on a different unit: a household, a team, a branch, a building, a clinic, a restaurant, a property, a fleet, a class, or a service route.

The visible user is important, but the operating unit is the smallest group of people, objects, incentives, and handoffs that must work together for adoption to hold.

For a UAE marketplace, the user might be the customer, while the operating unit includes the merchant, courier, customer service team, payment flow, refund rule, and delivery window.

For a PropTech product, the user might be the tenant, while the operating unit includes the landlord, property manager, maintenance vendor, building security, service-level agreement, and payment responsibility.

For a hospitality tech product, the visible user might be a guest or staff member, while the operating unit includes front desk, housekeeping, operations, finance, vendors, and the manager who deals with the complaint when the system breaks.

For a sustainability service, the person who cares about the outcome may not be the person who pays for the system or operates the handoff.

This is where adoption gets misread.

A founder hears positive user feedback and assumes the product is close. People like the idea, say they would use it, understand the demo, follow the interface, and accept the business case in principle.

Then usage weakens after launch because the real operating unit was never designed.

The buyer has no proof of value, the operator has no practical workflow, the service staff inherit extra work, the approver cannot defend the spend, and the visible user has intent without a system around them.

That usually means the issue is system fit, not persuasion.

The Dubai recycling case made this very concrete. A resident might care enough to sort material inside the apartment, yet the value disappears if the cleaner cannot recover the bag quickly, if the building has no collection logic, if the property manager cannot see whether the service is working, or if the payer treats the program as a nice idea rather than a managed building amenity.

The handoff between actors mattered more than the message to any one actor.

The reusable bag helped because it gave the handoff a body, making the service visible, recoverable, trackable, and shared. The bag carried the state that would otherwise be lost between resident intent and building-level execution.

The product lesson sits there.

Sometimes the product object is not the app, page, or feature. It is the thing that allows different actors to coordinate without each one carrying the whole system in their head.

In software, that object might be a shared dashboard, a case record, an onboarding checklist, a tagged customer state, a claim file, a booking object, or a workflow status that means the same thing to sales, support, operations, and the buyer.

The object is useful when it answers four questions across roles:

• who needs to act next;
• what state are they inheriting;
• what proof or constraint travels with the work;
• who absorbs the cost if the handoff fails.

If the object only helps the visible user, it may improve the surface while leaving the operating unit broken.

That is the trap in a lot of early product work. The team can make the visible experience easier and still leave the buyer with no reason to renew, the operator with extra labor, the approver with no evidence, and the service staff with another exception to manage.

The interface then gets blamed because it is the easiest thing to inspect.

Sometimes the interface is the problem. Often, the interface is where the operating-unit problem becomes visible. The product asks one actor to do something useful, but the system around that actor does not make the useful action repeatable.

For a marketplace, that might mean the customer flow is clean but merchant operations are chaotic. For a property product, the tenant flow may be smooth while vendor assignment, access, proof, and payment remain messy. For a hospitality product, the guest experience may look good while the handoff between front desk, housekeeping, maintenance, and finance creates the real service drag.

The product lesson is not to ignore the user.

It is to stop assuming the user is the whole product environment.

That is why I do not start service or B2B2C product work by asking only who the user is. I want to know who uses, who pays, who approves, who operates, who recovers failure, and what object carries state between them.

The answer often changes the product strategy.

A founder may think the work is onboarding when the issue is payer proof, UX when the issue is service staff friction, marketing when the operating unit has no shared object, or weak adoption when the product is asking one person to carry a system that actually belongs to several actors.

This is especially relevant in Dubai and the wider UAE because so many startup categories are service-heavy. Marketplaces, PropTech, delivery, hospitality, sustainability, fintech, and business services often sit between the person who experiences the service and the person who buys, manages, approves, or operates it.

The product can look good in isolation and still fail in the building, branch, store, route, property, or team where it has to live.

The audit question I would ask first is simple: what is the operating unit?

If the answer is a person, design for the person; if it is a team, design for the team; if it is a building, route, property, or service chain, do not pretend the interface alone can carry the adoption problem.

A system-level audit is useful when the product keeps failing somewhere between user intent and operating reality. It maps who uses the product, who pays for it, who operates the handoff, who absorbs failure, and where state needs to transfer.

The Dubai recycling case study is one example of that logic. The target metrics in that work were practical: weekly participation, bag recovery, and extraction time. The point was not to make recycling sound better. The point was to make the system easier to operate than to ignore.

The principle I keep coming back to for B2B2C work is direct.

Design for the operating unit, not only the visible user.