Meridian
How Tesla Turns Five Pricing Dialects Into One Operating Language
This project is a structured product strategy exercise targeting the Sr. PM, Global Pricing Platform role at Tesla, Fremont CA (Req. 274919).
The problem framing, system architecture, stakeholder analysis, requirements framework, and measurement design draw from Tesla's public SEC filings, Q1-Q4 2025 and Q1 2026 earnings calls, Robotaxi operational reporting, FSD subscriber disclosures, and publicly available EV market share data from CFRA, ARK Invest, and industry publications. All figures cited are from these sources.
Several sections - concept scoring, preference testing structure, SCAMPER ideation, and technical build phases - are written as how I would approach this stage rather than executed deliverables. These are labeled throughout.
Phase 1 scope is vehicle-first by design - consistent with the role's primary focus on vehicle pricing. The broader five-engine architecture is the target state; the roadmap sequences engine delivery to match that priority.
The goal is to show how I think, how I structure genuine complexity across multiple business models, and how I would operate in this role from the first week.
Tesla's pricing is not chaotic.
Its pricing platform is.
From the outside, Tesla's pricing looks like a company that changes its mind frequently - Model Y prices moving 6-10 times per year, Robotaxi fares evolving from $4.20 flat to $3 + $1.40/mile within six months of launch, FSD shifting from a $15,000 one-time purchase to a $99/month subscription-only model.
That surface reading is wrong. Each decision made rational sense in context. What is broken is the infrastructure that executes, coordinates, and learns from those decisions across five simultaneously operating businesses.
| Business Line | Pricing Model | Update Cadence | Data Owner | Consumer Touchpoint |
|---|---|---|---|---|
| Vehicle | Dynamic MSRP | Ad hoc, 6-10× / year | Sales / Finance | Tesla.com, showroom |
| Robotaxi | Per-ride fare | Actively evolving | New ops team | Robotaxi app |
| FSD / Software | SaaS subscription | Capability-gated | Software team | Tesla app |
| Energy | B2B contract | Deal-by-deal | BD / Finance | Direct sales |
| Cybercab | Fixed + fleet + operator share | At launch + live | Undefined | Multiple |
These five models do not share a data schema, a simulation environment, a margin calculation methodology, or a telemetry layer. What is called the “Global Pricing Platform” is, in practice, a vehicle MSRP update tool bolted onto business models it was never designed to serve.
Five separate pipelines.
Zero shared infrastructure.
Every pricing decision travels five stages: signal detected, analysis runs, decision made, change deployed, results monitored. The failure is not at any single stage - every stage is degraded by the absence of shared infrastructure beneath it. Red cells below mark where each business line operates without platform support.
The critical failure is column three: every decision deploys without a cross-segment simulation. This is not a process problem - it is an infrastructure problem. Fixing any single stage without rebuilding the shared layer beneath produces local efficiency gains and zero portfolio-level improvement.
Six data points frame the stakes.
Gap between automotive revenue at 2023 peak ($82.4B) and 2025 actuals ($69.8B). A portion is recoverable through better platform tooling.
US EV market share lost between 2022 and Aug 2025 - from ~50%+ to 38%. Loss aversion and reference price erosion are primary behavioral drivers.
FSD subscription ARR (1.28M subscribers × $99/mo). A tier upgrade from $99 to $150/mo = ~$649M incremental ARR - or $649M at risk if timed wrong.
ARK Invest's modeled Robotaxi TAM by 2030. Fares are currently being iterated live, city by city, in spreadsheets.
Energy gross margin in 2025, approaching automotive margins. Megapack 3 + Megablock enter the lineup with no platform pricing support.
Auto gross margin recovery from 2024 trough to Q1 2026 - but Q1 2026 included one-time items the platform cannot isolate in real time.
Why do pricing decisions lack unified margin visibility?
| Why | Finding |
|---|---|
| Why is margin visibility fragmented at decision time? | Each business line owns its own pricing data and KPI stack with no shared layer. |
| Why does each business line own its own stack? | The platform was originally architected for vehicle MSRP updates only; each new business extended it independently. |
| Why wasn't the platform extended as a unified system? | Each new business (FSD, Energy, Robotaxi) was treated as a product extension, not a new pricing model class requiring platform-level design. |
| Why are new pricing model classes not platform-native? | The platform has no pricing abstraction layer - no shared schema that can express MSRP, per-ride, SaaS, B2B, and multi-sided pricing on a common data model. |
| Why does no abstraction layer exist? | Because the platform was designed to update prices, not to manage pricing as a multi-model operating system. |
Clustering the signal from earnings calls, analyst data, and consumer forums.
- Buyers delay purchase anticipating further price cuts
- US EV share: ~50%+ (2022) → 38% (Aug 2025)
- Nov 2025 deliveries: ~40K - lowest monthly since early 2022
- “Wait and see” behavior explicitly cited in Q3/Q4 2025 earnings
- r/teslamotors: “should I wait for end-of-quarter cuts?” is a recurring post
- Auto margin trough: 16.2% (2024), down from 25%+ in 2022
- Q1 2026 recovery to 21.1% includes one-time warranty/tariff items
- Energy: deployments +29%, revenue +27% - ASP declining, not tracked in real time
- Analysts on Q1 2026 call asked about margin recovery - Tesla could not answer precisely
- Five pricing models on one tool designed for one (vehicle MSRP)
- No shared pricing schema across business lines
- No simulation environment before price changes deploy
- Cybercab multi-sided pricing has no defined home in any platform
- Finance, Sales, Analytics: separate dashboards, separate sources of truth
- Sales responds to demand signals 3+ days before Finance sees the data
- No audit trail for pricing decisions; ownership unclear post-deployment
- Legal has no visibility into pricing change log for compliance review
- Robotaxi: $100B TAM requires city-by-city fare management that doesn't exist
- FSD unsupervised pricing: $649M incremental ARR at stake; no modeling environment
- Cybercab: consumer + fleet + operator = 3 pricing relationships; no revenue-share architecture
- Megapack 3 + Megablock: new product tiers need new pricing logic; no platform support
Internal users of Meridian.
| Role | Team | Primary Need | Current Friction |
|---|---|---|---|
| Pricing PM | Product | Set platform vision; coordinate across business lines | No unified platform to own; each line is its own silo |
| Finance Director | Finance | Real-time margin visibility before decisions deploy | Margin data available only post-facto; manual reconciliation takes days |
| VP Sales | Sales | Demand elasticity modeling before committing to a price change | No simulation environment; decisions made on intuition + lagging BI |
| Analytics Lead | Analytics | Experiment design, KPI ownership, causal measurement | No shared KPI layer; each business line runs its own definitions |
| Ops Lead, Robotaxi | Operations | City-by-city fare management and deployment | Spreadsheets rebuilt from scratch per city; no platform support |
| Engineering PM | Engineering | Single pricing codebase rather than 5 separate implementations | Pricing rules embedded in application code across 5 systems |
| Legal / Privacy | Compliance | Audit log for pricing decisions; regulatory compliance per market | No structured audit trail; Robotaxi regulatory constraints not platform-integrated |
Four platform users. Four broken workflows.
Maya owns pricing analysis for Model 3 and Model Y. She pulls from four separate data sources - Finance BI, Sales CRM, a third-party competitive tool, and an internal inventory tool. She cannot run a cross-segment simulation: if Tesla cuts vehicle prices, she doesn't see the FSD attach rate implication until it's too late.
James watches Megapack deployments grow 29% while revenue grows only 27% - a declining ASP signal - but cannot pinpoint which deals drive the compression. His team reconstructs margin per deal manually in Excel after the fact. He has never seen a real-time margin projection before a pricing change takes effect.
Arun manages fare pricing for Robotaxi. When Tesla moved from $4.20 flat to $3 + $1.40/mi, he ran the analysis in ride data exports and Excel. Each new city gets its own fare structure based on manual benchmarking against Uber/Lyft. There is no surge pricing logic. No demand elasticity model. No owner-operator revenue share calculator.
David bought Full Self-Driving for $12,000 in 2022. In Q1 2026, Musk confirmed that HW3 vehicles “have only 1/8th the memory bandwidth of Hardware 4” and cannot run unsupervised FSD. The platform has no mechanism to handle his segment's pricing equity - only a blanket $99/mo rate.
How a Finance Director runs a pricing decision today.
How Meridian changes it.
James (Persona 02) is the primary internal user for Vehicle and Energy pricing decisions. His current workflow takes 12 steps across 4 tools and averages 5-15 days. The workflow below is inferred from the decision archaeology implied by Tesla's public reporting and cross-segment margin disclosures.
| # | Current State | Tool | With Meridian |
|---|---|---|---|
| 1 | Sales flags a demand signal via email or Slack | Email / Slack | Signal auto-detected from live sales velocity data; routed to James in Meridian queue |
| 2 | James pulls last quarter margin data from Finance BI | Finance BI (separate login) | Current margin loaded automatically for affected business line at queue entry |
| 3 | Downloads raw data to Excel; builds scenario model manually | Excel | SimLayer runs pre-built scenario model; James inputs delta and sees projected output |
| 4 | Requests FSD attach rate data from Analytics team; waits 1-2 days | Email + Analytics BI | FSD attach rate impact shown in same SimLayer output; no external request needed |
| 5 | Reconstructs cross-segment portfolio view manually | Excel + PowerPoint | MarginLayer shows cross-segment impact in real time before decision is made |
| 6 | Prepares recommendation deck for VP review | PowerPoint | Simulation output exports directly as decision brief; deck optional |
| 7 | VP review and approval; round-trip 3-7 days in calendar | Calendar / meetings | Approval workflow built into Meridian; async with audit record |
| 8 | Price change deployed manually per-channel by Sales Ops | CRM + manual | ChannelLayer deploys simultaneously across all channels on approval |
| 9 | James checks revenue BI 2-4 weeks later for outcome | Finance BI | TelemetryLayer tracks outcome in real time; James is notified at day 7, 14, 30 |
| 10 | No rollback mechanism; any reversal requires same 5-15 day cycle | None | Rollback available with one action; full audit trail preserved |
How I would validate this before writing a single requirement.
All findings in this document are inferred from public sources - SEC filings, earnings call transcripts, analyst reports, and operational reporting. Every persona, friction point, and requirement is a directional hypothesis. In a real engagement, six methods run before any design work begins. This is how the problem gets deconstructed, not assumed.
The wrong question has a fast answer.
The right question builds a platform.
How do we update prices faster?
How do we build one platform that natively expresses five pricing model types - dynamic MSRP, per-ride fare, SaaS subscription, B2B contract, and multi-sided fixed pricing - on a shared data schema, with a unified simulation, margin, and telemetry layer, so that every pricing decision across every business line is fast, margin-informed, and reversible?
What the platform actually needs to accomplish. Not features - outcomes.
Simulate before deciding - show me projected margin impact, demand response, and cross-segment effect before I commit.
Every pricing decision is backed by a simulation run in the platform, not a lagged BI report.
See the full portfolio picture - when vehicle margins are under pressure, show me whether FSD, Energy, or Robotaxi is compensating in one view.
A shared margin intelligence layer that aggregates cross-segment impact in real time.
Price a new business model natively - when we add Robotaxi per-ride or Cybercab multi-sided, let me define it in the platform.
A pricing abstraction layer that can express any model type on a shared schema.
Deploy with confidence and a safety net - let me deploy across all channels simultaneously with a rollback mechanism.
Channel-synchronized deployment with full audit trail and rollback.
Run a real experiment - give me an A/B framework that handles segmentation, statistical significance, and guardrail metrics.
Experiment-first pricing culture supported by native tooling.
Know when pricing is hurting the consumer before they tell us - surface demand signals before they show up as a delivery miss.
Demand-side signals integrated into the telemetry layer alongside margin data.
What Meridian must do, should do, could do, and will not do.
Must Have (P0)
Should Have (P1)
Could Have (P2)
Five directions evaluated. One selected.
| Concept | Core Idea | Strengths | Weaknesses |
|---|---|---|---|
| A - Unified Schema First | Build the shared pricing data model before any new engines | Foundation for everything; unblocks all downstream work | Invisible to leadership in the short term; no immediate output |
| B - Simulation Engine Only | Build a scenario modeling tool layered on top of existing systems | High-impact, fast to show value; Finance sees it immediately | Doesn't fix underlying fragmentation; schema debt persists |
| C - Vehicle + FSD Coherence ✓ | Bring the two largest revenue streams onto shared margin visibility first, then expand | Covers $70.8B of revenue; solves the most urgent analyst questions; addresses HW3 equity issue | Leaves Robotaxi and Energy without platform support in Phase 1 |
| D - Robotaxi Fare Engine First | Build the missing fare management system for the live commercial service | Solves an active operational gap; high urgency | Doesn't address the broader coherence problem; leaves the largest revenue lines unserved |
| E - Full Rebuild | Redesign the platform from scratch across all five business lines simultaneously | Solves the root cause completely | 18-24 month horizon before any value delivered; too slow |
Post-ideation scoring against nine weighted criteria.
| Concept | C1 | C2 | C3 | C4 | C5 | C6 | C7 | C8 | C9 | Total |
|---|---|---|---|---|---|---|---|---|---|---|
| A - Schema First | +1 | +2 | +1 | +1 | +1 | −1 | +2 | +2 | 0 | 9 |
| B - Simulation Only | +2 | +1 | 0 | +1 | +1 | +2 | +1 | +1 | +1 | 10 |
| C - V+FSD Coherence ✓ | +2 | +2 | 0 | +2 | +1 | +1 | +2 | +2 | +2 | 14 ✓ |
| D - Robotaxi First | +1 | 0 | +2 | 0 | +1 | +2 | +1 | +1 | +1 | 9 |
| E - Full Rebuild | +2 | +2 | +2 | +2 | −2 | −2 | +1 | +2 | 0 | 7 |
Concept C advances as the MVP foundation. It scores highest on the criteria most urgent to Tesla's 2026 business situation. Concept A (Unified Schema) is incorporated as the architectural prerequisite inside Phase 1 of Concept C. Concept D (Robotaxi) advances to Phase 2.
Where each capability sits. Why Phase 1 starts with schema + audit.
Phase 1 build sequence: FR1 (schema) → FR5/FR6 (audit + rollback, low effort high impact) → FR2/FR3 (simulation + margin) → FR9 (FSD tier logic) → FR4 (channel layer) → FR11 (analytics dashboard). Dependency order, not complexity, determines the sequence. Schema gates everything - without FR1, no engine can be built on shared infrastructure.
Five engines. One platform. Built in sequence.
Meridian is a modular pricing operating system for Tesla's five-business reality. It separates pricing model expression (what each engine does) from pricing infrastructure (what all engines share) - so Tesla can add new pricing models without rebuilding from scratch.
Dynamic MSRP · Demand elasticity
SaaS + HW tier logic · FSD
Per-ride fare · Surge · Ops
B2B contract · ASP mgmt
Cybercab multi-sided pricing
Meridian is built across six teams. The PM is the connective tissue.
A pricing platform at this scale cannot be owned by any single team. The PM role here is not feature management - it is cross-functional system integration. Each team has a specific interface with Meridian, a specific thing they need from it, and a specific thing they need to contribute to it. The PM defines and maintains those contracts.
- →Technical spike: can Vehicle + FSD pricing data be exposed to the unified schema without a full rewrite?
- →FSD hardware attestation API - does per-vehicle HW state exist at the platform layer?
- →Schema ratification: each business line must agree to a shared data contract.
- →Pricing logic extracted from 5 codebases into the engine layer - PM owns the migration spec.
- →Validate MIPC as the north star metric - Finance must accept it as meaningful or it won't drive behavior.
- →Embed cost floors as live guardrails: margin below X% triggers CFO-level approval gate automatically.
- →COGS data feed integration: Procurement's cell cost updates flow into SimLayer on a monthly refresh cycle.
- →Tariff scenario modeling (FR8): Finance enters tariff rates; platform calculates cross-segment margin impact.
- →SimLayer design spec: "Show me what happens to delivery volume if we cut Model Y by $2K."
- →Cross-segment view: vehicle price cut → FSD attach rate delta → combined portfolio margin - Sales currently cannot see this.
- →Decision cycle compression: 5-15 days → 2-3 days through shared data and pre-built simulation.
- →Audit trail: every Sales pricing recommendation is logged with what data was used to support it.
- →AuditLayer spec: every pricing decision logged with decision owner, timestamp, data used, simulation run, and channels deployed.
- →Rollback SLA: any deployed price change reverted within 24 hours - this is a contractual commitment built into the platform.
- →Regulatory compliance per Robotaxi market: city-by-city fare constraints integrated into MobilityEngine design.
- →HW3 tier change: Legal review required before any FSD tier pricing logic goes live - consumer protection review.
- →Consumer communication plan for HW3 tier logic: Marketing and Legal must be involved from Sprint 1, not after the feature is built.
- →Demand sentiment signal: consumer forum analysis (r/teslamotors "wait and see" posts) feeds into TelemetryLayer.
- →Brand equity guardrail: pricing changes that score high on wait-and-see sentiment require a MarketingLayer review gate.
- →Cross-sell trigger (FR15): vehicle purchase → Powerwall or FSD promotion surfaced in-platform, coordinated with Marketing campaigns.
- →MobilityEngine spec: city-by-city fare configuration with surge logic parameters and demand-weighted optimization.
- →Current state audit: what does Arun actually do in a spreadsheet today? Shadow one full city launch cycle before designing the tool.
- →Robotaxi ride data structured format: Engineering must expose this before MobilityEngine can ingest it - Phase 2 dependency.
- →Owner-operator revenue share calculator: Cybercab multi-sided engine (FR12) designed with Ops as primary user, Phase 3.
The simulation logic that works for vehicles fails completely for FSD.
This is the architectural decision.
The most common assumption about pricing platforms is that they start with cost: COGS sets a floor, the platform finds the optimal price above it. That assumption is correct for two of Tesla's five businesses, partially correct for one, and irrelevant for the remaining two. This is not an edge case - it is why Meridian requires five distinct engines rather than one universal simulation model.
Building one simulation engine that asks “what is the optimal price given cost?” would serve Vehicle and Energy adequately - and fail completely for FSD and Robotaxi. The modular engine architecture is not a preference. It is the only design that correctly serves all five pricing model types simultaneously.
What a unified pricing record looks like - and what a pre-deployment simulation outputs.
The unified schema is the architectural foundation of Meridian. Every pricing engine writes to it. Every simulation reads from it. Every audit log is anchored to it. The three records below are illustrative - the actual schema would be designed through the Phase 1 technical spike and ratified with Engineering leads from Vehicle and FSD before any build begins.
The schema ratification process - getting Engineering leads from Vehicle, FSD, Finance, and Analytics to agree on a shared data contract they do not currently have - is the most politically complex step in Phase 1. It is also the one that must complete in Sprint 1, before any engine can be built. This is Action 6 in the next steps plan.
What the simulation actually outputs.
Model Y MSRP cut of $2,000.
The scenario below illustrates how SimLayer would process a Vehicle pricing change before deployment. Inputs are based on Tesla's Q1 2026 public data: ~127,000 vehicle deliveries, ~22% FSD attach rate among new buyers, $45,990 average Model Y MSRP, and a stated price elasticity of approximately -0.8 for the US EV segment per ARK Invest modelling.
| SimLayer Input - Scenario A3: Model Y LR MSRP -$2,000 | |
|---|---|
| Business line | Vehicle |
| SKU | Model Y Long Range AWD |
| Change type | MSRP reduction |
| Price delta | -$2,000 (from $45,990 to $43,990) |
| Price change % | -4.35% |
| Baseline quarterly units (US) | 42,300 (Q1 2026 proportional) |
| Demand elasticity applied | -0.80 (ARK Invest US EV segment estimate) |
| FSD attach rate baseline | 22.0% of new Vehicle buyers |
| Simulation horizon | 90 days |
| SimLayer Output - Projected 90-Day Impact | ||
|---|---|---|
| Metric | Projected | Confidence |
| Demand lift (units, 90 days) | +1,477 units (+3.5%) | Medium - elasticity estimate |
| Revenue per unit delta | -$2,000 | High - direct |
| Gross revenue delta (90 days) | -$82.8M (volume gain partially offsets) | Medium |
| Gross margin delta (90 days) | -$23.1M (at ~$15,600 gross margin / unit) | Medium |
| FSD attach rate (new buyers) | 20.8% (-1.2pp) - price-sensitive cohort enters | Low - limited prior data |
| FSD ARR impact (12-month tail) | -$185K ARR (-142 net subscribers) | Low |
| Combined portfolio margin delta | -$23.3M over 90 days | Medium |
| Decision cycle (with Meridian) | 2.3 hours (vs 5-15 day baseline) | High - platform baseline |
SimLayer recommendation: Deploy with a targeted FSD incentive for the buyer cohort entering at the lower price point - a 3-month free trial converts at approximately 18-22% to paid subscription, partially recovering the attach rate drop. Deploy recommendation requires Finance Director approval and Legal sign-off on incentive terms before ChannelLayer publishes. Rollback window: 24 hours post-deployment.
This is the output Finance and Sales would see before a decision deploys - not two weeks after. The confidence intervals are explicit, not hidden. The FSD attach rate impact is visible at the same moment as the vehicle margin impact. This is what “cross-segment portfolio intelligence” means in practice.
$70.8B of Tesla's 2025 revenue. One shared margin layer.
Vehicle and FSD together represent $70.8B of Tesla's 2025 revenue ($69.5B auto + $1.3B FSD ARR). They share a customer, a margin pressure, and an immediate platform gap. Solving coherence between these two first demonstrates platform value to leadership and establishes the shared schema all subsequent engines build on.
| Component | Scope | What It Enables |
|---|---|---|
| Unified Pricing Schema v1 | Shared data model covering Vehicle MSRP and FSD subscription model types | Foundational; all Phase 1 features depend on this |
| SimLayer v1 | Scenario modeling for vehicle price changes with FSD attach rate and cross-segment margin output | Finance can simulate a $2K Model Y cut and see the portfolio margin impact including FSD uptick |
| MarginLayer v1 | Real-time combined margin view: vehicle + FSD | First time Finance sees combined margin without manual reconciliation |
| FSD Tier Logic (FR9) | Hardware attestation integration linking HW3/HW4 state to subscription tier pricing | Solves HW3 equity problem; enables unsupervised FSD pricing tier when ready |
| AuditLayer + Rollback v1 | Full audit log; 1-click revert for any vehicle or FSD pricing change within 24 hours | First-ever safe deployment mechanism; regulatory compliance |
| Analytics Dashboard v1 | Shared KPI definitions for vehicle + FSD: margin, conversion, subscriber growth, churn | First shared language between Finance and Analytics across two business lines |
Margin-Informed Pricing Coverage (MIPC)
The percentage of pricing decisions made with a SimLayer simulation showing cross-segment margin impact, run before deployment. Today: ~0%. Phase 1 target: 60%. Phase 3 target: 90%+.
| Metric | Current Baseline | Phase 1 Target (Q3-Q4 2026) | Phase 3 Target (Q3-Q4 2027) |
|---|---|---|---|
| MIPC | ~0% | 60% (Vehicle + FSD) | 90%+ (all 5 lines) |
| Pricing decision cycle time | 5-15 days | 2-3 days (vehicle + FSD) | <24 hours (all segments) |
| Cross-segment margin reconciliation lag | ~2 weeks post-facto | Real-time (Vehicle + FSD) | Real-time (all segments) |
| FSD tier pricing accuracy | Not measured | 100% - no HW3 subscriber on HW4 rate | 100% maintained |
Start narrow. Prove. Expand.
| Stream | Q3 2026 | Q4 2026 | Q1 2027 | Q2 2027 | Q3 2027 | Q4 2027 |
|---|---|---|---|---|---|---|
| Phase 1 · Vehicle + FSD | Unified schema · SimLayer v1 · MarginLayer v1 · Audit + Rollback | FSD tier logic · Analytics Dashboard v1 | - | - | - | - |
| Phase 2 · Robotaxi + Sim | - | - | SimLayer v2 · A/B framework · Tariff modeling | MobilityEngine v1 · Robotaxi fares in-platform | - | - |
| Phase 3 · Energy + Cybercab | - | - | - | - | EnergyEngine · Megapack 3 ASP | FleetEngine v1 · Cybercab multi-sided · Sentiment |
Six assumptions are Critical. Any one wrong changes the direction materially.
| ID | Assumption | Urgency | How to Validate |
|---|---|---|---|
| A-01 | Platform was originally built for vehicle MSRP only and extended to other lines rather than rebuilt | CRITICAL | Internal stakeholder interview: ask Engineering to describe current pricing architecture across all 5 lines |
| A-04 | Vehicle pricing decision cycle is 5-15 days; Robotaxi and FSD have no formal defined pricing process | CRITICAL | Cross-functional process shadowing - measure actual cycle time end-to-end in 2 business lines |
| A-05 | Root cause is structural (missing abstraction layer) not organizational (siloed incentives) | CRITICAL | Internal stakeholder interviews before any design work; if a schema exists but isn't used, the solution changes entirely |
| A-10 | FSD ARR of $1.3B calculated at $99/mo; actual blended ARR is lower due to EAP owners at $49/mo | MEDIUM | Tesla internal subscriber cohort data; EAP vs. standard subscriber mix |
| A-12 | MIPC baseline ~0%; Phase 1 target 60%; decision cycle time baseline 5-15 days | CRITICAL | Internal metrics audit before Phase 1 launches; define and agree MIPC measurement methodology with Finance and Analytics |
| A-13 | Phase 1 Q3-Q4 2026 timeline assumes engineering capacity allocated, schema ratification completing in Sprint 1 | HIGH | Technical spike (Sprint 1) results; engineering capacity assessment; leadership prioritization workshop |
What could go wrong, what is assumed, what is open, and what is blocked.
If this were a real Tesla project: the first eight actions.
1. Audit current pricing decision workflows across all five business lines. Document the full cycle from signal to deployment: tools, time elapsed, data quality. This is the baseline Meridian will be measured against.
2. Map existing data sources for Vehicle and FSD pricing to the proposed unified schema. Identify where data is available, where it requires engineering work, and where it simply doesn't exist yet.
3. Interview Finance and Sales leads in Vehicle and FSD to validate the simulation use case. What scenarios do they wish they could run before a pricing decision?
4. Technical spike on FSD hardware attestation data. Before designing HW3/HW4 tier logic, validate that per-vehicle hardware state is accessible from the platform layer. This dependency gates the most customer-sensitive part of Phase 1.
5. Validate MIPC as the north star metric with Finance and Analytics leadership. The metric only works if the people evaluated against it accept it as meaningful.
6. Draft the unified pricing schema with Engineering leads from Vehicle and FSD. Schema ratification is the most politically complex step - each business line must agree to a shared data contract they don't currently have.
7. Design the consumer communication plan for HW3 tier logic in parallel with the technical design. This is customer-facing and requires Legal and Marketing from the start, not after the feature is built.
8. Identify and escalate the organizational gap. Meridian needs a cross-segment pricing strategist above the platform layer. If that role doesn't exist, recommend it to leadership before Phase 1 launches.
Make decisions with complete margin context, in hours rather than days, with a simulation that answers “what happens if” before “what happened.”
Experience pricing that moves less, signals more, and erodes brand trust less - because decisions are modeled before they deploy, not reactive after the fact.
Stops leaving margin on the table from decisions made blind and starts compounding the precision that comes from a shared source of truth across five business lines operating simultaneously.
The standard: Every pricing decision at Tesla runs through Meridian. Not because it is required. Because it is better.