Project Background

You’re the TPM for Google Nest’s Smart Home Devices team working on a next-gen battery-powered doorbell scheduled for a high-visibility launch tied to a retail partner’s fall promotion. The doorbell includes a new custom low-power SoC and a revised camera pipeline. Your team owns a critical software component: the Power & Thermal Management Module (PTMM)—firmware + OS services that control sleep/wake, camera duty cycling, thermal throttling, and battery reporting.

The PTMM must be stable before the device can pass regulatory certification (thermal safety) and meet battery life claims on packaging. The business has already committed to “6 months battery life under typical use” and “<2 seconds wake-to-live-view” in marketing drafts. Missing the launch window would forfeit a co-marketing slot estimated at $18M in incremental revenue and create channel conflict with the previous model.

Here’s the problem: the final hardware (EVT2) is delayed. The silicon vendor found an issue in the PMIC that requires a board re-spin. You will not have EVT2 boards for 6 weeks, but the firmware team is expected to hit a Feature Complete milestone in 4 weeks so the rest of the system can integrate. You do have limited access to:

• EVT1 boards (10 units) with known power measurement inaccuracies and a different thermal sensor calibration
• A cycle-accurate simulator from the silicon vendor (slow: ~1/50th real-time)
• A FPGA prototype that matches some peripherals but not final power behavior
• A lab setup that can emulate battery discharge curves, but only at the system boundary

Stakeholder Landscape

• Hardware Engineering needs PTMM integration early to validate the new PMIC behavior once EVT2 arrives, but they are also overloaded with the re-spin and can’t support extensive firmware debug.
• Firmware Engineering wants to avoid building “test-only abstractions” that could slow delivery or introduce bugs.
• QA/Systems Test is accountable for end-to-end reliability and wants measurable coverage and automation, not ad-hoc bench testing.
• Product Marketing is pushing to lock battery-life claims and performance messaging now for packaging deadlines.
• Regulatory/Compliance requires documented evidence for thermal safety and safe charging/discharging behavior; they will not accept purely theoretical results.

These priorities conflict: marketing wants certainty now, engineering wants to wait for real hardware, and QA wants repeatable evidence.

Constraints

Your Task (Deliverables)

As the TPM, outline how you would approach testing PTMM before EVT2 hardware exists, while still keeping the program on track. In your answer, produce the following:

1. A test strategy and coverage plan that explicitly separates what you can validate on simulator/FPGA/EVT1 vs what must wait for EVT2.
2. A phased execution plan (weeks 1–12) with milestones, entry/exit criteria, and how you’ll prevent late surprises when EVT2 arrives.
3. A risk register: top risks created by testing without final hardware, with mitigations and clear triggers for escalation.
4. A trade-off proposal: if you can’t fully validate battery life and thermal behavior until EVT2, what do you ship as “feature complete” in week 4, and what do you defer? Include how you’ll communicate this to marketing and compliance.
5. A launch readiness and rollback plan: how you’ll gate launch, what telemetry you’ll require, and what you’ll do if EVT2 reveals a power regression late in the schedule.

Complications

1. Simulator fidelity dispute: The silicon vendor claims the simulator is accurate for sleep/wake timing, but your systems engineer believes it underestimates interrupt latency by ~15%. The vendor won’t commit to a fix date.
2. EVT1 thermal sensor mismatch: EVT1 uses a different sensor calibration curve. QA worries any thermal throttling tests on EVT1 are misleading, but hardware says it’s “close enough” for early validation.
3. Scope pressure: Product wants to add a “smart pre-wake” feature (predictive wake based on motion) that could improve perceived latency but may hurt battery life. They want it in the launch build.

Your response should show how you drive alignment across firmware, hardware, QA, marketing, and compliance; how you structure testing to reduce uncertainty; and how you make pragmatic decisions under a fixed launch date.