Ամենաօգտագործվող ֆունկցիաներում ցանկացած փոփոխություն կպատճառի սուր արձագանք։ Այս խնդիրը կանխելու համար պետք է օգտատերերին աստիճանաբար պատրաստել փոփոխություններին, որպեսզի դրանք չլինեն անակնկալ ()։

Եթե մրցակիցները մեր լայնածավալ փոփոխությունների ընթացքում գործարկեն արշավներ «ակնթարթային բոնուսներով», մենք ռիսկի կենթարկենք օգտատերերի մի մասին կորցնելու։ Սա նաև պատճառներից մեկն է, թե ինչու չարժե ժամանակից շուտ հայտարարել կարևոր թողարկումների մասին։

Եթե փոփոխությունների անհրաժեշտությունը բացատրում ենք միայն «նորության» գործոնով, շատերը դա չեն ընդունի։ Նույնիսկ եթե փոփոխությունների պահանջը եկել է հենց օգտատերերից, նրանք կարող են դժգոհ մնալ։

Եթե փոփոխությունները լիովին համահունչ են պրոդուկտի համատեքստին, կարելի է դրանք բաժանել փոքր մասերի և ներկայացնել փուլերով՝ օգտատերերի անհարմարությունը նվազագույնի հասցնելու համար։

Եթե պրոդուկտի փոփոխությունները վերաբերվում են դրա գաղափարախոսական կամ տերմինաբանական մասերին, պետք է համոզվել, որ դրանք համահունչ են օգտատերերի համոզմունքներին։ Ամենապարզ օրինակը՝ եթե բաց կոդով (open-source) ծրագրավորողների խումբը սկսի վաճառել իրենց լուծումը, դա կհակասի իրենց լսարանի արժեքներին:

Օգտատերերը կարող են ցանկանալ տեսնել փոփոխությունների «մինչև» և «հետո» տարբերակները։ Եթե դա տեղին է, կարող ենք ներկայացնել փոփոխությունները այդ տեսքով։ Եթե ոչ, կարելի է փոփոխությունները ներկայացնել մաս-մաս՝ համեմատությունը դժվարացնելու համար։

Կարելի է հրապարակել մի քանի հոդված՝ կապված սպասվող փոփոխությունների հետ՝ լսարանի արձագանքը վերլուծելու համար։ Սա կօգնի հասկանալ, թե ինչն է առավել անհանգստացնում օգտատերերին։ Մենք կարող ենք օգտագործել այս տեղեկատվությունը ապագա փոփոխությունների նկատմամբ բացասական արձագանքները մեղմելու մեխանիզմներ ստեղծելու համար:

Անհրաժեշտ է ստեղծել նոր ֆունկցիոնալությունը օգտագործելու չափազանց պարզ հրահանգներ։ Այն ամենը, ինչ հնարավոր է պարզեցնել ինտերֆեյսում, պետք է պարզեցվի։ Եթե ​​պրոդուկտի առանձնահատկությունը թույլ է տալիս, մենք կարող ենք ստեղծել ֆունկցիոնալության երկու տեսողական ներկայացում (Ստանդարտ և Ընդլայնված տեսք): Սա կարող է լինել ժամանակավոր լուծում, քանի դեռ օգտատերերը ծանոթ չեն հիմնականին։

Նույնիսկ այն ֆունկցիաները, որոնք պրոդուկտի օգտատերերը հազվադեպ են օգտագործում, նրանք ընկալում են որպես «իրենց սեփականություն»։ Նման ֆունկցիաների չհիմնավորված փոփոխությունները կարող են սուր արձագանք առաջացնել, որը կարող է թվալ ոչ համաչափ ֆունկցիայի օգտագործման քանակին ():

Մենք բոլորս ինտուիտիվ կերպով հասկանում ենք էական փոփոխությունների ռիսկերը: Սովորաբար, եթե մենք որոշում ենք դրանք, ապա պրոդուկտի ապագան վերածվում է զրոյական գումարի խաղի, որտեղ մենք կամ ստանում ենք ամեն ինչ, կամ ոչինչ: Սովորաբար, նման որոշումների դեպքում կարևոր է ստուգել մեր ենթադրությունները թիմի մյուս անդամների հետ՝ սխալներից խուսափելու համար։ Այսպիսով, մենք կարող ենք սխալվել ենթադրությունները մեր լսարանի «աշխարհի» սխալ ընկալման պատճառով ( , ), մեր գոռոզության ( , ) կամ մեր կույր հավատքի պատճառով՝ ինչպես «Մենք այնքան ջանք ենք թափել, որ արժանի ենք հաջողության» ( ):