Project Unify
Leadership asked if our two products for property owners should merge. My research found they could, as long as we tailored the experience for landlords who self-manage, and investors who want oversight without the operations.
Roofstock is a real estate investment platform for buying, managing, and selling rental properties. It has two products for property owners. Stessa is a self-management tool for hands-on landlords who run their properties themselves. Mynd is a full-service property management company for passive investors who would rather delegate. Both serve property owners, but they had always operated as separate experiences.
Two Products or One?
On paper the two products looked like obvious candidates for a merge. They served the same market and solved adjacent problems. Side by side, they differed in who used them, how often, on what device, and how each one made money.
Leadership asked the product team whether these two products should share a unified owner experience. The thinking was that owners would benefit from a single portfolio view, regardless of how each property was managed. Continuous discovery had already shown owners juggling spreadsheets, property management software, rent collection services, and accounting tools. A unified platform could cut that friction and open cross-sell paths between the two products.
Self-Management
Full-Service ManagementThe cost of guessing wrong ran in both directions.
Unification would take a large engineering investment, and getting it wrong meant degrading two working products to build one mediocre one. Commit too early and we could build the wrong thing at scale. Wait too long and competitors could fill the gap. Leadership was open to either direction. We had already run multiple design sprints on the concept. What we needed was validation.
Leadership needed to decide on a costly, hard-to-reverse merge, and there was no evidence yet that owners from either segment wanted one.
I participated in those design sprints and helped shape the initial unified concept. After the sprint phase, I met with users from both segments to understand their current experience and test a refined prototype, then came back with a recommendation.
How Each Segment Worked Today
I needed to understand how Stessa and Mynd users actually worked. That meant how they monitored their properties, where they ran into issues, and what mattered enough to pull them into the product, rather than what they’d ask for in a feature request.
I designed a 15-participant moderated interview study. Each session had two parts, a conversation about the participant’s current experience with the product, then a think-aloud walkthrough of the prototype. The first half told me what users needed. The second showed me how they responded to what we'd built. Blending them would have made it impossible to tell whether a reaction came from a real unmet need or just from my design.
The two segments worked in almost opposite ways.
Six of seven Stessa users were desktop-first. They logged in monthly, mostly for transaction tracking and tax preparation. Six of eight Mynd users were mobile-first and notification-driven, logging in only when something needed their approval. It was one audience, but in practice they used the product on different devices, at different frequencies, for different reasons.
Stessa users reported syncing failures with banks, credit unions, AppFolio, and mortgage providers. Some shared they were abandoning features entirely because they couldn’t trust the numbers. It wasn’t one of my research objectives, but it may have been the most important thing I found. A unified product can be well designed and well organized and still fail if the data underneath it is wrong.
“If the money doesn’t add up, I will leave.”
Stessa user
A Prototype Built to Test, Not Sell
Every component in the prototype was a hypothesis about what users needed and how they expected it to work. We knew we wanted to put the idea in front of owners before going further, so the question wasn’t whether to test but how. I designed the prototype for mobile because the constraint forced prioritization. On a small screen you can't show everything at once, so every module had to earn its place.
I put approvals, maintenance, and urgent notifications above the financial data to test whether users prioritized doing over browsing. Across both segments, participants preferred action first and treated analytics as secondary. What they wanted to act on differed. Mynd users looked for approvals, Stessa users looked for transactions to categorize.
Here is a summary of your portfolio’s financials:
This contribution replenishes the reserves and covers pending costs.
Dead oak blocking the driveway.
Ants trailing from the AC to the kitchen.
Behavior told me more than any interview question could.
Instead of guessing at the perfect default, I built a dashboard users could reshape by toggling components on or off and reordering them by priority.
Participants took to it immediately, and what each group kept or turned off split along segment lines. It confirmed the two wouldn’t agree on a single layout. It also turned an abstract question, what matters most to you, into something I could watch them answer.
The dashboard showed the whole portfolio by default. Users could narrow it to a group of properties or a single one, and every figure updated to match. Tapping a month on a chart broke it down into where the money went. Participants in both segments found the filter without prompting and used it the same way, starting broad and narrowing to a single property. The standout was the net cash flow by month chart, which 11 of 15 participants singled out, because it let them spot anomalies like missing rent at a glance and then dig into why.
The signal was participants wanted AI, just on their own terms.
Users liked the idea of proactive intelligence, but how it showed up mattered. Placed at the top, the AI insights section read as promotional, like the product was selling to them rather than helping. I recommended folding it into the customization feature as an opt-in, so users could pull it up when they wanted it instead of having it there by default.
The segments agreed on transparency, action over analytics, customization, and automation that does useful work. Where they diverged was everything those principles get applied to, from workflow and information hierarchy to device and how often they showed up. Forcing both into one interface would have meant compromising each.
Unify the Product, Not the Experience
Leadership had asked one question, should the two products merge? Every feature tested well, so on its own the answer was yes. The segment data changed what yes should mean. The question was no longer whether to unify, but what should be shared and what should stay separate.
The single-product vision still made sense, but a single experience didn’t.
One dashboard would be too cluttered for the Mynd user who just wants to approve something and too sparse for the Stessa user reconciling a month of transactions. But a shared product didn’t have to mean an identical screen. It could be one interface with the same look and feel, showing different components depending on who was looking at it.
Customization let users in both segments build their own.
That worked cleanly until you got to users who did both, self-managing some properties and delegating others. They belonged to both segments at once, so a rule that showed Stessa users one thing and Mynd users another had nothing to go on. Customization answered it. Instead of the product guessing which experience someone needed, it let them build their own. We could still set a sensible default for each segment, and any user could reshape it into something that fit how they actually worked.
The unification question could wait. The data problem couldn’t. Data syncing was broken often enough that Stessa users had stopped trusting what they saw, so I made the case for prioritizing the fix. A unified product built on numbers users already doubted would inherit the problem.
The decision is still open, and now it rests on evidence.
The recommendation was clear, but the decision wasn’t mine to make. Leadership is still weighing whether and when to pursue unification. The research replaced assumption with evidence, and the company has a real basis for the call whenever they make it. If they do unify, the plan is already there: one product, shared components, and a default for each segment that users can reshape.