Zhe Lim

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

What was broken

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

How I understood it

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, then analysed cycle time data to quantify where time was being lost and built the case for investment.

What I built

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.

What changed

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

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

What was broken

HappyCo's 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.

How I understood it

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 built

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

What changed

• 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, launch, onboarding, iteration. Partnered with engineering, product marketing and customer success.

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

What was broken

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.

How I understood it

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 consistent enough to automate and validated with customers that automated assignment would be trusted if the logic was transparent.

What I built

An AI-powered task assignment tool that automatically allocated tasks based on learned patterns from historical assignments, property attributes and team availability.

What changed

• Reduced manual task assignment effort for property managers
• HappyCo was awarded Most Innovative Use of AI in Real Estate 2025 (Inman)
• Demonstrated AI capability within the platform, opening the door for further AI investment

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

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

What was broken

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

How I understood it

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 built

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 without escalating to the team lead.

What changed

• Common policy and process queries deflected, 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. Self-initiated value-add delivered outside contracted scope.

Status: Live • Built with: Claude Code

What I was solving

Every renewal notice I received had increased in price. My process was the same each time: quote with multiple providers, compare manually, decide whether to switch. It was tedious enough that sometimes I just paid the increase. I realised most people overpay on renewals not because they do not care but because the effort to compare 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 upload a bill or add details manually. Rinuly extracts key information, tracks renewal dates and sends reminders before anything auto-renews. It also includes a platform that compares electric and gas services using the user's past usage to estimate savings against other current provider plans, and an automated agent that obtains quotes on behalf of the user. 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 with automatic extraction to reduce manual entry.
• Reminders timed to give users enough lead time to compare before renewal.
• Usage-based comparison so savings estimates reflect actual consumption, not generic averages.
• Automated quoting agent to remove the effort of contacting providers individually.

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
• Building an automated agent to handle a repetitive task on the user's behalf

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

What 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 accurately without maintaining a spreadsheet where the friction of upkeep always outweighed the benefit.

What I built

A functional web app that tracked card closure dates, mapped them against current exclusion period data and calculated the earliest eligible reapplication date for each product.

What I learned and why I killed it

Through testing with initial users I discovered a fundamental engagement problem. Exclusion periods now average around 24 months, meaning a user who was churning all possible cards would visit the application only a few times per year. The problem also did not expand naturally into adjacent areas that provided ongoing content for frequent flyer point accumulation and redemption. Given extremely low engagement frequency, a narrow use case I decided to sunset 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