Finding the Pattern: Reporting Add-On at CIMx

Context

CIMx sells manufacturing execution system software to highly regulated industries — think aerospace, medical devices, complex discrete manufacturing. The product's differentiator was a single, configurable platform rather than the expensive modular bundles or fully custom builds that dominated the market. My title was Application Specialist, which in practice meant I demoed the software, went on-site to gather requirements for implementations, handled support, and acted as a junior Product Owner for existing customers.

Problem

I was early in my career and honestly struggling with the sales and demo side of the role. It wasn't my strong suit, and I was actively looking for ways to contribute differently. Reviewing past implementations, I noticed a pattern: we were building the same custom reports over and over for different clients, charging custom rates each time, and treating it as one-off work. The reports weren't exotic — they were nearly identical views of data that most manufacturers needed. We just hadn't productized them.

My Approach

I proposed building a reporting add-on package: a set of mostly pre-configured reports with limited customization options, offered at a lower price point than fully custom work. The pitch internally was "take it or leave it" and the addon was standardized enough to be repeatable, but flexible enough to be useful.

To figure out what should be in it, I reviewed previous implementation notes and sales records to identify which reports we'd built most often and which gaps customers consistently mentioned in our core product. I also did some market research, though it wasn't particularly useful — this was around 2017 and most MES competitors didn't disclose product details publicly, let alone reporting capabilities.

I wrote the reports myself with engineering support, which was my first real hands-on work with SQL and data querying. The pricing model followed an approach already used elsewhere in the business: customers could get a discount on the add-on if they agreed to let a templatized version of their custom report be added to the package, making it more valuable for the next buyer.

I won't overstate my autonomy here — I was junior, I asked for direction more than I probably needed to, and leadership held the go/no-go on whether add-ons were even worth pursuing as a model. But the pattern recognition, the proposal, and the execution were mine.

Outcome

The next two customers I was present for both purchased the package, generating roughly $10K in new revenue. More importantly, it shifted our internal thinking: the prior assumption had been that stock reports weren't useful and custom was the only real option. This was early evidence that a middle path — standardized but reasonably priced — had real demand.

What I'd Do Differently

Talk to existing customers directly before building. I worked from implementation notes and sales records, which were useful proxies, but real conversations would have surfaced what people actually cared about versus what they'd asked for in the past. In a regulated industry where customers are often guarded — there's a persistent "what's the catch" wariness in manufacturing sales — that kind of direct research requires more trust-building than a cold survey. But it's worth the effort, and I'd prioritize it now in a way I didn't then.