Skip to content
Nerdy beta

From Tooling Sprawl to Product Alignment

Case Study Product Operating Model Workflow

The Situation

This is an anonymized account of Nerd/Noir work with a global online travel company. The client was implementing a product operating model, and their Jira estate was actively working against it. Years of growth, mergers, and acquisitions had left every team and group with its own dialed-in configuration, each one leaning on the tool as a substitute for actual practices and workflow. To understand how the whole system operated, you had to go tribe by tribe and learn the local customs. Basic questions like “when will this product ship?” required archaeology.

There’s a Conway’s Law twist buried in here: the client’s Jira had grown exactly the way Atlassian itself grew, one team, one merger, one acquisition at a time, each arrival minting a new configuration. The consumer’s tooling had come to mirror the vendor’s org history.

The sprawl was measurable. Twelve different custom “team” fields did the job of one default. Dozens of pages and hundreds of schemes and configurations sat abandoned but still in the way. Teams had quietly stopped using whole swaths of functionality because required fields made the tool too demanding to bother with. The data leadership wanted was technically in there and practically unreachable. And when the complexity finally came down, a telling thing happened: some leaders missed it, because all those custom states had made pinpoint micromanagement possible. The teams did not miss it.

What We Did

The client made a smart strategic call early: don’t just make Jira compatible with the product operating model, use Jira to actively advance it. The tool became an instrument for increasing transparency, surfacing problems, and feeding the metrics the model runs on. That framing shaped everything downstream, because it turned every configuration decision into a product decision.

So we treated the tooling like a product. We built personas for the operating model’s roles, ran story mapping against them, and carved out the journeys that mattered most. A portfolio manager’s journey through the tool is nothing like a software engineer’s; engineers mostly want Jira updated as a side effect of good commit behavior, not as a second job. Anchoring priorities in those real journeys kept the redesign honest.

We also named the values the redesign would stand on: simplicity, reduced redundancy, team-centricity, and lean agility. Every requested tweak got lensed through them. Does this make the system simpler, or does it reintroduce preventable complexity? That one question killed most of the special cases before they started, in the spirit of process minimalism.

Some customization was legitimate and had to stay. The client’s in-house A/B testing framework was deeply integrated, so rather than fight it, we isolated it, treating it almost like a microservice attached to Jira. The experimentation teams kept their fast feedback loops without their customizations bleeding into everyone else’s work items. Service requests got the same treatment: re-segmented away from software work items so neither degraded the other’s flow. Dozens of integrations came down to a couple.

Rollout ran through people, not mandates. We used a train-the-trainer approach aimed at development managers, release managers, and the folks formerly in Scrum-master-shaped roles, the people closest to the teams, so knowledge flowed from local authority rather than from a central office. We mined the training sessions (with an AI assist) for the topics that generated the most discussion and used those to program office hours: part targeted re-teaching, part open Q&A, and a genuine feedback loop for teams who just needed to be heard.

Migration started with a small pilot spanning both product and platform teams, with hands-on support through about a month of sprints. After the pilot validated the approach, everyone switched. The clean setup lived in the same Jira instance as the mess: gold-copy templates, a golden path, from which teams spin up new spaces with simplified defaults already applied. Teams kept real freedom over their own boards, dashboards, and plans, while changes with organization-wide blast radius rolled up for centralized review. Decisions close to the team stay with the team; decisions that shape the whole system don’t.

The Results

The migration completed, the tooling now reinforces the product operating model instead of undermining it, and the whole thing was done lean: one embedded Nerd/Noir collaborator working alongside a small client team, backed by leadership that held the line on the vision. Teams report the new setup is faster and less micromanagy, and leadership still gets the data that matters.

The most useful result is the least obvious one. The pressure to revert, and the old chaos that used to be smeared tacitly across the entire organization, is now corralled in one visible place. It’s like walking into a dark room and turning on the light: the challenges didn’t vanish, but nobody has to search the whole city for them anymore. That focus is a strategic lever for the operating model’s larger ambitions.

It’s ongoing work, and it should be. You can’t kill entropy. You can only decide where it lives, and keep the light on.

Resources