Turn Control Center
V1 of an internal tool was shipped and nobody used it. Discovery for V2 found that users didn’t
want a better task queue. They wanted visibility into the work the system never tracked.
Roofstock is a real estate investment platform for buying, managing, and selling rental properties. Its property management arm, Mynd, is a full-service management company handling tenant placement, maintenance, rent collection, and day-to-day operations for thousands of single-family rentals across multiple markets. An internal operations team coordinates the inspections, repairs, vendor work, and owner approvals that keep those properties occupied.
A Job Too Big for the Tool
When a tenant moves out, a “turn” begins. That's the process of inspecting, scoping, repairing, and preparing the property for the next tenant. Turns are measured in days, and every day a property sits empty is rent the owner doesn’t collect. Mynd runs these across thousands of properties in multiple markets at once.
A turn moves through several stages and involves construction specialists, property managers, field dispatchers, general contractors, vendors, property owners, and incoming tenants.
At the center of all of it is the construction specialist (CS).
CSs manage an entire market’s worth of turns, and their job is to move them forward, remove blockers, and get properties to rent-ready status.
CSs needed a better tool for managing their work. A previous version of the Turn Control Center had shipped, but nobody used it, and the team wanted a V2.
Before thinking about V2 features, I wanted to understand why V1 had failed.
The team had built it without research or design, on the assumption that CSs needed a task manager. That assumption wasn’t unreasonable, since CSs juggle a lot of tasks. But task management turned out to be a fraction of the job.
CSs were working across at least six systems a day. They were also exporting Sigma reports into Google Sheets to audit their entire portfolio by manually adding notes, flagging issues, and tracking follow-ups in the spreadsheet.
When CSs don’t have the full picture, the work falls behind.
Turns run longer than they should and rental revenue drops.
Pre-leased units miss move-in dates and leases get canceled.
Vendors get dispatched on trips that turn out to be unnecessary.
If V2 failed the same way, the CS team would have no reason to trust a third attempt. The spreadsheet workaround told me V1 had been too narrow. Before designing anything, I needed to learn more about how CSs actually worked and what a new tool would have to do to be worth using.
What CSs Actually Needed Was Visibility, Not Tasks
The project came to me as a design request to build V2 of the Turn Control Center. The expectation was to start from V1’s requirements, add on the features CSs had asked for, and improve the UI. I proposed we start with a two-week discovery phase instead. If we designed V2 from V1’s feature list, we risked repeating the same mistakes with a better interface. I worked with the PM to make room in the timeline before we committed to a direction.
Semi-structured interviews over screen share, walking through real daily workflows, plus stakeholder input sessions. I interviewed CSs across a range of tenure levels and portfolio sizes, and CS leadership.
The task queue only showed a fraction of the work.
The queue surfaced tasks ready for direct CS action, so anything sitting in someone else’s queue, blocked by an approval or a quote, or moving without CS input was invisible. As one CS put it: “We’re very task heavy in here but we don’t see our full list of what we need to do.”
Turns get held up waiting on owners, vendors, institutional partners, or other internal teams. Those blockers don’t generate CS tasks, so the CS has to follow up manually. The turn clock keeps running while nothing happens and no system is tracking it.
CSs were also dispatching vendors to properties that already had an open service request or a duplicate turn. One CS described a vendor arriving to find a remediation that should have blocked the turn. A wasted trip, wasted money, wasted time.
“If you were covering for a teammate, [the AI summary] gives you that extra couple of minutes that you don’t have to do that extra digging.”
CS leadership
CSs didn’t need AI to summarize their own work.
We had started putting AI into our products, and the assumption going in was that AI summaries would be valuable to CSs. When I asked, experienced CSs said they didn’t need a summary of their own work. CS leadership thought it could be helpful when covering for someone while they’re out of office. That’s what moved AI to optional and off by default.
The synthesis reframed the entire project.
The original assumptions and the discovery findings diverged on nearly every point:
CSs need help prioritizing their task queue
CSs need visibility into their entire portfolio, not just tasks
“My Work” = tasks due today
“My Work” = everything I’m responsible for
AI summaries would be valuable
AI summaries only useful for coverage scenarios
Escalation workflow is the priority
Visibility into blocked items is the priority
Performance metrics are a priority
Operational visibility is a priority
Slack notifications are just noise
Slack notifications fill gaps that aren’t in the internal system
The project changed from designing a task management tool to designing a portfolio visibility and coordination platform. The question now was how to fit that into a single experience CSs would actually use every day.
From Four Tabs to One
The governing design principle was to show CSs everything they’re responsible for in one place, organized the way they already think about it. That was easy to state and hard to lay out. A single view had to carry a CS’s entire portfolio, including the blocked and invisible work the old queue never showed.
CSs already thought about turns by stage, reinforced by the “pizza tracker,” the stage progress bar already in the system. The design needed to match that model instead of introducing a new one.
The first structural concept was a four-tab layout: My Work (action-oriented), All Turns (portfolio table), Stage View (Kanban), and Metrics. In iterative reviews, the CS team’s feedback was to combine the to-do list and the turn overview, and organize by stage. That became My Portfolio, a single stage-based view holding task management and full portfolio visibility together.
That consolidation was the most important design decision in the project.
It eliminated tab-switching, put action and monitoring work in the same place, and matched the model CSs already had. It also created information density. A CS with a large portfolio could be looking at dozens of turns across five or six stages in one scrollable view. The four-tab concept had managed that by keeping action items and the full portfolio apart.
The solution was progressive disclosure through smart expand/collapse logic. A “Needs Attention” section sits at the top and stays expanded whenever it has items in it. It pulls turns from every stage, so urgent work stays visible even when individual stage sections are collapsed. Below that, each stage section expands by default if it contains tasks due today or blocked items, and collapses to a summary if everything is on track.
For the turn details, I didn’t design from scratch. I had recently built the Resident Experience Control Center (RX CC), which used a table and side panel pattern for a different internal team. Instead of reinventing the interaction model, I showed the RX CC pattern to CSs during discovery to test whether it fit their workflow. It did. One CS called it “definitely a better view.” Reusing a validated pattern reduced design risk and shortened the timeline, and engineering could build on infrastructure that already existed.
The related service request detection answered the wasted vendor trip directly. The system scans for duplicate turns and open service requests at the property, and surfaces a warning before a CS schedules work. Whether to hard-block scheduling or warn and allow was a decision I took to stakeholders since that involved operational consequences.
I created a decision document covering 17 open questions, from Needs Attention trigger logic to coverage view behavior to AI summary placement. I paired it with a Slack message for async review and a scheduled stakeholder meeting, so people had two ways to weigh in. I had recommendations for most of the decisions, but V1 had been designed with little input, and that isolation likely contributed to its failure. Getting stakeholders bought into the logic meant they were bought into what we shipped.
The same applied to the CS team. I committed early to showing them designs throughout the project instead of testing a finished design at the end, and they agreed to ongoing reviews. The users who most needed to trust this tool watched it get built.
Deferring “View As,” the coverage feature, to a fast follow was a real tradeoff. Coverage was one of the top pain points in discovery, and I knew CSs would ask about it. But scoping it into Phase 1 would have extended the timeline and delayed the core portfolio visibility everything else depended on. It was the first thing prioritized after the initial build, and it shipped shortly after.
I kept the AI scope small. The organization was investing in AI, but I let the research decide where it belonged. The AI turn summary was positioned as optional, aimed at coverage scenarios, which was the use case that came out of the interviews. QAI reassignment, when an AI agent hands work back to a human, became a Needs Attention trigger so those handoffs don’t sit unnoticed. Everything the research didn’t support stayed out.
What shipped was a single stage-based view organized the way CSs already thought about their portfolio, with the work they had been tracking by hand surfaced in the product itself. Every structural decision behind it had been reviewed with the CS team and settled with the stakeholders who own the process, so nothing arrived as a surprise. The one thing none of that could answer was whether CSs would use it, which is where V1 fell short.
What Adoption Looks Like the Second Time
V1 shipped and went unused, so the only meaningful test of V2 was whether CSs would choose to work in it.
Early adoption has been positive and the CS team is actively using the tool. V2 is being built and released incrementally instead of launching in one piece, so each release reaches CSs as it lands. That alone is a change from V1. It’s still too early to track the efficiency and turn-duration metrics we set as success criteria.
The stage-based portfolio view, Needs Attention, the turn side panel, and related service request detection.
The “View As” coverage view, prioritized first after the initial build.
Remaining scope is being built and released incrementally.
Three things hold up without a number attached.
The CS team is working in the tool. It was designed around how CSs actually work, validated with them iteratively, and brought stakeholders in from the start.
CSs can now see their full portfolio organized by stage, including the turns that generate no tasks and the blocked work that was invisible before.
What came in as a request for a better task manager shipped as a coordination platform that accounts for the full complexity of the role.
The discovery work produced artifacts that apply past this project. The workflow map and the decision framework carry into the next operations tool, and the interaction pattern is now proven with two internal teams.
If I could change one thing, it would be establishing quantitative baselines before starting design.
The qualitative research drove the right decisions and I’m confident in that. But I didn’t pull data on time spent manually auditing turns, or on V1 usage before the project began. So the impact case rests on adoption signals and qualitative feedback instead of a before-and-after comparison. The research told us what to build. Measurement set up earlier would have told us how much better V2 actually is.