top of page

3 weeks

Timeline

May 2026 - June 2026

PM + Designer

My Role

Research, design, data analytics

Live product

Stage

​Post launch optimisation

-44% data contamination

Impact

Reduced contaminated data by ~44%

01
The Brief

Growth marketing flagged a 40% drop-off on the newly launched product’s "Add rent details" screen, mid-way through the application flow.

 

They shared ~5 Mixpanel session replays showing users spending a long time on two fields on that page — Lease End Date and Lease Duration — and concluded those fields were the problem. Their ask: move the fields later in the flow to reduce friction.

First, the page displayed a milestone stat — "10,000 miles earned by RentlyPay customers" — prominently above the fold. The product hadn't launched yet. Nobody had earned anything. I completely understand that this is a marketing tactic to hook users into signing up. But beyond being factually false, it was exactly the kind of claim that would erode trust with the users we were asking to hand over large recurring rent payments.

RP Slice 1.png

Fake stat, erodes trust

Shipping Fast + Shipping Right

In August 2025, Rently assembled a small cross-functional team to quickly validate a new product idea: Rently Pay. The hypothesis was that offering the right perk could get tenants paying rent on our payment rails, with the long-term intent of upselling additional products to them down the line.

I was the product designer on the team. We had a few months, limited dev resources, and a mandate to get a signal fast — one we could communicate to investors.

02
The Investigation

Mixpanel only proved that users were dropping off on that screen; it couldn't tell me why. I felt that ~5 replays weren't enough to conclude those fields were the cause.

So I cold-called the users who'd dropped off on that screen to investigate.

Cold Call Findings

02 The Investigation P1.png

Two different stories came back.

  1. Some users had signed up looking for a rental listings marketplace (a legacy product we'd retired) and dropped off once they realized this wasn't it.
     

  2. Others came from a separate flow (colloquially referred to as the “I’m Still Looking” flow), meant for users without a lease who couldn’t apply for the product yet. They wanted to explore the product and see pricing, but the other flow didn’t allow them to do that. So they brute-forced their way into the application flow in the hopes they'd get to see pricing here.

That prompted me to go back into Mixpanel to check: how many of the drop-offs on the Add Details Screen had first gone through the “I’m Still Looking” flow? 16 out of 112 had, over a duration of 2 weeks, which meant ~15% of the drop off on the Add Rent Details screen weren't true drop offs. They were users from a different flow, muddying our application flow data.

02 The Investigation P2.png

I kept calling to validate these two findings and to check whether anything else would surface. Nothing else of note came up besides real reasons like: the user's circumstances changed and they are no longer renting etc.

What I can't say with confidence is which of the two reasons was bigger overall — cold-call samples are self-selected by who picks up, and that's not something I can correct for. So I treated them as two validated, co-equal findings rather than ranking them.

02
The Solutions

Nobody reported friction with the two fields marketing had flagged, so I pushed to leave them where they were in the meantime, and solve for the pain points we knew existed.

Solution for users who sign up expecting retired product

I handed growth marketing a list of affected users and their entry points into the flow. With this, they can hopefully nip the problem in the bud by removing outdated ads and blog posts that promoted our retired marketplace product.

Despite this issue not stemming from a product root cause, I also designed a low-lift fix at the application entry point to encourage users looking for the marketplace to self-select out before sign up. 

Callout to help users self-select out

02-The-Solutions---Self-Selecting-Out.png

Solution for users looking to explore product and see pricing

For users who didn’t have a lease ready (and were hence not ready to apply for the product), but wanted to see pricing, I designed a dashboard card that allowed them to access pricing information without entering the main application flow. 

I did consider other solutions, but discussions with the dev team convinced me this was the right balance between dev effort and business impact at that point in time.

02-The-Solutions---Dashboard-Card.png

Card on dashboard leads to pricing calculators on product landing pages

03
Outcome + Reflection

03 Outcome.png

After the dashboard card launched, the contamination rate of the main application flow  roughly halved.

I’m still checking with growth marketing on why traffic in the “after” period was noticeably higher than “before." But the rate itself, not just the raw counts, tells the same story either way: fewer of these users needed to misrepresent their lease status to get what they came for.

I consider this a win on two fronts: we gave “I’m Still Looking” users a legitimate way to see pricing, and cleaned up a data quality problem in our main application flow, with a relatively low-effort fix.

The lesson wasn't about either fix — it was about the importance of diagnosing real causes based on evidence. Marketing had a plausible hypothesis, backed by real replay data, pointing at two specific fields on the screen. But that data couldn't definitively prove the fields were the reason people were dropping off.

The actual cause had nothing to do with the screen it appeared on. If I'd trusted the first hypothesis and shipped what was asked for, I'd have redesigned two fields that were never the problem, and missed the two things that actually were.

⟡ Footnote:
A UX Improvement On The Side

The original session replays also revealed an unrelated insight: one of the fields on that page involved a calendar date picker component, and was genuinely fiddly to fill in. Mixpanel replays showed users unaware that they could click on the year to change it, and were clicking “Next month” upwards of 10 times to get to their Lease End Date.

It wasn't why people were dropping off, but it was worth fixing on its own merits, so I redesigned the date picker component to keep location of "Next month" consistent on each month's view. We also added functionality allowing users to type their end date instead of selecting it using the component.

In the two weeks following the redesign, 174 of 219 users progressed past "Add rent details" (79.5%), compared to 176 of 222 before (79.3%). No surprise that this fix didn't move the numbers: this was never the driver of the drop-off, so fixing it in isolation would not change anything.

Thanks for reading!

Diagnosing 
Before
Designing

Growth marketing came to me with a concern: there was a big drop off point in our newly-launched product's application flow. They had Mixpanel replays to back them up, and suggestions on what we should do about it.

My job was to execute. But before I could do that, I needed to make sure we'd accurately identified the reason for the drop-offs.

bottom of page