Drove MANA from an open-ended concept to a launch-ready MVP in three months by defining the product direction, establishing scalable foundations, and preparing the team to learn from real usage.
Delivered MANA from concept to a working multi-LLM product for selected business customers in 3 months.
Established semantic tokens, reusable components, shared patterns, and light and dark themes to support future growth.
Connected product hypotheses to SatisMeter, Redash, and Google Analytics to guide post-launch decisions.
When I joined the MANA team, the existing product had already accumulated inconsistent UI patterns and costly implementation debt. With 3 months to launch a new AI productivity product, my mission was to help the team move fast without recreating the same structural problems.
This time, the MVP could not just be fast. It had to be built to last.
A sequential process would not fit the timeline. I moved 3 connected tracks forward in parallel.
Turning “an AI productivity tool” into a specific proposition, audience, and MVP scope.
Just enough system — tokens, components, and patterns — to accelerate delivery without delaying it.
Connecting product hypotheses to observable behaviour before implementation was complete.
When the project began, “an AI productivity tool” was still too broad to guide design or engineering.
Instead of waiting for a complete brief, I created early wireframes to make the missing decisions visible. They gave the PO, PJM, and engineers something concrete to react to — and helped us clarify the product's key value, target users, MVP scope, and validation goals.
We positioned MANA as an approachable and secure multi-LLM workspace for business users, rather than a technical interface designed mainly for advanced AI users. That positioning translated into a set of practical design principles the team could apply directly.
The result was a clearer product direction, a focused first release, and a design language grounded in the experience we wanted to create — not simply in visual preference.
The wireframes did more than visualize MANA. They helped the team decide what MANA should be.
The previous product showed us the cost of building without shared foundations. However, creating an extensive design system before launch would have introduced a different risk: spending the MVP timeline designing abstractions we might never need.
I therefore focused on the smallest set of system decisions that would improve delivery immediately and remain valuable as the product grew.
Together with the frontend engineers, I evaluated three approaches.
| Approach | Trade-off |
|---|---|
| Build from scratch | Maximum control, but incompatible with the timeline |
| Adopt a library as-is | Fast, but difficult to differentiate or evolve |
| Adopt and customize | Best balance of delivery speed and long-term flexibility |
We assessed Ark UI against accessibility, component coverage, customizability, theme support, stack compatibility, and maintainability. The objective was not to borrow another product's visual language, it was to reuse reliable behavior and invest our time where MANA required product-specific thinking.
I established the foundations that would otherwise create repeated work across every feature.
Defining tokens by purpose allowed components to adapt across themes and product areas without accumulating one-off overrides.
I standardized common components early, then introduced MANA-specific patterns only as their requirements became clear.
Design and implementation happened in the same loop. Wireframes exposed technical questions, implementation revealed missing states, and those discoveries were fed back into both the product and the shared system.
We built enough system to accelerate the product — not enough to delay it.
Launching MANA was only useful if the team could learn from the release. Because the product was new, we needed to connect its core proposition to observable behavior before implementation was complete — not attempt to reconstruct meaningful metrics afterward.
We established Monthly Active Users as a long-term North Star, but the MVP required more immediate signals.
| Product hypothesis | Observable behavior | Initial signal |
|---|---|---|
| Users can reach value quickly | Completes the first prompt and receives a response | Activation |
| The experience supports repeated work | Returns and starts another conversation | Retention |
| Multi-LLM access is valuable | Selects or switches models | Model adoption |
| Onboarding is low-friction | Completes registration and enters the product | Completion rate |
| The product feels responsive | Receives the first generated token | Time to first token |
Acquisition and traffic.
Product behavior, funnels, and retention.
Operational and organization-level usage.
Defining success signals early also improved the product itself. When a flow did not have a clear completion event, it often meant its purpose or interaction still needed clarification.
We did not instrument the product to collect more data. We instrumented it to make the next product decision clearer.
Within three months, the team launched ManaChat’s first usable MVP with five core features, reusable product patterns, light and dark themes, and product analytics. The next release no longer started from a blank canvas. Designers and engineers could reuse established patterns, discuss technical constraints earlier, and evaluate product decisions against real user behavior.
The MVP shipped quickly, but the work was designed to outlast the first release.
The most difficult part of this project was the constant race against time.
Stakeholders needed to see features moving forward, but the team also had to protect the product’s technical stability and avoid creating foundations we would need to replace later.
I learned to break large decisions into smaller, testable steps and iterate quickly. Each release needed to show visible progress while also leaving the product in a better state for the next one.
That balance was not easy. There were always trade-offs between what could be delivered now and what needed to remain scalable later.
The biggest lesson was that speed and scalability are not solved in one decision. They are balanced continuously, one iteration at a time.
