Defining an AI smart glasses product from zero

Context

Sidekick Labs is building AI-powered smart glasses: a lightweight heads-up display paired with a companion phone app. The AI is the product; the hardware is how you reach it.

I’m the product manager across all of it:

hardware and firmware
the AI stack
the phone and glasses apps
design, working with the founders

I’m the only product manager. My job is to give all of these one shared definition of what we’re building, for whom, and why, and to keep it honest as reality pushes back. That definition now runs to several hundred requirements, and is read by six teams and the partners and stakeholders around them.

The problem

Three constraints shaped everything:

Hardware and software iterate at different speeds. A hardware cycle is long; a software cycle can be a day. Learning can’t be paced by the slower one.
The AI can’t do everything yet. Not reliably, cheaply and quickly all at once, and not for every task people will ask of it.
Many teams move at different speeds. Without a shared, current definition, each builds its own version of the product.

What I did

Made the phone a complete product, not a companion

The obvious framing for a glasses company is glasses first, with the phone app as a settings screen. I defined it the other way round: the product is a complete phone experience, and the glasses add a small set of things the phone can’t do, namely hands-free voice, first-person capture, on-glasses commands and a heads-up display.

That call did two jobs at once:

Learning at software speed. Ideas could be tried with real people on a phone, without waiting on a hardware cycle.
One spec, not two. Each glasses extension is specified once and applies to every use case, so the two surfaces can’t drift apart.

Wrote a strategy that says what would change it

The strategic anchor is a working-backwards PR-FAQ. The part that earns its keep is a table of strategic hypotheses, each with how it will be tested and what we do if it fails. The strategy says in advance what evidence would change it, and the personas behind it cite research rather than intuition.

Wrote requirements teams can build and test against

Requirements started out organised by product domain. Each was framed around the job the user needs done.

I later restructured them into a launch requirements set split by surface, including the internal tools behind the product. For the AI layer, I wrote capability specs from a fixed template. Each spec has explicit lists of what was retired and what was deferred, so nobody has to infer scope from silence.

Let product propose and engineering validate

For anything architectural, the rule is: product proposes, engineering validates feasibility. When the architecture documentation and the requirements disagreed, I ran gap analyses in both directions. Each conflict was resolved and recorded, not just noted.

Took it into the field

I built demos and a working prototype, then tested them on-site with real people. The travel assistant prototype has its own case study. Field testing changed my assumptions quickly. What people valued depended heavily on where they were and what they were doing, and the product had to be able to adapt to that rather than behave the same everywhere.

Defined “ready” before asking whether we were

As the work matured, “are we on track?” kept getting asked without anyone agreeing how to judge it. So I wrote the assessment frame first: scope baseline, how optimistic the estimates were, how reliable each workstream’s status signals were, and whether the experience quality was good enough. Then came the evidence:

Readiness audit. I traced each launch requirement to the code that implements it across the product’s repositories. “Are we on track?” became a list of specific gaps engineering could act on.
User acceptance testing. A structured campaign with checklists for each scope, and a test, report, fix, re-test loop feeding a findings tracker.
Safety and compliance. Started from what platform and model providers already guarantee, and specified only what we needed on top.

The result so far: pilot programmes secured, and the phone and glasses apps on the way.

How I make the calls

Outcomes over features. A use case earns its place by the outcome it delivers for someone, not by how impressive it looks in a demo.
Filter by what’s solvable today. If a use case depends on the wider ecosystem maturing first, it doesn’t make the cut. It hands off to existing apps until it can be done well.
Place each workload deliberately. Whether something runs on the glasses, the phone or the backend is decided by battery, what the hardware can actually do, update frequency and download size.
Write down what’s deferred and retired. Scope nobody wrote down gets rebuilt from memory, differently by each team.

What I took from it

Field testing beats desk assumptions. One afternoon with real visitors overturned what I’d have argued for in a document.
Passing tests means “built as specified”, not “does what users need”. Last-mile product testing is a separate job, and someone has to own it.
“On track” can’t be answered until everyone agrees how to measure it.
Build on the baseline you inherit. For safety, privacy and platform behaviour, start from what the providers already guarantee and specify only the difference.