Skip to content

 
 
 
IMAGINE EXECUTIVE BLOG SERIES

How we build:
Product strategy and R&D grounded in customer reality

The broadcast technology industry has seen too many platforms arrive over-engineered, under-tested, and misaligned with how customers actually operate. Technically impressive demonstrations that fall apart under real-world pressure. Ambitious roadmaps that don’t account for the messy reality of live production environments.

We know this because we’ve been there.

A turning point

Let me tell you about a deployment that changed everything for us. A few years ago, we were working with a major North American broadcaster on one of our first large-scale implementations of multisite origination and distribution capabilities. The project involved consolidating multiple independent broadcast centers serving dozens of channels across two major facilities.

We thought we understood how customers would use this technology. We had designed it, tested it internally, and believed we were ready. But actually watching operators use it every day, seeing where their workflows stumbled, understanding which features they reached for instinctively and which ones sat unused — that taught us what no amount of internal testing could.

I remember sitting in their operations center during a particularly intense production week. The team was managing a complex multi-feed scenario, and I watched as they tried to accomplish something our system was designed to optimize. It worked, but it required three extra steps we never anticipated.

Our customer didn’t complain. They just worked around it. But we took note.

That experience taught us that innovation without operational practicality isn’t innovation; it’s a liability. What we build and how we build it must both start with customer reality, not lab scenarios.

Executives at Imagine Communication in a meeting

Building quality in, not bolting it on

You can’t deliver reliability by testing harder at the end. Quality has to be built into the process from day one.

Our VP of engineering, Steve Sulte, has driven fundamental changes in how R&D operates. As he explained to me recently, “We build systems that are representative of the customer environment. We don’t depend on idealized lab setups. Our dedicated, customer-focused systems are configured the way customers actually deploy our products.”

This approach transformed our release process. Steve continued, “We share test plans and test cases openly with customers. We install sandbox test-beds next to our customer production systems. The cases customers run, we run in parallel. This eliminated situations where features were scoped and the customer went off and did a test plan we never saw, testing things in ways we knew would fail.” Synchronizing test plans early exposes gaps that can be easily overcome. 

We’ve also dramatically increased automated validation, using frameworks to provide comprehensive coverage without relying on manual testing that can vary from person to person. This allows our QA talent to focus on scenarios that can’t be automated effectively.

Partnership internally and externally

We’ve fundamentally restructured how product management and engineering work together. Product management, facing outward, is responsible for understanding customer needs and defining the roadmap. Engineering, focused inward, is accountable for delivering a quality product on time.

This separation of concerns, with tight collaboration between the teams, replaced the old model where everyone had input but accountability suffered. Now we can move faster because roles are clear, and we can deliver products more efficiently because the right people are making the right decisions.

But here’s what really makes it work: the partnership isn’t just between product and engineering. On major deployments, you’ll find our senior leaders from across the company on regular program calls. Not micromanaging, but listening, ensuring alignment, and clearing obstacles. Our sales, engineering, product, and customer care teams work as genuine partners — both with each other and with our customers.

Executives at Imagine Communication in a meeting

Learning across customers and markets

One of our unique advantages is our global customer base. We see how broadcasters worldwide solve similar challenges. When a European broadcaster develops an innovative workflow, we can bring that proven approach to a North American customer facing a similar need.

This isn’t just about products; it’s about operational knowledge. Our teams include people who’ve worked as traffic directors, operations managers, and engineers at customer sites. They understand the pressure of the broadcast environment because they’ve lived it.
 

Coming full circle

Remember that deployment I mentioned at the beginning? When our customer’s workflow needed those extra steps. We didn’t just note it and move on. We brought it back to engineering, worked through the changes, and adjusted our approach. The next customer who needed similar functionality found it intuitive from day one.

That’s how we build now. Not in isolation, but in partnership. Not based on assumptions, but on reality. Not with shortcuts, but with discipline.

When our customers tell us they keep coming back to Imagine because we can solve their problems, it’s not about having the flashiest demo. It’s about having the operational expertise, quality processes, and customer focus to deliver solutions that actually work when it matters most.

Imagine Executive Blog Series

Want to see where it all started: CEO Steve Reynolds outlines how Imagine changed its internal culture—strengthening accountability, delivery discipline, and responsiveness to rebuild customer trust.

Executives at Imagine Communication in a meeting
A headshot of Brendon Mills

Brendon Mills

Chief Product Officer

Brendon Mills is the Chief Product Officer for Imagine Communications. In this role, Brendon oversees the strategic direction of the company’s market-leading Video and Ad Tech solution portfolios.

Stay connected!

Be the first to know about latest news, updates, and more. Subscribe now!

"*" indicates required fields

This field is for validation purposes and should be left unchanged.