Creating the AI platform that creates multiple avatar videos, in every language
Role
Product Lead
Company
doinstruct
Responsibility
0 to 1
Timeline
June 2026
Project
6 dev + 1 des
Stakeholders
CEO + Head of Engineering
Problem
Doinstruct trains frontline workers, people in warehouses, food production lines, and logistics hubs. A single site often runs in ten or more languages, and video is the format that actually reaches these workers.
Inside the product, video creation lived in three disconnected features: a video upload, a slide-to-video generator, and AI voiceover generation. But none knew about the other, creating problems in: quality of content, unfair credit cost and most importantly, quality of translation.
Of all product requests were about translation. Every one was support load on our side, every inconsistent language version audit risk on the customer's side.
My Role
How we normally work
Design and engineering run one-week sprint cycles. Solution fast, ship, iterate. We don't spend weeks researching before touching code, real usage is a big part of our research.
Why this was no different
Even though technically a feature, this project is a new product. Allocated two months to reach alpha, where we kept the agile pace of building the product while iterating on features, design and capabilities.
In this project I owned the product side of things as well as the transition from design to code. Definition, design, prioritisation, stakeholder alignment, and decision log were under my responsibilities.
This meant being fully embedded into the engineering team, the repo, the daily reality of the codebase, the new AI workflows we are constantly testing and adopting, deep enough to care for UI accuracy in code myself instead of judging it from Figma.
Project Roadmap
We didn't run discovery first and build second. From day one, two tracks ran in parallel to buy speed: engineers built a technical prototype to learn what the AI models could actually do, while I ran the product definition, feedback inventories, CX tickets, conversations with users, and sessions with our internal content-creation team.
Every team always begins with the same problem: team chaos. "Where should we start? Who is doing what? What are we even building?"
I facilitated a Product Canvas exercise as a method of gathering team alignment. This allows the team to form a shared basis of understanding, and part of the job was training engineers to think in product, to keep our iteration agility while still building the right thing, and to see that the effort actually paid off.
When the two tracks converged, model reality on one side, user reality on the other, we built the feature list together: brainstormed how far each feature could go, mapped what competitors offer, and drew the four core flows, create, edit a scene (the money flow), translate, publish.
Every open question went on one board and got sorted by two axes: is it hard to reverse, and does it block the first real work.
Questions landed with an owner's name on them, the data model, the multi-language algorithm, the component-library reuse. The reversible ones were decided by their owner and moved on. Only the hard-to-reverse, blocking ones earned a seat in the leadership alignment.
Then the cut, surface by surface, MoSCoW scoped to the alpha.
Definition
Topic
Decision
What do we build?
Compliance/operational content generator.
Who for?
Non-tech frontline managers.
Where?
Standalone product, but connected to main.
How?*
As experimental as non-tech UX allows.
*yes, how. Not why or when since we already had these defined.
Screenshot of the C level alignment meeting.
Design To Code
We can now easily build the interface I design. The work ships through pull requests like everyone else's, and design QA happens in the PR.
The AI workflow behind that runs on three tools sharing one source of truth. Claude Design for fast exploration, Figma as the system of record, Claude Code working in the repo, and our design system is what connects them: tokens and components mapped between Figma and code, so what an AI reads on one side resolves to what exists on the other. That mapping is why thirteen production-fidelity screens came out of one session, and why prototype designs became a clickable product early instead of waiting in a handoff file.
How that system was built is its own story → the design-system case study
Final screenshots of the main 3 flows for Alpha
OUTCOMES
A locked direction that hasn't moved since July, four decisions, written down, still standing.
A working product iterated on daily in code, not a prototype waiting for engineering.
An alpha scope everyone can refer to: every feature prioritised, cuts written down with reasons.
Beta will get iterated on based on Alpha performance and feedback.
