Building a Product Culture in a Legacy Industry
Building a product culture in a legacy industry is different from building one in a tech-native market. The differences are specific and worth naming — not because they're obstacles, but because they shape how we think about shipping, learning, and what it means to move fast.
What "legacy industry" actually means for product development
Legacy industry doesn't mean the users are unsophisticated. Affordable housing developers are highly competent professionals who've been doing complex work for years. They have strong intuitions about what's real and what's marketing, and they're appropriately skeptical of software that claims to solve problems it doesn't understand.
What legacy industry means, in practice, is that the feedback environment is different:
Feedback cycles are longer. A deal in affordable housing development takes 18–36 months from initial site evaluation to closing. Software that supports that workflow doesn't get validated by whether users complete a checkout flow in 3 minutes — it gets validated by whether the decisions it supports lead to deals that close. Some of the most important feedback we'll receive is feedback we won't get for another two years.
Trust is earned more slowly. In consumer software, users can try a product, get value quickly, and decide whether to continue. In a professional context where the stakes are real — where an analyst is using a tool to make a recommendation to a development director who's going to make a real capital commitment — trust is accumulated through a track record, not through a good demo. We're building that track record one design partner at a time.
The cost of being wrong is higher. A consumer app that gives a slightly off recommendation is annoying. A feasibility tool that produces a confident-sounding output that's wrong in a material way costs someone real resources. This shapes our philosophy about accuracy, uncertainty communication, and product claims in ways that are more demanding than most B2C product teams face.
How we ship despite this
Given the longer feedback cycles and higher stakes, it would be easy to justify moving slowly. We don't.
The way we reconcile fast shipping with practitioner trust is through specificity: we're precise about what a feature does and doesn't claim to do, we communicate confidence levels explicitly, and we don't ship outputs that we haven't validated against real cases. Within those constraints, we move fast.
Our design partners — a group of affordable housing developers who use the product on real sites and give us real feedback — are the mechanism that makes this work. They're the accelerant for feedback cycles that would otherwise be too long to learn from. They tell us quickly when something doesn't match how they actually work, when an output doesn't feel right, when the interface creates friction at a step we thought we'd solved.
We take those conversations seriously. Not because we always agree with every piece of feedback — domain expertise and product judgment sometimes point in different directions — but because practitioners who are using the product on real deals are telling us things we can't learn any other way.
What shipping fast looks like here
Fast shipping in our context doesn't mean shipping features that aren't ready. It means:
Short cycles between user feedback and product response. When a design partner identifies a friction point or a missing capability, we move to address it quickly. Not every request becomes a feature — we say no frequently — but the signal from real usage shapes priorities at a pace that most enterprise software teams don't manage.
Preference for working software over documentation. Our design partners learn the product by using it, not by reading documentation. We invest in making the product legible enough to be self-explaining before we invest in formal documentation.
Shipping to learn, then iterating. We'd rather have a feature in production with design partners giving us real feedback than have a feature in internal testing that we think is ready. The gap between "what we think will work" and "what actually works for practitioners" is large enough that getting to real usage as quickly as possible is consistently the right call.
The culture implication
The culture this creates is one where everyone — engineering, product, design — is close to users and close to the domain. We don't have a layer of product managers who translate between users and engineers. Engineers talk directly to design partners. Product decisions get made with input from people who've seen the software used on real sites.
This is a culture where context matters. Understanding why a user makes a specific decision, what the downstream consequences of that decision are, and how the software fits into a workflow that extends well beyond the product — all of that context shapes how we build.
We're not building for an abstract user. We're building for practitioners whose names we know, whose deals we're tracking, whose feedback we'll see next week. That proximity to the work produces a different kind of product culture — one where what we ship feels like it matters, because we can see directly that it does.
We're building a product culture grounded in close collaboration with practitioners who use the software on real deals. If that sounds like an environment where you'd thrive, we'd like to talk.