How We Turn Customer Needs into Product Features

When an enterprise customer comes to you with a tough data quality problem, you have two choices: build a one-off solution for just them, or create something that transforms your platform for everyone. At Bigeye, we chose the latter when a major financial institution approached us with sophisticated requirements that our existing tools didn't fully address.

What emerged from that partnership wasn't just another feature, it was our Advanced Data Quality suite, including features like customizable data quality dimensions, join rules, and asset linking that now serve customers across a variety of industries. Here's the inside story of how we turned one customer's urgent need into capabilites everyone could use.

Starting with the Real-Life Problems

The process begins long before any mockups or code. Kyle Kirwan, our Chief Product Officer, explains how these opportunities typically surface: "Many times one of their team members who is using Bigeye for other tasks will ask internally 'Can we use Bigeye for X?' which ends up in front of the team that owns the Bigeye deployment. We meet regularly with all of our customers and they'll bring this to us during those syncs."

This particular customer’s challenge was particularly complex: they needed to maintain thousands of existing data quality rules while embracing modern observability capabilities.

But identifying the opportunity is just the beginning. Product Manager, Tanner Garrett, emphasizes the importance of approaching discovery with an open mind: "The process usually starts with high level discovery, we sit down with the customer and ask questions about the problem space first, we avoid trying to present any of our current ideas so that we do not bias the customer in the interview."

This unbiased approach is crucial for enterprise customers, who often have complex, nuanced needs that don't fit into neat boxes. By starting with the problem rather than potential solutions, we can uncover insights that would otherwise remain hidden.

The Design Challenge

Once we understand the core problem, the real work begins. Product Designer, Anil Jethani, walks us through the challenge that defines enterprise feature development: "It's always a balancing act between addressing a real, specific customer challenge and ensuring the solution scales. I start by digging into one customer's workflow, that's where the insights are most tangible."

Building out Advanced Data Quality exemplified this perfectly. The customer's data governance requirements were sophisticated and specific, but Anil knew the solution had to work beyond just their environment: "Once we understand the 'why' behind their pain points, we look for patterns across other customers to see if the need holds true more broadly."

Building for Complexity

Enterprise design work differs fundamentally from building for smaller customers. As Anil explains: "With SMBs, the focus is usually delivering immediate value and ease of use. For enterprise, the challenge shifts to integration and scalability to make sure the features fit seamlessly within complex environments that already have established tools and processes."

This complexity drives a more intensive iteration cycle. "The number of iterations depends on the project's size and the complexity of its features. At times, I've gone through as many as seven rounds of revisions, while simpler projects might take just two," Anil notes.

Each iteration involves deep customer collaboration. Tanner describes the back-and-forth process: "Once we feel good about the problems being real and valuable to solve within our product, we begin defining a solution on paper, then in mockups. We'll then follow up with the customer and present the mockups and concepts to validate that they would indeed solve their problem. We gather feedback in that call and refine the concepts."

Proving It Will Work

When you're building for the biggest enterprises in the world, these tools need to work flawlessly in production environments. Customer Success Engineer, Larissa Riley, plays a crucial role in this validation process, serving as the bridge between our product team and customer reality.

"Customer success fosters engagement between the product team and customers to ensure customer needs are being heard directly whenever possible," she says. "However, spontaneous feedback happens often without product around, so I strive to take detailed notes to present internally to them."

The validation process goes beyond simple feature testing. Larissa describes her hands-on approach: "Thankfully, my customers enjoy a good show-and-tell as much as I do when it comes to utilizing new features, so I get to enjoy a hands on validation experience very often. Otherwise, I ask generic questions on how the feature is working and then how it works in association with their use cases."

For the Advanced Data Quality features, validation meant testing across diverse enterprise environments. Could customizable dimensions work with existing governance frameworks? Would join rules perform effectively across different database types? Could asset linking integrate seamlessly with other tools?

For enterprise customers, this validation process is particularly nuanced. "Enterprise teams want new features that fit right into their existing workflows without causing any headaches," Larissa notes. "Before rolling something out, a lot of thought goes into understanding who it helps and how, all while making sure it doesn't disrupt what's already working smoothly."

Balancing Product and Engineering

Kyle describes how product and engineering work together: "Product helps to answer the question 'what problems do our customers need to solve and what does the product need to be able to do in order to meet those needs?' Engineering helps to answer the question 'how can we build the best solution to these problems.'"

Partnership is essential because the best answers often emerge from the intersection of customer need and technical possibility. "The two really need to work together in parallel because engineering can identify amazing solutions once they understand the problem to be solved, but are also most successful when the problem to be solved is relatively well defined."

The discovery process itself evolves throughout the development cycle. Kyle explains: "It depends on what stage we're in but it can range from high level verbal conversations to understand priority, impact on their business, budget available to solve, etc. all the way to clickable prototypes and beta testing pre-production versions of features."

This evolution reflects Kyle's broader philosophy about product development: "I see product development as the identification of potential value in the market (either through being able to serve new customers or being able to solve new problems for existing customers), the understanding of what characteristics a product would need to have to create that value, an understand of what portion of that value goes to the customer and what portion goes to us (in software we want high margins), and then the stages of designing, building, testing, and ultimately marketing that product."

From One Customer to Many

Enterprise product development is about understanding what your customers need and creating solutions that work at scale. Through deep customer collaboration, iterative design, and careful validation, we can take individual customer requests and turn them into platform-wide improvements.

The Advanced Data Quality features that emerged from our customer partnership show how powerful this process can be. The result was a comprehensive solution: customizable data quality dimensions that align with existing governance frameworks, join rules that validate data consistency across different databases, and asset linking that enables precise reporting on critical data elements.

By focusing on the underlying problem the customer needed to solve, and working directly with them to understand implementation, we created something flexible enough to work in different enterprise environments while still solving the original use case effectively.