Startups: verfijnde UX Vs. Snelle rollouts
Een startup is per definitie een entiteit met beperkte middelen. Die middelen kunnen budget, tijd, talent of iets gerelateerd zijn, maar wat zeker is, is dat er inderdaad een vorm van beperking is aan middelen - anders zou het geen opstart zijn.
Dit is de reden dat veel managementstijlen zijn uitgeprobeerd en getest in de strijd om de uitdaging aan te gaan die een van deze beesten van tijd en energie lanceert en draait. En in de loop van de jaren lijken er twee onafhankelijke denkrichtingen te zijn ontstaan binnen de markt: de lean-lancering en de grote opbouw.
De lean-lancering omvat zaken als agile ontwikkelingsprocessen, gebruikerstests, ideevalidatie, doelgerichte programmering, gedragsgestuurde ontwikkeling en vele andere. Aan de andere kant heb je de grote build voor de lancering: in dit model zou je veel tijd en ontwikkelaars weggooien in een project om ervoor te zorgen dat het feature compleet is voordat een enkele klant het ooit een keer ziet.
Deze twee stromingen hebben elk hun voor- en nadelen, zoals men zich kan voorstellen, en ze hebben elk managers die in bijna een hardvochtige mate in hen geloven. In dit artikel zullen we misschien uitvinden welke niet hardvochtig zijn en welke niet. Of we kunnen iets verrassends vinden. Laten we erin duiken.
Een verfijnde gebruikerservaring hebben
Laten we eerlijk zijn, design is enorm belangrijk. In feite is ontwerp zo belangrijk dat het de processen van sommige startups bijna volledig heeft ingehaald. Ze richten al hun tijd en energie op de gebruikerservaring, en als ze zichzelf tot een functie maken, verklaren ze dat ze weinig tijd hebben voor iets anders - en misschien terecht. Nu zou de andere partij niet zeggen dat dit de juiste manier is, maar we zullen dat argument voor later verlaten. Voor nu hebben we het over de wereld van een gepolijste UX en feature-set voor de lancering.
De positieve kant van een verfijnde UX
Gebruikmakend van het volledige merk
Branding is een enorm onderwerp en het is om deze reden dat het lijkt alsof mensen de behoefte voelen om op deze manier te werken. Ze vinden dat ze, als ze gaan lanceren, moeten starten met alles waar hun merk voor staat, vanaf de eerste dag ingebouwd in de site. De klassieker, "v1 moet feature complete zijn" is iets dat ik vaak van managers heb gehoord. En er is een goede redenering achter. Ze willen niet dat hun website weergeeft wat ze niet zijn, en daarin ligt de karikatuur. We zullen hier meer over beginnen in de cons-sectie, maar dit kan leiden tot ernstige feature-creep. Mijn motto is, als je een ruimte binnenloopt waar concurrenten zitten die misschien zwaarder zijn dan welke andere online ruimte dan ook (denk aan Dropbox of Apple), dan zou je dit serieus willen overwegen, omdat in dat geval branding zal zijn erg belangrijk. Hoewel je met een magere lancering kunt trouwen met fantastische technologie en een mooi merk, alles in één - wat we later ook zullen bespreken.
Directe interesse ontvangen
Een ander positief punt als het gaat om de verfijnde en gepolijste uitrol is dat het van tevoren meer gebruikers kan aantrekken vanwege het fantastische ontwerp en de volledige service die aan het hele product wordt gegeven. Tenminste, dat is wat we graag aannemen. Realistisch gezien kan het echter ook een toetredingsdrempel zijn. Ik heb gebruikers gezien die vinden dat een product te groot is of te veel functies heeft om een gevoel van 'wil' te krijgen als het erop aan komt, en ze zullen binnen een minuut van de site terugspringen. Gebeurt de hele tijd, en is allemaal te bedroefd eerlijk. Ik haat het om de ideeën van een ondernemer of zelfs manager te zien worden weggezogen vanwege de al te vaak voorkomende functiecrip. Hoewel het wel gebeurt, is het nog steeds zo dat ondernemers niet het gevoel hebben dat de rente tienvoudig wordt verhoogd als ze hun product volledig voltooien voordat ze worden gelanceerd. Dit is een grote.
De functie compleet zijn
Als je dit stadium haalt en in dit kamp woont, dan ben je waarschijnlijk op dit punt compleet. We hebben hier tot nu toe een beetje over gesproken in de bovenstaande secties, maar hier wordt het interessant. Veel, en ik bedoel dat veel start-ups denken dat ze compleet moeten zijn voordat ze kunnen opladen, of impact hebben voor die kwestie. Ik zeg niet dat dit argument geen enkele verdienste heeft, maar ik denk dat het door de jaren heen overdreven is. Vanuit mijn oogpunt en wat ik in de loop der jaren heb gezien, kun je gewoon vragen of gebruikers voor een product zouden betalen voordat ze het hele ding hebben ingevuld. Nu, laten we zeggen dat je gung-ho was over feature compleet te zijn, en je wilde inderdaad alles erin. Nou, je zou een zeer minimale versie van elke feature kunnen lanceren. Iets dat de betreffende functies vertegenwoordigt, of misschien zelfs video's van degenen die ontbreken. Houd in gedachten dat er manieren zijn om compleet te zijn zonder echt aanwezig te zijn.
Het nadeel van een verfijnde UX
Feature creep
Dit is een veel voorkomende mislukking als het gaat om de gepolijste UX en bieden een volledige aanpak voor het opstarten van een start-up. En dit is wat we een situatie noemen die de doodsspiraal van feature creep wordt genoemd. De managers of eigenaren zullen de behoefte voelen om meer en meer functies aan het product toe te voegen terwijl u anderen voltooit, totdat er letterlijk niets anders te doen is, maar meer functies toevoegen. Het is in sommige gevallen een oneindige cyclus en vooral in gevallen waarin u geen rigide richtlijnen of specificaties hebt vastgesteld.
Waterval ontwikkeling
Watervalontwikkeling is een op zichzelf staande fout, en niet zonder controverse. Een typische werkstroom van een waterval ziet er als volgt uit: idee, ontwerp, ontwikkeling, testen, onderhoud. Er zijn sommige mensen die in zo'n omgeving gedijen, maar minstens een gelijk aantal vindt het absoluut schadelijk. Of het is een vrij standaard proces dat heel gewoon voor de meesten van ons aanvoelt, en toch voor ideeën die snel duidelijk zullen worden, kan het vaak schadelijk zijn om daadwerkelijk een product te verzenden.
De reden ligt niet noodzakelijk in het systeemmodel zelf, maar in het feit dat u afzonderlijke teams hebt die werk doen dat elk door micro-managers wordt beheerd. Een typische stroom kan er bijvoorbeeld als volgt uitzien: een idee wordt gevormd door de oprichter / ondernemer; hij neemt een team voor ontwerp en ontwikkeling aan en misschien managers of creatieve directeuren voor elk team; het idee wordt doorgegeven om te ontwerpen, om mockups te maken, die mockups worden omgezet in Photoshop-documenten die heen en weer gaan met de eigenaar en de creative director totdat ze perfect zijn; dan, zonder enige consensus over wat zelfs mogelijk is, wordt het doorgegeven aan de ontwikkeling om te worden gecreëerd; en na het heen en weer gaan met de ontwikkelaar van het dev-team, de eigenaar en mogelijk zelfs de creative director, vinden ze een ontmoetingsplaats en maken ze het product af.
Wat ik echter niet noemde, is dat elk van deze stappen waarschijnlijk elk 50-100 e-mails bevatte, en dat is een voorzichtige schatting (zeer conservatief). Zoals u kunt zien, is dat niet echt efficiënt, omdat de eigenaar en oprichter op elk moment meer werk konden toevoegen dat niet in het plan was, of dingen kon veranderen. Micromanaging is vaak niet de beste optie als het gaat om softwareontwikkeling, en toch lijkt het watervalsysteem te gedijen in een dergelijke managementstijl.
Houd dat altijd in gedachten, en als je het niet goed doet om micromanaged te worden, laat dat dan aan je baas weten. Bedenk dat het altijd beter is om eerlijk en eerlijk te zijn over een mogelijk niet-productieve toekomst dan om die weg in te gaan die feitelijk onproductief is. En houd er ook rekening mee dat er meer typische microbeheerproblemen zijn die allemaal in de pijplijn zitten voor dit systeem; vanuit mijn persoonlijke ervaring is het niet ideaal.
Dus wat is ideaal? Welnu, dat is subjectief, maar ik kan u vertellen dat de mogelijkheid om snel te starten en te herhalen tijdens cyclustijden, mij en mijn teams de mogelijkheid heeft gegeven om een grotere hoeveelheid producten te verzenden dan we ooit met Waterfall hadden kunnen doen. Dus wat is dit mysterieuze magische systeem van verzending van producten?
Snelle uitrol en een lean start-up
De lean start-up is iets dat, naar mijn mening, een revolutie teweeg heeft gebracht in onze gemeenschap. En dat komt vooral omdat het is gebaseerd op iets dat we de feedbackfrequentie leren-bouwen-meten noemen.
De kunst van de snelle uitrol - vaak kan het een eenvoudige pagina zijn die vraagt of gebruikers hiervoor zouden betalen, of het kan een product zijn met blote benen - is iets dat mensen in de loop der jaren hebben geperfectioneerd, en naarmate ik meer verankerd raak in onze technische wereld Ik vind dat het steeds belangrijker wordt.
Het grote ding hier is marktacceptatie en validatie. Een belangrijke vraag: wie zegt dat de code die u schrijft zinvol is? We leven in een tijd waarin mensen echt geen enkele ounce van hun kostbare tijd kunnen vergooien. Het is een tijd van maken of breken van houdingen, groot worden of naar huis gaan. Het is een tijd waarin de realiteit ons elke dag in het gezicht treft wanneer we geen eten kunnen kopen of huur kunnen betalen, en daarom is het des te belangrijker om ervoor te zorgen dat je niet wegcijfert wat er door niemand wordt gebruikt.
Je hoeft geen genie te zijn bij marketing, maar je moet wel een experimentele gemoedstoestand begrijpen. De constante status van bèta is hier een schitterende metafoor voor. We mogen nooit zo verstrikt raken in onze trots dat we niet eens een item over een project kunnen veranderen. We moeten niet vergeten dat het leven experimenteel is, en hoe eerder je dit beseft, hoe beter: en er is geen betere manier dan met de magere startup.
Het voordeel van het magere start-up
Gebruikersfeedback
Het gebruik van een methode als deze is vergelijkbaar met het feit dat er een voorraad wordt verteld voordat deze piekt. Dit is een geweldige manier om informatie te krijgen over uw demografische doelgroep en om validatie te krijgen voordat u uw tijd verspilt.
Dit is hoe je het doet. Krijg een gemaakte bestemmingspagina en laat zien wat uw product of dienst op een hele mooie en verklarende manier doet. Besteed wat geld aan dit deel als je wilt, want het is het belangrijkste. Voer vervolgens een eenvoudige aanmelding in met uw e-mailadres als u daarin geïnteresseerd bent. Gedaan. Nu, dat lijkt misschien niet dat je veel doet, maar je doet best veel in de realiteit. U valideert een volledige productmarkt of servicemarkt met één pagina. Je besteedt geen maanden en duizenden dollars om iets onnodigs te bouwen dat niemand zal gebruiken, je maakt simpelweg één ding om uit te zoeken of het het waard is.
Er zijn mensen geweest die 5 servicepagina's lanceren die lijken op wat ik net heb gezegd, en diegene waar ze de meeste feedback op krijgen, zijn degenen met wie ze verdergaan. Het is een briljante daad, en het kan worden gezien als investeren in veel manieren. U krijgt rendement op uw investering en zo niet, dan verlaat u de markt voordat u veel potentiële voordelen verliest. Ik denk dat Warren Buffet hier dol op zou zijn.
Snellere iteratiecycli
Een van de beste dingen om productontwikkeling op een lean manier te doen, is dat je vaak zult merken dat je iteratiecycli veel sneller zijn, en in sommige bedrijven verzenden ze code meer dan 20 keer per dag. Er zit veel filosofie achter, bijvoorbeeld hoe Facebook op het moment dat een nieuwe technicus aan boord komt 5 bugfixes krijgen in hun welkomstmail op hun eerste dag. Veel reden voor het doen van dit soort dingen is dat als je je systeem zo hebt ingesteld dat het elke keer breekt dat er een nieuwe medewerker aan boord komt, het niet zij, je systeem is kapot.
Soepele ontwikkeling
Agile ontwikkeling gaat in essentie zo snel mogelijk van het ene kleine ding naar het andere. Je gaat dan van elke sprint naar de volgende sprint, die vaak wordt bepaald door een gebruikersverhaal en dat is gewoon een gebruiker op je site die een beetje functionaliteit wil. Het lijkt veel op testen in Rails of een ander framework, omdat je alleen zoveel doet als je nodig hebt en niets meer. Je kunt enorm veel tijd sparen door op deze manier ontwikkeling te doen.
Het nadeel van het magere start-up
Een klein minpunt dat kan optreden wanneer u een gebruiker bent van de agile ontwikkeling en het lean-opstartsysteem, is dat de site in de loop van de tijd kan veranderen. Dit zou idealiter gebeuren vanwege het verzoek van een gebruiker, maar toch kan het voor sommige gebruikers schokkend zijn.
Dus het doen met klasse en elegantie is belangrijk. Vooral als het een product is waar ze om geven. Ontbreek de kerngebruikersbasis van uw product niet zoals Digg v4 dat deed, maar geef in plaats daarvan details over wat u doet en waarom, en als al het andere niet lukt, rolt u terug.
Zorg er altijd voor iets als git of subversion te gebruiken om versies van uw product op te slaan. In feite doe ik het als filialen, zodat we altijd terug kunnen gaan als dat nodig is.
Ten slotte
Als uw startup zo technisch geavanceerd is dat het er niet toe doet, ga dan met de snelle uitrol. Mensen zullen zich zorgen maken vanwege de technologische verandering die ze zien. Hoewel, als je in een ruimte met enorme concurrentie concurreert, dan is misschien een combinatie van beide het beste. Kortom, doe altijd het beste wat je kunt doen met verfijnde UX, maar doe het in korte agile bursts.