But my question is for the situation where you have a low volume of
users (like an early B2B product), so you can't afford to use them as
"guinea pigs" because they are each very important.
Ovviamente questo è vero ma ha un effetto a due lati. Se non esegui il test, non puoi migliorare il tuo prodotto e questo influirà negativamente anche sul tuo utente.
Detto questo: il test non deve essere come il gioco d'azzardo. Può essere un esercizio misurato. Le aziende più grandi a cui fai riferimento generalmente sono molto brave a misurare tutte le interazioni tra gli utenti e l'app.
Quindi, per esempio, FB misura quanti video guardi sulla tua timeline. Quando aggiornano il software della timeline con una nuova versione, fanno questo:
- Prima: misurano sempre le statistiche in modo che conoscano il "normale", diciamo 5 video.
- Invia l'aggiornamento a una piccola percentuale di utenti
- Misura quanti video guardano, diciamo 2, aggiornamento errato
-
Dopo alcune misurazioni decidono automaticamente (hanno una squadra che lo controlla):
if(currentVideosWatched < 50% * videosWatchedBefore) {
alertDevelopersToFix();
// FB doesn't seem to revert the release but I know of systems who automatically revert the update to the last stable version which may work well for you.
}else{
increaseAmountOfUsersForThisVersion();
}
Puoi rendere questo processo come manuale o automatico come desideri.
In questo modo impediscono che si verifichino problemi davvero brutti. Puoi fare la stessa cosa in modo più semplice fuori rotta. Maggiori informazioni qui: link
Per convertire è nel tuo caso:
The problem I'm running into, is that to get this sweet feedback as
soon as possible, I have to show features unpolished.
Dipende dal tuo metodo di sviluppo fuori rotta, ma in generale dovresti essere in grado di fornire funzionalità che sembrano "buone". Con questo intendo: non dovresti distribuire pezzi che non sono ancora finiti. Non ha senso. Inoltre, non è necessario fornire versioni completamente lucidate. Questo è l'altro lato.
Questa è una valutazione professionale che devi fare. In generale: crea una funzione meno complessa / completa e avvialo. Quando ottiene trazione puoi migliorarlo ulteriormente. La cosa più importante è che ottieni le metriche in modo da non dover indovinare, ma puoi prendere decisioni reali in base ai fatti.
So my question is, how does one balance those 2 concerns? (getting
early, uncut feedback via actual use of a feature, vs. exposing
unpolished features and thus showing users a lower standard of
quality)
Cerca di fornire piccole caratteristiche di bell'aspetto e le loro misure iniziali. Questa è la linea di base. Se vuoi, puoi anche etichettarli nell'interfaccia con il flag "beta" se vuoi (anche se ciò potrebbe cambiare il comportamento degli utenti).
Su un piccolo B2B vorrei personalmente segnalare agli utenti dove vuoi inviare gli aggiornamenti beta. Quindi puoi includere persone a cui piace dare un feedback per primi.
L'altra vera alternativa che hai è assumere un gruppo di veri tester. Il problema è che devono essere sperimentati con il campo B2B in cui stai lavorando. Altrimenti non scopriranno i bug della logica di business ma solo quelli tecnici.