My Role

Product Lead

• Cross-Functional Collaboration: Worked with 2 Designers, 6 Engineers, and 1 Data Analyst
• Roadmapping & Vision: Established and maintained the consumer-facing app product roadmap, aligning priorities with overall business objectives, and guiding feature development
• User Research & Validation: Led user interviews and testing
• Stakeholder Alignment: Communicated strategy and progress across departments and executive teams
• Release Management: Planned releases from concept to launch; managing sprints and collaborating cross-departments
• Data-Driven Experimentation: Setup and trained data analytics team. Defined key metrics and dashboards to measure outcomes. Leveraged insights for continuous improvement

Growth & Marketing Lead

• Team Leadership: Managed a growth squad of 3 and marketing team of 6, setting goals and processes for initiatives
• Growth & Marketing Strategy: Led growth and marketing strategies focused on user acquisition and retention
• Data-Informed Experimentation: Established a culture of rapid, data-informed testing
• Managed Rebrand: Led collaboration with an external agency to manage Plum's rebranding

Championed Vision Company-wide

• Evangelized "critic-rated meals delivered daily," ensuring alignment company-wide across teams including logistics, menu selection and marketing
• Conducted company-wide workshops and interdepartmental strategy sessions
• Authored the company culture handbook, codifying values and aligning them with key business drivers

Context

Plum, a nascent 3-month old, 30-person company, aimed to disrupt the food delivery landscape in Hong Kong, a market dominated by well-established players like Food Panda and Deliveroo. The founder's vision involved delivering a daily rotating menu of five dishes from a variety of restaurants around the city to working professionals in key business districts.

Main Challenge

Despite the initial strategy of acquiring users by offering free meals, Plum struggled to convert users into paying customers. At peak, the team had 1,000 unpaid daily orders and negligible paid orders.

What I Did

#1 Crack product-market fit

Recognizing the local foodie culture's preference for exclusive and high-quality meals, I proposed a pivot towards a gourmet-focused value proposition. This involved sourcing critic-rated dishes, which differentiated Plum from competitors.

We tested this idea by changing the messaging on our flyers and immediately saw an increase in paid orders. Following this success, we modified our meal sourcing strategy to focus on critic-rated dishes.

Within 2 months, Plum achieved product-market fit, scaling from 1,000 daily unpaid orders at peak to 10,000 daily paid orders and boosting retention from a stagnated 17% to 46%.

#2 Ensure strategic vision is executed company-wide

Executing on the strategic vision of "critic-rated meals delivered daily" required coordination across the entire organization, from menu selection to product development to operations.

To ensure company-wide alignment, I regularly organized workshops and departmental strategy sessions.

For example, I led our menu selection team in developing a data-driven methodology that guided dish selection in support of specific business goals such as acquisition, retention, and branding. I also created a company culture handbook, which helped both new and existing employees embody our values and deliver on our promise at every touchpoint, from delivery to customer service.

#3 Product development, growth and branding

As product and growth lead, as well as advisor to the marketing team, I mentored team members and ran weekly strategy review meetings.

Key product initiatives:

• Collaborating with design and engineering on development of mobile app
• Labelling Michelin-recommended dishes with Michelin logo, resulting in 237% increase in orders
• Conceived and championed a menu selection strategy, driving over 11.8% month-over-month growth in orders
• Became the first food delivery app in Hong Kong to implement a feature allowing users to select their desired tip amount and opt out of receiving cutlery
• Set up and trained first data analytics team member, guiding team on which metrics to track and how. Defined company OKRs and analytics dashboard. Created retention cohort charts.

Key growth initiatives:

• Loyalty program
• Referrals program
• Daily notifications to place orders
• Notifications for wishlisted items

Additionally, I managed Plum's rebrand in partnership with an external agency.

Before rebrand

After rebrand

Overview

Led research and discovery for a global luxury retailer seeking operational efficiency improvements post-COVID-19, uncovering 18 innovation opportunities.

WhatsApp for Business

Associates estimated saving roughly 60–90 mins a week on manual note-taking and organization. The solution centralized client conversations with features like labels and internal notes. Status: added to development roadmap.

Digital Queue Ticketing

Prototyping revealed potential for a 40–50% cut in median wait time, from ~60 min to ~35 min. Predicted 10–15% improvement in customer satisfaction. Status: added to roadmap.

Centralized Product Styling Hub

Testing showed styling resources usage increased from 60% to 80% of interactions, with location time dropping from ~6 mins to ~3 mins. Associates gained better product knowledge access.

System Integration

Workflow analysis identified staff spending about 3.5 hours per week on duplicate data entry and error correction. Integration projected to reduce this by ~57%, to around 1.5 hours per week, plus 10–25% revenue uplift potential.

Employee Feedback Platform

A 2-week pilot produced 22 actionable issues versus historical 5–7 monthly. Staff reduced reporting time from 1-hour weekly meetings to just 5–10 minutes per person per week.

Predictive Personalization

Research showed 80% customer interest in personalized recommendations. Recommendation was escalated to headquarters for evaluation.

Challenge

The client team faced a high volume of feature requests from other departments and had difficulty prioritizing these alongside their own initiatives. They also struggled with rationalizing their prioritization decisions and quantifying their impacts for management.

What I Did

Phase 1: Research

• Led stakeholder interviews and cross-functional workshops to map pain points and define success metrics
• Conducted job shadowing to document as-is workflows and bottlenecks
• Key Insight: 60% of "urgent" requests lacked measurable outcomes or conflicted with annual OKRs

Phase 2: Framework Design

• Architected a RICE-based prioritization framework that measured impact based on strategic team and organizational goals

Phase 3: Operationalization

• Trained 11 analysts in hypothesis development and A/B test design, standardizing experimentation practices
• Implemented and facilitated bi-weekly standups, bi-monthly triages, and quarterly sessions for ideation workshops, roadmap reviews, and retrospectives to compare projected versus actual outcomes for continuous refinement
• Built lightweight tracking via automated Jira scoring

Overview

Collaborito is an AI-enabled platform that connects individuals with shared interests to collaborate on passion projects. Backed by the Hong Kong Science and Technology Parks (HKSTP), it currently has 263 registered users with 21% WAU.

My Role

• Team Building: Recruited a full-stack AI engineer from Nvidia as CTO, plus a UI/UX designer and two software engineering interns
• Strategic Direction: Established product vision, business model, and roadmap
• Fundraising: Created investor-facing pitch deck and financial projections
• Product Design: Led product design with iterative user feedback sessions
• Go-to-Market: Planned and executed go-to-market strategy with zero marketing spend

Key Design Decisions

Avatar Size

Smaller avatars prioritize text-based user information (skills, roles) over profile pictures.

Information Architecture

Users took 57% less time to read text presented in bordered text boxes versus continuous blocks, with a 33% increase in testers describing the layout as straightforward and easy to navigate.

Color Strategy

Multi-color profile cards enhance engagement and help users distinguish individual contributors in the text-heavy interface.

Content Prioritization

Deprioritized user-generated content and newsfeed features to focus on core matching functionality given the small initial user base.

Opportunity

Private equity due diligence is a manual, time-consuming and inefficient process that can take around three analysts one to two months to perform depending on the deal size.

My Role

• Established lean startup methodology
• Conducted 5 interviews with PE analysts and 5 with executives
• Analyzed competing AI due diligence tools
• Designed product
• Prompt engineering for LLM accuracy

Key Design Decisions

Navigation

Top navigation preferred (vs. sidebar) to dedicate sidebar to deal-related navigation.

Chatbot Placement

Pop-up chat window for analysts; standalone tab for executives — reflecting the different depth of interaction each role needs.

Overview

Estel is an AI-powered relationship communication coach app.

My Role

• Defined product vision and business strategy
• Developed pitch deck
• Led product design

Status

Customer development interviews with therapists in-progress.

Watch the demo on YouTube →

History is taught one civilization at a time, so the question I always had, what else was happening right then, never had an answer on one page.

Open Histoline →

The problem

Every history book I have read runs down one lane. Ming China, then the Ottomans, then the Renaissance, each in its own chapter, each with its own dates. Nothing in that format tells you that while Gutenberg was printing, Zheng He's fleets had already been scrapped and Constantinople had three years left. The timelines that do try to show everything at once are posters: too small to read, fixed at one zoom, and not something you can ask a question of.

What I wanted was simple to say and hard to build. Pin any year, and see what every part of the world was doing at that moment, with enough context on each item to trust it.

How it started

The first version was called Meanwhile and took a weekend. It covered 1440 to 1660, eleven civilizations, 172 events, and lived in a single HTML file of 3.7 MB, with every image embedded so the page could be sent to anyone and opened anywhere with no server behind it. I built it with Claude, starting from a design canvas with three art directions and choosing one, then keeping the data as one JSON file per region with a small validator script that refused to build if a date was malformed or an event was missing a source.

It worked well enough that people asked for other centuries, and that is where a weekend build turns into a product decision.

Key decisions

Trust is the product, so check everything against an outside source

A timeline that is mostly right is worse than useless, because you cannot tell which parts to believe. Once the range grew to 3500 BC through 2026, I had every dated item cross-checked against Wikidata's structured records. For the original eleven lanes, 981 empires, reigns, wars, eras, people and events found a match. About 700 agreed within Wikidata's own stated precision. Twelve were corrected. Forty-eight differ only by which standard periodisation you prefer, such as whether the Roman Empire ends in 395 or 476, and those stay as they are with the reasoning noted. The six lanes added later went through the same pass on arrival: of roughly 900 dated items, six were corrected and about a dozen era bands were re-cut where the authoring had left seams. Around 1,350 summaries were then read against the Wikipedia lead for the same entity, and seven were fixed.

The numbers are published on the page itself, in the About panel. That was deliberate. If you are asking people to trust a history site made with AI, the audit has to be visible, not claimed.

An importance budget, not an importance score

Showing everything at once is unreadable, so every event is ranked 1, 2 or 3: a landmark that bent its civilization, something significant to that lane's story, or texture like daily life and curiosities. The trick is that rankings are relative to each lane, with a budget per lane per era. Without that, Rome and Greece would flood the screen and West Africa would vanish. Zoom in and the lower tiers appear.

Contested history is named in each community's own terms

Where two communities remember the same event differently, both names appear. 1948 is shown as both Israel's Declaration of Independence and the Nakba. Characterisations that are disputed are attributed rather than asserted, and casualty figures use scholarly ranges. I would rather the page be honest about disagreement than quietly pick a side.

Eleven lanes are not the world, and the page says so

The first release covered eleven civilizations and said plainly that India, Japan, Korea, Southeast Asia, Africa beyond Egypt, the Andes and Oceania were absent. Six of those have since been added, bringing it to seventeen. A World strip carries what no single region owns, such as technologies, diseases and trade networks that crossed continents, and an Empires strip shows polities that genuinely begin and end, from the Akkadian Empire to the Soviet Union. Select one and every region it never reached dims.

A second view where thickness means people

The Streams view draws each region as a ribbon whose thickness follows population estimates from McEvedy and Jones and from HYDE, scaled by square root so small regions stay legible. It is a claim about relative size, and it is labelled as one.

What I learned

Building it took a weekend. Making it trustworthy took far longer, and that was the real work. The generation step is now cheap; the checking step is what turns a demo into something you would show a teacher. I also learned to publish the limits: a clear "what is not here" paragraph did more for credibility than any amount of polish.

Next are the Prehistory and True Scale views, and a proper mobile treatment, since on a phone the timeline currently shows markers rather than labels.

I had more ideas than I could build and no honest way to see which ones deserved a weekend. So I built the board first.

Open the board →

The problem

Once building became cheap, the idea list became the bottleneck. I had dozens of things I could make with AI, from a subscription reminder that reads my inbox to a language app that retells a story you already know, and the list grew faster than anything got shipped. Each idea needed a rough sense of how good it was, who it would help, how easy it would be for someone else to copy, and, new in 2026, how well AI could actually build it today. None of that lived anywhere.

There was a second problem underneath. I post what I build as @rubyonai, and an audit of two creator accounts in July had reversed a plan I was sure about: product on screen wins, and faceless philosophy content floors. That meant the board could not just be a private to-do list. It had to be something people could look at.

What it is

A kanban with six lanes, from Ideas through Up next, Building, Built, Demo recorded and Posted. Every card carries three ratings out of five, for how good it is, who it helps and how easy it is to copy, plus a separate rating for how well AI can build it, with the hardest part named in one line. Behind each card is a five-part case study: the problem and the evidence for it, the scope, the key design choice, the results or the metrics I would watch, and what I learned.

There are fifty-five cards. Seven are built and in use, including this board.

Key decisions

One address, two boards

Visitors and I go to the same link. The site checks for a sign-in and quietly serves a different page: visitors get the board with every card visible but none of them openable, and none of the private content in the page at all, not merely hidden. I get the same board with every card open, drag between lanes, editable text and ratings, and a Publish button. I chose this over two separate links because a portfolio should have one address you can say out loud, and because the failure direction is safe: if the swap ever fails, the public board is what shows.

No database. The repository is the store.

The obvious build was a database with an admin login. Instead, the board is generated from one file in a repository, and pressing Publish commits my edits back into that file. The site rebuilds itself a minute later. That gives me a full history of every change, nothing new to pay for or maintain, and one source of truth. The trade is a minute of delay between saving and seeing it live, which is fine for a board that changes a few times a week.

Edits are held until you publish, and never lost

Dragging a card or re-rating it changes the page immediately but goes nowhere until I publish. A bar counts what is unpublished. If publishing fails, because I was signed out or the connection dropped, the edits stay in the browser and can be retried or copied out as text. I wanted to be sure a mistake could cost a minute, never a session of work.

The AI rating stays off the card

It is on every card inside, with the reasoning, but not on the face. A number like "AI 3/5" on a public card reads as a claim about the idea rather than a planning note about my effort, and it would invite the wrong argument. The three ratings that describe the idea itself are what visitors see.

Drafts you edit, not boxes you fill

The fifty-five case studies were first drafted by Claude in my voice, from the card, my notes and the numbers I already had, then edited by me. Where an idea has not shipped, the results section says so and lists the metrics I would watch, with targets. A draft to correct is far easier to finish than an empty field, and the discipline of five fixed sections is what makes the board useful for interviews rather than just for me.

It looks like the rest of my site

The board uses the same blush ground, the same single red and the same serif pairing as rubytang.com, rather than a dashboard look. It is a portfolio page that happens to be a working tool, and it should read that way.

What I learned

Two things went wrong that were worth more than the things that went right. The password form was posting to a piece of code that had never actually been deployed, so no password could ever work, and the fix came from checking the live page rather than reading the code again. Later, two sites briefly shared one deployment and overwrote each other on the live domain for a few minutes. In both cases the lesson was the same one I keep relearning as a product manager: verify the thing in production, not the thing on your screen.

The other lesson is about scoring. Once every idea had a number for how well AI could build it, the board sorted itself. Most ideas land at 3 or 4, a few are genuinely a weekend, and one, dubbing a streaming show into another language in the browser, is a 1 because copy protection blocks it regardless of how good the model is. Knowing that before starting is the whole point.