First Post-Launch Status Review for Pulse Watch

Good morning, everyone. Four days after launch, it's time for our first post-launch review. Thank you all for the effort that got Pulse Watch out the door on time. Today we'll look at how the launch actually went in customers' hands, go through the top issues team by team, and decide what goes into the first monthly update in September. Eunji from Customer Experience is joining us for the first time.

Hi, everyone. Eunji Park, Customer Experience. My team runs the support channels and analyzes customer contacts. I'll share what people are calling and writing to us about.

Jason and Nari from SQE. We have the telemetry and the crash data.

Alex and Mina from Framework. We'll cover the connectivity and boot topics.

Jason, let's start with the big picture.

Overall, the launch is in decent shape. About a hundred and ten thousand watches have been activated so far. The day-one update reached eighty-two percent of activated watches within the first forty-eight hours, which is better than our target of seventy percent. Most users got it during the initial setup, exactly as we planned.

The system crash rate is 0.18 per thousand device hours, which is in line with the previous Pulse Watch at the same point after launch. We don't see any new crash signature in the top ten. So from a pure stability perspective, there's nothing alarming.

That's good to hear. What about the eSIM boot loop? That was my biggest worry going into launch.

We've had three confirmed cases in the field. All three were watches that were reset before taking the day-one update, which is exactly the scenario we predicted. In all three cases, support used the companion app recovery method, and every watch recovered in under five minutes without a service visit.

And since the day-one update includes the provisioning fix and the boot hardening, we haven't seen a single boot loop on a watch that has the update installed. The safety net is doing its job.

That's a great outcome, especially given where we were two weeks ago. Thank you, all of you. Jason, is there any difference between regions or between the LTE and Wi-Fi models that we should know about?

Mostly not. The crash rate is very similar across regions. The one difference is update adoption: in Korea and North America, it's above ninety percent, but in a few European markets, it's closer to sixty. We think that's because the setup flow there offers to skip Wi-Fi more prominently, so people complete setup using only the phone's Bluetooth connection and never download the update.

That's worth fixing in the setup flow for future models. For the current ones, the update can also download over the phone's connection, it's just slower. We could enable that path for the day-one update specifically.

Eunji, what are customers telling us?

Contact volume is about thirty percent lower than for the previous model at the same point, which is a good sign. The top five contact reasons are, in order: battery life shorter than expected, notifications arriving late from the phone, heart rate readings during workouts, a crash with one popular third-party watch face, and questions about eSIM activation. Battery is by far the largest, about forty percent of all contacts.

Forty percent is significant. What exactly are people saying about battery?

The marketing materials say up to forty hours. Many customers report getting about a day, maybe twenty-eight to thirty-two hours. Reviewers have noticed too. Two major reviews mentioned that the battery life claim felt optimistic. Most customers aren't angry yet, but they're disappointed, and that can turn into returns if it isn't addressed.

Jason, what does telemetry say about battery?

The median battery life in the field is thirty-one hours. Our forty-hour claim was measured with the always-on display turned off and a typical notification load. In the field, sixty-five percent of users have the always-on display turned on, because it's enabled by default in the setup flow. With always-on enabled, our lab measurement is about thirty-two hours, which matches the field almost exactly.

So the software isn't wasting power. The expectation was set using a configuration most people don't use.

Mostly, yes. But there's one real software issue in the data. About seven percent of watches show much worse battery life, around eighteen hours. Those watches all have a high number of wake-ups from the Bluetooth stack, more than two hundred an hour. We think it's related to how the watch handles a weak connection when the phone is in another room.

That's my area, and it's connected to the notification delay complaints too. When the Bluetooth link gets weak, the watch tries to reconnect aggressively, which drains the battery. Then, to save power, a backoff timer kicks in, and during that backoff, notifications from the phone queue up. So users see both problems from the same root cause: too many reconnect attempts, then too long a pause.

Can you fix that for the September update?

I believe so. We already have a better reconnect policy in the main branch for the next watch: fewer attempts at first, but a much shorter maximum pause, and a quick reconnect when the phone's signal gets stronger again. In our lab, it reduces Bluetooth wake-ups by about seventy percent in weak-signal conditions and cuts the worst notification delay from four minutes to under thirty seconds. I'd want two weeks of dogfood on it before shipping.

Now the harder conversation: the always-on display. Should we change the default?

From a support perspective, I'd say the problem isn't the default itself, it's that customers don't know the trade-off. Many people we talk to are happy to turn it off once they understand it costs about eight hours of battery. Others prefer to keep it on. What frustrates them is discovering this on their own.

We could add one screen to the setup flow that explains the choice: always-on display with about thirty hours of battery, or standard display with about forty. The user chooses, and the expectation is set correctly from the start. It's a small framework change.

I like the idea, but setup changes only affect new users. The hundred and ten thousand people who already set up their watches won't see it. For them, we'd need a different approach, maybe a one-time tip after a few days of use.

Both of those are product decisions as much as engineering ones, so I'll take them to the product owner today. But I'd like engineering to be ready. Mina, can you estimate both changes so I can present the cost along with the proposal?

Sure. The setup screen is about three days of work. The one-time tip is a bit more, maybe a week, because it needs some logic to decide when to show it without being annoying.

Let's go through the remaining issues quickly. The watch face crash?

It's a third-party watch face that uses an API we deprecated in this release. It crashes when the user opens the customization screen. We've contacted the developer, and they've already submitted an update to the store. Meanwhile, we can add a compatibility shim on our side, but I'd rather not, because the developer's fix should be live within a few days.

That's fine, as long as support has a clear answer in the meantime. Could you give us a short statement we can use?

Of course. I'll send you two sentences today: the issue is known, the watch face developer has released a fix, and updating the watch face from the store resolves it.

And heart rate during workouts?

We compared field data with chest strap measurements from our internal fitness testers. During steady exercise, like running, the readings are within the expected accuracy. During high-intensity interval training, the watch lags behind fast changes by up to twenty seconds. That's a limitation of the sensor algorithm, not a software bug, and the previous model behaves the same way.

Then let's not put engineering effort into it this month, but please share the comparison data with the health product team. They may want to improve it in a future algorithm update.

Let's lock the scope of the first monthly update. The release date is September 8th, with a content cutoff on August 28th. What goes in?

From SQE's side, I'd prioritize the Bluetooth reconnect policy, since it addresses two of the top five complaints at once. Plus the September security patches, which are mandatory. If the product owner approves the setup screen for always-on display, it could go in too, because it's isolated and low risk.

The reconnect policy needs two weeks of dogfood. If I merge it into the dogfood build by Thursday, we'd have about ten days before the cutoff. That's a little short of two weeks, but if the data looks clean, I think it's acceptable.

I'd like to add a targeted test as well. We can recreate the weak-signal condition in the lab by putting the phone in a shielded box with adjustable attenuation. That way, we're not relying only on dogfood users happening to leave their phones in another room.

Good. So the September update contains the reconnect policy, the security patches, and possibly the setup screen, pending the product decision. Everything else waits for October.

Before we talk about monitoring, I'd like to capture a few early lessons while they're fresh. We'll do a full retrospective later, but some of this is useful for the next watch program, which kicks off in two weeks. What went well, and what should we do differently?

What went well was the decision to split the fix between the factory build and the day-one update. It let us ship a proven, minimal factory image and still deliver the real fix on launch day. I think we should plan for a day-one update from the start next time, instead of treating it as an emergency option.

I agree. What I'd do differently is test the battery claim under realistic settings before it goes into marketing materials. SQE measured thirty-two hours with always-on display months ago, but that number never made it to the marketing team. The data existed; it just didn't reach the people who needed it.

From the support side, I'd ask to be involved earlier. If my team had known about the eSIM boot loop and the companion app recovery before launch, we could have trained agents in advance instead of writing the script on launch day. We got lucky that only three cases came in.

On the Bluetooth side, the lesson for me is that our test lab is too friendly. Every test device sits next to its paired phone with a perfect signal. Real users leave their phones in bags, in other rooms, or in cars. We should have weak-signal testing as a standard part of every watch program, not something we add after launch.

I'll make sure the shielded box setup becomes a permanent part of our watch test plan, not just a one-off for this update.

These are great. I'll write them up and share them with the next watch program's kickoff, so we start with them instead of rediscovering them in a year.

Finally, what should we keep watching between now and September 8th?

Three things. The crash rate, in case something new appears as more watches are activated. The battery distribution, especially the group with heavy Bluetooth wake-ups. And day-one update adoption. Every watch without the update is still exposed to the boot loop if it's reset.

From our side, I'll report weekly contact volume and the top reasons. If battery contacts don't go down after the September update, that tells us the expectation problem is bigger than the software problem.

For the remaining eighteen percent without the day-one update, could we send a gentle reminder through the companion app? Most of them probably skipped Wi-Fi during setup.

Good idea. That's low effort and reduces the boot loop risk further. Let's do it this week.

Let me summarize the actions. Alex: merge the reconnect policy into dogfood by Thursday, and send support the watch face statement today. Nari: set up the shielded box test for weak Bluetooth signals. Mina: estimate the setup screen and the one-time tip, and prepare the companion app reminder. Jason: weekly telemetry report covering crash rate, battery, and update adoption. Eunji: weekly contact report. And I'll take the always-on display question to the product owner today.

Thank you for including us. It's really helpful for support to understand the engineering side. When our agents can explain why something happens, customers are much more patient, even if the fix is still a few weeks away.

Please keep coming; your data was the most useful part of today. Our next review is Tuesday, August 25th, at 10 a.m. Korea time, three days before the content cutoff. Thank you, everyone.

Thanks, Sarah. See you next week. I'll also include the European update adoption numbers in the weekly report, so we can see whether Mina's download path makes a difference once it's enabled.

And I'll post the first dogfood battery numbers for the new reconnect policy next Monday, so we have something concrete before the review.