We are excited to announce the launch of Momentum Method, our human-centered process for building industrial software fast. Digital Plant Director, Ryan Crownover, shared the grand reveal during his speaker session "Delivering Value Through Digital Transformation" at the Inductive Community Conference (ICC) 2025. Most people get that digital transformation improves efficiency, real-time decision-making, and operational effectiveness. But it also involves considerable investment and risk. The question many of us are asking is, how do you reap the benefits of digitization while reducing risk and accelerating ROI?
In this blog post, I’ll summarize the key points from Ryan’s talk, and provide you with actionable takeaways to enhance your digital transformation journey.
What If We Built Industrial Software Differently?
Key lessons from Ryan Crownover’s ICC talk on unlocking Value in digital transformation
Digital transformation in manufacturing has a branding problem. For years, it’s been marketed as a technology revolution—a path paved by platforms, dashboards, and buzzwords. But inside plants, the story feels different. Millions are spent, projects stretch on, MES deployments creep from months to years, and plant leaders start asking the same question:
“Why aren’t we seeing value yet?”
In this post, we’ll walk through the key ideas Ryan presented—why industrial software projects stall, what manufacturing can learn from modern software development, and how Momentum Method can unlock ROI in weeks, not years.
Industrial Software Isn’t Special
Ryan opened with a comparison that surprised a lot of people in the room: industrial software isn’t actually unique. And that’s exactly why we need to rethink how we build it.
To explain, he used an unexpected analogy: pilot flight schedules.
Imagine you’re a commercial pilot. Before each flight, you open an app on your iPad where you can:
- See your flight schedule
- Check inbound aircraft status
- Review maintenance notes
- Perform digital pre-flight checks
- Pull weight and balance data from landing gear sensors
It sounds like a specialized aviation system. But Ryan revealed that the screen he showed wasn’t from an airline at all.
“This is actually an application we built that's a work order management system,” he explained.
Whether you’re flying a plane or running a packaging line, the pattern is the same: a queue of jobs, interaction with connected hardware, reporting, and close-out.
The takeaway was simple but powerful: digital plant applications have more in common with enterprise software than with PLC logic. MES, scheduling, and downtime tracking are business applications that live near the process, not control it. They handle massive amounts of data and are meant to improve decision-making.
That’s why Ryan argued the way forward isn’t to invent something new, it’s to borrow what already works from the software world.
"Instead of reinventing the wheel, our goal is to steal the wheel. We don't want to come up with anything new… We want proven practices that are battle-tested.”
The Limits of “Getting the Requirements Right”
Next, Ryan introduced a familiar character—Digital Transformation Dave.
Dave is sharp, experienced, and genuinely trying to modernize his company’s operations. Like most project leads, he starts with a detailed requirements process: gather every need, document the workflows, build a huge work breakdown structure, and promise that if the requirements are solid enough, everything else will follow.
If you’ve ever been part of a traditional MES rollout, you already know what happens next:
- Scope changes mid-project.
- New requests appear once operators finally see the screens.
- Months of development are sunk before a single ROI metric moves.
“Confession, I have been Digital Transformation Dave before, and I'm sure all of you have, and the requirements aren't enough,” Ryan said.
The hard truth is that in software, you can build anything. The challenge isn’t gathering requirements—it’s understanding why those requirements matter.
During his talk, Ryan displayed a series of unlabeled buttons on a screen and asked the audience what each one did. Every answer was different. The point landed: even the smallest ambiguity in a user interface can multiply confusion on the plant floor.
“This is the bane of software development... these things are not clear, and every user is gonna have a different interpretation of what these buttons mean.”
That’s why UX research—the practice of talking directly with users before you write a line of code—has become standard in the software world. It surfaces not only what users say they need, but why they need it. When you understand the why, you stop guessing at value.
Stealing the Wheel
Instead of trying to reinvent project delivery for the plant environment, Ryan suggested we steal the wheel—borrow the best ideas from modern software engineering and apply them to industrial projects.
That toolbox includes:
- UX Research – Interview operators, supervisors, and engineers to uncover friction points and success factors.
- Solutioning and Prototyping – Turn insights into quick, low-fidelity screens, get feedback early, and refine before code.
- A Value Roadmap – Rank potential features by business value and technical feasibility. Build the highest-value items first.
- A Living Backlog – Keep a single, constantly updated source of truth for priorities.
The key shift is moving from “collect requirements once” to “learn continuously.” Each iteration refines understanding, reduces risk, and makes every dollar spent on development more likely to return value.
From Waterfall to Iterative Delivery
Ryan contrasted Digital Transformation Dave’s linear project plan with the iterative rhythm used by modern development teams. Instead of one giant go-live, you build in small, testable increments tied to measurable goals.
Each iteration follows a simple cycle:
- Choose a focused sprint goal—for example, start and stop a work order.
- Deliver a working piece of software within two weeks.
- Get real feedback from real users in production.
- Adjust the backlog and plan the next sprint.
“Fake users make fake feedback,” Ryan reminded the crowd. “The best feedback comes from using the real application.”
In one project example, operators requested a new performance chart after just two weeks of using a new application. The team added it in the next sprint, then realized they had enough data for OEE calculations, which they deployed soon after. The software evolved through actual use—not speculation.
This approach does more than speed things up. It changes the relationship between integrators, engineers, and stakeholders. When users see progress every two weeks, trust builds. When code is in production early, ROI starts earlier.
Why Ignition Makes This Possible
Ryan tied these concepts back to the conference’s core theme. Ignition, he explained, isn’t just a visualization tool—it’s a platform that supports this new delivery mindset.
Features like Perspective’s rapid WYSIWYG development, CI/CD pipelines, and configuration as code allow teams to deploy updates quickly and safely. The scalability of Ignition 8.3 means teams can start small—one plant, one process—and expand horizontally without rewriting the foundation.
Without that kind of platform flexibility, true iterative delivery would be nearly impossible in industrial environments.
Momentum Method
Finally, Ryan revealed our new framework: Momentum Method™.
It’s the practical structure for everything he described—a delivery model built on proven software practices, translated for the realities of manufacturing, data centers and solar plants.
“Momentum is our evidence-based, agile development methodology,” Ryan explained. “It delivers value fast through a series of iterative deployments that build on each success.”
The process starts with deep UX research (Momentum UX) to understand how people actually work. From there, the team enters a solutioning phase (Momentum UI) to define a value roadmap and build an initial product backlog.
Then comes Momentum Launch, an eight-week engagement focused on solving one critical problem. Each launch uses two-week sprints, giving clients a working product quickly and the ability to adjust goals as they learn.
The benefits compound:
- Human-centered design leads to faster adoption.
- Goal-based execution keeps projects aligned with measurable value.
- Iterative sprints make it safe to test new technologies or ideas.
- Frequent deployment turns sunk cost into visible ROI.
And perhaps most importantly, it changes how transformation feels. Teams see tangible progress every few weeks instead of abstract promises months away.
Building Your Digital Plant, One Win at a Time
Ryan closed his session with a challenge to both integrators and end users: stop accepting long timelines as inevitable.
“If you are an end user who's building applications, do not let your internal team or an integrator string you along for months and months and months before you get an ROI. You can get an ROI inside of 90 days. You shouldn't have to wait.”
That mindset—short cycles, measurable value, continuous improvement—is what will finally bridge the gap between ambition and execution in digital transformation.
The Digital Plant isn’t a single system or platform. It’s an ecosystem that grows and adapts. By borrowing the best practices from the broader software world, industrial teams can build that ecosystem faster, with less risk, and with far more confidence in the outcome.
If you’re interested in learning more about the Momentum Method or have questions about digital transformation, feel free to check out our page or reach out to someone on our team. And if you'd like to watch the full talk, check it out here!
Comments