Over the years, I've learned that while the surface details change — riders and drivers, couriers and eaters, hosts and guests, shoppers and customers — the core job of a marketplace PM is the same: designing and steering the systems that connect multiple sides of a market. To do that, you need more than personas and backlogs; you need a way to see the system you're responsible for.
The mental model that's helped me the most is simple enough to sketch on a whiteboard, but deep enough to use for real decisions. I call it the S‑I‑N framework:
S‑I‑N = Sides → Incentives → Network Effects.
Most marketplace PMs already use frameworks like RICE or Impact/Effort. Those tools are good at ranking ideas in isolation — what's big, what's fast, what's cheap. The problem is that marketplaces don't live in isolation. They're systems of interacting sides and feedback loops. A feature that scores beautifully on RICE can still quietly damage the marketplace if it misaligns incentives or weakens a critical loop.
The point of S‑I‑N isn't to be "yet another framework." It's the system‑level lens that catches what RICE and Impact/Effort miss: whether your "top" ideas actually make the network healthier instead of slowly breaking it.
When I first moved into a marketplace‑style role at a grocer, I ran into this gap head‑on. I was responsible for the tools that connect online customers placing orders with in‑store shoppers doing the actual grocery picking. On paper, it looked like a straightforward optimization problem: make shoppers more productive, and the whole system wins.
One of my earliest roadmap ideas was a "high‑impact, low‑effort" feature. The picking app already allowed batching — grouping multiple customer orders into a single pick run — but it was conservative. I wanted to increase batching so shoppers could walk the store once and fill two or three orders at the same time.
By RICE, it was promising:
- Reach: almost every store and shopper would benefit.
- Impact: big gains in units picked per hour and labor cost per order.
- Confidence: strong.
- Effort: medium; mostly changes in batch logic and UI.
On the spreadsheet, it looked like a clear win. In reviews, though, leadership pushed back, calling it half‑baked — it pushed hard on efficiency but never really grappled with what might happen to customer outcomes if something went wrong. At the time, I didn't have great language for that discomfort; through a pure impact lens, the idea still seemed obviously good. It was only when I started thinking in terms of Sides, Incentives, and Network Effects that I understood what they were reacting to.
Build your S‑I‑N map
Before you obsess over features, roadmaps, or intake queues, there's one foundational task every marketplace PM should do:
Build a living S‑I‑N map of your marketplace — and keep it current.
Think of it as your internal "marketplace constitution." Everything else (tickets, designs, policies) should be downstream from this.
S — sides: Who are you really connecting?
Most PMs can list their "users." That's not the same as understanding your sides.
Think of a familiar marketplace like Uber: it connects riders who need trips with drivers who can provide them, plus payment providers and cities that shape how the system operates. Most marketplaces follow a similar pattern: distinct demand, supply, and enabling sides, with segments within each side that have different needs.
For your marketplace, ask:
- What distinct groups does this platform connect?
- Which are demand, which are supply, and which are enablers (payments, regulators, partners, internal ops)?
- Where are we pretending "it's one side" when there are actually multiple segments with conflicting needs?
Write them down. Draw them. Name them. Once you've done that, you can stop designing in the abstract and start designing for the actual network you're responsible for.
I — Incentives: What does winning look like for each side?
Sides tell you who is in the market. Incentives tell you why they play.
For each side, ask:
- What does "success" look like for them here?
- What do they gain — money, flexibility, convenience, status, reliability, control?
- What do they want to avoid — wasted time, uncertainty, risk, low‑quality matches?
In a ridesharing marketplace, riders care about price, wait time, safety, and reliability, while drivers care about earnings per hour, predictable demand, and control over when and where they work. In other marketplaces — say, home‑sharing — the labels change, but the pattern is the same: each side optimizes for its own mix of value, risk, and control.
Now ask: how do your product, pricing, policies, and UX push on those incentives?
- Surge pricing changes driver incentives to come online in peak times, but also changes rider incentives to defer or cancel trips.
- Strict cancellation policies change guest and host behavior in different ways.
If you don't understand incentives, you're just moving pixels. The same feature can either stabilize or destabilize your marketplace depending on what it teaches people to optimize for.
N — network effects: How does more of one side change the experience for others?
Once you see sides and incentives, you can look for network effects — the feedback loops that make marketplaces powerful (or fragile).
A classic positive loop: more drivers → shorter ETAs → happier riders → more trips → more earnings → more drivers.
A classic negative loop: too many low‑quality participants on one side → worse experiences on the other side → less demand → the best participants churn first.
Your job is to be able to complete sentences like:
- "If we make it easier for X, we expect behavior Y, which will likely increase/decrease metric Z on side A and side B."
- "If we add this policy, what feedback loop might we be strengthening or breaking?"
This is where marketplace PM shifts from "shipping features" to engineering system behavior.
So, how did I refine batching with S-I-N?
Let's go back to that "perfect" batching feature. RICE said "ship it," leadership said "slow down." S‑I‑N is what finally decoded the disagreement.
When I looked at the idea through S‑I‑N, the gap was obvious. On the Sides dimension, the proposal was great for shoppers (more productive time, better earnings) and stores (lower labor cost per order), but it treated customers — the people who care about on‑time, accurate orders — as if they were unaffected. On Incentives, aggressive batching taught shoppers to optimize for efficiency at all costs, subtly rewarding risky behaviors like juggling more carts and rushing substitutions, while giving customers no control yet asking them to absorb the downside when things went wrong. And on Network Effects, the short‑term loop looked fantastic (higher batching → higher productivity → lower costs), but the medium‑ and long‑term loops were fragile: more late orders and mixed bags would mean more complaints and credits, lower repeat rates, and eventually less demand per store and fewer hours for shoppers — a weaker marketplace dressed up as a win.
Through a RICE lens, the feature was still a clear win. Through S‑I‑N, it was clearly under‑designed for the system it lived in. The idea — "let shoppers batch more" — wasn't wrong; what was missing was everything that protected the other sides of the marketplace.
S‑I‑N didn't tell us to abandon batching. It showed us what had to ship with it: guardrails so orders close to their due time couldn't be thrown into big batches that would push them late, simple in‑app checks when a shopper handled multiple orders at once, and tighter feedback loops and dashboards for customer issues back to operations so we could see when efficiency gains were starting to erode experience. The roadmap shifted from "ship bigger batches" to "ship smarter batching plus protections and visibility." The RICE score didn't change much — the work was still high‑impact — but S‑I‑N changed the shape of the feature and the sequencing of what had to launch alongside it.
Bringing it all together
Draw your S‑I‑N map for your current marketplace: sides, their incentives, key positive and negative loops. Revisit it at least once a quarter as markets, policies, and behaviors evolve. Run big decisions and roadmap themes through it by default.
Most marketplace PMs are optimizing features. The best ones are optimizing systems. Having a mental map like S‑I‑N — and using it consistently — will put you ahead of the many platform product managers who are still reacting to the loudest request in the room.
Your tools for choosing what to do next are probably already good enough. S‑I‑N makes sure that, whatever you choose, you're still building a healthier marketplace rather than accidentally eroding it over time. You become the person who doesn't just manage the backlog. You become the person who understands — and deliberately shapes — how the market actually works.
