The biggest Tell Me Ted decisions were not which model or API to use. They were decisions such as whether a child should press a button.
That may sound backwards for an AI product. The model is what makes the demo possible. But the product is defined by everything the child and parent have to understand around the model.
A technically sophisticated system can still be the wrong product if the child must adapt to its architecture.
1. A teddy instead of an app
The teddy was the first constraint.
It creates familiarity and physical presence. A child does not need to borrow an adult’s phone or learn a new interface. The product can sit beside a book without becoming the visual focus.
It also creates manufacturing, acoustics, charging, durability and trust problems. Every electronic component must fit inside an object that should remain soft, safe and recognisably a toy.
We chose the teddy because the interaction mattered more than the simpler engineering route.
2. The physical book remains central
Tell Me Ted has explored more than one product idea. Early thinking included milestone stories, recordings and generated content. The clearest differentiator became the ability to engage with a physical book the family already owns.
That decision acts as a filter. The camera exists to serve the page. Conversation exists to help the reading moment. The device should not pull the child away from the book into a general-purpose AI experience.
It also stops us from making inflated claims. The product is not a substitute teacher and the current prototypes have not proved educational outcomes. The honest proposition is simpler: make it easier and more engaging to spend time with a real book.
3. The camera belongs in the eye
From a storytelling perspective, the camera in Ted’s eye is obvious. Ted “looks” at the page.
From an engineering perspective, it creates trade-offs in angle, focus, occlusion, mounting and privacy perception. A camera hidden too well may feel deceptive. A camera exposed too prominently may make the product feel clinical or unsettling.
The correct answer is not only industrial design. The product must be clear about when a page is captured. Our current design uses on-demand still images rather than continuous capture. That boundary matters more than making the system appear magically aware.
4. One-button simplicity is valuable
Voice should carry most of the interaction, but a physical button can be more predictable than an inferred phrase.
Page turning is the best example. A child may speak quietly, use a phrase the system did not expect or simply prefer not to talk. A debounced button gives one unambiguous instruction: the page has changed.
Fallbacks are part of good AI product design. They reduce the amount of intelligence a system must pretend to have and give the user control when inference fails.
The harder question is which button. Children should not have to distinguish a power control, wake control and page control hidden inside a plush surface. Our prototype work is testing clear, limited roles rather than adding controls for every feature.
5. Latency is a product decision
We originally treated latency as an engineering optimisation. It became a reason to change the architecture.
A child’s attention does not pause while a pipeline transcribes, generates, synthesises and downloads. The delay changes whether Ted feels conversational or broken.
That is why the current direction moved toward a more continuous session and earlier speech playback. The priority is not winning a benchmark. It is reducing the silence before something useful happens.
This decision also influences cost, network behaviour, buffering, error recovery and session limits. Product experience and technical architecture are the same conversation.
6. “Always listening” is not automatically better
An always-open microphone could make some interactions easier. It could also make privacy harder to explain, consume more power and blur the boundary between an active reading session and ordinary family life.
Our current design favours explicit session boundaries and bounded child turns. Speaking and listening are separated, and simple activation can remain local rather than becoming continuous cloud input.
There may be future reasons to revisit those choices. The burden of proof should sit with the more invasive design.
7. A prototype must admit what it is
Early prototypes indicate that the system can be integrated and that the core interaction is technically feasible.
They do not prove mass-production quality, certification, market demand or long-term child use. Structured parent research, supervised testing, compliance work and manufacturing refinement remain next-stage activities.
Calling that out is itself a product decision. Teams get into trouble when a compelling demo becomes evidence for claims it was never designed to test.
Some decisions are more settled than others. Keeping the physical book central and avoiding continuous camera capture are principles. A more continuous interaction and a physical fallback are the current direction. Exact cues, controls, listening thresholds and acoustic design remain experiments that need evidence from supervised use and final hardware.
The decision framework we use
Before choosing a model, sensor or workflow, we now ask:
- Does this keep the physical book central?
- Can a young child understand what to do?
- Can a caregiver predict when the device listens or captures a page?
- Does it fail clearly and safely?
- Does it avoid collecting data we do not need?
- Can the actual hardware support it with margin?
- Can we test and update it after the device leaves our desk?
No single question produces the answer. Together they stop a technically attractive idea from bypassing the product principles.
The best interface may be less AI
AI product discussions often assume progress means removing buttons, inferring more intent and making the system appear more autonomous.
For Tell Me Ted, a visible session boundary, one reliable button and a narrow reading role may create a better product than an invisible general-purpose assistant. The child gains control. The parent gains predictability. The engineering team gains clearer failure states.
The sophistication sits behind the interaction, not in the number of behaviours the user must learn.
That is the broader lesson: start with the relationship you want between the person, the physical object and the task. Then choose enough technology to support it.
Next in the series: how we turn a sentence such as “add page-turn detection” into a task a coding agent can execute safely.
Tell Me Ted is an independent, pre-launch project that I work on outside my role at HubSpot. The views expressed here are my own and do not represent HubSpot.