Zhe Lim

Company: HappyCo (Product Manager, promoted to Senior Product Manager) • SaaS platform for managing commercial real estate

Problem

HappyCo's professional services team manually configured every new customer's environment during onboarding. As the customer base grew rapidly, this became a scaling bottleneck. Setup tasks that were acceptable at low volume were now delaying launches and consuming team capacity.

Discovery

I led discovery with the professional services team and new customers to map the onboarding workflow end-to-end. I identified which configuration tasks were repetitive and rule-based versus those requiring human judgement. I analysed onboarding cycle time data to quantify where time was being lost and built the case for investment.

What I delivered

A suite of self-service configuration and setup tools that allowed professional services teams to complete onboarding tasks faster and with fewer errors. The tools targeted the highest-volume, most time-intensive steps first.

Outcome

• Customer time-to-value reduced by approximately 55%
• Professional services team capacity freed up to handle increased launch volume without additional headcount
• Onboarding became a scalable process rather than a bottleneck

My role: Owned discovery, definition, prioritisation and delivery. Partnered with engineering, professional services and customer success throughout.

Company: HappyCo (Product Manager) • Happy Asset, a new product line for multifamily portfolio asset management

Problem

HappyCo's existing platform served property operations but did not address asset management workflows for multifamily portfolios. There was an adjacent customer segment with unmet needs and no product serving them within the HappyCo ecosystem.

Discovery

I led discovery with prospective customers in the multifamily asset management space to understand their workflows, pain points and what would make them adopt a new tool. I validated demand and defined the minimum viable feature set needed for the first cohort of enterprise customers.

What I delivered

Happy Asset: a new product line built within the HappyCo platform. I owned the full lifecycle from discovery and requirements definition through to go-to-market strategy and customer onboarding. I designed and executed the GTM and onboarding for the first six enterprise customers.

Outcome

• Happy Asset added approximately 7% to total company revenue within its first year
• Six enterprise customers onboarded and adopted the product
• Established a new product line and customer segment for HappyCo

My role: End-to-end ownership. Discovery, definition, GTM, onboarding, iteration. Partnered with engineering, product marketing and customer success.

Company: HappyCo (Senior Product Manager) • AI-powered automated task assignment

Problem

Property managers using HappyCo were manually assigning inspection and maintenance tasks based on property type, location, team capacity and task history. This was time-consuming, inconsistent and prone to suboptimal allocation.

Discovery

I worked with customer success and directly with property management teams to understand how task assignment decisions were made. I identified patterns in assignment behaviour that were consistent enough to automate and validated with customers that automated assignment would be trusted if the logic was transparent.

What I delivered

An AI-powered task assignment tool that automatically allocated tasks based on learned patterns from historical assignments, property attributes and team availability. I led an empowered product team through design, build and launch.

Outcome

• Reduced manual task assignment effort for property managers
• HappyCo was awarded the Most Innovative Use of AI in 2025 in the real estate industry
• Demonstrated AI capability within the platform, opening the door for further AI features

My role: Led the empowered product team. Owned discovery, problem framing, prioritisation and cross-functional coordination with engineering, design and customer success.

Company: Think Tank Consulting Australia (Delivery and Technology Lead) • Custom GPT-based Q&A assistant

Problem

A functional team of 10 supported all government school sites across South Australia on matters related to service delivery policy, issue escalation and resolution processes. New team members frequently escalated common policy and process questions to the team lead, consuming senior capacity on queries that had well-documented answers buried in policy documents and procedural guides.

Discovery

Working within a consulting engagement, I identified this pattern as a quick win outside my core project scope. I observed the volume and nature of questions being escalated and confirmed that the majority related to established policies and standard procedures rather than edge cases requiring judgement.

What I delivered

A custom GPT-based Q&A tool deployed on the client's internal platform, trained on their policy documents and procedural guides. The tool allowed team members to get fast, accurate answers to common queries about service delivery policy, escalation pathways and resolution processes without needing to escalate to the team lead.

Outcome

• Deflected common policy and process queries from new team members, reducing interruptions to the team lead
• Recognised by the area executive as driving internal efficiencies
• Plans initiated to scale the tool to other functions across the organisation

My role: Identified the opportunity, scoped the solution, built and deployed the tool. This was a self-initiated value-add delivered outside my contracted scope.

Status: Live • Built with: Claude Code

Problem I was solving

Every time I received a renewal notice for insurance or energy, the price had increased. My process was always the same: go online, redo the same quote process multiple times with different providers, write down the results somewhere, compare them manually and then decide whether to stay or switch. It was tedious enough that sometimes I just paid the increase rather than going through the process.

I realised this was a common pattern. Most people overpay on renewals not because they don't care but because the effort to compare and switch is too high relative to the perceived saving.

What I built

Rinuly is a web app that gives households visibility over what is renewing, when and at what cost. Users can upload a bill or add details manually. Rinuly extracts the key information, tracks renewal dates and sends reminders before anything auto-renews. The goal is to give people the time and information they need to make an active decision rather than passively accepting a price increase.

Key design decisions

• No bank connections and no automatic switching. Privacy-first by design. Users stay in control.
• Upload-based input (bills, documents) with automatic extraction to reduce manual entry.
• Reminders timed to give users enough lead time to compare before renewal.

What it demonstrates

• Identifying a real user problem from personal experience
• Designing a product around a specific behavioural insight (effort-to-saving ratio)
• End-to-end execution: problem definition, UX, build, launch
• Using AI coding tools to move from idea to live product as a non-engineer

Status: Terminated after validation • Built with: Cursor, Codex and Claude Code

Problem I was solving

Credit card signup bonuses are a meaningful source of value for people who manage them actively. The challenge is tracking exclusion periods: the window after closing a card during which you are ineligible to earn the signup bonus again. These exclusion periods vary by institution and change over time. My process involved digging through old emails to find card closure dates, then checking each institution's website for the current exclusion period to calculate when I could reapply. I never set up a spreadsheet for it because the friction of maintaining one outweighed the perceived benefit each time I thought about it.

What I built

I used AI coding tools to build a functional web app that tracked card closure dates, mapped them against current exclusion period data from financial institutions and calculated the earliest eligible reapplication date for each product. The output was a simple timeline of available dates.

What I learned and why I killed it

Through testing with initial users, I discovered a fundamental engagement problem. The use case was too sparse to sustain an active product. Exclusion periods now average around 24 months, meaning a user who churns a card has no reason to return to the app for potentially two years. Users did not want to browse or check in. They wanted a notification when they became eligible. That meant engagement would amount to a handful of interactions per year at most.

The problem also did not expand naturally into adjacent areas. It stayed narrow: credit card churning for frequent flyer points. There was no broader day-to-day financial concern pulling users back regularly.

Given the combination of extremely low engagement frequency, narrow use case and limited expansion potential, I made the decision to terminate the project.

What it demonstrates

• Identifying a niche but real problem from personal behaviour
• Using AI coding tools to move from idea to functional product rapidly
• Validating with real users rather than assuming demand
• Disciplined decision to kill a project when the engagement model was fundamentally broken
• Product judgement: understanding that a solvable problem is not necessarily a viable product