Jeffrey Potter‘s path from criminal justice degree to head specifier to product manager at Deltek is instructive not for its novelty but for the gap it exposes. At HMC, he had the instincts and the proximity to see what was broken. At Deltek, he finally got the authority to act on it. The space between those two states reveals something structural about how the AEC industry treats the people closest to its problems. This was a candid conversation about what it means to build products in an industry that struggles to let its own people build anything at all.
About Jeffrey Potter
Jeffrey is a product manager at Deltek, where he owns strategy, vision, and execution for Specpoint, the platform built on the MasterSpec specification library. Before joining Deltek, he spent years as a specification writer and head specifier at HMC Architects, where he redesigned internal spec workflows, built feedback loops across six offices, and pushed for BIM integration. His transition from practitioner to product manager happened not through a conventional career plan but through a customer relationship that became a job application; he saw the PM opening, had no idea what a product manager does, and applied because he saw the word “specs.”
“I almost feel like there’s not empowerment to own your role in the industry.” Jeffrey Potter
The AEC industry has no shortage of people who see problems. Specification writers who know their templates waste hours every day. Project coordinators who watch teams duplicate effort across offices. Recent graduates who spot inefficiencies in their first week but lack any mechanism to address them. The constraint isn’t perception; it’s permission. The industry’s most informed observers are often the least authorised to act on what they observe.
Jeffrey’s career arc makes this visible. As a spec writer at HMC, he identified process failures, prototyped solutions using existing tools, and gathered iterative feedback across offices. He was, by any functional definition, doing product management. But he needed board approval to rearrange steps in an existing workflow using software the firm already paid for. At Deltek, doing the same work requires no such permission. The gap has nothing to do with capability. It’s entirely a question of organisational design.
The gap between seeing and acting, between identifying problems and being authorised to solve them, is not unique to Jeffrey. It reflects a structural pattern that shapes how the entire industry relates to its own improvement.
The practitioner’s lens: why lived experience changes everything
Most product managers in construction technology arrive from consulting, software, or generalist PM roles. They learn AEC’s complexity from the outside. Jeffrey learned it from the inside, which gives him something that can’t be replicated through user interviews alone: the ability to test solutions against his own muscle memory.
His discovery process at Deltek follows recognisable product management principles: define the problem, validate feasibility with developers, work through UI and UX, test with stakeholders and customers, iterate. But there’s an additional step that most PMs can’t perform.
“I sat back, took off my Deltek hat, put on my spec rider hat, was like, do I love this? No, I would hate this. I need to do something else.”
That internal validation, testing a solution against years of lived workflow experience, catches problems that customer feedback alone might miss. It’s not a replacement for external discovery; it’s a filter that accelerates it. When Jeffrey describes being on his fourth iteration of a feature, the pivots aren’t arbitrary. They’re informed by a practitioner’s sense for what will feel wrong in daily use, even when it looks right on screen.
This connects to a broader pattern. Krzysztof Jedrzejewski, speaking about product management at Autodesk, observed that “in a pure-software company everybody gets [what a PM is]; in an AEC enterprise nobody is quite sure what it is.” Jeffrey validates this from the other direction. He didn’t know what a product manager was when he applied for the role. He simply recognised that the work he’d been doing informally at HMC, identifying problems, gathering feedback, iterating on solutions, had a name and a home in a software company. The AEC industry produced a natural product manager and then had no category to place him in.
Jeffrey’s path from customer to product owner also points to a recruiting pattern most AEC software companies undervalue: the practitioners who stress-test your product daily, who experience its limitations through the lens of real workflow friction, may be the strongest product management candidates available. They arrive with the domain expertise that takes years to build from the outside.
The intrapreneurial deficit: when billable hours crowd out problem-solving
Jeffrey’s experience at HMC illustrates a tension that surfaces repeatedly across AEC practices. He had two colleagues approach him with a clear message: our spec process is broken. He already knew this. But, as he describes it, “I was never really empowered to make a change. And when they came to me, it was like, all right, I’ve got backing now.”
Consider what that sentence reveals. A practitioner who understood the problem, had access to the tools, and could see the solution still needed political backing before acting. The constraint wasn’t technical or intellectual. It was organisational.
What followed was product management in everything but name. He broke down the existing process, identified what was wrong, built solutions using tools the firm had already paid for, and created a continuous feedback loop across offices nationwide. Each office had different preferences: San Diego used Bluebeam Projects, Phoenix wanted BIM integration, and others wanted different meeting cadences. He adapted to each while maintaining a coherent standard.
And none of it was billable.
Dustin Schafer from Henderson Engineers captures this dynamic precisely: boards “empower their innovation teams to work within the current delivery system, but not on the system itself.” Jeffrey wasn’t proposing to replace the firm’s delivery model. He was, as he puts it, “just shuffling the pieces around on the board, just moving part M up farther, moving part B back farther.” He was rearranging existing steps using existing technology. The scope of change was modest. The approval process was not.
This is the intrapreneurial deficit in action. The AEC industry’s project-driven, billable-hours model creates a structural barrier against the very people it needs most: practitioners who see problems and instinctively move to solve them. As Jeffrey explains:
“You’re working on a project. It’s tied to dollars. Tied to billable hours. You don’t have that R&D time to say, man, this is not working. I got to figure out something different.”
The pattern recurs in the article on transforming computational teams for product success: teams with intrapreneurial instincts are essential for driving internal innovation, but funding models built around utilisation targets and billable hours systematically prevent them from operating. The industry needs entrepreneurs within firms, but the operating model treats entrepreneurship as insubordination.
The authority gap: same work, different permission
The intrapreneurial deficit explains why practitioners can’t carve out time for improvement. But even when they do, a second barrier emerges: who is authorised to make decisions about how work gets done.
At Deltek, the work Jeffrey was doing informally at HMC has a name, a budget, and decision-making authority. The skills didn’t change. The organisational design did.
“As a PM you’re, I mean, that is your job. If I had to go to our chief product guy every time, or our senior VP every time, like why have that PM role? I’m enabled to make that decision.”
The work is identical. The authority to do it is not. At a software company, what Jeffrey was doing at HMC is called product management, resourced accordingly, and given decision-making authority. At an AEC practice, the same work exists in an organisational grey zone: valued when it produces results, but never formally sanctioned or staffed.
Jeffrey extends this observation beyond his own experience with a striking example: “If I’m just somebody working on Revit all day. Do I have a say in an architectural template that is bad? It’s costing me 20 minutes every time I have to load, save, or sync it. And I’m doing that five times a day. That’s an hour and a half a day production time.”
He then asks the question the industry rarely confronts:
“Is that individual empowered? Maybe at some firms. I would probably argue across the board, probably not. Because that portion is controlled by some other entity of the firm.”
An hour and a half of lost productivity per person per day, visible to everyone experiencing it, unaddressable by anyone experiencing it. The person closest to the problem has no mechanism to fix it. The entity that controls the template may not even know the problem exists. This is not a technology gap. It’s an authority gap.
The four hidden barriers article describes this as a cultural collision: the same mindset that ensures reliable project delivery, control, predictability, and approval layers creates friction against internal improvement. Jeffrey’s Revit template example is a textbook case. The approval structure exists to manage risk. But the risk it creates, accumulated inefficiency that compounds across every person, every day, goes unmeasured and unmanaged.
AI forces the bet: risk aversion meets a forcing function
The AEC industry has maintained its conservative posture toward change for decades, and not without reason. As Jeffrey articulates: “If we do things differently, are we opening ourselves up for risk? The risk in the construction industry could be millions of dollars. And people don’t like to play with those odds.”
This risk calculus has historically been self-reinforcing. The cost of change is immediate and visible; the cost of stagnation is diffuse and deniable. Firms can absorb the accumulated inefficiency of broken templates and redundant processes because no single incident is catastrophic enough to force action.
AI disrupts this equilibrium. Not because it directly solves the problems, but because it forces organisations to take a position. When competitors begin using AI to compress execution time, when clients start expecting AI-enhanced deliverables and when new entrants can replicate commodity work at a fraction of the cost, the option of waiting disappears. Every firm must decide: adopt, or accept the consequences of not doing so.
Jeffrey sees this forcing function operating at multiple levels. On the product side, he describes a concept where “you log into the app and the app has AI in it, but it builds what you want as a user on the fly. Your preferences are going to be different from mine.” The pattern is already emerging: AI enables the kind of per-user customisation that traditional development economics couldn’t support.
On the business model side, the implications are more disruptive. Tim Wark from Airis Analytica identified this pattern in mining: when AI collapses execution time, competitive advantage shifts from building speed to problem understanding. The same dynamic applies to specification work. If AI can generate 80 to 90% of a standard spec (Jeffrey’s own estimate of cross-regional consistency), the value shifts from the labour of writing to the judgement of knowing what’s different and why.
This is where the authority gap and the AI forcing function intersect. The practitioners who understand the nuances, who know that building in northeast Vermont requires different waterproofing than southern California, who can identify the 10 to 20% that varies, are the same people the industry has historically prevented from acting on that knowledge. AI doesn’t replace their expertise; it makes their expertise a scarce resource.
As Jeffrey puts it, “just because you’ve done it this way forever doesn’t mean that’s the way you should continue to do it.” In the context of AI, this isn’t aspirational advice. It’s a competitive reality. The firms that enable their practitioners to rethink workflows, question existing standards, and experiment with new approaches will capture the value that AI creates. The firms that maintain existing approval structures and billable-hour constraints will watch that value flow to competitors.
The standardisation question: 80% the same, 100% rigid
One of the most revealing moments in the conversation comes when Jeffrey discusses the standardisation of specifications across regions.
“I’ve always believed like 80 to 90 percent of the spec is the same across the regions. It’s just the products that are different.”
This observation carries significant implications for how we think about tooling in AEC. If the overwhelming majority of content is shared, and meaningful variation is limited and predictable (e.g., different materials, building codes, pricing by region), then the tools should support a single version with structured variation, not multiple independent versions that drift apart over time.
Jeffrey suspects that current technology may be contributing to the problem rather than solving it: “I almost wonder if the tech is maybe repeating the problem and not allowing firms to have a degree of standardisation but also allow for the flexibility to be unique and to deviate when you need to.”
This is a product insight that could only come from someone who has written specs across multiple regions. A PM without practitioner experience might accept the fragmentation as a given. Jeffrey recognises it as a design failure in the tooling itself. The industry created workarounds for a limitation that should have been solved at the platform level.
His approach to solving this at Deltek reflects the iterative, MVP-oriented thinking the role demands. Rather than building a comprehensive customisation engine, he advocates for shipping a middle-ground solution, gathering feedback, and expanding based on real usage patterns. As he puts it, “the first solution I have is not the actual final solution. And it changes based on feasibility, based on how much time it’s going to take to build, based on feedback.”
This is precisely the kind of insight that gets stranded in practice. Jeffrey can act on it at Deltek because the role carries decision-making authority. A spec writer who sees the same fragmentation at a 200-person firm has no equivalent mechanism, no budget, and no mandate to address it.
The culture conundrum: why we don’t talk about failure
Building great products means failing fast and learning from mistakes. But AEC doesn’t work that way. So I’m asking every builder I talk to the same question: why is failure such a taboo topic in our industry?
Jeffrey’s answer connects directly to the authority theme running through this entire conversation. The industry doesn’t discuss failure because the people who experience failures most directly lack the authority to surface them. The recent graduate who loses 90 minutes a day to a broken Revit template isn’t going to escalate that to the board. The spec writer who knows the process is inefficient isn’t going to challenge the managing principals without political backing.
The risk calculus Jeffrey describes, millions of dollars at stake, legitimate consequences for getting it wrong, explains why the industry developed its conservative culture. But it doesn’t fully explain why that conservatism extends to internal process improvement, where the consequences are contained and the learning opportunities are significant.
Jeffrey’s own trajectory offers an answer. His spec process redesign at HMC “wasn’t a complete success but wasn’t a complete failure.” That ambiguity, the messy middle ground where most real improvement lives, doesn’t fit the industry’s binary framing of success and failure. In a culture that fears failure, partial success is classified as a risk rather than as progress.
The pattern runs deeper than individual firms. Construction delivery operates on binary outcomes: a building either meets code or it doesn’t; a project either hits the deadline or it doesn’t. That binary thinking migrates inward, shaping how we evaluate internal experiments. A workflow redesign that improves efficiency by 40% but doesn’t solve every edge case gets filed under “incomplete” rather than “validated first step.” The result is an industry that struggles to learn iteratively because it won’t recognise iteration as a legitimate outcome.
When the operating model becomes the bottleneck
Jeffrey Potter’s path from criminal justice to spec writing to product management is idiosyncratic. But the pattern it reveals is not. The AEC industry produces natural product thinkers, practitioners who identify problems, prototype solutions, and iterate based on feedback, and then denies them the organisational conditions to do that work.
Three structural forces create this condition:
- The billable-hours model treats internal improvement as overhead rather than investment, ensuring that the people closest to problems never get dedicated time to solve them
- Approval structures designed for project risk management get applied to internal process change, creating disproportionate friction for modest improvements
- The absence of product management as a recognised function in AEC practices means there is no natural home for the work Jeffrey was doing at HMC
AI is changing the calculus, not by solving these problems directly, but by raising the cost of leaving them unsolved. When execution time compresses, the value of understanding what to build and who should be trusted to decide increases. The firms that recognise this will do what Deltek did for Jeffrey: create roles where practitioners with deep domain knowledge are authorised to act on what they see.
The question isn’t whether the industry has people capable of this work. Jeffrey’s story proves it does. The question is whether firms will create the conditions for that capability to operate, or whether they’ll continue losing their best problem-solvers to software companies that already know what to do with them.