
BJERKE / DSGN
Senior Design Lead · IBM
Challenge
IBM's Hybrid Cloud product roadmap was driven by internal stakeholder opinions, not user evidence. The team was churning through features, reprioritizing constantly, and couldn't make confident forward plans. There was no mechanism to put user data in the room when roadmap decisions got made.
Use the Kano method to categorize user priorities across 27 roadmap features with statistical confidence — giving the product team a defensible basis for what to build next and what to defer.
Findings edited for intellectual property — specific feature names are confidential
Results needed to be actionable within an existing roadmap planning cycle
Cross-functional teams (design, product, engineering) needed to trust and act on outputs
Study design had to be rigorous enough to hold up to internal skepticism of research
How we learned
588 participants took the screener; 61 qualified and contributed data. 27 features were evaluated, each with three Kano questions to categorize them as Must-have, Performance, Attractive, Indifferent, or Reverse. Six additional qualitative insights came from paired interviews. The results were reviewed with stakeholders — and directly informed which items moved out of the 60–90 day roadmap into the backlog, and which got promoted from backlog to beta and GA planning.
Kano Method survey (27 features × 3 Kano questions each)
Screener to qualify participants (588 screened, 61 qualified)
Paired qualitative interviews for 6 additional insights
KJ Method workshops with stakeholders
Statistical categorization into Kano buckets (Must-have, Performance, Attractive, Indifferent, Reverse)
Several features the team treated as must-haves were categorized as Indifferent by users — meaning users neither expected them nor cared when they were absent. That shifted roadmap investment toward features with genuine user pull.
— Kano Roadmap Study
Attractive features — ones users didn't expect but loved when present — represented the highest opportunity for competitive differentiation. The study gave the team a framework for where to make bets.
— Kano Roadmap Study
After the readout, the roadmap conversation shifted from 'which internal stakeholder's priority wins this sprint' to 'how do we leapfrog the competition.' That shift was the real output of the research.
— Stakeholder Readout
How we worked
Study Design & Recruitment · 2 weeks
Designed the Kano survey instrument across 27 features with 3 Kano questions each. Built and ran a screener to qualify participants — 588 screened, 61 qualified.
Survey + Paired Interviews · 3 weeks
Ran the Kano survey with qualified participants and conducted 6 paired qualitative interviews to add depth to the quantitative findings.
Analysis & Categorization · 1 week
Categorized all 27 features into Kano buckets. Identified where the team's internal assumptions didn't match user data — particularly the 'must-have' features that turned out to be Indifferent.
Stakeholder Readout & Roadmap Impact · Ongoing
Presented findings to product and design leadership. Items moved out of the 60–90 day roadmap into the backlog; others were promoted from backlog to beta/GA planning. Conference talk presented at Booster Conference, Bergen, Norway.
Impact
The study directly shifted roadmap priorities — moving features in and out of the 60–90 day plan based on user evidence rather than stakeholder volume. More importantly, it changed how the team talked about the roadmap: from internal churn to competitive strategy. Troy later presented this work at Booster Conference in Bergen, Norway.
Study scale
Roadmap impact