Sol Amour‘s experience leading product development for Dynamo at Autodesk gives him unique insight into managing software at a global scale across multiple host applications and release cycles. In this conversation, we explore how systematic frameworks must synthesise both objective data and subjective insights about how work affects people’s feelings, and why crafting better stories about change often matters more than building better features. This was a great conversation, and I hope you enjoy it as I enjoyed speaking with Sol!
About Sol
Sol is a multidisciplinary leader who fuses technical precision with design empathy. At Autodesk, he shapes Dynamo’s future, championing automation that empowers, not replaces, human creativity. His passion lies in crafting software that removes friction, allowing teams to reconnect with the art of building intentionally, beautifully, and holistically.
Introduction
“Storytelling is the base human condition. You think about it. Right? What is a song? It’s telling a story. Building a building is telling a story. Making a product is telling a story. We’re all storytellers in different ways, in different forms, in different shapes, in different sizes.”
Sol Amour
Sol Amour knows something about stories. As part of the team behind Dynamo at Autodesk, he has witnessed firsthand how software at a global scale requires more than just good code; it demands understanding the human narratives that drive real change in how people work.
But how do you systematically break down ambitious ideas into testable assumptions while navigating the complex ecosystem of host applications, legacy constraints, and diverse user needs? How do you build the trust necessary for users to abandon familiar workflows? How do you discover genuine problems rather than performing research theatre?
The answer, Sol discovered, lies in recognising that product development is fundamentally about people and the stories they tell themselves about change. Whether you’re prioritising features, managing disruptive updates, or proving ROI for open-source software, you’re always crafting narratives that help people move from resistance to adoption.
Every technical decision becomes a story about what you value. Every user research session becomes an exercise in separating authentic problems from polite responses. Every product’s success depends on telling a better story than the one users currently tell themselves about why change is impossible.
The craft of breaking down complexity
When you’re dealing with big ideas, context becomes everything. Sol describes the process as more craft than skill, requiring synthesis of thousands of hours of customer conversations, forum discussions, and industry insight. “Everything is different,” he explains. “No single idea compared to another is ever the same.”
This aligns with Dan Heath‘s concept in Reset, where he asks, “What’s the goal of the goal?” This idea emphasises the importance of digging deeper to identify the right problem rather than just addressing surface-level symptoms. The key lies in asking “why” five times to reach the root causes:
“It’s about getting to the heart of things… asking yourself why five times. For example, ask, ‘Why this? Why this? Why this?’ Get to the root cause.”
The team at Autodesk uses what Sol calls importance versus difficulty matrices, plotting ideas relative to each other using sticky notes that can never occupy the same grid position. “You have to plot any idea relative to another idea,” he notes. “Each idea has to be always more or less important and more or less difficult than something else in order to help it drive you forward.”
This approach reveals four distinct territories that emerge when ideas are plotted relative to one another. The high importance, low difficulty quadrant represents what Sol calls “your really high return on investment. Things that if you spend the time, you get huge results. Disproportionate results.” These are the sweet spots that every product team dreams of finding.
Then there’s the high-importance, high-difficulty work, which Sol describes as “your strategic layer. These are things that you need to do. You need to figure out how you can get them done. They might be larger in scope, more complex in nature.” This might include integrating Dynamo into a new product, a highly complex but necessary step for achieving long-term success.
The low importance, high difficulty quadrant is what Sol bluntly calls “the sucky thing. It’s not something that we can use. We only do that if we have a huge amount of people hours and time at our disposal.” These are the ideas that sound interesting in theory but make little practical sense given resource constraints.
Finally, there’s the low-importance, low-difficulty work “your nice-to-haves, low-hanging fruit that you’ll feed through into a product cycle.” These represent steady improvements that don’t move the needle dramatically but keep the product evolving.
The beauty lies not in the framework itself but in how it forces relative thinking. No idea exists in isolation; every decision happens in the context of opportunity cost. “You have to plot an idea relative to another idea,” Sol emphasises. “Every idea has to be always more or less important and more or less difficult than something else.”
But the real craft lies in what happens before the plotting. Teams must synthesise both objective data, which reflects what people actually do, with subjective insights about how work makes people feel and what they want to see manifest in the product. It’s about understanding not just the words customers say, but understanding the spirit of their requests themselves.
Trust and the reality of disruptive change
Not all change is created equal. Sol breaks it down into three categories: additive change, which users can ignore if they don’t want it; subtractive change, which removes existing functionality; and the trickiest of all, modificative change, which alters existing behaviour.
“Change is very, very hard,” Sol reflects. “Change that is disruptive is way, way harder.” He shares the example of resizing nodes in Dynamo, a visual change that didn’t affect functionality but frustrated users with particular spacing preferences. “We had a miss in terms of doing the work to resize those. We did the work to resize the nodes, but we did not do the work to space out those nodes appropriately in a graph.”
This oversight resulted in a visually unappealing change that disrupted users’ workflows, even though it didn’t affect the execution of their graphs. For users with strong organisational preferences, the spacing disruption was genuinely frustrating.
The team owned the mistake completely. “We do own it. We continue to own it,” Sol emphasises. “That’s something that we learned, and we have now taken way more caution when it comes to making any kind of change like that that has an impact that puts time and effort into you and any other Dynamo customer.”
The challenge becomes more complex when you’re managing software across multiple release cycles and host applications. Dynamo spans 50-60 releases across three years of active support, integrated into 6-7 different host applications with their own release schedules. Unlike cloud-based software that can flip switches and roll back changes, desktop software locks teams into their decisions.
“Because of Dynamo’s desktop technology, it’s very hard for us to introduce rollbacks,” Sol explains. “All we can do is make changes moving forward.” The constraints run deeper than simple versioning. “We can patch smaller things like bugs or memory leaks, but due to the complex nature of software, more complex things are too risky for us to do as changes occur not just in Dynamo, but also in its host applications that can affect behaviour and stability.”
The team faces careful decisions about what changes are worth the risk. Bug fixes that change behaviour can be patched, but performance improvements often can’t. “If there’s something that’s a performance improvement, we can’t really go and patch that in previous versions because the landscape within which it developed is completely different to the landscape of the software beforehand,” Sol explains. “And doing the whole testing cycle and validating that that works appropriately, there’s a hefty lift.”
This differs dramatically from cloud-based software, which can “just flip the switch and roll something back.” The desktop constraint creates a fundamentally different risk profile that shapes every decision about change.
The limitation has forced the team to become more disciplined about change management. “That’s something that we learned, and we have now taken way more caution when it comes to making any kind of change like that that has an impact that puts time and effort into you and any other Dynamo customer,” Sol reflects. When you can’t easily undo your decisions, you learn to make them more carefully.
The proximity trade-off
Building for external users creates what Sol calls a “proximity trade-off”.
Sitting next to your users enables rich conversations and shared understanding, but risks creating solutions that are too fit for purpose, akin to the Homer Simpson car problem. This challenge aligns with what Teresa Torres and Petra Wille discuss in “All Things Product” about the crucial role of curation in product decisions, asking not just “Can we build this?” but “Should this exist in the world we’re trying to create?”
“The challenge with that is you might be building something that is too fit for purpose for that person,” Sol notes. The value of distance lies in abstraction, the ability to synthesise perspectives from dozens of companies to understand common challenges that exist across the industry.
This synthesis reveals what Sol calls “the truth behind what is being said.” When someone asks for something specific, they might need something different from their literal request. “The spirit of the ask is what we’re seeking, not necessarily the particular solution they talk about.”
This requires a disciplined approach to understanding problems rather than accepting solutions at face value. When a customer says they need a specific feature, the real question becomes: what underlying challenge are they trying to solve? The digging process becomes even more critical when synthesising feedback across global markets, where the same fundamental problems get described using different language shaped by local practices and constraints.
The result is a deliberate strategy that Sol describes in terms of coverage percentages. Autodesk excels at providing “the generalist tool set,” where “the base of Revit or the base of AutoCAD or Civil 3D gives you that 80% kind of solution or 80 or 90% solution.” This foundation works across different companies, regions, and disciplines because it addresses common workflows most organisations share.
Every organisation has specific requirements that fall outside that coverage. “And so then you have tools like Dynamo where you could, in theory, build your own sort of niche workflows that do whatever you want. It’s kind of like that final 20% or final 10%,” Sol explains. This customisation layer allows organisations to build their unique workflows and solutions without requiring Autodesk to anticipate every possible use case.
Discovery as craft, not theatre
With AI enabling faster and cheaper mockups and prototyping, discovery becomes the bottleneck. But Sol warns against the seductive trap of fake discovery, what he calls “discovery theatre.”
This fragility makes user research both critical and treacherous. Human nature works against honest feedback at every turn. “People’s human nature at large across the board is just to be nice,” Sol observes. “To kind of tell you what they think you want to hear. That’s always nice to get, like, a pat on the back and feel good about yourself, but it’s not very useful when it comes to building a product.”
The solution requires building what Sol calls “brutally honest relationships” through sprint demos with rotating customers. Five to fifteen different users join monthly reviews, providing feedback that can be devastatingly direct. “This is terrible. This doesn’t work. We want to fix this and change it. I would never use that,” Sol describes the conversations they welcome. “These kinds of very strongly opinionated conversations are something that we embrace a lot.”
The relationship works because trust flows both directions: “They trust that we’re trying to do what is right for the product and right for them as customers. We trust that they have the best interest of the product at heart, not just for themselves, but for the broader community.” One customer provided ten ideas for group improvements in Dynamo 3.6 and the upcoming 4.0 release. The team implemented six or seven because they made broader sense; the others remained too niche for the community’s needs.
But here’s where craft can decay into performance. “It’s easy to fall into a trap there to say, this idea is a good one. Right? I think this, therefore, we should do it,” Sol explains. “But ideas should be born of themselves. A good idea is a good idea… because it’s a good idea!”
The red flags are consistent across organisations: coming with solutions instead of challenges, casting too broad a scope (“boiling the ocean”), and injecting personal agendas instead of maintaining open minds. When no ideas get killed, when backlogs never change, when discovery outputs don’t impact roadmaps, you’re watching theatre, not doing the work.
Teams often fall into the trap of asking “What do you need?” when they should be observing workflows directly, shifting from requirements gathering to understanding how work actually gets done.
Real discovery stays problem-driven. “You should never come with a solution. That is not the point. You come with a challenge. What is the challenge? How do you manifest a solution that solves that challenge?” Effective discovery stays narrow, focuses on current timeframes rather than work that will become obsolete in 6-12 months, and drives roadmaps forward in ways that customers actually want to keep using.
With AI making mockups faster than ever, the human intelligence required to identify genuine problems becomes more valuable, not less. “It’s the human connection piece that matters; Soft skills matter even more when it comes to discovery.”
Proving value through narrative
Perhaps nowhere does the craft versus science tension become more apparent than in proving ROI for an open-source product. Dynamo’s unique position, Autodesk sponsors but doesn’t own it, creates measurement challenges that traditional SaaS metrics can’t solve.
“Monthly active users are not a very good metric,” Sol acknowledges. “Do people use it once a month for five seconds? Do people use it 400 times a month? Quite hard to reason with.”
Instead, justification comes through storytelling. Customer narratives about saving 1000 hours across 100 projects. Stories about enabling visual programming for non-coders who would never learn C# or Python. Evidence of augmentation value for other Autodesk products.
“We have to justify usefulness or reason for being through narrative and stories,” Sol explains. “We seek out stories from customers who say, ‘Hey, I use Dynamo to do this, and it was awesome. I saved a thousand hours!’
This isn’t marketing convenience, it’s recognition of something fundamental about human communication. “Storytelling is the base human condition,” Sol reflects.
“You think about it. A song is telling a story. Reading a novel is storytelling. Watching a movie is storytelling. Building a building is telling a story. Making a product is telling a story.”
The story that changes stories
As our conversation winds down, the deeper pattern emerges. Whether you’re managing node spacing controversies, synthesising feedback from global enterprises, or proving ROI through narrative, you’re always dealing with the same fundamental challenge.
“It’s almost always, I think, everything in life beyond the domain that we’re in, architecture and software, it’s always a people thing, never so much anything else,” Sol observes.
Some people embrace change and “run into the darkness and shine their own light.” Others prefer “hitting this rock with this hammer forever.” The spectrum of human response to change creates challenges that extend far beyond software functionality.
This is where Sol’s insight about storytelling becomes most profound. In AEC, where technical innovation often struggles against cultural resistance, where proximity and distance create equal but opposite risks, and where discovery can easily become theatre, success depends on understanding something essential about human nature.
“If you can tell a good enough story, if you can convince people, if you can influence people through your story, if your story is better than the story they’re telling themselves, change can happen. But they have to choose it truly,” Sol concludes.
The real skill lies not in building solutions, but in understanding problems. Not in following processes, but in synthesising human needs across diverse contexts. Not in optimising for metrics, but in crafting stories that help organisations move forward together.
This isn’t about manipulation or clever messaging. It’s about recognising that storytelling is the fundamental human condition. We’re all storytellers in various ways, forms, shapes, and sizes.
Building great products for AEC means understanding that people don’t resist better solutions; they resist the vulnerability required to abandon familiar ones. The stories we tell about change must acknowledge this vulnerability while providing a compelling vision of what’s possible. Sometimes it means having the wisdom to build something less perfect for one person but more valuable for everyone, the opposite of Homer’s dream car, but exactly what the industry needs.
For teams navigating the complexity of software at a global scale, Sol’s insights offer a reminder that, beneath all the frameworks and methodologies, success still depends on the fundamentally human work of understanding what people need and helping them achieve it. The craft lies in making that compromise feel like a gift rather than a sacrifice.
The craft continues, one honest conversation at a time.