Luke Freiler, CEO van Centercode, sluit zich aan bij Ryan Chacon op de IoT For All Podcast om te discussiëren gebruikerstesten van IoT-producten. Ze praten over hoe geconnecteerde producten zijn veranderd, de voordelen ervan product testen en hoe het gedaan wordt, de verschillende soorten producttesten, de uitdagingen van gebruikerstesten, het testen van software versus hardware, hoe je weet wanneer een product klaar is en hoe je gebruikerstesten goed uitvoert.

Wilt u uw IoT-datastrategie optimaliseren en de volledige waarde van uw data benutten? Samenwerken met DAIN-studio's, de experts in datagedreven oplossingen. Ze zijn gespecialiseerd in het bouwen van robuuste IoT-datastrategieën die het potentieel van uw data volledig benutten. Hun team kan u helpen bij het systematisch identificeren, prioriteren en implementeren van datamogelijkheden om uw bedrijf vooruit te helpen.

Door het opzetten van key enablers zoals data governance en architectuur, zorgen zij voor de succesvolle implementatie van uw IoT-ambities. Lees meer en bezoek ze op dainstudios.com.

Over Lucas Freiler

Luke Freiler, CEO en mede-oprichter van Centercode, levert oplossingen voor gebruikerstesten aan toonaangevende technologiebedrijven. Met een achtergrond in softwareontwikkeling leidt hij het ontwerp van het Centercode Platform, een SaaS-platform dat continue betrokkenheid van het publiek tijdens de productontwikkeling mogelijk maakt. Als tech-idealist wil Luke technologie gebruiken om wrijving te verminderen en echte problemen op te lossen. Hij is toegewijd aan het verbinden van productmakers en hun publiek om deze visie, product voor product, te verwezenlijken.

Geïnteresseerd om in contact te komen met Luke? Neem contact op via LinkedIn!

Over Centrumcode

Centrumcode is van mening dat het creëren van uitzonderlijke producten die echt aan de behoeften van de klant voldoen een robuust en effectief gebruikerstestprogramma vereist. Ze ontwikkelden een krachtig deltatest- en feedbackbeheerplatform dat bedrijven over de hele wereld helpt het volledige potentieel van hun producten te ontsluiten.

Met hun platform kunt u de juiste testers voor uw product identificeren en rekruteren, het feedbackproces efficiënt beheren en de gegevens analyseren om waardevolle inzichten te verkrijgen die toekomstige beslissingen over productontwikkeling kunnen ondersteunen. Hun platform wordt vertrouwd door enkele van 's werelds toonaangevende merken, waaronder Microsoft, GoPro en Bose, om er maar een paar te noemen.

Belangrijkste vragen en onderwerpen uit deze aflevering:

(00: 38) Inleiding tot Luke Freiler en Centercode

(04: 15) Hoe zijn verbonden producten veranderd?

(05: 55) Voordelen van producttesten en hoe het wordt gedaan

(07: 41) Verschillende soorten producttesten

(08: 50) Uitdagingen bij gebruikerstesten

(10: 49) Software versus hardware testen

(12: 58) Hoe weet je wanneer een product klaar is?

(16: 58) Hoe u gebruikerstesten goed uitvoert

(19: 56) Meer informatie en opvolgen

Transcript:

– [Ryan] Welkom Luke bij de IoT For All Podcast. Bedankt dat je hier deze week was.

– [Luke] Bedankt, Ryan. Blij om hier te zijn.

– [Ryan] Ja. Het is geweldig om je te hebben. Spannend gesprek Ik weet dat we het gepland hebben, maar ik wilde het aftrappen en jou gewoon een introductie geven aan het publiek over jezelf en het bedrijf. 

– [Luke] Mijn naam is Luke Freiler. Ik ben de CEO van een bedrijf genaamd Centercode. Dit is al een tijdje een passieproject voor mij. Ik ben er eigenlijk mee begonnen toen ik nog heel jong was, rond 2021 of rond sorry 2001. Daarvoor heb ik enige tijd doorgebracht in het Amerikaanse bedrijfsleven. Ik werkte voor Samsung. Ik werkte voor Ericsson en door die ervaringen werd ik verliefd op wat destijds bruikbaarheid heette, maar uiteindelijk breder werd erkend als gebruikerservaring. En ik werd gewoon verliefd op het idee dat technologie toegankelijk moet zijn. Het zou echte problemen voor echte mensen moeten oplossen. En daar heb ik mij maar op gericht. En terwijl ik dat deed, leidde ik een vroeg webteam bij Ericsson. Een productmanager kwam naar me toe en zei: Hé, ik wil dat je een bètatest uitvoert voor dit product. We hebben allemaal samen aan deze grote investering van Ericsson gewerkt. En ik zei: oké, wat is, wat betekent dat precies? En hij zei: oh, we krijgen een aantal klanten en we proberen het. Ik dacht: nee, ik begrijp wat een bètatest betekent. Ik weet niet wat het betekent in de context van Ericsson. We hebben voor werkelijk alles een proces. Wat is ons proces? Wat zal ik doen? Waar zijn de stappen? En hij zei: kijk man, die hebben we niet. En eerst geloofde ik hem niet. Dit was een honderd jaar oud technologiebedrijf met honderdduizend mensen, en eerlijk gezegd had ik er jarenlang geen zin in, maar ik concentreerde me en begon met veel mensen te praten en ik ontdekte dat er een zeer interessante kloof bestond. op de markt, dat uiteindelijk als een noodzakelijk kwaad werd gezien.

Iedereen begreep dat het testen van echte producten en echte omgevingen met echte mensen essentieel is om echt uit te zoeken hoe dat product in de echte wereld opraakt, maar er is veel wrijving en een deel van het probleem is dat je eigenlijk, weet je, , een bewust kapot product, een onafgemaakt product voor een groep vreemden en hen vervolgens vragen om je zinvolle feedback te geven en daar zitten zoveel dingen in die lastig zijn. Dus voor mij werd ik verliefd op het oplossen van dat probleem. Het idee dat we kunnen helpen als orkestrator of facilitator van de relatie tussen bedrijven en hun klanten om uiteindelijk iets op te bouwen dat beter is voor iedereen. Dus startte het bedrijf, startte het in eerste instantie op en bouwde het van daaruit verder op. En tot op de dag van vandaag werken we samen met veel van de grootste bedrijven in de technologiesector.

– [Ryan] En als we het hebben over producten zoals verbonden producten, is dit dan meer de consumentenkant of is dit de zakelijke kant, of is het een combinatie van beide? 

– [Luke] Het is een combinatie van beide, en we testen zowel hardware als software, maar met IoT verbonden producten zijn de beste keuze. Het zou zeker de meerderheid uitmaken, en een deel daarvan komt doordat er altijd een combinatie is van hardware, software en een servicecomponent in de definitie van IoT. Er kan dus veel misgaan. Dat is dus waar we veel van onze activiteiten zien. 

– [Ryan] Ja, ik wilde jullie vragen wat voor jullie allemaal de focus is, of het nu hardware en software is, of en/of software, want voor, laten we zeggen het bedrijfsleven, ik denk dat zelfs de consumentenkant, er altijd een softwarecomponent is waar het is een app, het is een webinterface, het is iets waarmee je met het apparaat kunt communiceren of de gegevens kunt bekijken en dergelijke. Dus ik neem aan dat je het testen en zowel de hardware- als de softwarekant voor beide kanten afhandelt.

– [Luke] Ja, absoluut. Ik zou zeggen dat 90 procent van wat we aanraken, software bevat. En het kan software zijn die in het product zelf is ingebed. Het kan via een app zijn. Vrijwel alles heeft tegenwoordig een app. Er is dus bijna altijd software bij betrokken, en dan is er zeker veel hardware. 

– [Ryan] Hoe zijn ze in het algemeen veranderd, met de groei van verbonden producten door de jaren heen? Zoals hoe, dit zal uiteraard een soort vraag spelen rond testen en hoe dat is geëvolueerd en het belang ervan, enzovoort. Maar in het algemeen gesproken: als we naar verbonden producten kijken, wat zijn dan de grootste veranderingen geweest die van invloed zijn geweest op het gebied waarin u werkt?

– [Luke] Het grootste en waarschijnlijk meest voor de hand liggende is dat producten en de aard van het verbonden zijn, is dat ze iteratief worden. We zeggen vaak dat mensen producten niet meer als producten beschouwen, maar als diensten, toch? Vroeger was een product meer een vuur-en-vergeet-strategie: ik ga deze luidspreker uitbrengen en hij gaat luidsprekerdingen doen. Of misschien is het beste voorbeeld dat ik deze AC-unit ga blussen en dat hij airconditioning- en HVAC-dingen gaat doen. En toen was er een keerpunt toen ze met elkaar verbonden raakten. Nu verwacht je niet alleen dat het voor altijd blijft doen wat het doet, zelfs niet op een verbonden basis; je verwacht dat het evolueert. Je verwacht dat het zich herhaalt, nieuwe functies krijgt, nieuwe problemen oplost, verbinding maakt met nieuwe producten die nog niet bestonden toen het werd gemaakt, en dat de verbonden natuur een iteratief ontwikkelingsproces creëerde. Het bracht Agile in de hardwarewereld, wat twintig jaar geleden waarschijnlijk ondenkbaar zou zijn geweest, maar nu effectief noodzakelijk is.

Ik zal nooit een gesprek vergeten dat ik bij Bose had, waarin ze zeiden dat ze hun hele cultuur als bedrijf moesten veranderen, omdat alles vroeger een releasecyclus van 18 tot 24 maanden was. Ze brachten een geweldige koptelefoon tevoorschijn, een geweldige luidspreker en daarna raakten ze hem nooit meer aan. En ze zeiden dat ze het zich gewoon niet kunnen veroorloven om zo te denken. Als ze dat doen, zullen hun concurrenten rondjes om hen heen draaien. Ze moesten dus de hele mentaliteit van de organisatie veranderen om flexibeler te kunnen reageren op verbonden producten. 

– [Ryan] Mensen die daar luisteren en proberen te begrijpen, ik denk dat mensen op een hoog niveau de waarde van testen begrijpen, maar als je het zou hebben over de algemene voordelen van producttesten, vooral in de IoT-ruimte, wat zijn die dan? voordelen en hoe wordt het testen gedaan zonder in al te gedetailleerde details te treden? Laat ons gewoon zien wat dat eigenlijk betekent? 

– [Lucas] Ja. In onze ruimte is het basisidee precies hoe het klinkt. Je gaat echte mensen vinden die het echte probleem hebben dat jouw product oplost, je gaat het onder hen distribueren en zij gaan het gebruiken. En wat je eigenlijk probeert te doen, is de problemen die ze hebben bestuderen, de ideeën waarvan ze denken dat ze het product zouden aanvullen of verbeteren, en ook de lof die ze krijgen. Je bent op zoek naar een soort van deze drie dingen. Problemen, ideeën en lof, maar je zoekt er in de loop van de tijd naar, want een van de dingen van verbonden producten is niet alleen dat de ontwikkeling niet brandt en vergeet, maar ook het gebruik ervan niet.

Het is dus dat adoptiecomponent dat je niet echt kunt vastleggen in een traditionele QA-omgeving. Je kunt het niet vastleggen via geautomatiseerd testen. Je moet mensen het product echt in hun natuurlijke omgeving laten gebruiken. En wat dat doorgaans betekent, is niet alleen de interactie met veel andere producten, want nogmaals, de aard van een verbonden product is dat het afhankelijk is van producten waarover hij geen controle heeft om succesvol te kunnen presteren.

Ze zijn niet alleen op zoek naar de interactie met die producten, maar je zoekt ook naar de interactie met die producten in de loop van de tijd terwijl ze evolueren, omdat zij dezelfde iteraties maken die jij maakt. En dat kan allerlei problemen veroorzaken. Het voortdurend testen en adopteren van functies en producten in de loop van de tijd is dus echt wat dit scheidt en zo cruciaal is in de verbonden ruimte.

– [Ryan] Ik kan me voorstellen dat er tijdens de ontwikkeling verschillende soorten tests plaatsvinden, van de eerste ideevorming tot en met de lancering en gewoon de voortdurende groei van een product zelf of gewoon nieuwe versies van het product. 

– [Lucas] Precies. Dus we beschouwen het zeker als, weet je, wanneer je in zo'n alfa-achtige fase begint en er uiteraard tests zijn die verder gaan dan, weet je, lang voordat een klant er ooit bij betrokken is, maar je weet dat het voor ons zo is Meestal krijg je het al vroeg in handen om de basisprincipes te testen, om er zeker van te zijn dat zelfs in een onvolledig product het doet wat het zou moeten doen en op zoek gaat naar die vroege feedback. Je hebt dan wat je zou beschouwen als die traditionele bètatest van vier tot acht weken vóór de lancering, je laat mensen een bijna eindproduct gebruiken, hopelijk is de functie compleet, maar er zijn waarschijnlijk nog steeds een aantal bekende problemen, en jij We gaan op zoek naar meer problemen in die echte ervaringen. En vanaf daar gaat het allemaal om de volwassenheid van het product, toch? Nogmaals, die iteratieve component bestaat uit producten die in de loop van de tijd volwassen worden en elke nieuwe release die je doet, kan het product technisch gezien blokkeren. Dat is het risico van onze ruimte. Dat is de afweging. Dus ervoor zorgen dat een kleine groep mensen er alles aan doet om ervoor te zorgen dat dit niet het geval zal zijn, wordt het initiatief vanaf de release. 

– [Ryan] Bij het testen van deze verbonden producten door gebruikers, variëren de producten uiteraard in type eindgebruiker, de omgeving waarin ze zullen worden gebruikt, de hoeveelheid functionaliteit en kenmerken die ze hebben. Wat zijn enkele van de grootste uitdagingen waar mensen zich bewust van moeten zijn als ze deze IoT-apparaten gaan testen? 

– [Luke] Een van de uitdagingen van een nog niet uitgebracht IoT-product is dat je doorgaans maar een beperkt aantal eenheden hebt, toch? Het is preproductie, ze zijn duur, ze zijn moeilijk verkrijgbaar, iedereen in de organisatie wil ze. We hebben er vaak over gesproken dat we in onze ruimte niet de luxe van big data hebben. Na de release kun je allerlei soorten data bestuderen, maar vóór de release draait het allemaal om het maximaliseren van kleine data. Voor ons gaat het er dus om dat we op een aantal manieren aan ons publiek denken. We willen nadenken over het profiel van wie ze zijn, hebben ze het probleem dat dit product oplost? En dat is voor iedereen een startpunt voor die test. Van daaruit gaat het om hun ervaringsniveau, wat opnieuw van invloed zou kunnen zijn op hun gebruikerservaring, hoe slim ze zijn in de ruimte. En dan net zo belangrijk: hun omgeving, het begrijpen van welke andere soorten producten ze tot hun beschikking hebben.

Deze producten zijn mogelijk niet in hun standaardstatus geconfigureerd. Het is vrijwel zeker niet zo dat je het misschien al hebt getest. Het gaat er dus om zoveel mogelijk aandacht te krijgen, zowel aan de demografische kant van wie ze zijn en de problemen die ze hebben, maar ook aan de technologische kant van wat voor soort producten er zijn. Hier zal interactie mee plaatsvinden en opnieuw zouden ze zich moeten aanpassen als onderdeel van een bestaand ecosysteem. Het vinden van die mensen is dus echt van cruciaal belang. Zodra je het product uitbrengt en je hebt al klanten en je doet iteratieve releases, wordt het een stuk eenvoudiger om op zijn minst een pool beschikbaar te hebben, en het wordt een stuk goedkoper omdat je je in principe kunt richten op je bestaande klanten die enthousiast zijn over uw product, of nogmaals, welk probleem het ook oplost.

Dus als we erop ingaan, gaat het vooral om profilering om de beperkte middelen te maximaliseren. En van daaruit gaat het om het opbouwen van een voortdurende groep mensen die altijd klaar en beschikbaar zijn en enthousiast zijn om te testen en de toekomst van een product vorm te geven. 

– [Ryan] Bij een IoT-apparaat hebben we al gezegd dat er een hardware- en een softwarecomponent bestaat, en uiteraard is software via draadloze updates vaak gemakkelijker te updaten als er een bug of een probleem is. Maar hoe zit het met de hardwarekant? Ik kan me voorstellen dat er een ander plan en denkproces moet zijn dat gaat over hoe we niet alleen gaan testen, maar ook wanneer iets gereed wordt geacht voor lancering, want als je een product en veel eenheden naar buiten duwt, wordt het door veel mensen gebruikt. van mensen en er is een probleem met de hardware, dat is veel moeilijker op te lossen dan een softwarefout. Je kunt ze gewoon de nieuwe, de nieuwste versie laten updaten, en dan is het waarschijnlijk gepatcht en zijn we klaar om te gaan.

– [Lucas] Ja. Heel verschillende problemen en heel verschillende resultaten, toch? Als het een software-update is, kun je het in theorie herstellen, maar je hebt een merkreputatie en dergelijke die nu geschaad is, terwijl als het een hardwareprobleem is, de terugroepacties en dergelijke vrijwel het slechtst mogelijke scenario zijn. .

Die bètafase is er dus eigenlijk op gericht ervoor te zorgen dat de hardware op alle mogelijke manieren werkt, terwijl de tests na de release, de lopende tests, wat we deltatests noemen, vooral gaan over het garanderen dat de software presteert. Je hebt beide echt nodig om volledig te slagen, want je moet er uiteraard voor zorgen dat het product, de functionele hardware, gaat werken. Maar dat is wat die meer diepgaande test aan het begin is, die gericht is op het benadrukken van het hele product. Vanaf daar concentreer je je eigenlijk alleen op de delta tussen releases. Wat is er veranderd en hopelijk heb je het merendeel van je hardwareproblemen opgelost. Het is ongelooflijk gebruikelijk om ook hardware te herhalen, maar in onze wereld is het doorgaans vrij stil tussen grote releases. Je hebt voor de buitenwereld vijf verschillende versies van een 1.0-product die zijn geëvolueerd en verbeterd en onderdelen worden goedkoper, dingen worden efficiënter, batterijen worden beter, enzovoort. Vaak weten de eindgebruikers niet eens dat dit gebeurt, maar die worden allemaal nog getest voordat ze op de markt komen. Dat zou over het algemeen het doel zijn. 

– [Ryan] Is er een bepaald verschil in de drempel of ik vermoed het niveau van iets dat tussen aanhalingstekens en zonder aanhalingstekens wordt voltooid voor hardware versus software, wetende dat je hardwarefouten en updates gemakkelijker kunt oplossen vóór of nadat het is gelanceerd versus hardware. En dan denk ik dat dat aansluit bij een vraag waar ik nieuwsgierig naar ben geweest: hoe krijgt een bedrijf iets op een punt waarop ze klaar zijn om live te gaan en het gevoel te hebben van, oké, al de dingen waarvan we niet wisten dat we ze het gevoel hebben dat we het nu weten, in plaats van dingen op tafel te laten liggen waarvan ze misschien nog steeds niet weten dat ze dat moeten weten voor potentiële problemen nadat je de tijd in de hardware en het geld in de hardware hebt geïnvesteerd en dat gaat uit, dat is moeilijk, veel moeilijker achteruit lopen dan dat het software is.

– [Luke] We hebben dit probleem al een hele tijd bekeken en een aantal jaren geleden kwamen we met in principe drie maatstaven die we gebruiken, de KPI's in onze ruimte, die lange tijd een groot gat vormden, en we splits het op in drie dingen. Nummer één is wat wij de gezondheid van de test noemen, dus het is een gezondheidsscore. En waar het echt naar kijkt, zijn twee kanten van een medaille. De eerste is: zijn testers alles aan het testen? Dus gaan ze het product door en gebruiken ze het ook daadwerkelijk, en testen ze alle functies die u wilt testen, en heeft u daar bewijs van? Ten tweede: geven ze je dan bruikbare feedback over de dingen die niet aan hun verwachtingen voldeden of die hun verwachtingen te boven gingen?

En nogmaals, het zijn de problemen, de ideeën en de lof. Daar komt het allemaal op neer. Als ze dat hebben bereikt, als een test beide dingen heeft bereikt, heeft deze volledige dekking, is er sprake van een brede dekking van het product, wordt alles getest en krijgt u duidelijke instructies om de gevonden problemen op te lossen en de tekortkomingen aan te pakken. die zijn gevonden, dan heb je een hoge gezondheidsscore. En dan is dat een belangrijk uitgangspunt om te weten dat we het voldoende hebben getest. Heeft niets te maken met de resultaten, heeft niets te maken met wat ze hebben gevonden, maar we hebben het getest. Wij hebben vertrouwen in onze test. De volgende score leunt daarop, en dat noemen we een successcore. En wat dat doet, is door de ogen van de klant naar het product kijken en zeggen: oké, op een schaal van één tot honderd, hoe blij waren ze met het resultaat? En als je teruggaat naar de dingen waarvan ik zei dat we ze verzamelden, kunnen we die gebruiken om erachter te komen.

We beoordelen en geven een score voor elk stukje feedback. Niet alle feedback is gelijk, toch? Een beveiligingsprobleem is doorgaans veel belangrijker en ernstiger dan een cosmetisch probleem. We kijken naar die dingen en zeggen: oké, als alles lovend was en er geen problemen waren en geen ruimte voor verbetering, wat nog nooit is gebeurd, maar het is theoretisch mogelijk, dan heb je een zeer hoge successcore. Als je geen lof had, alles waren problemen, alles waren tekortkomingen, dan heb je een zeer lage score. De realiteit, en daarom is de partituur nuttig, ligt altijd ergens tussenin. Het is de uitkomst van, oké, we weten dat er een aantal goede dingen zijn, een aantal slechte dingen, we weten waar we staan. Wat dat je dan oplevert, is een richtpunt om te zeggen: oké, we hebben een 60, toch? En ons doel was een 80, en ik zal dat doel zo meteen bespreken. Ons doel hier is dan om u instructies te geven over hoe u die 80 moet halen. Om u precies te laten zien waar u heen moet. En dan is de laatste kernstatistiek, en dit is weer een heel belangrijke, kijken naar het verschil tussen wat die score zou zijn geweest als je het product zojuist had uitgebracht zoals het is, en wat die score inhoudt, waarbij je erkent dat je bugs hebt opgelost en nieuwe ideeën hebt geïmplementeerd. , wat het ook is, en dat laat je de impact van die testinspanningen zien. En alle drie deze scores worden prachtige KPI's, omdat het dingen zijn die je met eenvoudige tactieken kunt verbeteren. U weet wel, het verbeteren van uw betrokkenheid, het verbeteren van uw product zelf, en het verbeteren van de manier waarop u reageert op problemen in dat product en deze aanpakt.

Het doel is dus dat je als bedrijf doorgaans in de loop van de tijd releases uitvoert. Je doet het opnieuw, als je behendig bent, doe je tweewekelijkse, maandelijkse releases, wat voor jou ook logisch is. Dus dat getal wordt een toetssteen. Het wordt een benchmark die u begint te leren kennen en relatief aan uw product kunt u doelstellingen hebben die relevant zijn voor uw organisatie, toch?

Als je eindeloos veel geld hebt en je wilt investeren om perfect te zijn, dan kun je dat doen. Je kunt veel geld uitgeven om een ​​echt hoge score te behalen. Als je begrijpt dat de marktimpact van dit product beperkt is, is het een experiment. Wat het ook mag zijn, je hebt misschien lagere ambities, maar het biedt de toetsstenen om je daar doorheen te loodsen.

– [Ryan] Ik denk dat een goede manier om dit gesprek af te ronden is door te praten over hoe mensen die hiernaar luisteren goed kunnen testen. Hoe, we hebben duidelijk veel vooruitgang gezien op het gebied van AI waarvan ik zeker weet dat ze hier nu een rol in spelen of zullen spelen. Waar moeten mensen aan denken als ze het pad bewandelen om een ​​product gereed te maken voor release, of misschien hebben ze al een product op de markt en zeggen ze: hé, we hebben dit niet grondig getest op de manier waarop we dat waarschijnlijk zouden moeten doen. Hoe kunnen we dat met terugwerkende kracht aanpakken? Dus welk advies zou je hebben voor mensen die hiernaar luisteren, over hoe ze goed kunnen testen en waar dit allemaal naartoe gaat? 

– [Luke] Dus ik zal het enigszins bevooroordeelde antwoord geven, of misschien wel een meer dan enigszins bevooroordeeld antwoord, en dan zal ik proberen het een beetje te generaliseren. Eigenlijk doe ik het in omgekeerde volgorde. Ik zal je eerst de generieke geven. Er is geen slecht moment om te beginnen. De realiteit is dat elk bedrijf in verschillende snelheden volwassen wordt en dergelijke. Dus het idee om een ​​groep samen te brengen, het hoeft niet groot te zijn, 20 mensen, 30 mensen, we raden eigenlijk geen tests aan die te groot zijn, maar die groep zo snel mogelijk krijgen en ze gewoon een kanaal geven om om uw feedback te vragen en duidelijk met hen te communiceren over de soorten feedback waarnaar u op zoek bent. Dat is heel belangrijk. Vanuit onze wereld is het meer bevooroordeelde antwoord dat we het afgelopen jaar onze go-to-market-strategie hebben gewijzigd. Vroeger waren we vrijwel ondernemingsgericht. We werkten alleen met de grootste van de groten. We bevinden ons nu op een andere plek dan waar we onze markt hebben uitgebreid naar individuele productmanagers die 's nachts moeite hebben met slapen. En er is een gratis versie van ons product waarmee ze een test kunnen uitvoeren zonder ooit met ons te praten, zonder ooit met ons in zee te gaan. We hebben dan jouw typische manier van swipen met een creditcard voor een beetje meer functionaliteit. En naarmate uw programma volwassener wordt, hebben we natuurlijk het traditionele zakelijke aanbod beschikbaar. Maar wat we op de markt hebben gebracht voor de functionaliteit die ze krijgen, is weer gratis te starten en dan is die betaalde versie veel, en we krijgen ze behoorlijk ver. En nogmaals, ze hoeven niet met een verkoper te praten. Ze kunnen gewoon aan de slag en het is van maand tot maand. Ze kunnen het op elk moment doen. Het is heel simpel. 

Hoewel het natuurlijk erg bevooroordeeld is, omdat we er zo hard aan hebben gewerkt om het te bouwen, is het een geweldige oplossing die ongelooflijk goedkoop is en voor iedereen beschikbaar is. Ons doel als bedrijf is eigenlijk niet om daar geld te verdienen. Het gaat erom het bewustzijn te blijven vergroten en hen in staat te stellen waarde te tonen binnen hun organisaties, zodat we, naarmate ze volwassener worden en deze waarde inzien, een echte commerciële discussie kunnen voeren over zes maanden, over een jaar, wat dan ook. Ik zou ook nogmaals aan de vrije kant willen zeggen: twee dingen die we doen om iedereen te helpen waar iedereen van kan profiteren: één: we hebben een community genaamd betabound.com. Het is een gemeenschap van bètatesters die producten willen testen. En wij stellen het gratis ter beschikking. Als u uw mogelijkheden daar wilt posten, sturen wij kosteloos testers naar u toe. En dat is gewoon betabound.com. En dan het laatste, een groot deel van onze strategie: we zijn geen marketing- en verkopers. We zijn echt een productmerkbedrijf. We produceren een enorme hoeveelheid content. We hebben gewoon een geen geheime sausmentaliteit. Onze hele groeistrategie draait dus rond contentmarketing en we produceren veel waardevolle informatie. Dus ga naar centercode.com, lees wat informatie en nogmaals, absoluut gratis. We gaan je niet achtervolgen. En hopelijk zal dat je helpen om erachter te komen waar je hier kunt verbeteren. 

– [Ryan] Luke, bedankt dat je even de tijd hebt genomen. Ik was eigenlijk: de laatste vraag die ik je wilde stellen, is hoe je verder moet gaan, maar je hebt dat al aangesloten, wat perfect is. Ik denk dat het een heel interessante ruimte is om alleen maar na te denken over al deze producten die we gebruiken, of het nu consumenten of ondernemingen zijn, en te beseffen hoeveel werk en moeite er moet worden gestoken om het zo te krijgen dat jij, de eindgebruiker, het ook daadwerkelijk hebt als het in hun handen is. Net als de beveiliging en de gesprekken die ik in het verleden heb gehad, kun je dit proces van testen nooit te vroeg beginnen, zo klinkt het, en hoe beter je jezelf kunt voorbereiden, hoe beter je de problemen eerder kunt ontdekken en oplossen. en krijg iets waar uw consumenten uiteindelijk dol op zullen zijn, terwijl u blijft herhalen, groeien en testen gedurende de hele levensduur van het product. Dit was fantastisch. Bedankt dat je de tijd hebt genomen om hier licht op te werpen, en het was geweldig om je hier te hebben. 

– [Luke] Bedankt, Ryan. Dat kan ik waarderen.

• Door SEO aangedreven content en PR-distributie. Word vandaag nog versterkt.
• PlatoData.Network Verticale generatieve AI. Versterk jezelf. Toegang hier.
• PlatoAiStream. Web3-intelligentie. Kennis versterkt. Toegang hier.
• PlatoESG. carbon, CleanTech, Energie, Milieu, Zonne, Afvalbeheer. Toegang hier.
• Plato Gezondheid. Intelligentie op het gebied van biotech en klinische proeven. Toegang hier.
• Bron: https://www.iotforall.com/podcasts/e320-user-testing-iot-products