Long Suciu’s most dramatic lead time reduction did not come from a process framework, a tooling change, or an organizational redesign. It came from a conversation. In this segment of his discussion with Patrycja Radwanska on the Let’s Talk Operations series, he recounts how a travel industry API team went from 52-week delivery cycles to shipping within a single quarter – and how the catalyst was a product director who looked at a feature backlog for the first time and said five words that changed everything.
The Setup: One to Two Years Was Just Normal
The team Suciu was consulting for built APIs for the travel industry. Airlines tapped into their product to access database and client services. The delivery model was traditional in the most literal sense: a product director would assemble a business case, secure funding for a two-to-three-year project, resource a team, and then the team would build the entire feature set before anything went to production.
A one-to-two-year cycle from start to deployment was not considered a problem. It was considered normal. Nobody had questioned it because nobody had been given a reason to. The organization operated on a project-oriented model where everything – funding, resourcing, planning – was structured around delivering a complete package. The idea of shipping a piece of that package independently had not entered the conversation.
The Intervention: Map the Journey, Not the Requirements
Suciu’s approach was not to introduce agile terminology or impose a framework. It was to ask a different question. Instead of “what are the requirements?” he asked “what is the customer journey when they use your APIs?” The distinction sounds subtle. Its effects were not.
When the team started mapping the customer journey – how users actually interacted with the product, step by step – the monolithic set of requirements began decomposing naturally into discrete features. Not because someone mandated smaller work items, but because the journey itself had natural boundaries. Each step in the journey corresponded to a distinct capability, and each capability could, in principle, exist independently.
The team, the product manager, and eventually the product director worked through this mapping together. And then the moment arrived.
“Instead of having to get all the features before releasing it publicly, the product director saw a feature that could be immediately used.”
The product director looked at the feature backlog that had emerged from the journey mapping and recognized something that had been invisible when the work was framed as a bundle of requirements: one of those features was useful on its own. Right now. Without waiting for everything else. They did not need the complete package. They needed that API, and they needed it this quarter.
The Shift: From Monolith to Incremental Delivery
The team built and shipped that single feature within the quarter. What had been a 52-week minimum became 13 weeks for the first delivery. The psychological shift was more significant than the timeline improvement. The product director had experienced, firsthand, the possibility of getting value sooner – and once that experience lands, the old model of bundling everything into a multi-year project stops being the default. It starts looking like a choice, and not a particularly good one.
Incremental delivery became the new mode. Instead of asking “when will the whole thing be done?” the conversation shifted to “what can we ship next?” Each subsequent feature was scoped, built, and delivered on its own timeline. The overall product still came together, but it came together through a series of usable releases rather than a single monolithic deployment.
The funding model was the root cause of the original dysfunction. When you resource a team for a two-to-three-year project and evaluate success by whether the complete package ships, there is no incentive to ship anything sooner. The structure rewards completion of the whole, not delivery of the parts. Suciu did not attempt to change the funding model directly. He changed the conversation about what counted as a deliverable, and the funding model’s grip loosened as a consequence.
Why the Customer Journey Was the Right Entry Point
The reason journey mapping worked where process mandates would not have was that it changed the object of discussion. Instead of debating practices, methodologies, or delivery models – conversations that trigger organizational antibodies in any company that has been doing things a certain way for years – the team was talking about their customers. That is a conversation everyone wants to have. It does not feel like a threat to anyone’s authority or expertise. It feels like doing the job better.
And the decomposition that emerged from the journey was not artificial. It was not someone coming in and saying “you need to break your epics down to two weeks of work.” The features fell out of the journey naturally, and the priority order was determined by the person with the authority to determine it – the product director – who made the call based on what they could use immediately.
The lesson Suciu draws is that the most powerful agile transformation technique he has found is not a framework or a metric or a tool. It is putting the right people in a room, asking them to describe how their customers actually experience the product, and then letting the implications of that description do the work. The 52-to-13-week reduction was not engineered. It was discovered.
For the full interview breakdown, see our complete Expert Insight with Long Suciu.
Tools Mentioned in the Interview
The following tools and platforms were referenced during this conversation.
Related Content
Scaling Product Operations Without Breaking Teams: Expert Insights with Long Suciu
Long Suciu has spent 25 years redesigning how product and engineering teams plan, prioritize, and ship. He breaks down why story points are often the first thing to cut, how a six-week quarterly planning cadence brought alignment to 30+ teams at Gartner, and why tools must reinforce behavior rather than replace it.
Why Dropping Story Points Is the First Move in Any Agile Transformation
Long Suciu explains why eliminating story points -- a practice used by 90% of software teams -- is often the single most productive shock to the system when transforming how teams plan and deliver.
How Productboard and Jira Alignment Eliminated the Slide Deck Problem
Long Suciu traces the journey from objectives in slide decks to a fully integrated Productboard-Jira system at Gartner -- a transformation that got 70 product managers working at the right altitude and kept Jira clean for the teams actually executing.