Building one product development lifecycle across three continents

As product organizations grow, complexity rarely comes from the products themselves. More often, it comes from the way teams work.

Processes evolve organically. Teams adapt to local markets. Product managers develop their own approaches to discovery, prioritization, and delivery. Over time, these ways of working become deeply embedded – and, in many cases, incredibly effective.

The challenge begins when those teams need to work together.

During my time at American Express, I've had the opportunity to work alongside product, engineering, and design teams across the US, UK, and India. Although we were united by a common purpose – delivering products that created value for our customers – our approaches to product development had naturally evolved in different ways.

None of those approaches were wrong. But as our organization continued to grow, the differences became more noticeable. Product artefacts varied between regions, governance wasn't always consistent, and teams often had different interpretations of what it meant for a product to be ready to move from discovery into delivery.

It wasn't a process problem. It was a collaboration problem. 

To solve it, rather than asking, "How do we make everyone work the same way?" we asked, "How do we create enough consistency that great teams can collaborate effortlessly, wherever they're based?"

That distinction shaped everything that followed.

Standardization is about clarity, not control

One of the biggest misconceptions about standardization is that it removes flexibility. In reality, the opposite is true.

The best operating models don't prescribe every activity or dictate every decision. They create clarity around outcomes, responsibilities, and decision points, while allowing teams the autonomy to determine how they achieve them.

That became one of our guiding principles. Rather than attempting to replace successful local practices, we focused on establishing a common product development lifecycle that everyone could understand and trust. It wasn't about introducing more governance. It was about reducing ambiguity.

Start with principles before process

Before we designed a single template or governance checkpoint, we spent time understanding how teams were already working. We spoke with product managers, engineering leaders, designers, and delivery managers across each region to understand what worked well, where teams experienced friction, and what they wished was easier.

Those conversations revealed an important truth: the differences weren't rooted in capability. They were rooted in context. Each team had optimized for its own environment.

Instead of asking people to abandon that expertise, we identified the principles that should remain true regardless of geography:

• Every product initiative should begin with a clearly understood customer problem.
• Engineering should be involved early enough to shape solutions rather than simply estimate them.
• Product decisions should be supported by evidence, not assumptions.
• Success should be measurable long after launch.

Those principles became the foundation of the lifecycle.

Designing a lifecycle people would actually use

One lesson I've learned throughout my career is that nobody adopts a framework simply because it's well documented. People adopt frameworks because they make work easier.

With that in mind, we designed a product development lifecycle that balanced consistency with flexibility. Each initiative progressed through a common set of stages, from opportunity identification and discovery through to product definition, delivery, launch, and continuous improvement.

Rather than prescribing every activity, each stage answered four simple questions:

1. What outcome are we trying to achieve?
2. What evidence do we need before moving forward?
3. Who needs to be involved?
4. What decisions need to be made?

That structure created enough consistency for teams to collaborate effectively while allowing individual product teams to adapt their approach depending on the complexity of the work.

Creating a shared product language

One challenge that often goes unnoticed is language. Ask five product managers to define terms like MVP, discovery, roadmap, or ready for development, and you'll often hear five different answers. Those differences seem harmless – until multiple teams need to collaborate.

One of the most valuable outcomes of our work was creating a shared product vocabulary that aligned expectations across product, engineering, and design. Conversations became simpler because everyone was working from the same definitions. For new joiners, onboarding became less about learning regional nuances and more about understanding the product itself.

Templates were never the goal

Like many organizations, we already had documentation. What we lacked was consistency.

As part of the wider operating model, we introduced a standard set of product artefacts covering discovery, product definition, prioritization, launch readiness and post-launch learning.

The templates themselves weren't revolutionary. What changed was the confidence they created. Whether a stakeholder was reviewing work from New York, Brighton, or Bengaluru, they knew where to find the information they needed and what they could expect to see. The conversations became richer because less time was spent interpreting documentation and more time was spent discussing customer outcomes.

Rethinking governance

Governance often carries an unfair reputation within product organizations. Too often it's associated with approval gates, lengthy documentation, and unnecessary delays.

We approached it differently. Instead of asking whether teams had completed a checklist, governance became an opportunity to ask better questions:

• Have we validated the customer problem?
• Do we understand the technical dependencies?
• Have we identified delivery risks early?
• How will we know if this initiative has been successful six months after launch?

That subtle shift changed the nature of the conversation. Governance stopped feeling like oversight and started becoming a mechanism for improving decision quality.

Adoption happens through ownership

Looking back, one of the biggest reasons the work succeeded wasn't the framework itself. It was the way it was created.

Rather than building the operating model centrally and asking teams to adopt it, we involved colleagues from every region throughout the design process:

• Product managers challenged assumptions.
• Engineers highlighted practical considerations.
• Designers brought the customer perspective.
• Delivery teams identified where additional clarity would help.

The framework became something we built together, rather than something that was imposed. That shared ownership made adoption significantly easier than any formal rollout plan could have achieved.

What changed

It's easy to measure outputs when introducing a new operating model – the number of templates created, the governance forums established, the documentation published.

The more meaningful outcomes, however, were behavioral:

• Teams collaborated more naturally because expectations were aligned.
• Product managers could move between programs with less friction.
• Stakeholders developed greater confidence because product decisions were presented consistently.
• Cross-functional conversations became focused on solving customer problems instead of debating process.

Perhaps most importantly, the product development lifecycle became an enabler rather than an obstacle. People spent less time navigating how work should happen and more time delivering value.

Five lessons for product leaders

Reflecting on the experience, five lessons stand out:

1. Standardize principles, not personalities: Great product teams thrive when they're given clarity, not rigid instructions.
2. Build with your teams, not for them: Adoption begins long before launch. The people expected to use a framework should help shape it.
3. Treat your operating model like a product: Gather feedback, iterate regularly, and improve continuously. No framework is ever truly finished.
4. Make governance about decision quality: The purpose of governance is to increase confidence, not increase paperwork.
5. Never lose sight of the customer: The product development lifecycle exists to help teams solve customer problems more effectively. When process becomes the objective, you've lost the point.

Final thoughts

Standardizing product development across global teams is rarely about creating the perfect framework. It's about creating the conditions for people to do their best work together.

For me, one of the most rewarding aspects of this experience at American Express wasn't seeing a new lifecycle documented or a new governance model adopted. It was watching product teams across three continents begin to collaborate with greater confidence, speak a common language, and spend more time focused on what mattered most: delivering better outcomes for our customers.

That's the real value of a product development lifecycle. Not consistency for its own sake – consistency that creates the space for innovation to flourish.