Putting a live Turn platform to the test.

AMH manages single-family rental homes at national scale. Every tenancy that ends triggers a Turn: a move-out inspection, a condition assessment, vendor work, multi-level cost approval, and a final make-ready before the home goes back on the market. The business runs this against a hard target — market-ready within ten days of the move-out inspection.

That clock runs across at least six tools: the core platform (4Services and 4Enterprise), the Primo field app and Primo Web for inspections, Power BI for property status, and a legacy CRM — with vendor communication happening entirely outside all of them, by phone, text and email. Data is carried between systems by hand.

The platform was already live. What it had largely skipped was validation with the people using it. This research was that validation, done after the fact.

I spent four days on the ground in Greensboro doing contextual inquiry — watching real work rather than asking people to describe it from memory. Two days shadowing two field turn technicians in vacant properties, and two days alongside two field managers in the back office.

The aim was to understand the perfect scope and how it is really carried out, how technicians use the Primo field app, the challenges they hit during inspection, how they coordinate with vendors, and how field managers operate across their stack of tools. I clustered what I gathered with thematic analysis — grouping observations into themes, summarising each, and translating them into candidate actions.

The problems sorted into five themes:

That distinction changes what the work is for. A single-market bug list invites a round of fixes. A cross-market pattern invites a roadmap — and it gives a small, single-market sample more weight than its size alone would earn. The same problems in a second market are worth more than more interviews in one.

A Field Manager’s job is to move properties through the Turn and protect the ten-day clock. That means deciding what can move next, which technician should take it, whether the property is actually ready, and whether the resident, vendor, inspection and approval context is clear enough to commit the work.

That decision was spread across systems. Field Managers moved between Power BI for property status, 4Enterprise for scheduling, Primo Web for inspections and cost approval, and email or text for vendor and resident coordination. To build a single day’s plan, they needed condition issues, work order notes, resident contact details, preferred visit times, technician availability and market-specific recurring tasks — but that context lived across different tabs, tools and conversations.

One finding that landed.

One detail made the problem especially visible: the resident’s preferred visit time was present on the Work Order screen, but hidden behind a hover state. It was technically available, but not visible at the moment the Field Manager needed to commit the work. That made it easy to miss the preferred window and schedule against the wrong resident expectation.

I surfaced this during the contextual enquiry, and it directly informed the final screen design.

Before any of this field work, I had built a provisional field turn technician persona from institutional knowledge — what the business believed a technician's day looked like.

Greensboro was where I tested it against reality. The field work confirmed parts of it, corrected others, and surfaced things the provisional version never had — the connectivity workarounds, the lockbox-and-occupied-property escalations, and the “training task” used as a workaround to schedule work the system had no proper type for (quietly destroying the tracking metrics in the process). I turned what I learned into a validated Day-in-the-Life card, mapping the technician's real day system by system, need by need.

That is the honest arc of this section: an assumption I had documented, then went and tested, then corrected — so future stories and requirements start from how the work actually happens, not how we imagined it.

As part of the contextual enquiry, I mapped the Primo Web and Primo Mobile journey within the wider Turn lifecycle, showing how work moved between Field Managers, Field Turn Techs, In-House Maintenance and External Vendors.

The map made the handoffs visible: where inspections started, where approvals stalled, where vendor coordination left the system, and where mobile field activity failed to translate cleanly back into operational progress.

This journey mapping was later used by AMH’s internal design team to inform the redesign of an internal version of Primo, helping reframe the product from disconnected web and mobile screens into an end-to-end operational workflow across roles, tools and decision points.

A discovery that ends with a deck is a discovery that gets forgotten. I recommended a continuous-discovery cadence: monthly engagement with business stakeholders to keep prioritising the medium- and longer-term roadmap against business direction, and ongoing technician and field manager interviews across markets to keep the picture current.

That second part wasn't only a recommendation — follow-on technician interviews across other markets did go ahead, which is the thread that carried this work past the readout.

What this work delivered wasn't a shipped feature or a number — it was a prioritised, evidence-backed roadmap across three horizons and a field-validated persona the wider team could build from. The recommendations from this research were integrated into the product.

What I'd hold honestly: the sample was small and single-market — four people over four days. What gives me confidence in it is the Orlando overlap; the same themes in a second market are worth more than a bigger sample in one. The largest recommendations — replacing Primo, consolidating the stack — are programmes that need breaking down before anyone could commit.

And the wider lesson sits one level up. This was research run after a platform had already shipped largely untested. It found real, fixable problems — but most were the kind earlier validation would have caught before they reached the field. The honest takeaway isn't about this build; it's about where validation belongs in the lifecycle.