Et nyttigt problem er stort eller hyppigt nok til at kræve opmærksomhed

Dashboardet ser smukt ud i demoen. I dette tænkte tilfælde finder det en formateringsfejl i en månedlig eksport. Fejlen tager to minutter at rette og sker to gange om året. Alle kan lide demoen; ingen åbner dashboardet efter prøveperioden.

Problemet er virkeligt nok til at beskrive, men prisen ved at leve med det kan være mindre end prisen for endnu et værktøj. Et elegant produkt skaber ikke af sig selv hastværk.

En optaget produktsamtale giver en nyttig test med to akser: Pas på problemer, der både er små og sjældne. Et stort problem kan kræve opmærksomhed, selv når det sjældent viser sig; et lille tilbagevendende problem kan hobe sig op som en daglig vane. Pointen er at se på arbejdet bag salgstalen.

Tæl hændelser og konsekvenser hver for sig

»Hvor mange har problemet?« er for bredt som første spørgsmål. Spørg et bestemt team, hvornår det sidst skete, og hvad der fulgte. Brugte nogen minutter på det, mistede de et salg, forsinkede de en ordre, blev private data afsløret, eller var det blot irriterende? De konsekvenser er ikke ens.

Spørg derefter, hvor ofte samme slags hændelse opstår. En rettelse på fem minutter hver uge kan koste overraskende meget tid i et stort team. En fejl én gang om året kan stadig være vigtig, hvis den stopper en kritisk overførsel. En irritation på to minutter to gange om året er sværere at sælge som selvstændigt produkt.

Se et tænkt valg ud fra begge akser:

Felterne er opfordringer til at undersøge, ikke domme over markedet. »Høj« afhænger af, hvis omkostning der tælles. En fejl, som næsten ikke påvirker en administrator, kan skabe et alvorligt problem for en kunde. En fejl, der ikke optrådte i ét kort interview, kan være central i sæsonens travleste uge.

Et problem kan være lille i demoen og stort i systemet

Integrationsarbejde gør forskellen konkret. En forkert feltværdi ser lille ud i én kontaktpost. Hvis samme mapping anvendes på tusindvis af kontakter, bliver den en tilbagevendende kilde til manuelle rettelser. Omvendt kan en avanceret alarm for en enkelt kosmetisk uoverensstemmelse give mere administration, end den sparer.

Guiden til at integrere forretningsværktøjer begynder med en arbejdsgang og en autoritativ kilde, fordi den egentlige omkostning ligger i, hvordan poster flyttes og bruges. Et team, der beslutter, om det skal opgradere fra gratis værktøjer, bør også tælle nødløsninger og manglende handlinger i stedet for kun at sammenligne funktionslister.

Bed om de sidste tre virkelige hændelser. Registrer for hver af dem, hvem der opdagede den, hvem der rettede den, hvilket andet arbejde der stoppede, og hvad der ville være sket uden indgriben. Det sidste spørgsmål skiller irritation fra usynlig risiko. Det forhindrer også en stifter eller køber i at gøre en slående hypotese til et målt mønster.

Spørg derefter, hvad den nuværende nødløsning koster. Et regneark og en kontrol på fem minutter kan være godt nok. En manuel proces, der kræver en specialist til at afstemme poster hver morgen, er det måske ikke. Alternativet er en del af produktets værdi, ikke en pinlighed, der skal ignoreres.

Test prisen for at tage produktet i brug

Selv et vigtigt problem begrunder måske ikke en ny app. Nogen skal forbinde den, lære den, gennemgå dens output og holde adgangen ved lige. Hvis produktet kræver mere opmærksomhed end opgaven, kan købere med god grund holde fast i deres nødløsning.

Kildesamtalen advarer også om, at praktisk hjælp med opsætning kan få den tidlige interesse til at se større ud, end den er. Et team kan se ud til at købe software, men i virkeligheden være afhængigt af rådgivning, der ikke er prissat. Et lille problem med en dyr vej gennem opstart er særligt svært at løse bæredygtigt. Det udelukker ikke service; det betyder, at servicen skal tælles med.

Der findes undtagelser til de to akser. Regler om overholdelse kan kræve handling, selv når observerede hændelser er sjældne. Et nyt marked kan have meget lidt historik at måle. En nichegruppe kan have et smertefuldt nok problem, selvom den brede befolkning ikke har det. I de tilfælde bør beviset komme fra forpligtelser, troværdige fejlveje eller afsatte budgetter frem for kun et skøn over hyppigheden.

Akserne hjælper også med at afgøre, om behovet fortjener sit eget produkt eller en lille funktion i noget, folk allerede bruger. Et sjældent mindre problem med formatering kan være en værdifuld knap i eksporten, selvom ingen ville abonnere på en særskilt tjeneste for det. Et hyppigt lille problem løses måske bedst med en ændret standardindstilling frem for endnu et dashboard. Produktets omfang bør følge den opmærksomhed, opgaven allerede får. Spørgsmålet er ikke, om problemet findes, men hvor meget ny adfærd løsningen med rimelighed kan kræve.

Det frugtbare undersøgelsesspørgsmål er ikke »Ville du bruge det?« Det er »Fortæl mig om sidste gang det skete, hvad det kostede, og hvad du gjorde i stedet.« Et produkt fortjener at findes, når svaret peger på arbejde, folk allerede forsøger at ændre.