Zhe Lim

Company: HappyCo
Role: Product Manager for shared platform and unified experiences
Context: SaaS platform for managing commercial real estate in the United States

What was broken

Enterprise customers needed to integrate HappyCo with external property management systems such as RealPage, Yardi and Entrata during onboarding. This was a critical step because customer data needed to flow correctly before they could get full value from the product.

For a long time, much of the setup process was handled manually by engineering. That worked when launch volume was lower but became a bottleneck as HappyCo scaled. It slowed customer launches, consumed engineering capacity and created risk around data quality during onboarding.

How I understood it

I was Product Manager for a shared platform team responsible for admin persona experiences, unified web experiences and customer integration setup. I worked with engineering, customer success and launch teams to understand the manual setup process, where delays occurred and which steps were repeatable enough to productise.

The goal was not just to make setup faster. The goal was to create a scalable platform experience that allowed non technical launch team members to complete integration setup safely while reducing risk for enterprise customers.

What I built

We started with a focused internal tool for the most common integration path. This allowed launch team members to complete end to end setup without relying on engineering for every customer.

From there, I prioritised the roadmap based on upcoming enterprise launches, property management system coverage, customer volume and delivery risk. I also supported planning for the migration from the old architecture to the new platform experience, including staged rollout, data integrity risk management and fallback planning.

What changed

• Customer time to value reduced by approximately 55 percent.
• Non technical launch team members could complete setup for the most common integration.
• Engineering dependency reduced for repeatable onboarding work.
• The onboarding process became more scalable and less exposed to manual handoffs.

My role: Owned discovery, product definition, roadmap prioritisation and delivery. Partnered with engineering, customer success and launch teams throughout.

Company: HappyCo
Role: Senior Product Manager
Context: AI assisted task assignment for centralised maintenance workflows

What was broken

The multifamily property industry was moving toward centralised maintenance, where technicians worked across multiple properties rather than a single site. This created a more complex allocation problem for maintenance leaders.

Customers needed to triage large volumes of maintenance tickets, prioritise urgent work, match tasks to technicians based on skillset and location, reduce travel time and still deliver a good resident experience.

How I understood it

HappyCo leadership had set centralised maintenance as a strategic direction. As Product Manager of an empowered product team, my role was to understand the customer problems within that direction and lead the team from discovery through to delivery.

I worked with customers, customer success, design, engineering, product marketing and leadership to understand how maintenance work was being managed and what made centralised maintenance difficult to operationalise.

Through discovery, we found that assignment decisions involved urgency, technician capability, resident consent to enter apartments, appointment windows, property proximity, travel time and fairness rules around prioritising older issues first.

What I built

We created a unified work board with portfolio level visibility, prioritisation, technician matching and smart assignment recommendations.

A key decision was to keep users in control of the AI assisted allocation. We designed a preview mode so managers could review and rearrange recommended assignments before committing them. We also introduced a short undo period after commitment.

This added technical complexity but was necessary to build user trust and support adoption given the hesitancy around AI.

What changed

• We tested prototypes with customers in the United States and launched first to six enterprise innovation customers before broader release.
• Usage grew at consistent double digit rates week on week for the first few months.
• The feature became part of core daily maintenance workflows for users.
• This work directly contributed to HappyCo receiving an industry award for the Most Innovative Use of AI.

My role: Led the product team through discovery, problem framing, prioritisation and delivery. Partnered with design, engineering, customer success, product marketing and leadership.

Status: In development. Built and tested on iPhone with TestFlight as the next milestone.
Built with: SwiftUI, Xcode, CloudKit, WidgetKit, App Groups, App Store Connect, Codex, ChatGPT and AI image generation.

What I was solving

People often book holidays months in advance because the anticipation itself has value. The trip becomes something concrete to look forward to during ordinary routines and a reminder that something good is ahead.

The problem is that once a trip is booked, the excitement often fades into the background. The holiday is real but it becomes buried in a confirmation email, calendar entry or vague mental countdown.

Most travel products do not serve this moment. They help people search, book, plan, compare, navigate or manage details. Those tools are useful but they usually create more tasks.

lookfwdly solves a different problem. It makes the future trip visible in daily life. The goal is not to help the user plan more. The goal is to remind them that something good is coming.

What I built

I built a native iOS app that lets a user add an upcoming trip by entering a destination and leaving date.

The app creates a visual countdown experience around that trip. The user sees how many days are left, a destination image and a short daily glimpse. They can also add Home Screen widgets so the trip stays visible without needing to open the app.

The core loop is simple:

1. Add a trip
2. See the countdown
3. See a beautiful destination image
4. Keep the trip visible through widgets
5. Return later for another glimpse

The product is deliberately narrow. There is no itinerary builder, flight tracking, hotel storage, packing list, price alert system or travel planning dashboard.

That was a conscious product decision. Adding those features would make the app more complete but less focused. lookfwdly is about anticipation, not travel administration.

The design became a major part of the product. Because the app is simple, it has to feel visually right. The countdown placement, imagery, typography, widget hierarchy, button placement and carousel behaviour all matter. Design taste is not polish in this product. It is part of whether the product works.

What I learned

The biggest lesson was that a simple product needs sharper judgement, not less judgement.

When there are only a few features, every decision matters more. A weak image, awkward button placement or overloaded widget can make the whole product feel cheap. A calm layout, strong image and clear countdown can make the same product feel meaningful.

I also learned that the target user was not simply someone travelling. The stronger user is someone who uses future travel as emotional fuel. They want a reminder that something meaningful is ahead.

AI tools helped move quickly but did not replace product judgement. ChatGPT and Codex helped with product thinking, implementation instructions, code iteration and content generation. But the important decisions still required human judgement: what to build, what to remove, what felt tasteful and what the product should not become.

The hardest discipline was resisting travel planning features. Many of them would be useful but they would pull the app away from its purpose.

What it demonstrates

lookfwdly demonstrates the ability to identify a real user behaviour and turn it into a focused product experience.

It shows disciplined scope judgement, especially the ability to avoid adding obvious features when they weaken the product strategy.

It shows design judgement because the success of the app depends heavily on taste, visual hierarchy and emotional clarity.

It also demonstrates practical AI assisted product development. AI tools helped accelerate the build but the product direction, tradeoffs and quality bar still required human judgement.

The strongest thing this case study demonstrates is the ability to turn a vague emotional insight into a working product with a clear point of view: make the future feel closer, more beautiful and more worth looking forward to.

Company: HappyCo
Role: Product Manager
Context: New product line for multifamily portfolio asset management

What was broken

HappyCo served property operations teams but had an adjacent opportunity in asset management workflows for multifamily portfolios. Customers needed better ways to understand asset condition, plan investment and manage portfolio level decisions.

The opportunity was not just another feature. It was a new customer segment and a new product line.

How I understood it

I led discovery with prospective customers and internal teams to understand the asset management workflow, where existing tools fell short and what would make customers adopt a new product inside the HappyCo ecosystem.

I focused on identifying the minimum product experience needed for the first enterprise customers while keeping the launch narrow enough to deliver.

What I built

Happy Asset, a new product line within the HappyCo platform.

I owned the lifecycle from discovery and requirements definition through to launch planning, go to market support and onboarding. I designed and executed the onboarding approach for the first six enterprise customers.

What changed

• Happy Asset contributed approximately 7 percent new revenue.
• The first six enterprise customers were onboarded.
• HappyCo opened a new customer segment and product line.

My role: Owned discovery, definition, launch planning, onboarding and iteration. Partnered with engineering, product marketing and customer success.

Company: Think Tank Consulting Australia
Role: Delivery and Technology Lead
Context: Government transformation program

Details intentionally anonymised due to client confidentiality.

What was broken

An internal government team was receiving repeated policy and process questions. Many answers already existed in internal documents but were hard for newer staff to find and apply quickly.

This created avoidable reliance on experienced staff and team leads for questions that were often variations of the same underlying issue.

How I understood it

While leading discovery for a broader technology workstream, I explored how the organisation was using Gen AI and whether it could help with practical bottlenecks I was seeing.

I found that the organisation already had access to approved internal Gen AI tooling that met its privacy and security requirements. The opportunity was to use that existing capability in a controlled and low cost way rather than start with a new technology build.

What I built

I prototyped a secure Gen AI assistant configured with source documents, real example questions and refined prompts using approved internal tooling.

I tested the assistant against real questions and compared its answers to responses prepared by experienced staff. I then refined the source material and prompts with stakeholder input until the responses were more useful and consistent.

What changed

• The assistant was developed as an MVP for internal team use.
• It helped staff find guidance faster.
• It helped reduce reliance on senior staff for repeated process questions.
• It provided a practical example of how Gen AI could be used safely in a governed environment.
• It also informed thinking for future digital service design.

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

Status: Sunset after validation.
Built with: Claude Code

What I was solving

Every renewal notice I received seemed to increase in price. The process to check whether I should stay or switch was always the same: gather details, quote with multiple providers, compare options manually and decide whether the saving justified the effort.

The insight was that many households overpay not because they do not care but because the effort to compare feels too high until the price increase is obvious.

What I built

Rinuly started as a renewal tracking product that gave households visibility over what was renewing, when it was renewing and what it cost. Users could add or upload renewal information, track renewal dates and get reminders before auto renewal.

I also built a functional automated quoting agent to test whether the most painful part of the workflow could be handled for the user. Alongside the product build, I spoke with prospects and users and manually ran comparison quotes to understand what people would actually value.

What I learned and why I killed it

The problem was real but the business model was harder than the product problem.

Users were open to paying as a percentage of savings but did not see value in paying if no saving was found, even if the service confirmed they already had a competitive policy. That meant the service cost needed to be materially lower than the savings generated.

The automated quoting workflow also had trust and unit economics challenges. Quotes could differ slightly due to start dates, timing, insurer assumptions or small input differences. Even small differences created questions about whether the result could be trusted.

Insurance quoting also required deeper question sets than expected. The agent worked best when the customer situation was straightforward but the edge cases made reliable automation harder and more expensive to run.

As model usage costs became clearer, the economics became less attractive. Running the agent through multiple quote paths created a cost base that was difficult to justify unless the savings were meaningful and predictable. Given the trust challenges, service cost and uncertain savings outcome, I decided to sunset the product.

What it demonstrates

Rinuly demonstrates the ability to move from personal problem to working product, then test whether the product can become a viable service.

It shows the importance of validating not only whether users have a problem but whether the solution can be delivered economically.

It also shows discipline in killing a product when the cost to serve, trust requirements and willingness to pay do not support a sustainable model.

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 outweighs the benefit.

The original insight came from my own behaviour. I would search emails to find card closure dates, check bank websites for current exclusion period rules and calculate when I could reapply. I knew the problem existed because I was repeatedly doing it manually.

What I built

A functional web app that tracked card closure dates, mapped them against 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 were often long, commonly around 24 months, which meant even active users would only need to check the product a few times per year.

The problem also did not naturally expand into adjacent areas that would create ongoing engagement around broader points earning and redemption behaviour.

Given the narrow use case and extremely low engagement frequency, 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 quickly.
• Validating with real users rather than assuming demand.
• Making a disciplined decision to kill a project when the engagement model was fundamentally broken.
• Understanding that a solvable problem is not necessarily a viable product.