Skip to content
All research
Product Development

Professional Perspective

What Housing Operations Can Teach Technology Product Teams

An impressive feature is not necessarily a useful product.

Author
Azmera Abraham
Publication date

Summary

Technology products are often evaluated by what they can do, but an impressive feature is not necessarily a useful product. Drawing on experience in real estate and housing operations, this perspective argues that product teams should study the work before designing the feature, treat exceptions as requirements, recognize that good data begins with good processes, and design for users with different responsibilities. It is an experience-based perspective, not a formal usability study.

Technology products are often evaluated by what they can do: automate a task, generate a report, summarize information, or reduce the number of steps in a workflow.

But an impressive feature is not necessarily a useful product.

Working in real estate and housing operations has shaped how I think about that distinction. The people using a system are often balancing competing deadlines, incomplete information, regulatory requirements, and the practical needs of clients or residents.

A product that looks efficient in a demonstration may introduce complications when it encounters those conditions.

Start with the work, not the feature

Consider a routine housing operation such as coordinating a lease renewal.

On paper, the process might look straightforward: identify an upcoming expiration, contact the relevant parties, prepare documentation, and record the outcome.

In practice, the work may depend on communication preferences, approval timelines, missing documents, changing circumstances, and responsibilities shared across multiple people.

A technology team that starts by automating the checklist may miss the real problem: users need a reliable way to know what has happened, what remains unresolved, and who is responsible for the next action.

Understanding that distinction requires studying the workflow before designing the solution.

Exceptions reveal the real requirements

Many systems are designed around the ideal transaction or the most common scenario.

Housing operations rarely consist entirely of ideal scenarios.

An application may be incomplete. A maintenance request may involve multiple vendors. A resident may need additional assistance understanding a process. An offer may be revised several times before a final decision.

These exceptions are not merely inconveniences. They often reveal which information, controls, and communication tools a product actually needs.

For product teams, documenting exceptions can be as valuable as mapping the standard workflow.

Good data begins with good processes

Organizations often want better dashboards and more sophisticated analytics. But the quality of those outputs depends on how information is collected.

If one team records a status differently from another, a dashboard may create the appearance of consistency without providing it.

Useful analytics require shared definitions, appropriate validation, and clear ownership of the underlying information.

This is one reason I see operations experience and data science as complementary. Understanding how records are created can help identify whether an analysis is measuring the intended activity—or simply reflecting inconsistencies in the process.

Designing for different users

Housing-related technology serves people with different levels of technical familiarity and different responsibilities.

An agent may want to review offers quickly. A manager may need an overview of outstanding work. A property owner may want a clear explanation of costs. A household may need information presented without industry jargon.

Those needs should influence the product's structure, language, and level of detail.

Accessibility, clarity, and transparency are not secondary design considerations. They help determine whether a product can be used effectively.

Applying these lessons to product work

My work on OfferIntel and the Housing Affordability Explorer reflects an interest in translating practical industry questions into structured digital tools.

The projects address different problems, but they share an underlying approach: define the decision a user is trying to make, identify the information needed, make assumptions visible, and avoid promising more than the product can deliver.

That approach also shapes how I think about product discovery and evaluation.

A feature should be assessed not only by whether it functions correctly, but by whether it addresses a meaningful problem, fits the user's workflow, and produces information that can be understood and trusted.

Where operations and technology meet

Housing is a particularly useful environment for studying product design because its processes involve real financial consequences, human needs, and complex coordination.

Technology can improve how information is organized and communicated. It can reduce repetitive work and make decisions easier to understand.

But it cannot eliminate the need for professional judgment, accurate data, or attention to individual circumstances.

The strongest products recognize those boundaries—and are designed around the realities of the work they are intended to support.

Editorial note: This is an experience-based product perspective, not a formal usability study or an evaluation of measured product outcomes.