A huge shout-out to Stevan Lukic, the first guest in a conversation series connecting the AEC world with modern product development thinking. We’re diving into how real teams build—and sometimes struggle to build—tools in our fragmented industry. Let’s be real: the AEC space doesn’t discuss Product lessons nearly enough.
Introduction
I want to start with this quote, which Stevan shared, the meaning of which will keep recurring in the conversation.
“Great things are not done by impulse, but by a series of small things brought together. The trick is to focus on the first small thing. Starting small is still starting, and small beginnings often lead to extraordinary endings.” — Vincent Van Gogh
The Architecture, Engineering, and Construction (AEC) industry is deeply rooted in a delivery mindset. Projects are scoped, planned, executed, and handed off often with little concern for whether the result solves the right problems for end users. That might work for buildings and infrastructure, but digital tools are different.
As Martin Fowler puts it, software thrives when teams own a product end-to-end, iterating based on honest feedback. This “you build it, you run it” mentality fosters a real connection between developers and users, something the AEC sector rarely benefits from when applying its traditional project-based model to software.
Building products comes with multiple challenges, which we rarely discuss openly. Most of the time, we scratch the surface and don’t try to tackle them.
This article reflects a conversation I had with Stevan, co-founder of Civils.ai. We talked about the real struggles and wins of building AEC applications that people enjoy using. What follows is not a step-by-step guide, but a conversation we invite you into.
Start narrow
“You can’t please everyone at once. Start with the ones you can serve best.”
That’s what Stevan told me when we were talking about the early days of Civils.ai, and that mindset still holds true.
Clarity matters when you’re building in a space as fragmented as construction. You can’t build for everyone. Stevan shared how easy it is to get pulled in every direction.
“The hardest bit with building products… everyone has different feature requests. You either build something very specific or constantly build new features.”
The moment something works, people come out of the woodwork asking for this or that. Different geographies, different job titles, all with valid use cases. But if you try to build for all of them at once, you lose the thread. The market’s fragmented, sure, but that’s not a reason to freeze. It’s a reason to go deeper before you go wider. Grow capability around that. Feedback comes in, you assess it, you get stronger, and eventually, you move sideways.
At Civils.ai, they began with a very specific tool: a borehole digitiser. It was focused, useful, and did one thing really well. Only after that did they find traction, and then they thought about expanding into adjacent problems, like broader PDF data extraction. That principle, vertical before horizontal, helped them to avoid the chaos of trying to serve every persona from day one. There’s always this (reasonable!) fear that if you don’t target a sufficiently broad set of users (or customers), you’ll miss out on a big opportunity.
Vision filters the noise
A strong product vision is what filters out the noise. It’s not just about building what’s feasible; it’s about building what makes sense for the direction you’ve chosen.
In a sector where every job site, every team, every spreadsheet looks a little different, it’s tempting to build for all of them. But the path to real adoption isn’t about being everything to everyone. It’s about being essential to someone first. The sharper your vision, the easier the decision-making becomes. Vision isn’t something you write once and forget; it’s a living guide. Revisit it often, because it will help you know when to stay the course and when it’s time to shift.
That doesn’t mean you ignore feature requests. Quite the opposite! They reveal pain, and that’s valuable. But they shouldn’t dictate your roadmap. Otherwise, you’ll end up with a bloated tool that solves no one’s problem well. This is where setting a cadence and talking clearly with your customers helps. Tell users: ‘That’s phase three, right now we’re doing phase one.’
Be honest about what you can actually build. Stevan was clear about this too: limited resources aren’t an excuse—they’re a reason to be strategic. It is necessary to establish some principles, set a direction, and be honest with customers about what you are able to accomplish. When resources are tight, it helps to cut scope aggressively rather than compromise on quality. Ask yourself, “What if we remove this? Is the product still useful?” Keep trimming until removing more would render it useless—this forces clarity and ensures that whatever you do ship remains worth building. That kind of transparency builds trust. Customers respect it when you say, “We’d love to solve that too, but right now we’re focused on this.”
From polite feedback to hard evidence
This is even more effective when paired with direct, structured conversations. Michael Sippey, former VP of Product at Twitter, puts it: “If you want valuable, actionable product input, there’s no substitute for sitting down with your customers and prospects to truly understand their problems.”
Stevan emphasised this point strongly, advising to watch users directly interact with your product. “Sitting beside users as they navigate your software reveals friction in real time,” he explained. “Maybe they’re on a smaller screen or a different OS than you expected, and you watch them get lost in the UI or stuck waiting for something to load. They don’t need to say a word—you feel their frustration. That quiet discomfort is some of the most honest, useful feedback you’ll ever get.” Complaints, in particular, can be a goldmine. Gaurav states, “If nobody complains, it’s almost a red flag.” Those moments of frustration from users often point directly to what matters most and should guide what gets prioritised next. This type of observation helps you spot what’s broken, misunderstood, or unnecessary before you start building around the wrong assumptions.
Stevan shared one more practice that keeps his team honest: no polite lies. They use what’s known as the Mom Test: a reminder that nice compliments don’t really help and that the real insights come from finding out what’s actually bothering people. Instead of asking users, “Do you like this?”—which people will often say yes to just to be nice—they do a few things differently:
- They talk about the user’s day‑to‑day, not the idea. They kick things off by asking what the workflow looks like right now.
- They ask for specific past experiences instead of hypotheticals. Like, “Tell me about the last time this spreadsheet ruined your evening.” Real stories beat wish‑list speculation.
- They look for solid commitments. If the pain is real, users will send sample files, introduce teammates, or even set aside a budget.
These sharper questions lead to way more honest conversations than polite chit-chat ever could. Stevan pointed out during our call that this approach consistently encourages open dialogue and helps the team avoid falling into the confirmation bias trap. These three methods help the team figure out real issues from just polite enthusiasm. They turn scattered feedback into a clear, actionable roadmap when mixed with observation, structured interviews, and a good attitude towards complaints.
Conclusion
Reflecting on our discussion, one thing is clear: building meaningful, enjoyable AEC applications is as challenging as it is rewarding. The trick lies in starting small, listening carefully, and staying laser-focused on solving the right problems. Start less and finish more; every successful product is proof of that.