For the third issue of this series, I had the pleasure of speaking with Krzysztof Jedrzejewski, Principal Product Group Manager at Autodesk. In this conversation, he shares hard-won insights about the identity crisis facing product managers in AEC enterprises, the economic realities of build vs. buy decisions, and how organisations can create the conditions for successful product development. Let’s dive in.
About Krzysztof
He is Principal Product Manager at Autodesk, bringing a unique perspective, having transitioned from traditional AEC environments to product management at one of the industry’s leading software companies. With a background in architecture and computational design, plus experience leading digital transformation at AEC consultancy Reope, he now focuses on creating accessible, interconnected AEC tooling ecosystems at Autodesk Forma.
Introduction
“It’s a position that is supposed to deliver clarity … ultimately responsible for building the right thing.”
Krzysztof Jedrzejewski
This observation from Krzysztof Jedrzejewski, who’s lived this identity crisis firsthand, moving from traditional AEC environments to product management at software companies such as Autodesk, cuts to the heart of a pervasive challenge: the product manager (PM) role in many AEC enterprises often suffers from an identity crisis.
What exactly is a product manager in this context? As I’ve experienced and as Krzysztof confirmed, it’s a question many within AEC are still trying to answer.
Walk into any tech company and mention “product manager,” and you’ll get knowing nods. Walk into an AEC enterprise with the same title, and you’ll get blank stares. It’s not that construction and engineering firms don’t need people building the right thing; it’s that they don’t yet know what that looks like. PMs might find themselves cast as evangelists, “explainers of tools,” or translators of pre-defined requirements, rather than the strategic drivers of product success. Without clear and empowered ownership, internal tools risk becoming a “feature factory,” producing outputs that fail to achieve meaningful outcomes and ultimately fail to transition into robust, widely adopted products.
Learning from failure first
But before exploring why this identity crisis persists, it’s worth understanding what happens when it goes unaddressed. In an industry like AEC, where projects are often measured by avoiding overruns and delays, discussing failure can feel, as I mentioned to Krzysztof, like an almost taboo topic. Yet as product people, we know that building innovative solutions inherently involves risk and the potential for missteps. When I asked Krzysztof about his own experiences with failure, his perspective was clear: failure isn’t just an outcome to be avoided, but a critical learning opportunity, provided you approach it correctly.
As I’ve explored previously in “Failure is not an option?”, this resistance to discussing failure can be particularly damaging in product development. The key is understanding that failure is inevitable; what matters is how we handle it.
“If you fail, you fail fast. The faster you fail, the better, because you invest fewer resources and you actually capture learning from that. One thing to be conscious of, though, is truly using the learnings afterwards. It doesn’t matter how fast you fail if you keep making the same mistake.”
Krzysztof highlighted two recurring failure patterns that plague product development in enterprise environments: tackling problems too niche to justify investment, or pursuing solutions without clarifying what problem they solve.
The first failure mode stems from misunderstanding market dynamics and user priorities. As Krzysztof learned, “Where I failed was understanding the hierarchy of needs. The problem was indeed pressing, frequent, but not popular enough to justify the investment.” Even when solving genuine problems, if the addressable market is too small or the problem isn’t urgent enough for most users, the solution fails regardless of its technical merit.
The second failure mode is more insidious, as it builds features driven by internal pressure rather than customer needs. “If you look at LinkedIn feed, half of it is flooded with AI – A lot of it caused by hype, pressure of the market or pressure from internal stakeholders such as sales or marketing. The majority of them incorporate new technology but solve non-existent problems. Some of them solve existing problems in a way that was not possible before and win as a result.” This type of challenge is particularly common in AEC enterprises, where innovation is more easily measured by appearance, not direct market demand.
These failures reveal why the PM identity crisis in AEC isn’t just semantic; it has real, expensive consequences. So what creates these conditions in the first place?
Why PMs struggle in AEC design practices
The root of the problem lies in fundamentally different operating environments. As Krzysztof explains, the PM role itself becomes unclear in enterprise contexts:
“It’s a position that is supposed to deliver clarity … ultimately responsible for building the right thing. But drop that same role into an AEC design practice, and suddenly you’re met with blank stares. It’s not that the position is undefined; it’s that the textbook definition doesn’t fully translate when you are building internal tools.”
This uncertainty manifests in practical ways. PMs in AEC enterprises often find themselves cast as evangelists, “explainers of tools,” or translators of pre-defined requirements, rather than the strategic drivers of product success. Without genuine product thinking, internal tools often become afterthoughts built to check a box rather than solve real problems.
Developing products for internal enterprise use versus those for the external market presents vastly different dynamics. As Krzysztof notes,
“If you’re building a product, you optimise for masses and mass scale… If you’re building within a bigger company… this market is significantly smaller, right? Immediately is like putting handcuffs on the scope of what you can build, which makes it so much more difficult to justify.”
This distinction shapes everything. External products benefit from users who’ve chosen to solve a problem, self-selecting customers who already recognise their pain points. Internal products face the opposite challenge: convincing a captive audience to change entrenched workflows. As Krzysztof observed about internal development, “that creates a little bit of a friction, I imagine, for a position of a product manager.”
The economics are equally challenging. External products have direct revenue metrics, while internal tools must justify their existence through harder-to-quantify efficiency gains. The pressure is immediate and relentless. As one practitioner described it: “You develop and in three months or less you need to be already useful for the project… You need to return immediately profitable.”
Perhaps most critically, there’s a structural mismatch too. Enterprises often operate with a project mindset, characterised by a defined scope, timeline, and budget, whereas product thinking demands continuous iteration and evolution. This cultural mismatch creates friction that goes far beyond the technical challenges of building software.
The danger of “if you build it, they will use it”
This structural tension manifests most clearly in a dangerous assumption that pervades AEC: the belief that users will adopt a tool simply because it exists. This mindset is common in industries with deeply entrenched workflows, but it’s a recipe for failure. Adoption isn’t automatic; it’s earned through a deep understanding of user behaviour, motivations, and resistance to change.
As I experienced firsthand in enterprise environments, “You need to convince people internally to use what you try to develop for them when… they said: Why do I have to change? I’m doing my work all the time in this way.” This captures the fundamental challenge: internal users aren’t customers who choose to solve a problem; they’re colleagues being asked to abandon familiar workflows.
Without genuine product thinking, internal tools often end up as a list of features rather than solving a problem truly. This requires understanding what Krzysztof calls the “job-to-be-done“, a framework he describes as “imagining that your product delivers a service and serves a certain purpose so it can be hired or fired by the customer.” This shifts the focus from just building features to understanding the deeper purpose behind why users engage with the tool and what outcomes they’re aiming for.
For example, when an architect exports a drawing to PDF, the “job” isn’t really “export to PDF”; it might be “communicate design intent to the contractor” or “get approval from the client.” But understanding this job also means considering user journeys holistically. Users rarely interact with tools in isolation, and the quality of the experience often depends on how well the tool integrates into their broader workflow from initial design creation through final delivery.
The economic reality
The build vs. buy reality check
Understanding these adoption challenges leads to a crucial economic insight.
“Building software is insanely, insanely costly, and we so often underestimate how much it actually takes us.”
“Even at large software companies… the first question you ask is: can we buy this… because it’s just cheaper and far less risky than building the tool from scratch, even if it is only 90% of the needs.”
This economic reality should be the first filter for any product decision in AEC. The math is stark: external software companies can amortise development costs across massive user bases, while internal enterprise tools serve limited audiences. The strategic framework becomes clear: build for core differentiating capabilities, buy for commodity functions, and partner for speed to market. A good PM in AEC needs to be ruthless about this calculus, resisting the temptation to build everything in-house simply because “we understand our needs better.”
The 10X better paradigm
When organisations do decide to build, the bar must be extraordinarily high. “If you provide something that is 10% better, people are not gonna adopt it,” Krzysztof notes, citing principles from “Zero to One.” “You have to shift a paradigm… something that’s strong enough for people to break their habits.”
This reflects Peter Thiel‘s core argument: marginal improvements aren’t compelling enough to overcome switching costs and inertia. Instead, you need order-of-magnitude improvement solutions that are 10x faster, cheaper, or more valuable than existing alternatives. Only then do you create enough value to justify the effort, risk, and cost of change.
This insight hits differently in AEC, where workflows are deeply entrenched and changing tools carry significant risks. Product managers must identify opportunities for these 10x paradigm shifts rather than incremental improvements. The question isn’t “How do we make this 10% faster?” but “How do we eliminate this entire step?” or “How do we make this process 10x more efficient?”
Building an innovation space
Given these challenges, from adoption resistance to economic constraints, how can AEC organisations create conditions for successful product development? The answer lies in structured innovation spaces. Large AEC organisations can foster better product thinking by creating protected spaces for innovation. Krzysztof points to Apple’s approach:
“Apple was phenomenal, being able to give protection to smaller emerging products… The iPod team was very much independent and was able to create and innovate within the small bubble.”
This wasn’t just about resources; it was about creating different operating conditions. The iPod team had high focus, proximity to customers, and could move at a completely different speed than the larger Macintosh organisation. As Krzysztof explains, even at scale, it’s beneficial to “break it down into smaller product teams… with their own identity and their way, their governance and the way of doing things.”
This aligns with principles from “Team Topologies,” which Krzysztof referenced, creating “stream-aligned teams focused on solving problems” supported by “teams with expert knowledge that specialise in solving one particular problem.” The key insight: “The scale becomes human scale again”, where teams can have direct discussions with users and understand problems without getting lost in organisational complexity.
This isn’t just about organisational charts; it’s about creating distinct governance models for various types of work. Different speeds, different decision-making authority, same strategic direction. For AEC enterprises struggling to balance innovation with operational excellence, this separation becomes critical.
But structure alone isn’t enough. These innovation teams need proven frameworks to guide their work:
Business strategy first: Before diving into frameworks, Krzysztof emphasised that “everything starts with understanding what you try to do from the business perspective… analysing who you are playing against… what’s the competition, what are people currently using? How are you differentiating within this landscape?” This includes defining clear personas: “If you don’t know who you build for, you cannot identify their problems. If you can’t identify the right issues, there is no point in building.”
Double diamond: “Once you know who you want to serve, you will see that they have a lot of problems. At that stage, you expand and you search for a general problem. Then, you narrow it down into the exact problem that you want to solve. And then… You go wide in figuring out what the solution to the problem is. Until you find the right solution and you narrow down to the exact solution.” Essential for navigating AEC’s complexity without getting lost in edge cases.
Iterative prototyping: To get to the real problems, Krzysztof recommended “The Mom Test,” a book about how “customers will always kind of lie to you… Subconsciously, as humans, we want to be supportive.” The key is to “instead of coming with the solution, come with the problem and understand how important the problem is.” This echoes the vital practice of direct user engagement and avoiding polite biases, a theme also strongly emphasised by Stevan Lukic of Civils.ai in our previous discussions on staying focused. Krzysztof is also a “huge fan of very iterative prototyping… bringing the technical leads and design leads into the interviews. And being able to start creating together… That way, everyone is deeply involved and can work on making hypotheses, prototypes and tossing them out until you gain confidence that the solution works.”
Ultimately, creating these structured innovation environments helps organisations avoid both failure patterns identified earlier: solving niche problems by ensuring proper market validation, and building purposeless features by maintaining a clear strategic focus on real customer needs.
Conclusion
The product manager role will stick in AEC when it’s empowered to deliver what the industry desperately needs: clarity about what’s worth building and what’s worth buying, acting as strategic guides to help organisations avoid the expensive mistake of building internal tools nobody uses. When it bridges the gap between technical possibility and genuine business value.
“Everything starts with understanding what you actually try to do from the business perspective,”
Krzysztof reminds us. In an industry finally waking up to its digital transformation needs, that strategic clarity has never been more valuable.
The question isn’t whether AEC needs product managers. It’s whether we’re ready to let them truly do the job.