by Sandy Ludington
May 5, 2026
Today we’re telling a software story about Josh, a senior product professional at a fast-growing data company.
Josh was excited to forge ahead in some new data products. He had spent the last eight years leading teams in developing specialized, complex data products to provide market insights for institutional investors – the kind of edge they can only get when people like Josh and his teammates spend the time to build a custom methodology. Now he was tasked with finding ways to serve corporate clients with similar products. How could the company take raw data and turn it into actionable insights for corporates – the kind they couldn’t get anywhere else – just as they had done for institutional investors?
Josh had seen dozens of successful data products built for institutional investors and they all required ingenuity and methods that resisted classification. No two were alike, but they were successful, and the company had proven they could be maintained despite their idiosyncrasies – so long as high-performing teams remained dedicated to them. He hired Alex to lead the team creating the new corporate-focused products, confident this task would require the same ingenuity so important to each of Josh’s previous product experiences. He also knew that the solution would look unlike anything else he’d previously known.
Alex got to work, but his perspective was different from what Josh had seen the last eight years. Alex recognized that the product would need to be distributed automatically across hundreds of clients, that it had more interactions and dependencies than the custom products built and maintained manually in Josh’s experience, and that it would need to continually expand with new additions without losing capability. This new product suite would be a complex system, and it needed to be managed in ways that other data products had never been managed before.
Alex defined requirements, created standards, specified components of the system, created means to validate the integrated product performance, and established performance monitoring for the deployed product. These were all early versions, but they were essential to setting a path for the long, complicated development work the team would embark on. He shared his vision with Josh.
At first Josh recoiled, “I’m not sure we want to put a lot of process around this. We’re building something new and we need to be able to adapt.” Josh had only ever seen data product teams succeed when they were unleashed to build as they saw fit, taking every necessary liberty in their methodology and their structure to arrive at the solution that was uniquely best for their application. Alex’s requirements, plans, and metrics seemed to put a lot of limitations on what a product team could do. And layering limitations was not the objective.
Rather than multiplying limitations though, Alex’s systematic approach led to growth. With defined structures and methodologies, clear requirements, and performance metrics, product developers were able to build and integrate at unprecedented scale. The new product suite became the fastest-growing in the company and it delighted customers who had never-before-seen capabilities at their fingertips.
The same holds true whether in software or hardware – the customers’ needs, system constraints, and physical reality all influence what you can do or should do. Success demands rigorous product development practices – especially when the consequences are high, the product is complex, or the scale is large. When your product is all of these, your team cannot reach the finish line without well-developed systems engineering practices. What may feel like “a lot of process” is actually an essential discipline, without which your products will struggle.