TranslationTurning a finding into a decision

Three weeks after a PM had announced a new onboarding redesign to engineering, a designer showed up to the progress review with a research finding nobody had asked for. A two-week diary study, planned for twelve people and finished with nine after drop-outs, had turned up something the brief never accounted for: a large share of new signups were coming in through referral links, skipping the marketing site altogether. These people arrived already sold on the product, with a clear idea of what it did. The new onboarding treated every new user as a blank slate. For the referral users, it would fail every time, dropping them into a tutorial they did not need, for a product they already understood. Engineering was two sprints in. The PM had committed.

The designer had a choice about what to do with it.

The first version of the meeting was the one the designer had prepared. It opened with “I need to raise a concern.” It framed the finding as a problem with the PM’s decision. It named the users who would break. It ended by recommending they pause and reconsider. The PM heard a veto dressed up as research, and answered evenly: “We’ll monitor it post-launch and iterate.” The finding went nowhere. The designer was the only one who ever acted on it.

The second version of the meeting was the one the designer ran instead.

It opened with a number: referral signups were 31 percent of new users, and they retained at nearly twice the rate of organic ones. It put the finding as a question the decision had to answer: how does the redesign protect the segment that retains best? Then it offered a specific move, a second way in. A thin fork that spotted referral-source users and skipped the introductory tutorial. The existing redesign would stay. Referral users would route around the step that broke for them.