A support ticket can look like a support problem.
Sometimes it is.
But sometimes the ticket is only where the problem becomes visible.
Hatch is a good example.
When Adam Jacox joined Hatch as VP of Engineering, integrations had become a significant bottleneck.
Hatch's platform depended on data from customers' CRMs and lead-source systems. The team had been building bespoke integrations for individual customers.
One customer would need specific data from a CRM, so Hatch would build an integration for them.
Another customer would need something slightly different, so the team would build more custom code.
Over time, maintaining those integrations became difficult.
The integrations were unreliable. Customers were reporting problems. And Hatch's engineering team was spending 30–40% of its engineering capacity on integrations.
That number is easy to focus on.
But there is something more interesting underneath it.
The customer wasn't buying an integration.
They were trying to use Hatch.
The integration was simply part of the implementation path required to make the product work for them.
When that path became difficult or unreliable, the consequences didn't stay inside the integration itself.
Customers experienced problems.
Support had to deal with those problems.
Engineering had to maintain and troubleshoot the underlying systems.
And engineering capacity that could have gone toward the core product was being consumed by integration work.
Hatch eventually changed how it handled integrations.
Instead of continuing to build one-off integrations for individual customers, the team moved toward productized, configurable integrations that customers could activate themselves.
The result was not just an engineering change.
Hatch reported fewer support and bug tickets, faster customer onboarding, and increased customer satisfaction.
That distinction matters.
The visible problem was integration work.
The larger problem was what customers had to go through to successfully implement the product.
The support ticket is often not the starting point
This is something I pay attention to when looking at developer-facing products.
A customer doesn't usually wake up and decide to create a support ticket.
They are trying to accomplish something.
They are trying to authenticate.
They are trying to connect an API.
They are trying to configure an SDK.
They are trying to deploy something.
They are trying to move data from one system to another.
They make a decision based on what the product appears to require.
Then they discover that the actual implementation is different from what they expected.
That's where friction starts.
Sometimes the customer figures it out themselves.
Sometimes they search through documentation.
Sometimes they ask support.
Sometimes the problem eventually reaches an engineer.
The ticket is visible.
The implementation problem that created the ticket is often less visible.
This is where implementation risk shows up
A developer-facing product can look straightforward from the outside while still creating difficult implementation paths for customers.
The product may expose an API, SDK, integration, deployment workflow, or configuration system that appears to work one way.
But the customer may still have to handle something they didn't expect.
Or make a decision they didn't realize they were responsible for.
Or discover a limitation only after they have already built around an assumption.
Those details matter because they affect what happens after the customer starts implementing.
A small mismatch can become:
- another support conversation
- a failed integration
- engineering investigation
- implementation delays
- repeated questions from different customers
- production problems
None of those necessarily start as an obvious product problem.
They can start with the customer's implementation path.
That's what I look for at DaxMac
At DaxMac, I investigate how customers actually implement developer-facing products.
I look beyond whether a product has good-looking documentation or a clean API reference.
The question is:
What can a customer reasonably believe they need to do, and what actually happens when they try to do it?
That means following the implementation path from the customer's side.
For API and SDK products, that can include validating the actual API behavior.
For other developer-facing products, it can mean looking at configuration, deployment, integrations, authentication, or other parts of the implementation process.
The goal isn't to produce another documentation review.
It's to find the points where implementation can go wrong before they become expensive problems for the company.
Hatch's story is a useful reminder of why that matters.
The support ticket may be what the company sees.
But the customer's implementation experience is often where the problem started.