When the Decision Was Already Moving

App Integration & Codebase Decisions

Being the user voice in a high-stakes codebase integration - with two weeks to make it count

The Research Challenge

Org context: A consumer app helping shoppers plan their weekly grocery routine in Canada.

Following an acquisition, the executive team decided to replace one app's codebase with another. Operationally, it made sense: less complexity, lower cost.

From a user perspective, it introduced a retention risk nobody had quantified yet.

The two apps served the same job in the market. But years of research had established that users actively chose one over the other; for specific UX and technical reasons. Removing App2's experience risked breaking routines that users had built around it.

Removing App2’s experience risked breaking established user routines, and created a risk to retention and user satisfaction.

This risk only surfaced once the integration plan reached delivery teams. Research raised a flag to the exec group. Leadership were open to hearing it, but the decision was already scheduled for Board approval in two weeks.

The question wasn't whether to integrate. It was what we'd be risking without understanding what users stood to lose.

We needed fast, credible insights without slowing decisions - clear signals for what to protect, adapt, or track post-integration.

Research Goal

Identify features and UX elements critical to retention for App 2 users, to enable informed trade-offs in the codebase decision.

Research Design

Framing the decision as risk, not UX optimisation

This was not a question of “what is the best UX,” but of risk tolerance. Research could not block or delay the integration, so my goals were to surface non-obvious retention risk and make potential user impact visible without slowing a time-sensitive decision.

This framing shaped every methodological choice that followed.

I intentionally avoided approaches that would have been easier to execute, but with low decision value:

  • Concept testing the ‘new’ app experience, which would have relied on hypotheticals rather than lived experience

  • Usability testing would capture a moment-in-time: revealing instant friction but miss behavioural adaptation over time

These methods would have been rooted in hypotheticals, and not represented real retention risks.

Despite the two-week timeline, I deliberately designed the research to simulate the exact change users were about to experience.

Methodology 1: Diary Study

Simulating real world routines across the entire app journey.

“Use (App1) For One Week Of Grocery Shopping”

Platform: Indeemo

Recruitment:

  • Recruited a mix of power and casual App2 users via a screener survey using an external sample provider.

    • Given the compressed timeline, Marketing-owned channels (e.g., email subscriber list) were not available.

  • While logistically intensive - including external survey coordination, recruitment emails and onboarding participants to the platform - this approach ensured representation across a broad spectrum of user behaviour types.

Scenario:

  • Participants used App1 for one full week as part of their regular grocery shopping:

    • The recorded themselves onboarding to App1 and learning how to use it

    • They recorded videos using the app during real shopping moments

    • Supplementary recordings asked participants to describe their broader shopping routines for context

  • 30-minute follow-up interviews explored what they liked and didn’t like about the ‘alternative’ app they had tested.

If the change was going to be drastic, executives needed to see - not imagine - its impact.

Methodology 2: Kano Analysis

Via a Conversational Survey

Validate at scale: Identify trade-offs and produce a quantitative prioritisation of features by retention risk.

Conversational Survey: Trying a new approach to Kano analysis

Platform: Rival Technologies

Approach:

  • Partnered with a research agency specialising in conversational surveys (Rival Technologies) delivered to their general population panel.

    • Required accelerated procurement, including proposal review and Legal and Finance approval

  • Recruited 750 App2 users (max feasibility given the user base)

  • I designed the Kano survey and qualitative questions, adapting it to fit a conversational survey format

Why I chose a new vendor and new approach during this high-risk project.

Conversational surveys were relatively new at the time and I hadn't used them in my own work before, but the format made sense here.

  • Standard surveys risk disengagement on demanding tasks like multi-feature Kano analysis.

  • A conversational format was more likely to hold participants' attention and produce more considered responses.

  • The addition of video answers also brought a qualitative layer that strengthened confidence in the findings.

Framing Insights & Recommendations

Providing fast, decision-ready signals for executives.

How insights were structured

  • Combined qualitative evidence, survey data, and behavioural analytics into a single view.

    • Features grouped using a prioritisation framework alongside a retention risk level

  • Deeper dives into each feature were provided, including highlight reels and quant rankings.

Given the two-week timeline and an imminent Board decision, insights were deliberately structured to be easy to interpret, standardised, and actionable - enabling rapid go / no-go decisions without requiring deep immersion in research detail.

How recommendations were framed

  • Protect where possible

  • Adapt where feasible

  • Track where trade-offs were unavoidable

What this revealed

  • One feature carried disproportionate retention risk:

    • ‘Priority Feature’ consistently surfaced as high-risk for retention and satisfaction

  • Other differences - while meaningful to the UX/UI - could be absorbed with minimal impact

What Happened Next

Decision Outcomes

  • All-up codebase consolidation proceeded due to timing constraints.

    ‘Priority Feature’ UX was not included in the integration

  • To ensure post-integration performance could be measured meaningfully, I worked with the Integration team to define baseline user signals and set expectations for how users were likely to respond.

Post-Integration

  • Overall attrition remained within the 5% tolerance goal.

  • But ‘Priority Feature’ emerged as the top driver of negative CX feedback over the following six months.

  • As a result, ‘Priority Feature’ was prioritised in the in-year roadmap, with a strong positive user response: tagged CX feedback dropped by 85% within one month of release.

Longer-term Impact

Not every recommendation lands in the moment - integration work moves fast and decisions often outpace the ability to course-correct.

But the research created a clear reference point, so when real-world signals emerged, the team could adapt quickly rather than starting from scratch.

In the post-integration retrospective, leadership identified early user research as a valuable input for estimating retention risk and aligned on involving Research earlier in acquisition-related decisions.

In subsequent acquisitions, I was invited onto the Integration Core Group - helping shape decisions before commitments were finalised.

This project highlighted that research earns its value twice: once when decisions are being made, and again when the real world responds.