Kicking Off Pulse Watch 4 with Lessons from the Last Launch

Good afternoon, everyone. Welcome to the kickoff for Pulse Watch 4. Most of you worked on Pulse Watch 3, which launched just over two weeks ago, so the lessons are still fresh. I've asked everyone to keep the retrospective notes open, because I want this program to start with those lessons built in, not discover them again next summer.

Alex, Platform Framework. I'll lead connectivity again, and I'm very motivated to get Bluetooth right from the start this time.

Mina, also Framework. Boot, recovery, and setup flow.

Hoon Jeong, Kernel and BSP. I'm new to the watch team; I moved over from the Orion Lite kernel team last week. Dongwook is on Atlas Lite now, so I'll be the kernel lead for Pulse Watch 4.

Nari, SQE. I found the boot loop on Pulse Watch 3, so I'll be watching very closely.

Jason, SQE lead for wearables. Welcome to the team, Hoon.

Let me give the background. Pulse Watch 4 targets a retail launch on August 13th, 2027. It moves to Qorvix's new wearable chip, the W5, which is about forty percent more power-efficient than the current one. It adds a new optical health sensor and a larger battery. And it will ship on the next wearable platform version from Google.

A new chip is the biggest risk from the kernel side. When does the first W5 BSP arrive?

Qorvix has committed to October 9th for the first drop, with an evaluation board available from mid-September. Laura from Qorvix confirmed the dates in writing last Friday.

Good. If the evaluation board is available in mid-September, I'd like two of them immediately. Based on what Dongwook did on Atlas Lite, starting early on an evaluation board saves about a month later.

I'll request them today, and I'll ask Laura whether Qorvix can include a sample of their power measurements on the evaluation board, so we have a baseline before our own hardware arrives.

Let's go through the lessons one by one and turn each into a concrete decision. Lesson one: the battery claim. On Pulse Watch 3, marketing claimed forty hours, measured with the always-on display off, while most users had it on and got about thirty. Jason, how do we avoid that?

SQE should define the battery test profile together with marketing, before any number is published, and the profile must use the default settings that ship on the device. If the always-on display is on by default, the claim must be measured with it on. We'll also publish the profile internally, so everyone knows exactly what the number means.

And we should decide the default early. The setup screen we added in the September update, where users choose between always-on and standard display, worked well. For Pulse Watch 4, I'd build that choice into setup from the start.

Then the decision is: battery claims use default settings, the test profile is agreed with marketing by the end of the year, and the always-on choice is part of setup. I'll get marketing's agreement this week, before anyone writes a number in a presentation.

One more thing: a forty percent more efficient chip will tempt marketing to promise a very big number. I'd ask that the claim isn't set until we've measured it on real hardware with real software, which won't be before February.

Lesson two: our test lab was too friendly for Bluetooth. Alex?

On Pulse Watch 3, every test watch sat next to its phone with a perfect signal, so we never saw the reconnect storm that drained batteries and delayed notifications. For Pulse Watch 4, the reconnect policy we shipped in September becomes the baseline, and every nightly build runs the shielded box test with weak and fluctuating signals.

I'd extend it beyond Bluetooth. Wi-Fi with old routers, which caused problems on Orion, and LTE in areas with poor coverage. Wearables spend a lot of time in pockets and under sleeves, so weak signals are normal, not an edge case.

Agreed. I'll ask Haeun's team whether we can borrow some of the old routers they're adding to the interoperability lab. There's no point in building our own collection if theirs already reflects real customer homes.

Good. That's decision two: weak-signal testing for Bluetooth, Wi-Fi, and LTE in the nightly suite from the first booting build.

Lesson three: the boot loop. Mina, Nari?

The root cause was a provisioning service that couldn't handle a slow modem, hidden for years by a wait in the boot sequence. The engineering lesson, from Dongwook's tech share, is that we never remove an ordering constraint without understanding why it exists. For Pulse Watch 4, I'd like every service that depends on the modem to handle the modem not being ready, explicitly, with tests.

And on the testing side: the unusual boot scenarios go into the nightly suite from the first build. Factory reset with an active eSIM, boot after an update, boot with full storage, boot after a crash, and first boot in a region without network coverage. On Pulse Watch 3, we only found the loop two weeks before launch because we only tested the normal boot.

From the kernel side, I'll adopt the per-phase boot budget that Dongwook proposed for Atlas. Watches are more sensitive to boot time than phones, because users restart them more often to fix problems. And I'll document every ordering dependency between the modem and the rest of the system on day one.

Excellent. Decision three: unusual boot scenarios in the nightly suite from the first build, explicit modem readiness handling, and a per-phase boot budget.

Lesson four: the day-one update. On Pulse Watch 3, it saved the launch, but we planned it in a panic. This time, I'd like it in the schedule from the start.

I'd go further. The setup flow should always offer the update over the phone's connection if Wi-Fi is skipped. On Pulse Watch 3, update adoption in some European markets was only sixty percent because people skipped Wi-Fi. That one design choice would have protected thousands more watches.

Planning a day-one update shouldn't become an excuse to ship a weaker factory build, though. I'd like a rule: the factory build must meet all launch criteria on its own. The day-one update is for improvements and late fixes, not for things we knew were broken.

I strongly agree with that. Decision four: a day-one update is planned in the schedule, setup always offers it, and the factory build must meet launch criteria by itself.

Lesson five came from Eunji in Customer Experience. Her team learned about the boot loop recovery method on launch day. She asked to be involved much earlier this time.

I'd invite Customer Experience to the monthly status reviews from feature complete onward. They don't need every technical detail, but they should see the known issues list, so they can prepare recovery steps and answers before customers need them.

They also see patterns we don't. On Pulse Watch 3, their contact data was the first clear signal of the battery and notification problems, before our telemetry dashboards made it obvious.

Decision five, then: Customer Experience joins monthly reviews from feature complete. I'll invite Eunji today.

Beyond the lessons, there's one new risk: the optical health sensor. It's a new component from a new supplier. Hoon, what do we know?

Very little so far, which is itself a concern. The supplier has provided a datasheet and a sample driver written for an older kernel. We don't know how mature their firmware is, or how often they plan to update it. After what happened with the fingerprint sensor on Orion Fold, I want a clear agreement on how firmware changes are communicated.

And the sensor's calibration process on the production line. On Orion Fold, a silent format change in calibration data almost shipped broken units. I'd want the driver to reject unknown calibration formats loudly from day one, the same fix Ara made.

I'll add a supplier kickoff for the sensor in September, with manufacturing engineering included, so the calibration and firmware processes are agreed before the first sample units arrive.

Hoon, since you're new to the watch team, what do you need to get up to speed quickly? I'd rather invest in that now than discover gaps in November.

Three things. First, a few hours with Dongwook to understand the Pulse Watch 3 kernel and the power management tuning, because a lot of it will carry over to the W5. Second, access to the Pulse Watch 3 crash data from the field, so I know which kernel issues users actually hit. Third, the boot traces from before and after his optimization work.

The boot traces are already on the wiki, along with the tech share notes. I'd also recommend reading the boot loop postmortem summary. It explains the modem dependency much better than the code does.

And I'd suggest Hoon joins the next two Pulse Watch 3 status reviews, even though he won't own anything there. Seeing how the field issues are discussed is the fastest way to learn what matters on a watch.

That would help a lot. Watches have very different constraints from phones: a tiny battery, very aggressive sleep states, and almost no thermal headroom. I'd rather learn those lessons from someone else's data than from my own mistakes.

I'll set up the session with Dongwook this week and add you to the Pulse Watch 3 review invitations. And please don't hesitate to ask basic questions in this group. Mark said the same thing at the Atlas Lite kickoff, and those questions turned out to be some of the most useful.

Before we finalize the schedule, I'd like to agree on what each milestone actually means. On Pulse Watch 3, 'feature complete' meant that the code was merged, but several features didn't work reliably until weeks later. That compressed our stabilization time.

What would you propose?

For feature complete: every feature is merged, passes its own functional tests at ninety-five percent or more, and has no open critical issues. For code freeze: the crash rate in a seventy-two-hour stress run is below our launch target, and the battery measurement is within ten percent of the claim. If a milestone isn't met, we say so openly rather than redefining it.

I like that, especially the last part. On Pulse Watch 3, we quietly moved a few features past feature complete, and nobody outside the team knew until it was too late to adjust the schedule.

Could we also add weak-signal and unusual boot results to the code freeze criteria? If those tests are in the nightly suite from the start, they should be passing well before code freeze.

Yes, that fits naturally. I'll write the full criteria for each milestone and share them by the end of September, so everyone can see them long before they matter.

Here's the draft schedule. Evaluation boards in mid-September. First BSP drop October 9th, with development officially starting on October 12th. First boot on proto hardware November 16th. Feature complete March 26th. Code freeze May 14th. Factory build July 9th. Launch August 13th. Please challenge it.

The gap between code freeze and the factory build is eight weeks, which is good. But I'd like the battery claim measurement in the plan explicitly, in February, and a second measurement after code freeze, since software changes between them always affect power.

Five weeks from the first BSP drop to first boot on proto hardware is reasonable, if the evaluation board work goes well. If Qorvix's drop slips, everything moves, so I'd like the same escalation trigger Hyejin uses on Atlas: five working days late means a formal replan.

Feature complete in late March works for framework, as long as the new platform version from Google is available by January. If it slips, we'll need to discuss whether to launch on the current version instead.

Noted. I'll add the platform date as a dependency with a decision point at the end of January.

Let me summarize the actions. Hoon: request two W5 evaluation boards, and document modem ordering dependencies once bring-up starts. Alex: weak-signal testing plan with Haeun's routers. Mina: setup flow design with the always-on choice and update over the phone's connection. Nari: unusual boot scenarios in the nightly suite. Jason: battery test profile with marketing. And I'll get marketing's agreement this week, invite Eunji, and schedule the sensor supplier kickoff.

This is the first kickoff I've been to where the lessons from the last program were turned into decisions in the first hour. Thank you, Sarah.

Thank you all. Our next meeting is Monday, September 14th, at 2 p.m. Korea time, once the evaluation boards are in hand. I'll send out today's decisions as a short document tonight, with the five lessons at the top, so anyone who joins the program later can see why we're doing things this way.

I'll start writing the unusual boot test cases this week, so they're ready to run the day the first build boots on the evaluation board.

And I'll talk to Haeun on Monday about the routers. If we can get them by October, they'll be in place before first boot on proto hardware.