Internal evidence
I interviewed Sales, Solutions, Product, and other teams, then reviewed available CRM records, contracts, and company context to establish what we already knew.
0→1 computer-vision platform
Turning YOLO from a Python package into an end-to-end product.
Ultralytics had widely used models and a large open-source community, but the working experience still lived in Python. The first challenge was not drawing screens. It was finding out who the product should serve, how their teams worked, and which parts of that workflow needed a product first.
Starting point
YOLO models, a Python package, and an active community already existed. A product did not — and we did not yet know which users or workflows to prioritise.
Business stakes
A guided UI could expand the addressable audience beyond ML specialists to software developers who needed the capability without the same Python expertise.
My ownership
I led discovery independently, shaped the segment and workflow framework, designed the platform experience, and helped change how the team shipped it.
I owned discovery and product design. Product, Engineering, ML, Growth, Sales, Solutions, and Community partners contributed domain knowledge and shipped the platform with me.
02 Discovery I led
Finding the product before designing the interface.
I triangulated company evidence with primary user research, then synthesised it into personas and a workflow framework. The portraits were a communication layer; the decision value came from comparing team structure, maturity, tools, handoffs, integration needs, and priority jobs.
Primary research
I recruited community members and customers through community managers, email outreach, and compensated sessions; I ran the interviews and synthesis myself.
Decision model
I mapped team composition, maturity, jobs, tools, handoffs, integration stacks, and must-have capabilities — then connected those patterns to scope and backlog priorities.
Contexts compared
- Learners & researchers
- Independent specialists
- Technical founders
- Product & engineering teams
- Enterprise AI / CV teams
The framework compared maturity, team composition, toolchain, and priority jobs — then linked each context to product decisions.
03 The product decision
One visible lifecycle, not a Python wrapper.
The platform translated package capabilities into a guided loop: prepare data, train and compare models, deploy them, observe real-world behaviour, and feed what was learned back into the dataset.
DataCollect · Upload · Annotate · Review
TrainConfigure · Run · Compare · Stop / retry
Deploy & monitorDeploy · Observe · Detect issues · ImproveThe design principle
Make every stage clear enough for the next decision.
04 Trade-off and learning
Core workflow first; broad integrations later.
This was the most consequential scope decision. It made the first release tractable, and post-launch evidence made its limit explicit.
Broad integrations
Customer stacks varied too widely to justify a large integration surface in v1. We shipped the common core loop first and captured integration evidence in the backlog instead of guessing.
Enterprise readiness
The audit showed that import, export, enterprise systems, and self-hosting were part of the workflow — not add-ons. They became the next product frontier for enterprise teams.
Closing the feedback loop after launch
I audited the live experience end to end: where users stalled, where the lifecycle leaked, and which dependencies the first release had exposed. Those findings went back into product and backlog decisions.
05 Beyond the screens
I also changed how the team shipped.
The goal was not to add design as another stage. It was to make design input part of development — faster to test, harder to mistranslate, and easier for engineers to build on.
Design in the loop
I used AI-assisted code prototypes, live branch previews, and precise task context so design intent travelled with implementation instead of through a separate handoff.
Earlier proof
Engineers could react to working behaviour sooner, preserve intent, and catch ambiguity before it turned into avoidable rebuilding late in delivery.
Change leadership
I aligned with engineering leadership, held one-to-ones, coached through resistance, and resolved day-to-day friction until the new collaboration model became familiar.
06 My design impact
What changed — and what I can claim.
The product launched recently, so I separate shipped and operating outcomes from lagging metrics that still need time and instrumentation.
An end-to-end platform shipped
Users could move from data to a trained, deployed, and monitored model through one visible workflow instead of recreating the journey through the Python package.
An undefined audience became a decision framework
The segment and workflow model gave Product, Engineering, and GTM a shared basis for scope, priorities, and backlog decisions.
Design moved closer to production
Working previews moved feedback earlier and removed translation layers from the handoff. The team experienced a tighter operating loop; a percentage change was not instrumented.
Enterprise requirements became explicit
Post-launch evidence moved integrations, data portability, and self-hosting from scattered requests into a clear enterprise product direction.
Story Product communication
Explaining the product outside the interface.
Launch, feature, and community assets made a complex platform easier for customers, community members, and internal teams to understand and share.
Measurement plan
Four questions before four claims.
The product had just launched, so the responsible next step is to establish baselines and instrument the behaviours that would prove durable impact.
- 01Are teams reaching first value?
- Activated teams · first complete model lifecycle · returning teams
- 02Where does the workflow break?
- Time to first model · stage drop-off · support requests by stage
- 03Did delivery actually improve?
- Design-to-release time · reopened work · rebuilds caused by ambiguity
- 04Can enterprise teams adopt it?
- Integration usage · self-hosting blockers · pilot-to-production conversion
Working on a product with this kind of complexity?
Start a conversation