Et nyttig problem er stort nok eller hyppig nok

Dashboardet ser flott ut i demoen. I dette tenkte tilfellet finner det en formateringsfeil i en månedlig eksport. Feilen tar to minutter å rette og oppstår to ganger i året. Alle liker demoen; ingen åpner dashboardet etter prøveperioden.

Problemet er virkelig nok til å beskrive. Men det kan koste mindre å leve med det enn å legge til enda et verktøy. Et elegant produkt skaper ikke hastverk av seg selv.

En samtale om produkter gir en nyttig test med to akser: Vær varsom med et problem som både er lite og sjeldent. Et stort problem kan fortjene oppmerksomhet selv om det dukker opp sjelden. Et lite, tilbakevendende problem kan hope seg opp til en daglig vane. Poenget er å undersøke arbeidet bak presentasjonen.

Tell hendelser og konsekvenser hver for seg

«Hvor mange har dette problemet?» er et for bredt første spørsmål. Spør et bestemt team når det sist skjedde, og hva som fulgte. Brukte noen tid på det, gikk et salg tapt, ble en ordre forsinket, ble private data eksponert, eller var det bare en irritasjon? Disse konsekvensene er ikke like.

Spør så hvor ofte samme type hendelse oppstår. En ukentlig rettelse på fem minutter kan bruke overraskende mye tid i et stort team. En feil som oppstår én gang i året, kan fortsatt bety mye hvis den stopper en kritisk overføring. En bagatell på to minutter to ganger i året er vanskeligere å selge som et eget produkt.

Se på et tenkt valg langs begge aksene:

Rutene er spørsmål som bør undersøkes, ikke dommer over markedet. «Høyt» avhenger av hvem sin kostnad du teller. En feil som knapt påvirker en administrator, kan skape et alvorlig problem for en kunde. En feil som ikke dukket opp i ett kort intervju, kan være sentral i sesongtopper.

Et lite demoproblem kan være stort i et system

Integrasjoner gjør forskjellen konkret. En feil feltverdi ser liten ut på én kontaktpost. Hvis samme mapping brukes på tusenvis av kontakter, kan den bli en stadig kilde til manuelle rettelser. Omvendt kan et avansert varsel for et kosmetisk avvik som bare skjer én gang, skape mer administrasjon enn det sparer.

Guiden til å integrere bedriftsverktøy begynner med arbeidsflyten og en datakilde som er fasit, fordi den virkelige kostnaden ligger i hvordan poster flyttes og brukes. Et team som avgjør om det skal oppgradere fra gratisverktøy, bør også telle omveier og tapte handlinger i stedet for bare å sammenligne funksjonslister.

Be om de siste tre virkelige hendelsene. For hver: Hvem oppdaget feilen, hvem rettet den, hvilket annet arbeid stoppet, og hva ville skjedd hvis ingen grep inn? Det siste spørsmålet skiller en irritasjon fra en usynlig risiko. Det hindrer også en gründer eller kjøper i å gjøre et slående tenkt tilfelle til et påstått målt mønster.

Spør så hva dagens omvei koster. Et regneark og en sjekk på fem minutter kan være godt nok. En manuell prosess der en spesialist må avstemme poster hver morgen, er kanskje ikke det. Alternativet er en del av produktets verdi, ikke en pinlighet som bør ignoreres.

Test også kostnaden ved å ta produktet i bruk

Selv et betydelig problem forsvarer ikke nødvendigvis en ny applikasjon. Noen må koble den til, lære den, gjennomgå resultatet og vedlikeholde tilgangen. Hvis produktet koster mer oppmerksomhet enn oppgaven, kan kjøpere med god grunn holde fast ved omveien de kjenner.

Kildesamtalen advarer også om at praktisk hjelp ved oppsett kan få tidlig interesse til å se større ut enn den er. Det kan virke som et team kjøper programvare, mens det egentlig er avhengig av konsulentarbeid som ikke er priset. Et lite problem med dyr innføring er særlig vanskelig å betjene bærekraftig. Det forbyr ikke tjenester, men tjenesten må regnes med.

Det finnes unntak fra de to aksene. Krav om etterlevelse kan kreve handling selv når observerte hendelser er sjeldne. Et nytt marked kan ha lite historie å måle. En nisjegruppe kan ha et smertefullt nok problem selv om befolkningen ellers ikke har det. Da bør bevisene komme fra forpliktelser, troverdige feilveier eller budsjetter folk faktisk vil bruke, ikke bare et anslag for hyppighet.

Aksene hjelper også med å avgjøre om behovet fortjener sitt eget produkt eller en liten funksjon i noe folk allerede bruker. Et sjeldent, lite formateringsproblem kan være en nyttig knapp i en eksportflyt, selv om ingen vil abonnere på en egen tjeneste for det. Et hyppig, lite problem løses kanskje best ved å endre en standardinnstilling i stedet for å selge enda et dashboard. Produktets omfang bør følge oppmerksomheten oppgaven allerede får. Spørsmålet er ikke om problemet finnes, men hvor mye ny atferd en løsning rimeligvis kan kreve.

Et bedre spørsmål under kartlegging er ikke «Ville du brukt dette?» Det er «Fortell om sist det skjedde, hva det kostet, og hva du gjorde i stedet.» Et produkt fortjener å finnes når svaret peker mot arbeid folk allerede prøver å endre.