Two valid ways to release software
Journey maps across four tools and a 50-person survey found two legitimate release strategies on a JPMorgan Chase engineering platform, and ended a product–engineering deadlock.
At a glance
- Role
- Vice President, User Researcher, JPMorgan Chase; led the research end to end
- Organization
- JPMorgan Chase, 2025, on an internal engineering platform used by more than 60,000 technologists
- Methods
- Interviews, workflow diagramming, journey mapping across four tools, a survey of 50 practitioners, moderated prototype sessions
- Outcome
- A validated workflow that supports early and late change-ticket creation, and a release initiative unblocked after weeks of deadlock
Summary
A new release-creation workflow was stalled. Developers and release managers disagreed about when a change ticket should be created; the product team's PM and engineering leads disagreed about what that meant for the design; and leadership assumed the ticket was a simple administrative step. I mapped how releases happen across Jira, Confluence, pipelines and change tickets, then surveyed 50 practitioners. Thirty-two created the ticket early, on a schedule; eighteen created it late, when the code was ready. Both were legitimate. Prototype sessions confirmed that a workflow accepting either order felt natural to both groups, and leadership stopped treating the ticket as paperwork and started treating it as release strategy.
What the team got
- Journey maps across four tools
- How a release moves through Jira, Confluence, pipelines and change tickets, with the handoffs, approval bottlenecks and the points where mental models split.
- Two behavioral segments, with numbers
- Early Planners (32 of 50, schedule-driven, governance first) and Just-in-Time Releasers (18 of 50, event-driven, code-ready first), from the survey and the interviews.
- A tested happy path
- A sequence of who does what, across developers, deployment authorizers, release managers and the platform, validated in moderated prototype sessions with both segments.
- A decision
- The rationale for supporting both ticket-creation orders, which ended the deadlock.
The work
The challenge
The engineering organization needed to launch a new release-creation workflow, but the initiative had stalled. Teams disagreed about when change tickets should be created, and leadership assumed it was a simple administrative step.
Who is involved in a release
Releases involved coordination across six personas, each with a different stake:
| Developers | Speed and minimal overhead |
| Release managers | Structure, predictability and cross-team visibility |
| SREs | Risk surfaces and environment stability |
| Managers | Delivery accountability |
| Auditors | Traceability and complete evidence |
| Deployment authorizers | The final approval gates |
Before the platform was ever involved, teams already maintained their own release constructs across tools: Jira for issue planning, Confluence for release notes and naming conventions, pipelines for deployments and artifacts, and change tickets for approvals and governance.
Research approach
- Interviews and workflow diagramming mapped real workflows across personas: sequencing, triggers and multi-tool dependencies.
- Journey mapping across tools showed friction between Jira, Confluence and pipelines, approval bottlenecks, the points where mental models split, and where cognitive load was highest.
- A survey of 50 practitioners validated when teams create change tickets.
- Moderated prototype sessions tested both sequencing behaviors: where people expected to create a ticket, whether the order felt natural, and how each persona reacted.
Two legitimate strategies
Key findings
- Teams maintain their own release constructs. Releases exist in Jira and Confluence before they ever touch the platform.
- Release managers and developers expect different workflows. One group needs structure, the other flexibility.
- Existing workarounds carry a lot of weight. Spreadsheets, naming conventions and Confluence templates give people comfort and predictability.
- Both sequencing behaviors are valid. Early Planners put governance first; Just-in-Time Releasers put code first.
- Adoption requires supporting both. A single rigid workflow would cause friction or outright non-adoption.
Impact
- Validated direction. The prototype supported both early and late ticket creation.
- Deadlock resolved. The research supplied the rationale for product sequencing and ended weeks of disagreement.
- Ready for production. The team moved forward with a workflow grounded in real developer experience and governance needs: flexible ticket entry points, a clear path for each role and better coherence across tools.
What carries over
Release workflows are cultural. Developers and release managers were following mental models, planning rituals, risk norms and coping strategies built up over years, as much as they were following tools. Designing for that meant mapping the complexity, respecting more than one valid path, making invisible workflows visible, and building a platform that adapts to teams rather than the reverse.
The practical lesson: when two groups disagree about a workflow, count before you decide. A survey of fifty people turned an argument into two segments with numbers, and the numbers ended the argument.