The Business Model Canvas for Two-Sided Marketplaces

Why the standard canvas breaks on a marketplace

Every block on the canvas is written in the singular: Customer Segments, not Customers; Value Proposition, not Propositions. That reads as a harmless simplification until you try to fill it in for a marketplace and find that each block silently forces a single answer.

The clearest failure is Value Propositions. For a ride-hailing app, the rider is buying a car that arrives in a few minutes at a price quoted before the trip. The driver is buying paid work that fits around a day job, without owning a fleet or advertising for customers. Those are different products with different promises, and they are not merely distinct — they pull against each other. Riders want short waits, which requires idle drivers nearby, which lowers each driver's earnings per hour. Put both on one sticky note and that tension disappears from the board, which is exactly the tension that decides whether your marketplace holds together.

Revenue Streams hides the same problem in the other direction: it hides who actually pays. A single "commission" note conceals that the rider pays a service fee, the driver pays a percentage or a subscription, and one of those two is frequently below cost because you are buying loyalty. Cost Structure then hides the subsidy entirely — a marketing line for rider discounts is recorded as spend but not as a decision about which side you are buying.

Channels, Customer Relationships, Key Activities and Key Resources fail the same way. You recruit drivers through referrals, depots and phone calls, not through the same campaign that reaches riders. You support drivers with payout questions and deactivation appeals, and riders with refunds and cancellations. You maintain a verified supply pool and a payout float that have no buyer-side equivalent. A single-answer canvas records whichever side you happened to be thinking about, and the other side goes unmodelled.

The split-block method

The fix is mechanical, and you can do it on paper. Duplicate every block into two columns, one per side, and give each side a colour. Then apply one rule when you place a note: if it cannot be assigned to exactly one side, it is not one note — it is two notes you have not split yet, or it belongs in cost structure and should be marked as shared. Nine blocks, two columns each, eighteen small conversations you would otherwise have skipped.

Work the blocks in this order, because each one constrains the next. Customer Segments first, and write supply on the left; you will be spending money to acquire them earlier than you think. Value Propositions second, phrased as an outcome for each side rather than a feature of your app. Channels and Customer Relationships third and fourth, since the answer to "how do we reach them" is different for each side and the relationship you maintain with a driver looks nothing like the one you maintain with a rider. Revenue Streams fifth, and force yourself to write the payer next to each stream. Key Resources, Key Activities and Key Partnerships sixth through eighth, with the trust infrastructure — verification, ratings, dispute handling — named explicitly, because it is what buyers are actually paying for. Cost Structure last, and split it by side so the subsidy is visible rather than averaged away.

The prompts below are the ones worth copying. They are deliberately phrased as questions rather than labels, because a question pulls a specific answer out of you and a label lets you write something vague and move on.

Worked example: a Guyana ride-hailing marketplace

Below is a board captured from an actual working session, transcribed as it was written rather than tidied up. It is a ride-hailing marketplace for Guyana, with commuters on the rider side and drivers on the driver side. It is a useful example precisely because it is competent and still incomplete — which is what most first-pass marketplace canvases look like.

The two omissions that matter most

The first is Cost Structure. The board lists marketing, customer support and fees on the rider side, and fees, licences and employees on the driver side. What is missing is the largest line item any marketplace carries: driver payouts and driver incentives. Insurance appears under Key Partnerships but never reaches Cost Structure, even though it is a real recurring premium and, in a market where a driver may be carrying passengers in a privately owned vehicle, a materially large one. A filled-in version would add guaranteed minimum earnings for drivers during the cold-start period, a fuel or completion bonus if you choose to run one, per-trip insurance, payment processing and remittance charges on every e-transfer payout, and refunds and cancellation costs on the rider side.

The second is misfiling. "E-transfer" sits under Channels on the rider side, but an e-transfer is a payment rail, not an acquisition channel — nobody discovers your app because you accept bank transfers. It belongs in Key Partnerships as a payment relationship and in Cost Structure as a fee, and the rider-facing decision about whether to require a card on file belongs under Revenue Streams. The board has a related ambiguity in the word "fees", which appears in both Revenue Streams and Cost Structure without saying whose fees: the commission you collect is a different thing from the bank charges you pay, and leaving both as "fees" makes the unit economics unreadable.

Two smaller fixes are worth making while you are there. Customer Segments lists commuters before drivers, which quietly implies the rider side is primary; on a canvas the order should reflect the side you must acquire first, because that is the side the costs are really about. And driver-side "Employees" is the only staffing note, which suggests the rider side runs itself — customer support is listed as a cost but not as an activity, and someone has to handle the disputes that follow a bad trip.

Why the colour convention is the most useful habit here

Blue for the rider side, green for the driver side. Two colours sounds like decoration until you use them consistently for an hour, at which point the board starts telling you things you did not write down. A block that is entirely blue is an admission that you have not modelled the supply side of that block at all — which is exactly what happens to Key Activities on the board above, where five notes describe tracking riders, tracking drivers and KYC, and a single note covers onboarding drivers.

The colours also make subsidy legible at a glance. Money that leaves one side and lands on the other shows up as green notes inside blue blocks and vice versa, and once you can see it, you can ask the only question that matters during a cold start: which side is this business currently paying to exist? Without the split, the same information is present but averaged into a single block that reads as cost rather than as strategy.

Cold start, and knowing which side you subsidise

Almost every marketplace guide stops at the canvas. The part they skip is that a marketplace has two cold-start problems and only enough money to solve one of them first, so the canvas is really a tool for deciding which.

In thin markets, supply is usually the harder side, and the reason is asymmetric forgetting. A rider who opens the app at 07:40 and sees no cars nearby concludes the service does not work and does not come back; re-earning that person costs more than acquiring a new one. A driver who opens the app and sees no requests is also disappointed, but drivers are fewer, easier to reach individually, and can be brought back with a guaranteed minimum that makes the empty hour worth their time. So the sequence that usually works is: subsidise supply until density is real on a small corridor, then buy demand into a marketplace that already functions.

That decision has to show up on the board or it is not a decision, it is a hope. Concretely: the guaranteed earnings you pay drivers belongs in Cost Structure on the green side, and next to it you write which Revenue Streams line is expected to cover it once density arrives. If you cannot name that line, the subsidy has no exit condition. Moving that money visibly from Revenue Streams into Cost Structure is the whole exercise — it turns "we will figure out monetisation later" into a dated bet.

Local conditions belong on the canvas too, because they change the answers rather than decorating them. WhatsApp is the dominant channel in Guyana, and for many riders a trusted phone number converts better than an app install, which means Channels on the demand side may honestly read "WhatsApp group + referral" before it reads "app store". Payment is mobile money or a bank e-transfer far more often than a card on file, so payouts are manual, reconciliation is a real activity, and your driver payout cycle is constrained by banking hours rather than by your code. GTT and Digicel coverage determines where live matching works at all, so coverage is a Key Resource constraint and not an engineering footnote. And prices should be set in GYD with the commission defined as a fixed percentage of a GYD fare, because a USD-pegged commission on a GYD fare moves every time the exchange rate does.

Using the free canvas tool

If you want to try the split without redrawing a board by hand, the free business model canvas tool runs entirely in your browser. It gives you the nine blocks with sticky notes, a Two-sided business switch for exactly the split described above — A is supply and green, B is demand and blue, with the A · Supply / B · Demand legend in the toolbar — and Export JSON so you can keep an editable copy of the board. Export PNG saves the whole canvas as a branded 3200px-wide image with the Lugetech logo, which is usually the version you want to send to someone. Nothing you type leaves your device.

Questions people actually ask