Following profile-completion and wear-time Nudges.
SATELLAI · connected pet technology
From connected hardware to a pet-centric product system.
I co-defined the model connecting pets, devices, and long-term data; owned the AI-health experience from prioritization and readiness through prompt, customer-facing insight, and evaluation; and improved the existing product using real return feedback.
PeopleReplaceable devicesPersistent Petidentity + historyHealth intelligenceLocation states
Compared with an Aug–Jan average of ~40%; observed after release, not claimed as sole causation.
Context
A pet product is not one device and one app.
The companion app connected a persistent pet identity with replaceable hardware, incomplete sensor data, imperfect connectivity, and the people responsible for care. A decision in one layer changed the rules in the others.
- Collaborated with
- CEO · CTO · Engineering
- Scope
- Product model · AI health · Connected hardware · Existing-product UX · Analytics tooling
01
Product model · Shipped
A collar can be replaced. A pet cannot.
Replacement was not only a pairing problem. When hardware stands in for identity, changing it can also disrupt history and make future device relationships harder to reason about.
Figure 01
Reconstructed from shipped relationshipThe product model separates what persists from what changes.
- Health history
- Activity history
- Insights
Assignable relationship↔replace · reassign
- Tracker
- Collar
- Future hardware types
Figure 02
Shipped-screen selection pendingModel → product behavior
The experience starts from a pet identity that can outlive any one device.
A compatible device connects through an explicit relationship.
Replacement or reassignment updates hardware without recreating the pet.
Health and activity history remain attached to the persistent entity.
02
AI health · Mixed shipped status
When should AI speak—and when should the product ask for more data?
The work began before the prompt: deciding which signals deserved proactive attention, whether the system had enough individual context, and how a useful insight should be generated, presented, and evaluated.
Figure 03
Real framework · visualization reconstructedWhat is worth monitoring?
Does the issue affect enough pets to justify proactive attention?
Is it difficult for owners to notice consistently on their own?
Can the signal lead to a meaningful next step?
Applied to early signalsResting respiratory rateActivityRest
Figure 04
Confirmed logic · detailed evidence pendingReadiness routes the experience before AI generates an insight.
Pet profile+Sensor history+Individual baseline↓Readiness check
Ask for the specific context the product still needs.
Help the pet accumulate enough consistent data for a baseline.
Respect the owner’s decision rather than continuing to push.
Context + prompt→Customer-facing insight→Evaluation + iteration
I owned this sufficient-data branch; exact prompt, output, and evaluation artifacts will be selected during evidence review.
Readiness outcome40% → 70%
The share of pets with an established health baseline increased following the profile-completion and wear-time Nudge redesign. This result validates the readiness branch, not generated-insight quality.
03
Existing product · January release
What return feedback revealed about the existing product.
Monthly return reasons surfaced different software problems with different causes. Connectivity was a system-comprehension problem; fence creation and editing were interaction problems.
When a connection problem looked like device failure.
Some customers interpreted weak connectivity as a broken device. The redesign made the connection condition and device state easier to distinguish.
Figure 05
Original + shipped UI pending reviewThe same connection problem, before and after
The exact original state will be selected from product evidence.
The exact shipped wording and behavior will be shown without adding unverified recovery claims.
Reducing friction in a core device task.
The fence work explored direct manipulation, physical and signal constraints, review states, and the choice to edit or proceed.
Figure 06
Design exploration · evidence selection pendingOne end-to-end fence interaction story
Select the precise creation or editing friction from the source file.
Show how owners shape and adjust the boundary on the map.
Surface roads, buildings, dimensions, and signal risks before saving.
Let the owner resolve highlighted areas or knowingly continue.
Figure 07
Correlation · not sole causationWhat we observed after the January release
Average overall return rate
Connectivity and fence improvements shipped
Observed average overall return rate
04
Two smaller decisions
Technical constraints and internal tools.
Pre-launch · Not market-validated when I left
Satellite communication–enabled trackerHow real-time should “real-time” be?
Freshness competed with battery life and satellite transmission cost. We defined a first-version rule rather than promising continuous updates.
Location freshnessBattery lifeTransmission cost>500m movement → one-way satellite location update
Final location-state evidence pending review.
Internal analytics
Removing SQL as a prerequisite for everyday product questions.
I built a Feishu workflow using OpenClaw and MCP to turn natural-language questions into BigQuery metric queries.
Feishu→OpenClaw→MCP→BigQuery→Feishu answer
Question Show health-baseline coverage for the last 30 days.
Answer Redacted conversation evidence pending review.
Models before screens. Data readiness before AI output. Physical constraints are product constraints.