DLDesheng LuContact
All work
ShippedAnonymized

AI + IoT Product / Shipped product proof

Computer Vision Smart Security

A shipped computer-vision product where onboarding and connected-device behavior became measurable product levers.

How experimentation treated onboarding and product experience as adoption levers inside a shipped connected product.

  • Connected product journey
  • A/B experimentation
  • Cross-functional release
  • GTM and adoption
Product stageShipped · Public-safe case
Leadership scopeProduct manager leading product strategy, roadmap, GTM, and delivery with a seven-person cross-functional engineering, design, and QA team.
Public-safe reconstructionIllustrates the product category and workflow; not an actual product screen
7
Cross-functional team
35%
Adoption improvement
40%
Flagship market-share growth contribution

Approved public figures. Definitions, attribution limits, and unresolved measurement details are stated later in the case.

Evidence first

What is proven, what I changed, and what remains open.

A 90-second evidence map for hiring review. Synthetic product views explain mechanics; they never count as outcome proof.

Verified now
A shipped connected-security product led with a seven-person cross-functional team, with approved 35% adoption improvement and contribution to 40% flagship market-share growth.
Next evidence gate
Connect the product decisions and outcomes to experiment design, event definitions, CV behavior, and public-safe hardware or interface evidence.
01

User / workflow evidence

Supported synthesis

Onboarding and product behavior were treated as measurable adoption frictions across connected hardware, mobile experience, and computer-vision safety features.

02

Product decision

Verified record

I framed activation as a product problem, aligned hardware and software delivery, and used controlled experiments to improve the path from setup to trusted everyday use.

03

AI / system boundary

Open evidence gap

The exact computer-vision signal, alert logic, monitoring, response, privacy controls, and architecture are not yet documented in a public-safe form.

04

Evaluation → change

Supported synthesis

A/B testing is part of the approved product record, but variants, sample, duration, activation event, baseline, denominator, and decision threshold remain open.

05

Outcome / boundary

Verified record

The approved adoption and market-share figures are presented as team and product contributions, not as sole personal attribution; the seven-person team is not described as seven direct reports.

AI product decision record

The choices behind the product, architecture, and release gate.

Use computer vision for perception, deterministic controls for device action, and behavioral experiments for adoption.

01

AI fit

Supported synthesis

Use a vision model only where sensor input requires classification or detection; keep setup and safety actions explicit.

The model can interpret visual signals, but the user still needs predictable device behavior and control.

Alternative consideredA rules-only detector cannot handle visual variation; an LLM is not the right model for the core perception task.

02

Knowledge & context

Supported synthesis

Use event metadata, device state, and privacy-preserving visual processing rather than RAG.

The product decision depends on real-time perception and state, not retrieval from a text corpus.

Alternative consideredA knowledge layer would not improve detection and could expand the privacy surface unnecessarily.

03

System architecture

Open evidence gap

Separate the perception pipeline, device rules, mobile experience, and human response boundary.

Each layer has different latency, safety, privacy, and recovery requirements.

Alternative consideredMCP or agent orchestration is not relevant to the verified core unless future tools must act across governed systems.

04

Evaluation & release

Supported synthesis

Combine model performance and false-alert analysis with onboarding experiments, activation, recovery, and user trust.

A technically accurate detector can still fail if setup, alerts, privacy, or recovery prevent sustained use.

Alternative consideredAccuracy alone or an adoption lift without experiment definitions cannot explain product success.

Evidence I still need from the private project record3 open items
  1. 01

    Exact onboarding experiment design and adoption-event definition.

  2. 02

    Public-safe CV user journey, trust model, and privacy boundary.

  3. 03

    Approved hardware, interface, experiment, or launch artifact.

Verified = direct approved recordSupported = defensible synthesisReported = source receipt pendingDesigned = future test or control

Zero-context product contract

What this product did, for whom, and why it mattered.

Public-safe representative journey. The precise setup steps, experiment variants, computer-vision output, and daily-use behavior are not yet approved as public evidence.

Primary user
Smart-home customers adopting a connected door lock with computer-vision safety features.
Trigger
A customer acquires the device and must move from initial onboarding into useful product behavior.
Product action
Guide the connected product experience, observe progression and drop-off, test alternative onboarding or product experiences, and release evidence-led improvements.
Output
A customer who reaches the intended product use and a product team with measurable evidence about adoption.
Decision enabled
Which experience change should be prioritized and shipped to improve adoption.

Product mechanics

See the product work before reading the retrospective.

The walkthrough uses fictional records to make the interaction and decision flow tangible. It does not replace the approved historical evidence or imply that every reconstructed state was shipped exactly as shown.

Simulated product scenarioComputer Vision Smart Security

A fictional household reviews a generic camera-derived safety signal. The mechanics are illustrative, not verified shipped feature behavior.

Product state · Onboard

Set expectation before the first intelligent event

The user sees what the safety feature can and cannot determine before enabling it.

User action
Enable, review privacy controls, or continue with lock-only use.
Fictional household

Maple Home · smart lock connected · safety signal optional

Product contractCamera-derived signals may suggest a condition; they do not confirm intent or replace user judgment.
Human confirmation required
Illustrative acceptance benchmark

consent, sensing boundary, retention, and human confirmation are visible before activation.

Inputs to product direction

What the available record supports.

Verified facts, historical artifacts, and public-safe reconstruction are kept distinct. Each item states the product implication without turning a plausible inference into a confirmed result.

01User-behavior analysis

User-behavior analysis was used across onboarding and product experiences.

Product implicationTreat adoption as a measurable product question rather than only a marketing result.

02A/B testing

A/B testing was used across onboarding and product experiences.

Product implicationUse comparative evidence to choose experience changes while keeping the exact variants outside the public record.

03Cross-functional release scope

Product strategy, roadmap, GTM, engineering, design, and QA had to move together for the shipped product.

Product implicationTreat adoption as a product-system outcome rather than an isolated feature or campaign result.

Journey transformation

A connected hardware and mobile product where onboarding and product behavior became measurable adoption levers

Public-safe representative journey. The precise setup steps, experiment variants, computer-vision output, and daily-use behavior are not yet approved as public evidence.

  1. 01

    Acquire

    User goal
    Bring a smart-security product into the household.
    Original friction
    A purchase does not guarantee activation or continued use.
    Product response
    Connect GTM and product planning to the post-purchase journey.
    Success signal
    The customer enters the onboarding experience.
  2. 02

    Onboard

    User goal
    Progress through the connected product experience.
    Original friction
    Behavior analysis showed friction across onboarding and product interactions.
    Product response
    Treat onboarding as a measurable product surface.
    Success signal
    The customer progresses toward activation.
  3. 03

    Activate

    User goal
    Reach the intended product use.
    Original friction
    Drop-off can prevent customers from experiencing the product's value.
    Product response
    Use behavior evidence to locate the adoption constraint.
    Success signal
    The customer reaches the defined adoption event; the exact event definition remains unpublished.
  4. 04

    Experiment

    User goal
    Improve the experience using observed behavior.
    Original friction
    Feature opinions alone do not show which experience helps users progress.
    Product response
    Run A/B testing across onboarding and product experiences.
    Success signal
    An experience change produces measurable evidence.
  5. 05

    Release

    User goal
    Improve adoption without confusing causation.
    Original friction
    Market and product outcomes can be overstated when evidence boundaries are unclear.
    Product response
    Ship the selected product change and retain bounded attribution language.
    Success signal
    Experimentation improved adoption by 35%; the launch contributed to market-share growth.

Product decision and rationale

Should adoption be treated only as a GTM result, or as a measurable product-experience problem?

This is an evidence-backed reconstruction of the product logic. It is not presented as a verbatim or dated decision record.

What the evidence said
  • Behavior analysis showed friction inside onboarding and product use.
  • A/B tests showed that experience changes affected progression.
  • Product strategy, roadmap, GTM, engineering, design, and QA were coordinated across the release.
Choice

Treat onboarding and activation as first-class product surfaces and use experimentation to improve them.

Tradeoff

The public record supports the evidence-led direction, but it does not identify a rejected variant or feature tradeoff.

Consequence

Experimentation across onboarding and product experiences improved adoption by 35%.

Included in the core product
  • Shipped smart door lock
  • Computer-vision safety features
  • Onboarding and product-experience analysis
  • A/B testing and cross-functional release
Outside the verified public record
  • Exact setup and pairing steps
  • Specific computer-vision signal, alert, monitoring, or response flow
  • Experiment variants, sample, duration, metric formula, and decision threshold
Release gate

The public record establishes the shipped product, cross-functional release, experimentation, and measured outcome; it does not establish the internal release gate.

Delivery and adoption

The work around the product is part of the product.

A shipped smart door lock with computer-vision safety features, supported by measured product-experience experimentation.

Cross-functional system
  • Engineering
  • Design
  • QA
  • GTM
  • Product support
Leadership moves
  1. 01

    Led product strategy, roadmap, and GTM across a seven-person cross-functional engineering, design, and QA team.

  2. 02

    Made behavior evidence and A/B results part of product prioritization.

  3. 03

    Connected product-experience evidence to adoption and bounded market-outcome language.

Product direction and program evidence

Place the product direction beside the approved evidence.

Adjacent evidence does not imply that one feature caused the full result. The approved metric language and attribution boundaries remain visible.

  1. 01
    Product direction

    Computer-vision safety product

    Observed or intended operating shift

    Brought a differentiated connected-security experience into the flagship offer.

    Approved program evidence

    Launch contributed to 40% growth in flagship-product market share.

  2. 02
    Product direction

    Onboarding and product-experience experimentation

    Observed or intended operating shift

    Onboarding and product experiences were examined through A/B testing and user-behavior analysis.

    Approved program evidence

    Adoption improved by 35%.

I led product strategy, roadmap, GTM, and a seven-person cross-functional engineering, design, and QA team; the evidence does not establish seven direct reports or sole causation for either outcome.

Evidence boundary

What the case proves, and what it does not.

The team is not presented as seven direct reports, and neither adoption nor market-share growth is attributed to Desheng alone.

Confirmed evidence
  • Shipped smart door lock with computer-vision safety features.
  • A/B testing and user-behavior analysis across onboarding and product experiences improved adoption by 35%.
  • The launch contributed to 40% growth in flagship-product market share; Desheng led a seven-person cross-functional team.
Still unresolved
  • Adoption event, baseline, denominator, sample, test duration, variants, and decision threshold.
  • Exact computer-vision signal, alert logic, interface, monitoring, response, privacy controls, and architecture.
  • Hardware, interface, or experiment artifacts approved for public display.
Return to the collectionShipped product proof