Customer Zero: How Running Our Own Products Became Our Edge

The first time someone outside IT asked me to defend GoPilots, the question was sharper than I expected. A product leader, mid-meeting, no warm-up: “Why should we weight your feedback over a paying customer’s?”

Fair question. The honest answer turned out to be the whole thesis. We do not weight it higher because we are smarter. We weight it higher because we are the only customer in the room who has already absorbed the cost of being wrong about the product — in production, at scale, on our own service desk, with our own users watching. A roadmap request is a wish; our feedback is a wound we already took. That is the reason an internal IT team became a source of product advantage instead of a line on a budget.

This is the origin story of how that happened — and the one claim in it I will defend.

The decision nobody volunteers for

In the summer of 2023, my organization moved the entire corporate IT service desk off Samanage and onto GoToResolve — the company’s own product, which at the time did not yet have feature parity with the mature platform we were leaving. We knew it had gaps. We moved anyway, and we retired the fallback rather than run both.

Read that back as a CFO would, and it sounds reckless: trade a stable, capable platform for a less mature one, and delete the safety net your support operation falls back on when something breaks at 2 a.m.

The reframe is the entire point. We were not buying a tool. We were buying a seat — the standing to shape a product the company sells, paid for in the only currency a product team actually respects, which is having run the thing in production, under real load, and owned the gap. That is the move that converted IT from a consumer of vendor output into a participant in product development. Not the technology. The decision to be early, on the record, and accountable for what was missing.

A practical note for anyone weighing this, because the decision is more bounded than it sounds: you do not go Customer Zero on everything at once. You pick the one workflow where the product’s gap is real but the downside is survivable and reversible — where, if it goes badly, you can route around it without a compliance failure or a revenue outage. The service desk qualified. A billing system in a regulated revenue path would not have. Choosing the survivable bet on purpose is what separates a deliberate program from recklessness.

Why credibility, not quality, is the real return

The standard defense of running your own products is quality assurance — you find the bugs before customers do. That is real, and the numbers bear it out: 233 feature requests and bug reports into the GoToResolve ticketing track, 46% integrated, with a separate asset-management track of 68 requests integrated at 57%. Defects caught before a paying customer ever met them.

But quality assurance is the smaller half of the return, and treating it as the whole story is the mistake I watched other teams make.

The larger half is credibility — and credibility compounds in three directions at once.

It compounds toward the product organization

A product team can dismiss a feature request. It cannot dismiss a team that has retired its own fallback and is operating on the gap right now. The feedback that moves a roadmap is not “this would be nice.” It is “here is the exact enterprise workflow this breaks, here is the workaround we are running today, and here is what has to change for us to delete that workaround.” Only a team that took the operational risk can write that sentence. The risk is what makes the feedback credible.

It compounds toward the business

When leadership needs to show that the product holds up at enterprise scale, the strongest evidence is not a slide. It is a live internal deployment running across a global, multi-region organization — a production proof point the business can point to, on its own books, at its own scale. We did not set out to become that proof. We became it because we had taken the operational risk in the open, and proof of that kind is something a roadmap promise can never be.

It compounds toward IT’s own standing

Here the return is one a tooling diagram never shows: an IT organization that visibly makes the company’s product better is no longer in the conversation it is forever trying to escape — the one where it explains its own cost. I have made the case before that the cost-center frame is the most expensive story IT tells about itself. Customer Zero is the sharpest exit from it I have found, and what makes it sharp is that the standing is non-transferable: it lasts exactly as long as you stay on the gap, and it evaporates the day you quietly re-adopt a fallback. A talking point you can borrow. This you have to keep paying for — which is precisely why it reads as real.

Promote the idea most people miss

Before the part where it almost broke, the non-obvious claim, because a skimming executive should not have to reach the end to find it: you do not run your own products to collect the wins you can foresee. You run them to manufacture the surface on which the wins you cannot foresee become possible.

The proof of that came later, and we did not design it. Once IT was operating its own ITSM platform in production, with the product organization paying close attention to how we ran it, the conditions existed for something none of us had scoped at the start. We built Tech-E — an AI support assistant — inside that same product, and it drove 28% ticket deflection while CSAT rose 12 points. I have written separately about how that assistant was actually built and why the discipline mattered. The point here is narrower and more important: Tech-E exists because GoPilots existed first. The Customer Zero relationship created the surface an AI integration could grow on, and the product team learned from what we did with it. We did not plan that adjacency. We made it possible — a more durable thing than planning it.

The integration rate is the visible return. The optionality is the real one.

The part where it almost did not work

The honest version of this is not a clean win, and the place it nearly broke was internal, not technical.

When you put your own service desk on a product with known gaps, the team feels the friction first and hardest. They are the ones explaining to a frustrated user why something that worked last month now needs a workaround. If that team reads the program as “leadership volunteered us to be a beta tester,” the whole thing curdles — they protect themselves from the product instead of improving it, and the feedback loop dies quietly.

What kept it alive was a structure, not a slogan — and it is the most copyable thing in this piece, so here is the whole of it. First, dedicated channels: specialized Slack-to-Jira lanes connecting our users, the development teams, and the program leads, so friction became a logged ticket instead of a private complaint. Second, structured intake: every issue written up in Jira against the product, not vented in a hallway. Third, named ownership: program sponsors accountable for the loop, and IT run as an internal MSP to the rest of the company — Security, HRIS, Payroll, and others eventually filing through the same channels. Three parts: a feedback channel, an issue-tracking system, and accountable owners. You can stand that up next week.

The lesson I would name in one sentence: the cost of Customer Zero is paid by your team before any benefit reaches the business, so if you have not made that cost visible, owned, and resourced, you have not started the program — you have just downgraded your own tooling.

The one position I will defend

So, back to the product leader’s question.

Running your own products is treated, almost everywhere, as a quality tactic — a way to find bugs early. That framing undersells it to the point of getting the strategy wrong. Here is the position a generalist cannot sign, because it only holds if you have actually paid for it:

Customer Zero is a credibility instrument, and its value is the standing it buys, not the defects it catches. But that conversion is not automatic, and naming where it fails is what separates the claim from a brochure: the exposure only becomes leverage if the product organization is structurally obligated to receive what you find — a shared forum, executive sponsorship, a real intake path. Without that, you have taken on the risk and downgraded your tooling for nothing. With it, the willingness to retire your own fallback and operate on the gap on purpose is the entire moat — because almost no team will do it. Any team can file tickets against a vendor. Almost none will give up the safety net and stand in the gap themselves. That is not a matter of courage. It is a matter of being willing to pay a structured, repeatable cost, in the open, and to resource it well enough that the team carrying it never has to ask why.

That is what turned our IT team from a cost the company managed into an advantage the company could point to. Not a tool we bought. A risk we took, structured well enough to keep, and honest enough to credit the team that carried it.

Common questions

What is Customer Zero in IT?
Customer Zero is when an IT organization runs the company’s own products in production, at enterprise scale, before or alongside paying customers, and feeds what it learns back into product development. At GoTo, that program is GoPilots. The distinguishing move is not using your own product; it is deliberately becoming the customer most exposed to the product’s flaws, then converting that exposure into roadmap influence. The IT team retired a mature platform (Samanage) for the company’s own GoToResolve despite known feature gaps, putting its own service desk on the hook for the difference.

Why did GoTo IT move off a mature platform to its own product?
To earn the standing to shape a product the company sells. In the summer of 2023, GoTo’s IT organization moved its entire corporate service desk from Samanage to GoToResolve, which did not yet have feature parity with the platform it replaced, and retired the fallback rather than run both. The trade was deliberate: absorb operational friction in exchange for production-grounded influence over the product’s direction. Feedback from a team running the product with no safety net is feedback a product organization cannot easily dismiss.

How is running your own products a source of credibility rather than just quality assurance?
Catching bugs before customers do is the smaller half of the return. The larger half is credibility, and it compounds three ways. Toward the product organization: a team operating on the gap writes feedback specific enough to move a roadmap. Toward the business: a live multi-region deployment is a production proof point a roadmap promise cannot match. Toward IT itself: an organization that visibly improves the product stops having the cost-center conversation. Crucially, that standing is non-transferable — it lasts only as long as the team stays exposed, which is exactly why it reads as real.

How did GoPilots lead to the Tech-E AI assistant?
Tech-E exists because GoPilots existed first. Once IT was operating GoToResolve in production with the product organization watching closely, the surface existed for an AI support assistant to be built inside that same product. Tech-E drove 28% ticket deflection while CSAT rose 12 points. The adjacency was not planned: running the product as Customer Zero manufactured the surface on which an unforeseen win became possible, which is the deeper argument for the model.