What It's Like to Be a PM at a Company Where the Users Are Domain Experts
Product management at most software companies involves bridging the gap between what users say they want and what they actually need. At Alpha Deal, that gap has a different character. Our users aren't general consumers or business generalists. They're affordable housing developers — professionals with deep, specific domain expertise who've been doing complex work for years and who will immediately recognize when a product doesn't understand what they do.
That changes how product management works in some fundamental ways.
The credibility bar is different
In consumer software, users often don't know what's technically possible. They describe the problem and trust the product team to figure out the solution. In domain-expert software, users frequently have a clear sense of what a correct solution looks like — because they've been doing this work manually, and they know what the work requires.
This means our product decisions get evaluated against a high bar of domain accuracy. If the zoning parameters we surface for a site are wrong, or if the program eligibility assessment doesn't reflect how the program actually works, our users notice immediately. They're not going to assume we got it right. They're going to check.
For a PM, this means being close enough to the domain to catch these errors before they reach users — or at least to recognize them quickly when users flag them. It also means being honest about the limits of what we know. Affordable housing development involves a lot of local nuance that we're still building knowledge about. Practitioners respect candor about that more than false confidence.
Research looks different
User research in most B2B software involves understanding user workflows, pain points, and decision-making processes. That's still true here, but the research has to go deeper. Understanding that development teams are time-constrained during site evaluation isn't enough. We need to understand the specific sequence in which they check things, the specific signals that change their direction, the specific moments where the current tools break down.
That level of understanding requires getting much closer to the actual work than surveys or user interviews typically produce. Our product team has spent significant time watching practitioners work on real sites — not asking them about their work, but observing how they actually do it. The distance between how practitioners describe their process and how they actually execute it is large enough that the observation matters.
The product decisions that require domain knowledge
Some product decisions are primarily judgment calls about user experience — how to organize information, what to surface at which step, where friction should be reduced. These are familiar PM questions.
But a significant portion of our product decisions require domain knowledge to evaluate correctly. How should program eligibility be assessed for a site in a specific market context? What's the right level of precision for a first-pass capital stack estimate? How should uncertainty in an input be represented to a practitioner who needs to make a real decision? These questions can't be answered by user research alone. They require understanding the domain well enough to have a defensible view.
The best PMs in this kind of environment are the ones who treat the domain as a genuine area of learning — not as background context, but as something they're actively developing expertise in alongside their product craft.
What makes it worth it
Building for domain experts is harder than building for general users. The credibility bar is higher, the research is more intensive, and the product decisions are more complex.
It's also more intellectually interesting. The problems are harder. The feedback is more specific. The users have high standards and they articulate them clearly. When we get something right — when a feature genuinely reduces the friction of a task that experienced practitioners found tedious or error-prone — we know immediately, because practitioners tell us directly.
That tight feedback loop between product quality and practitioner trust is what makes building in a domain-expert context different from most software environments. It's also what makes it worth the additional difficulty.
We're looking for product managers who want to build software that earns the trust of domain experts. If this kind of challenge sounds interesting, we'd like to talk.