Zhe Lim

Company: HappyCo
Role: Product Manager, shared platform and unified experiences

What was broken

Enterprise customers needed to integrate HappyCo with external property management systems such as RealPage, Yardi and Entrata during onboarding. Customer data needed to flow correctly before they could realise the full value of the product.

Much of the integration setup had historically relied on engineering. As customer launch volume increased this became a bottleneck, slowing onboarding, consuming engineering capacity and creating unnecessary manual handoffs.

How I understood it

I worked with Engineering, Customer Success and launch teams to understand the existing workflow, identify where delays occurred and determine which parts of the process were repeatable enough to turn into a product experience.

The goal was not simply to make setup faster. We needed to allow non technical launch team members to complete integration setup safely while maintaining confidence in the integrity of enterprise customer data.

What I built

We started with a focused internal experience covering the most common integration path so launch teams could complete setup without requiring engineering support for every customer.

I prioritised the roadmap using upcoming enterprise launches, customer volume, integration coverage and delivery risk. I also supported migration planning from the existing architecture to the new platform experience including staged rollout, data integrity considerations and fallback planning.

What changed

• Customer time to value reduced by approximately 55 percent.
• Non technical launch teams could complete the most common integration setup independently.
• Engineering dependency reduced for repeatable onboarding activities.
• The onboarding experience became more scalable with fewer manual handoffs.

My role: Owned discovery, product definition, prioritisation and delivery and partnered with Engineering, Customer Success and launch teams throughout.

Company: HappyCo
Role: Senior Product Manager

What was broken

The multifamily property industry was moving towards centralised maintenance where technicians worked across multiple properties rather than remaining assigned to a single location.

That created a more complicated allocation problem. Maintenance leaders needed to triage large volumes of work, prioritise urgent issues, match technicians based on capability and location, reduce travel time and still maintain a good resident experience.

How I understood it

Centralised maintenance had been established as a strategic direction for HappyCo. My role as Product Manager was to understand the customer problems within that direction and lead the team from discovery through delivery.

I worked with customers in the United States alongside Customer Success, Design, Engineering, Product Marketing and leadership. Discovery showed that task assignment involved far more than simply finding an available technician. Decisions also depended on urgency, skills, resident consent, appointment windows, property proximity, travel time and fairness around older unresolved work.

What I built

We created a unified work board providing portfolio level visibility, prioritisation, technician matching and AI assisted assignment recommendations.

One of the most important product decisions was keeping the user in control. Managers could preview recommendations, rearrange assignments before committing them and undo a committed allocation for a short period afterwards. Those controls added complexity but reduced the risk of asking users to trust a recommendation they could not understand or change.

What changed

• Prototypes were tested with customers before launch.
• The capability initially launched to six enterprise innovation customers.
• Usage grew at consistent double digit rates week on week during the first few months.
• The experience became part of customers' daily maintenance workflows.

HappyCo also received industry recognition for innovative use of AI during this period.

My role: Led the product team through discovery, problem framing, prioritisation and delivery and partnered across Design, Engineering, Customer Success, Product Marketing and leadership.

What I was solving

People often book holidays months in advance because anticipation is part of the value of travel. The trip becomes something meaningful to look forward to during ordinary routines. Yet once it is booked that excitement can disappear into a confirmation email, calendar entry or distant date.

Most travel products focus on searching, booking, planning or managing a trip. lookfwdly focuses on a different moment. It exists to make a future trip feel closer.

What I built

I independently took lookfwdly from the initial product idea through design, development and launch on the iOS App Store.

A user adds a future destination and departure date. The product then creates a simple daily experience around the upcoming trip through a countdown, destination imagery, short glimpses and Home Screen widgets.

The product deliberately avoids becoming another travel administration tool. There is no complex itinerary builder, booking engine, packing workflow or travel management dashboard. That scope is intentional. The product is about anticipation rather than administration.

How I am developing it

Launching the product changed the problem from building software to understanding whether people discover it, use it and return.

I use Mixpanel to monitor acquisition, engagement and conversion and continue to run small experiments around the experience and distribution. I have also built an AI assisted content workflow using coding agents and social media tooling to help create and distribute content across channels while retaining human review before anything is published.

What I have learned

A narrow product requires more product judgement rather than less. When there are only a few features each decision carries more weight. Imagery, hierarchy, language, widgets and seemingly small interactions materially affect whether the experience feels meaningful or disposable.

The target user also became clearer through the process. The strongest user is not simply somebody with a future holiday. It is somebody who gets genuine emotional value from having the next trip to look forward to.

AI tooling has materially increased how quickly I can build and experiment but it has not removed the need for product judgement. The difficult decisions remain what to build, what not to build, what to test and what evidence is strong enough to change direction.

What it demonstrates

• Moving from an emotional customer insight to a focused consumer product.
• Taking a product independently from idea through design, development and App Store launch.
• Product scope and prioritisation.
• Hands on use of product analytics after launch.
• Acquisition and distribution experimentation.
• Practical use of AI assisted development and workflow automation.

Company: HappyCo
Role: Product Manager

What was broken

HappyCo primarily served property operations teams but there was an adjacent opportunity within asset management. Customers needed better ways to understand asset condition, plan future investment and make portfolio level decisions.

This was not simply another feature opportunity. It represented a different customer segment and a potential new product line.

How I understood it

I led discovery with prospective customers and internal teams to understand existing workflows, where current approaches were inadequate and what would need to be true for customers to adopt another product within the HappyCo ecosystem.

The early challenge was balancing ambition with the minimum experience necessary to validate demand and support the first enterprise customers.

What I built

I led product strategy and discovery for the new offering and supported the product through definition, delivery, go to market and onboarding.

I designed the onboarding approach for the initial six enterprise customers and worked across Engineering, Product Marketing and Customer Success through launch.

What changed

• The first six enterprise customers were successfully onboarded.
• The product opened an adjacent customer segment for HappyCo.
• The first cohort contributed approximately 7 percent additional top line revenue.

My role: Led discovery, product definition, launch planning, onboarding and iteration.

Company: Think Tank Consulting Australia
Role: Delivery and Technology Lead

Details intentionally anonymised due to client confidentiality.

What was broken

An internal government team received repeated questions about policies and processes from other business areas. The information usually existed but was distributed across internal material and required experienced team members to repeatedly interpret and explain it.

How I understood it

While leading discovery across a broader technology workstream I explored how existing approved Gen AI capabilities could address practical operational bottlenecks.

Rather than beginning with a new technology procurement I looked first at capabilities the organisation already had access to and whether those could be configured around the problem.

What I built

I prototyped an internal Gen AI assistant using approved enterprise tooling and configured it around existing source material and real questions received by the team.

I compared responses with answers provided by experienced team members then refined source material and prompting based on the differences and stakeholder feedback.

What changed

The experiment produced an internal MVP and demonstrated a practical way existing Gen AI capability could be applied within a governed environment.

It also provided evidence for broader discussions about how AI could reduce repeated low value work and improve access to internal knowledge.

My role: Identified the opportunity, proposed the experiment, shaped the MVP and worked with stakeholders to test and refine the approach.

What I was solving

Insurance renewals repeatedly created the same problem. Prices increased and checking whether switching made sense required gathering information, completing multiple quotes and comparing the results manually.

The hypothesis was that people often overpaid because the effort required to compare providers outweighed the perceived saving.

What I built

Rinuly began as a renewal tracking product showing what was renewing, when it was renewing and what it cost.

I then built a functional automated quoting agent to test whether the most painful part of the experience could be handled on behalf of the user. Alongside the product I spoke directly with prospective users and manually completed comparisons to understand what people valued and what they were actually willing to pay for.

What I learned and why I stopped

The customer problem was real but the underlying business model was considerably weaker. Users were interested in paying from realised savings but generally did not value a service that confirmed their existing policy was already competitive.

This created difficult unit economics because the service still incurred a cost even when no saving was generated. Automated quoting also introduced trust issues. Relatively small differences in dates, assumptions or inputs could change a quote and create doubt about whether an automated result could be relied upon.

As the true cost and complexity became clearer the economics no longer justified continued investment. I stopped development.

What it demonstrates

• Testing willingness to pay rather than assuming demand.
• Validating both the customer problem and the economics of delivering the solution.
• Building enough technology to test the riskiest assumptions.
• Being willing to stop when the evidence no longer supports further investment.

What I was solving

People actively managing credit card signup bonuses need to know when exclusion periods expire before they can qualify for another offer.

The existing workflow often involved searching old emails, checking current bank rules and manually calculating future eligibility dates. I experienced this behaviour myself and wanted to understand whether removing that friction created a useful standalone product.

What I built

I built a functional web application that tracked card closure dates, mapped those dates against exclusion period rules and calculated the earliest eligible reapplication date.

What I learned and why I stopped

Testing exposed a fundamental engagement problem. Exclusion periods were often around two years which meant even highly engaged users might only need the product a handful of times each year.

I explored whether the product naturally expanded into adjacent points and rewards use cases but could not identify an extension strong enough to create meaningful ongoing engagement.

The original problem could be solved but the engagement model was too weak to justify continuing. I stopped development.

What it demonstrates

• Finding product opportunities through observed behaviour.
• Moving quickly from idea to functional product.
• Testing with real users rather than assuming recurring demand.
• Understanding the difference between a solvable problem and a viable product.
• Killing a product when the underlying engagement model does not work.