AMINE SONDALI Technical Product Leader
← Selected work

RSRV · ONGOING CASE STUDY

Defining the operating model behind a premium automotive marketplace.

RSRV connects Private Clients and Dealer Partners through vehicle listings, wanted requests, proposals, offers and timeboxed negotiations. I lead the end-to-end product definition that turns those interactions into one coherent marketplace system.

01 — THE MANDATE

Turn a marketplace concept into a product teams can reason from.

A marketplace is not simply a catalog of vehicles. It must coordinate different actors, intentions, permissions and transaction states while keeping the experience clear for every participant.

My responsibility is to define that shared product model—from the public experience to private workspaces and negotiation flows—then translate it into requirements that Design and Engineering can execute with confidence.

Product modelUser journeysBusiness rulesFunctional architecturePrioritizationDelivery alignment

02 — THE MARKETPLACE MODEL

Two transaction paths. One connected account system.

PATH 01SELL A VEHICLE

Private Client lists. Dealer Partners compete.

Vehicle listingDealer offerNegotiationDecision

The product structures how an owner receives, compares and negotiates offers within a controlled timeframe.

PATH 02FIND A VEHICLE

Private Client requests. Dealer Partners propose.

Wanted requestDealer proposalClient offerNegotiation

The product turns buyer intent into structured dealer proposals and a clear path toward agreement.

03 — THREE STRUCTURING DECISIONS

The choices that keep the marketplace understandable.

01

ONE IDENTITY, CONTEXTUAL PROFILES

Separate what the user is doing—not who the user is.

One person may operate as a Private Client, a Dealer Partner or both. A single account supports contextual workspaces without creating duplicate identities.

WHY IT MATTERS Permissions, navigation and notifications remain explicit while switching roles stays simple.
02

ONE NEGOTIATION LANGUAGE

Use consistent states across transaction paths.

Listings and wanted requests begin differently, but proposals, offers, counter-offers and decisions need a shared behavioral model.

WHY IT MATTERS Users and teams reason from consistent states instead of parallel feature logic.
03

TIME AS A PRODUCT RULE

Make urgency visible and deterministic.

Opportunities and negotiations are timeboxed. Countdown behavior, expiration and allowed actions are part of the product model—not visual decoration.

WHY IT MATTERS Every participant understands what remains possible and for how long.

04 — MY WORK TO DATE

Creating the foundation before claiming the outcome.

PRODUCT DEFINITION

Marketplace foundations

Vision, actors, value exchanges, product scope and the two core transaction paths.

FUNCTIONAL ARCHITECTURE

Rules and lifecycle

Entities, states, transitions, permissions, negotiation behavior and edge cases.

EXPERIENCE

Public and private journeys

Marketplace discovery, onboarding, profile switching, workspaces and deal management.

EXECUTION

Delivery alignment

Requirements, acceptance criteria, prioritization, validation and Product–Design–Engineering coordination.

WORKING ARTIFACTS

Product briefs · Journey definitions · Domain rules · API expectations · Acceptance criteria · Delivery priorities

05 — CURRENT STATUS

The operating model is defined. Product delivery is progressing.

NOWActive product development

Core marketplace journeys and supporting experiences are being implemented and refined with the delivery team.

FOCUSCoherence before scale

Current work focuses on completing flows, closing experience gaps and ensuring the system behaves consistently across roles and states.

NEXTValidation and learning

Commercial outcomes and behavioral metrics will only be presented after release and evidence from real product usage.

06 — WHAT THIS WORK DEMONSTRATES

Leadership before the success metrics exist.

RSRV demonstrates how I operate when the product is still being shaped: make the model explicit, resolve ambiguity, connect business intent to system behavior and keep execution aligned around one source of truth.

  • Structure a multi-sided marketplace from first principles.
  • Turn complex interactions into clear states and journeys.
  • Balance business, user and technical constraints.
  • Coordinate decisions across Product, Design and Engineering.
  • Separate delivered work from future direction.

WORK WITH ME

Building a marketplace with too many moving parts?

Let’s turn the actors, rules and transactions into one product your teams can build and your users can understand.

Start a conversation