Your Car Is Sending You 4,000 Signals a Second: Turning Telemetry Into Product Decisions

A modern car generates thousands of CAN-bus and sensor readings per second, but almost none are worth a feature. The PM's job is running every stream through a filter — does it serve a customer job, a safety insight, or a monetizable service — and killing whatever doesn't, since bandwidth, storage, and consent all cost real money.

Quick Answer: Don't instrument for coverage; instrument for a decision. Map each telemetry stream to a customer job (JTBD), a safety insight, or a monetizable service, and discard the rest before it ever hits your data warehouse or your privacy policy.

The Firehose Problem: Why "Collect Everything" Fails PMs

A single ECU-equipped vehicle can post several thousand CAN-bus messages per second across dozens of interconnected modules, and that's before ADAS camera, radar, and lidar streams enter the picture. The instinct to capture all of it feels safe. It is actually the riskiest default a data PM can choose.

The CAN bus itself is old, cheap, and everywhere. Bosch introduced the Controller Area Network protocol in 1986 to let a car's modules — engine control, transmission, brakes, body electronics — talk over a shared two-wire bus instead of a tangle of point-to-point wiring. SAE International later standardized variants of it, including J1939 for commercial trucks and buses, which is why fleet telematics vendors can plug a single dongle into wildly different truck makes and read the same signal classes.

That standardization is exactly why the firehose grew so large. Every module vendor added its own diagnostic trouble codes (DTCs), sensor channels, and proprietary parameter IDs, and OEMs kept most of them undocumented outside internal engineering. A platform PM inheriting this stack faces three temptations, and all three are traps:

1. "Store everything, decide later." Cold storage is cheap per gigabyte, but the real cost is engineering time spent maintaining schemas nobody queries and compliance risk on data nobody can justify retaining.
2. "Build a dashboard so stakeholders can explore." A dashboard is not a decision. It's a deferral of the decision to whoever's looking at the chart, and it multiplies infrastructure cost across every team that gets read access.
3. "Wait for engineering to tell us what's available." This inverts the product process — the schema should follow the decision you're trying to enable, not the other way around.

The fix isn't a bigger data lake. It's a smaller, sharper list of signals with a stated reason to exist, which is what a proper signal-to-value framework forces you to produce. For the wider context of how this fits into the vehicle's software and hardware lifecycle, see the automotive and mobility product management guide.

The Signal-to-Value Framework: Three Filters, One List Per Signal

Every telemetry stream should pass through exactly one of three filters before it earns a place in your schema: it serves a customer job, it produces a safety insight, or it powers a monetizable service. Anything that clears none of the three gets killed, not archived — archiving it just relocates the liability.

Filter one: does it serve a customer job?

Borrow directly from Jobs to Be Done. A driver isn't buying "telemetry" — they're hiring the vehicle (and its companion app) to do something: avoid an unplanned breakdown, prove they're a safe driver, minimize fuel spend, or keep a teenage driver within agreed limits.

Ulwick's outcome-driven framing is useful here because it forces you to state the job as an outcome statement — "minimize time spent diagnosing why the car won't start" — rather than a feature name. If you can't name the job a signal serves, in one sentence, it's not ready to leave the ECU. The Jobs to Be Done complete guide walks through opportunity scoring if you need to rank competing jobs.

Filter two: does it produce a safety insight?

Some signals earn their keep purely on risk reduction, independent of any monetizable feature. Wheel-speed differentials that flag imminent loss of traction, or battery-voltage sag that precedes an unexpected stall, fall here.

NHTSA's event-data-recorder rule (49 CFR Part 563) already requires a defined set of pre-crash signals — delta-V, belt status, throttle position — on any vehicle that has an EDR at all, which is a useful reference list for what regulators consider safety-relevant by default. Treat any signal in that category as a strong "keep" candidate even before a product case exists.

Filter three: does it power a monetizable service?

McKinsey's automotive practice has, in widely cited estimates, put the addressable global market for car-data-enabled services at several hundred billion dollars by the end of the decade — directionally large regardless of the exact figure, and a useful reminder that a handful of signal categories (location, driving behavior, vehicle health) account for nearly all of the realistic monetization paths. Most raw signals don't touch any of them.

Run every candidate signal through this table before it gets a schema field.

The pattern in that table is the real lesson: location and behavior signals carry the most product value and the most privacy exposure at the same time. That correlation is not a coincidence, and it's the subject of the governance section below.

Predictive Maintenance: The Cleanest Signal-to-Value Path

Predictive maintenance is the easiest category to justify because the customer job is universal — nobody wants to be stranded, and almost every driver will pay something to avoid it. The pattern is consistent: combine a handful of slow-moving trend signals with the vehicle's existing DTC library, and you get an early-warning feature without inventing new hardware.

A workable predictive-maintenance stack usually needs only a small signal set:

• Battery state-of-health trends (voltage under cranking load, charge acceptance rate over weeks) to flag a failing 12V battery before a no-start event.
• Brake-pad wear estimates, derived from brake-application force and frequency rather than a dedicated wear sensor on every trim.
• Oil-life and coolant-degradation models, already computed on many ECUs and simply under-surfaced to the owner or fleet manager.
• DTC frequency and clustering, since a code that fires intermittently for weeks before triggering the check-engine light is a better lead indicator than the light itself.

None of this requires the raw firehose. It requires four or five well-chosen trend lines, refreshed periodically rather than streamed continuously, which is itself a bandwidth decision worth making explicitly.

When a predictive-maintenance model does trigger an action — a scheduled service reminder, a firmware patch to a battery-management routine — that action often ships as an over-the-air update, and the UX of pushing changes to a vehicle that might be in motion deserves its own care; see how OTA updates work for moving vehicles.

A false "you're about to break down" alert has a real physical and financial consequence for the driver. The interface design for these alerts belongs in the same category as other safety-critical UX with physical consequences, not treated as an ordinary notification.

Driving Scores: Behavior Signals Without Building a Surveillance Product

A driving score turns raw acceleration, braking, cornering, and speed-relative-to-limit signals into a single number a driver or insurer can act on — and it's simultaneously one of the highest-value and highest-risk product categories in this whole space, because the same signals that make a great score also make a detailed behavioral profile of a specific human.

Usage-based insurance programs from major carriers have offered discounts in a directional range of roughly 10-40% depending on measured driving behavior, according to figures insurers themselves have published for programs like Progressive's Snapshot and State Farm's Drive Safe & Save. That range is a reasonable planning anchor, not a guarantee — actual discount curves vary by state, carrier, and underwriting model.

The product-design tension is real: harsh-braking and speeding events are also exactly the moments a driver-assistance system might be intervening (automatic emergency braking, lane-keep correction), so a score built naively can penalize a driver for the car's own safety system doing its job. Understanding how automated driving features hand control back to the human — and where responsibility sits during that handoff — matters when you're deciding whether to count an ADAS-triggered event against a driving score; the driver-assist AI and human handoff piece covers the ambiguity there.

Compare the major telemetry-driven product categories side by side before deciding which one your roadmap should prioritize:

Each row implies a different consent conversation and a different retention policy — which is worth mapping against the moments a driver actually notices the product, using something like a customer journey emotion curve to spot where a score drop or a premium change lands as a surprise rather than an expected consequence of a known trade.

The Data-Governance and Consent Trap

The signals with the most product value — precise location and individual driving behavior — are also the signals with the highest legal and reputational cost if handled carelessly, and that overlap is the trap platform PMs walk into by defaulting to "collect everything, ask legal later."

Location data re-identifies people faster than most PMs assume. A frequently cited mobility-privacy study (de Montjoye et al., published in Nature Scientific Reports, 2013) found that just four spatiotemporal points — four rough location-and-time pairs — were enough to uniquely identify roughly 95% of individuals in a large mobility dataset. A continuous GPS trace is not an anonymous data point; it is closer to a fingerprint, and it should be governed as one.

Three regulatory regimes shape what "governed properly" means in practice, and none of them are optional once you have identifiable EU or California drivers in your dataset:

1. GDPR requires a documented lawful basis (Article 6) for each processing purpose — consent is only one of six options, and "we might need it later" is not one of the six.
2. CCPA/CPRA in California gives consumers rights to know, delete, and opt out of the sale or sharing of personal information, which explicitly includes precise geolocation.
3. NHTSA's EDR rule governs a narrower, safety-specific slice — the pre-crash black-box data — with its own retention and disclosure expectations that are separate from marketing or product-analytics consent.

The governance mistake isn't collecting sensitive signals. It's collecting them without first deciding — and documenting — the specific job, insight, or service each one is for.

Practical guardrails that keep a telemetry program inside those lines:

• Aggregate before you store, where the job allows it. A driving score needs event summaries, not a second-by-second GPS trail retained indefinitely.
• Set a retention window per signal category, not one blanket policy. Safety-relevant EDR data, behavior-score inputs, and diagnostic trend lines plausibly warrant different lifespans.
• Separate consent by purpose, so a driver who opts into predictive-maintenance alerts isn't silently opted into a driving score shared with an insurer.
• Kill signals you can't defend a retention reason for, using the exact same three-filter test from earlier in this piece — governance risk is just the fourth reason a signal fails the framework.

From Signal Map to Shipped Schema

Deciding which signals survive the framework is only half the job — the other half is making that decision concrete enough for engineering to build against, before the first pipeline gets written. A signal-to-value map that lives in a slide deck tends to drift the moment an engineer starts naming database columns.

This is the part of the workflow Prodinja's Data Modelling tool is built for: you describe the telemetry entities your framework kept — a VehicleSignal, a MaintenanceEvent, a DrivingScoreSnapshot — and it turns them into real SQL DDL, with the relationships and fields your kept signals actually need.

That's a prototype experience aimed at closing the gap between "we decided this signal matters" and "the database agrees with us," so the schema reflects your keep/kill decisions instead of whatever the ECU happens to expose — not a promise that it replaces your data architect's judgment on indexing or partitioning at scale.

Key Takeaways

• Instrument for a decision, not for coverage. A telemetry stream earns a schema field only if it serves a customer job, a safety insight, or a monetizable service.
• Location and behavior signals carry the most value and the most risk simultaneously — that correlation is structural, not incidental, so treat it as a standing design constraint.
• Predictive maintenance is the easiest signal-to-value case because the customer job (avoid a breakdown) is nearly universal and needs only a handful of trend signals, not a raw stream.
• Driving scores need to account for ADAS-triggered events, or you risk penalizing drivers for the vehicle's own safety systems intervening on their behalf.
• A four-point location trace can re-identify most individuals, per published mobility-privacy research — treat continuous GPS data with the same rigor as biometric data.
• Separate consent and retention by purpose, not by a single blanket policy, so one opt-in doesn't silently authorize an unrelated use.
• Turn the keep list into a real schema early — a signal-to-value decision that never becomes a concrete data model tends to get reinterpreted by whoever builds the pipeline.