Why I Watched 50 Hours of Acquisitions Teams Using Excel
Before we wrote a line of production code, we watched affordable housing acquisitions teams work for fifty hours.
Not fifty hours total — fifty hours per team, across multiple organizations, observing how real practitioners move through the process of evaluating a site from first look to go/no-go decision. We watched what they opened, what they typed, where they paused, what they Googled, who they called, what made them confident and what made them uncertain.
This wasn't market research in the traditional sense — we weren't asking what features users wanted or what problems they'd pay to solve. We were trying to understand the actual shape of the work: what information a competent analyst assembles, in what sequence, and why.
What we learned that we couldn't have guessed
A few things from those fifty hours that we couldn't have anticipated from interviews or surveys alone:
The sequence matters as much as the information. Experienced evaluators check things in a specific order that's optimized (often unconsciously) to surface deal-killers first. They don't run through a fixed checklist sequentially — they triage as they go, following signals that suggest where the most likely problems are. Software that presents information in a fixed linear flow doesn't match how the work actually gets done.
Uncertainty is information. When analysts can't quickly determine whether a site falls in a QCT, or when program eligibility is genuinely ambiguous, that uncertainty itself shapes the evaluation. A good analyst doesn't ignore the ambiguity — they note it explicitly and factor it into their confidence level. Software that presents clean outputs when the underlying signal is messy produces false confidence that practitioners have learned to distrust.
The handoff is where deals fall apart. A significant share of the friction in the evaluation process happens at handoffs — when a site moves from the analyst who did the initial screen to the senior director who makes the go/no-go call, or when evaluation notes get packaged into a recommendation for leadership. The informal knowledge that lives in the analyst's head during the evaluation often doesn't make it intact through the handoff. This is a workflow problem as much as an information problem.
Practitioners don't trust generic outputs. Affordable housing developers are experts in their domain. They've seen enough analysis to know when something doesn't look right. A feasibility estimate that doesn't match their intuition doesn't get trusted — it gets dismissed, and so does the tool that produced it. Earning trust requires explaining the reasoning, not just presenting the conclusion.
How this shapes the product
Those fifty hours of observation have shaped product decisions in ways that would have been difficult to arrive at through conventional product discovery:
We build the interface around decision flow, not information completeness. The question isn't "what does the user need to know?" — it's "what does the user need to know next, given where they are in the evaluation?" These are different questions and they produce different interfaces.
We surface reasoning alongside outputs. When the product assesses program eligibility, it doesn't just produce a yes/no — it shows which factors drove the assessment and where the uncertainty is. Practitioners who disagree with the output can engage with the reasoning rather than dismissing the conclusion.
We design for handoffs. Documentation of an evaluation — why a site did or didn't advance, what was known and what wasn't — is a first-class output, not an afterthought. The information should be usable by someone who wasn't in the room when the analysis was done.
The continuing practice
We haven't stopped watching. The fifty hours that shaped the initial product have become an ongoing practice: regular observation sessions with development teams using the product on real sites, watching where the tool helps and where it creates friction, understanding how the work is evolving as teams build new habits around new capabilities.
This is the part of product development that's hardest to systematize. You can run surveys and analyze usage data and synthesize support tickets. But the things you learn from watching someone work through a genuinely difficult problem — the moments of frustration and the moments of unexpected insight — don't surface in any of those channels.
We think the best products for domain experts get built by people who have spent serious time watching domain experts work. The fifty hours aren't a credential — they're the minimum viable investment in understanding the problem before presuming to solve it.
We're looking for product and engineering people who want to build software grounded in how practitioners actually work. If this approach to building resonates with you, we'd like to talk.