Startup Development. Jesper Weltz Wollenberg. Helle Alsted Søndergaard Department of Business Administration. Author. Supervisor

Transkript

1 Speciale! Author MSc in Innovation Management Dyslexic Supervisor Helle Alsted Søndergaard Department of Business Administration Side 1 af 61!

2 1. Indledning! Problemformulering! 7 2. Metode! Traction vs. analytisk tilgang! Undersøgelser der giver værdi! Planlægning! 9 3. Teori! Startup! Produkt! Prototype! Agile software development! Sarasvathys fem principper! Bird in the hand! Affordable loss! Crazy quilt! Lemonade principle! Pilot in the plane! Big data! Handling og erfaringer! Cast.li produktet.! Hvad viste vi ved start?! Start!! Prototype - studerne (1)! Prototype - organisering (2)! Erkendelse! 29 Side 2 af 61!

3 Genfødsel! Guidens! Epiphany! Analyse! Company development model! 53 Vurdering! Kritik! Konklusion! Litteraturliste! Primær! Sekundær! 61 Side 3 af 61!

4 Abstract For the past 7 years I have worked with entrepreneurship, mostly on developing software products. When a company already have clients the approach is fairly easy and well documentet, but when you are about to start a new company with a new product it is a lot harder. There are no clients yet to sell to and you rarely have any major experience with the market that you are moving in on - it can be really hard to understand that market fully. If you take a step further and develop a whole new product that have no precedents, then you have a whole new market, new product and no organisation. That is a complex challenge. Through the years I have seen many entrepreneurs with good ideas fail. There can be many reasons for that; partners quarrel, somebody else owned the patent or something else. One of the errors that has annoyed me the most have been startups that came with a problem that I could relate to a 100%, but when they half a year later had a product then it just was not a product, that I could identify with. I could not see myself use it despite I was the target group. They had made the wrong solution to the rigth problem. For a startup to solve those challenges they need to use other methods that not necessarily exists in the academic litterature. One example of this is Eric Ries - The Lean Startup. It does not build on the acknowledged lean, but is changed acording to experience about the entrepreneurs situation. And eventhoug Steve Blank from Stanford layed the foundation to a method that focuses on developing a company, a business model and a product at the same time, it is still an area that lacks an integrated model that makes you able to maintain a broad focus on all the startups elements. Today you have to try to develop your product side by side with your business model and at all times ensure that the two courses move in the same direction and are compatible with each other. In a small organisation where the business developer and the product developer is the same person it is a challenge and easy to get cought up in one of the the two. Which can lead to big problems. At the same time the acknowledgement that a startup is not a company, but an organisation that works on building a company is not really there. That can mean as in our Side 4 af 61!

5 case, that we in the beginning began a product development without really understanding the dangers lying in the business development. In part it is because there is no good theory on the subject to lean on and find guidens in. Instead entrepreneurs exchange experience, but have no eye for the fact that a startups premise varies. And just because it worked for somebody else does not mean, that it will work for us. In our case we had looked at Niklas Stephensons company Firmafon succeed with building a fantastic product, that almost sold it self. We had not seen that we had to build a market first, because we in the beginning did not understand that we had to build a company around the product. Last but not least I have tryed to show my vision on what an integratet model for developing a company in a new market without an existing organisation, could look like. A model that combines the best of a number of models out there today and make them work as a whole. The model tryes to develop an understanding of the market in its first stage by analyzing the opportunities there are to make your vision come to life. In our case how we could clean the internet. The different opportunities is analyzed based on known methods and the goal is to get someone to buy your product. Then when you have your direction and your strategy you enter the the executing fase, where you build the product and develop it further and at the same time build the organisation up around the product. Side 5 af 61!!

6 1. Indledning Jeg har i 7 år beskæftiget mig med iværksætteri og i alle de år har jeg stort set arbejdet med udvikling af software produkter. Når man har en kunde der selv har nogle brugere er det en relativ lige til opgave, som er vel beskrevet i litteraturen, men står man overfor at skabe et nyt startup med et nyt produkt er det en noget sværere opgave: der er ingen rigtige kunder at tage fat i, man har sjældent nogen særlig erfaring i det marked man bevæger sig ind på og det kan være svært at forstå markedet fuldt ud. Går man skridtet videre og udvikler et helt nyt produkt der ikke findes noget fortilfælde til, så har man med et nyt marked, et nyt produkt og ingen organisation, hvilket betyder man står med en meget kompleks udfordring der, hvis den håndteres forkert, kan betyde at det problem man har løst aldrig rigtig kommer fra start. Gennem årene har jeg set rigtig mange iværksætter med gode idéer fejle, hvilket der kan være mange forskellige årsager til: man kan blive uvenner, der kom patenter i vejen, man kunne ikke få finansiering osv. Alle sammen årsager som kan ske og som er svære at gardere sig imod. En af de fejl der har irriteret mig gennem årene har været startups der kom med et problem som jeg kunne identificere mig med 100% men da de et halvt år senere stod med et produkt så var det bare ikke rigtig det jeg ville have og jeg ikke slet ikke længere se mig selv bruger det, og det på trods af jeg var i målgruppen. De havde lavet den forkerte løsning på det rigtige problem. Langt fra alle startups fejler på grund af sådanne fejl men en god portion gør, og da jeg selv stod over for en opgave, jeg havde set dræbe mange startups før mig, besluttede jeg mig for at undersøge hvad det er der gør at startups fejler, når de skal udvikle deres produkt. Efter som det ikke er et emne der ikke rigtig er beskrevet i litteraturen, var der få erfaringer at få fra den kant, derfor valgte jeg i stedet at basere det på observationer i forbindelse med udviklingen af mit eget produkt. Side 6 af 61!

7 1.1 Problemformulering Er den nuværende teori omkring produkt udvikling tilstrækkelig i forbindelse med udvikling af produkter for vækst iværksætter - et casestudie af et produktudviklingsforløb med henblik på at bringe et nyt produkt på markedet, set fra et iværksætter synspunkt. 2. Metode Hvad regnede vi med skulle til? Som etableret iværksætter med flere startups bag mig og med en uddannelse, der lige netop centrerer sig omkring innovation og produktudvikling, burde mit udgangspunkt for at vurdere hvad der skal til for at skabe et nyt og komplekst produkt i et startup være rimelige gode. Min erfaring har imidlertid vist mig at startupskolens tankegang og den akademiske innovationstankegang langt fra altid stemmer overens. For at sikre en fælles forståelse, vil jeg starte med at definere den teori som er vigtigt for tilblivelse af denne opgave. 2.1 Traction vs. analytisk tilgang Der er et ordsprog blandt startups, hvis ikke du er lidt skidt med dit første produkt, så har du ventet for længe med at lancere. Det hænger sammen med at man aldrig bliver færdig, hvis man som et lille team skal lave et perfekt produkt. Det gælder også her, vi skal have generet traction, og det betyder at handling skal prioriteres højt. Netop derfor har jeg sammen med min medstifter på projektet valgt at anvende Agile software development som vores udviklings metode. Agile software development er en metode, der lader os fokusere på udvikling og bruger. Samtidig står vi med et produkt, der ikke er lige til at forklare og yderligere gør produktets hidtidige udvikling, at vi ved start står med en simpel prototype, der mest af alt kan forklares som et proof of concept. De input denne tidlige udgave har genereret, vil vi bruge til at skabe grobund for første design og prototype og ud fra denne skabe forbedringer i et forløb som beskrevet i figur 2.1. Side 7 af 61!

8 Figure Agile development En væsentlig grund til at vælge denne tilgang er, at vores udfordring ikke ligger i at udvikle nogen form for komplekse nye teknologier, vi skal skabe en brugeroplevelse der gør at brugerne har lyst til at tage produktet til sig. Vores udfordring er i lille grade at få noget til at virke, for det er i store træk lykkedes før specialets start med det eksisterende proof of concept. Vi skal takle de markedsrisici, der ligger i at udvikle dette produkt. 1 Så selv om vi har opfundet en ny måde at håndtere data på nettet på, så er det, der skal give os succes ikke opfindelsen, men design og eksekvering. 2.2 Undersøgelser der giver værdi Når vi taler med brugere er målsætningen for os at finde frem til om brugeren kan lide produktet og om der er nogle ekstra ting omkring produktet brugerne gerne så tilføjet. Målet er ikke at få et videnskabeligt bevis for noget, men bare deres holdning til produktet. 1 Ulrich, Karl T. Eppinger, Steven D. (2008). Product Design and Development. Side 8 af 61!

9 Input kan komme fra alle sider af, og alle mulige steder fra, hvilket betyder at vi ikke har en decideret struktureret teknik til at udføre den slags, men i stedet går efter at vise det til så mange som muligt. Sidder man til en familie fødselsdag og man kan se sit snit til at vise det til en, så gør man det og ser på hvad man får ud af det Skal man have input til en funktion til studerende så går man på statsbiblioteket og forsøger at vise det til nogle og få deres input. Målet er at få input fra alle sider så tit så muligt, og det man skal have med der fra er et ja eller nej? - hvis nej hvorfor? Hvad ville få dig til at bruge det? Og hvis ja hvad betyder mest ved produktet? Hvad kan vi helt sikkert ikke undvære? Hvad betyder knap så meget? Man laver nogle simple noter af de vigtigste svar, og har man 5-10 mennesker der siger det samme, så er det nok rigtigt. 2.3 Planlægning Erfaringer har vist at en forretningsplan er utrolig meget arbejde på noget der umiddelbart ikke giver nogen værdi, og når den er færdig er den forældet - for forretningen ændrer sig hele tiden. Problemet er den er statisk og man har ingen nem mulighed for at ændre i den. I stedet har jeg altid arbejdet med et exetive summery, der indeholder det mest basale: hvad er produktet, hvordan tjener vi penge, hvem er kunderne, og hvad er visionen. Fire spørgsmål der er vigtige og som besvares på 1-2 sider. Fire spørgsmål der giver projektet retning, hvilket er det primære formål for markeds analyser og lignende er trods alt bare kvalificeret gæt. Side 9 af 61!

10 3. Teori I dette afsnit vil jeg indledningsvis definition en række begreber der vigtig for specialet. 3.1 Startup I udgangspunktet betragter jeg et startup som en lille virksomhed og den definition er meget lig den man finder, hvis man slår ordet op i ordbogen: start-up ˈstɑr ˌdəәp (also startup ˈstärtˌəәp ) noun A newly established business: problems facing start-ups and small firms in rural areas. En definition der i sin essens har bred tilslutning også i fag litteraturen, der er dog ikke total enighed om definitionen. Mere specifikt er Startup det ord som særligt mange it-iværksættere vælger og bruge om deres nystartede virksomhed. En klar definition er svær at finde, da der er mange forskelige holdninger til, hvad et startup præcist er, men Steve Blanks definition "A startup is an temporary organization in search for a scalable, repeatable, profitable business model." Er den jeg personligt finder mest sigende. Andre populære definitionerne omtaler startups som virksomheder, der endnu ikke er børsnoteret, men der findes mange virksomheder, som aldrig bliver børsnoteret så spørgsmålet er om disse definitioner er særlige sigende. I hovedreglen findes der fire typer af startups: Den første er den mest almindelige. Folk der beslutter sig for at starte en sandwitchbar, et autoværksted eller noget helt tredje for at de selv kan få noget at lave. Deres motivation er at tjene penge til dem selv. Social entreprenørers, folk der har fokus på at gøre noget godt enten for profit eller som non-profit. Side 10 af 61!

11 Store virksomheder i en branche, som bliver ændret af disruptiv innovation og derfor bliver tvunget ud i at tilpasse deres forretnings model til nye markedsvilkår. Disse store virksomheder er enlig ikke startups i traditionel forstand, men de bliver tvunget ud i at opføre sig som startups. Den sidste og vigtigste type for denne opgave er Scalable Startups. Det er startups, der går efter at implementere en ny forretningsmodel, der har til formål at skabe en stor virksomhed ved at implementere en eller anden form for disruptiv innovation. Scalable startups kan som regel ikke klare sig selv økonomisk uden en eller anden form for ekstern finansiering. Oftest starter scalable startups ikke med et defineret markedet eller med et defineret produkt, men centreret omkring et problem. Det er vigtigt at pointere at et scalable startup (fra nu bare startup) ikke er en lille udgave af en traditionel virksomhed, men en helt anden organisationsform. Et startups fokus er i stor grad at finde og udvikle en skalerbar forretningsmodel, hvorimod en stor virksomheds fokus hovedsageligt er at optimere på en etableret og bevist forretningsmodel. To meget forskellige fokus. På længer sigt er målet for et startup at blive en stor virksomhed og på vejen derhen er tre stadier. Startup fasen der handler om at finde frem til en forretningsmodel. Transaktions fasen der er fra forretningsmodelen er identificeret og til der er et Cash flow og virksomheden begynder at tjene penge. I denne fase skal virksomheden begynde at fokusere på at servicere kunder. Når virksomheden vokser sig til et stadie, hvor den nu begynder at kunne finansiere sig selv, virksomheden skal nu til at fokusere på at optimere driften, og fokusere på at sikre kvaliteten af deres ydelser. Side 11 af 61!

12 Tabel Transaktion model fra startup til virksomhed. Scalable Startup Transition Large Company Entrepreneurial-Driven Learning and Discovery Mission-Oriented Management Process-Managed Execution and Growth CEO s Personal Contribution CEO s Time Commitment Planning Process Superstar Leader Manager 24/7 As needed Long term 9 to 5 Opportunistic & agile Hates and eliminates Mission- and goaldriven As needed driven by mission Span of Control Hands-on Mission-driven Process-, and goaldriven Implements and uses Distributed to organization Focus Vision Mission Execution Chaos Brings order out of chaos Focuses on fast response Focuses on repeatability Kilde: Blank, Steve & Dorf, Bob. (2012). The Startup Owner s Manual. Portfolio Penguin. 1st Edition. 3.2 Produkt Helt grundlæggende er produktet dette speciale omhandler, et værktøj til at organisere og håndtere online indhold fra hjemmesider. Produktet i sig selv er også webbasseret og bygger på webteknologier, det vil altså sige produktet er et online multimediaproduktet. England og Finney beskriver netop sådanne multimedieprodukter som:... the seamless integration of text, sound, images of all kinds and control software within a single digital information environment. 2 I dette speciales tilfælde sker der en naturlig afgrænsning ved det at produktet er online passeret og jeg vil derfor kun se på multimedia produkter som et online fænomen. 2 England, Elaine & Finney,Andy. Managing Multimedia. Side 12 af 61!

13 3.3 Prototype Ulrich og eppinger definere en prototype som an approximation of the product along one or mere dimensions of interest så formålet er at undersøge en eller flere dele af interesse. 3 De fortsætter med at tale om to dimensioner i prototyping som jeg ikke mener er passende, når det kommer til software prototyping. Jeg vælger derfor at følge demissionerne fra Professionel Systemudvikling der skelner mellem vertikale og horisontale prototyper, hvor vertikale prototyper er en fuldstændig realisering af en udvalgt del af det funktionelle design, det kan eksempelvis være en profilside, der er gennemarbejdet fuldt ud, og hvor all funktionalitet er på plads. En horisontal prototype er derimod ikke gennemarbejdet i samme detaljegrad, men til gengæld er hele forløbet gennem produktet realiseret, så det er muligt at demonstrere, hvordan det vil være at bruge servicen, imidlertid er det nødvendigvis ikke muligt fordi databasser, fejlbehandling eller lignende ikke nødvendigvis er på plads. 4 En del af forklaringen på hvorfor jeg finder disse dimensioner mere anvendelige, findes i Ulrich og Eppinger. Inden for software er prisen pr protype meget lav og software handler om brugeroplevelser, hvilket betyder der er en stor markedsrisiko, hvis forventninger til produktet ikke indfries. For at elimere en del af dette påpeger Ulrich Eppinger, at i en sådan branche vil man bygge mange og håndgribelige prototyper, som vist i figuren herunder. 3 Ulrich, Karl T. Eppinger, Steven D. Product Design and Development. 4 Andersen, Niels Erik. Kensing, Finn. Lassen, Monika. Lundin, Jette. Mathiassen, Lars. Munk-Madsen, Andreas & Sørgaar, Pål. Professionel Systemudvikling Side 13 af 61!

14 Figure The use of comprehensive prototype depends on the relative level of technical or market risk and the cost of building a comprehensive prototype Kilde - Ulrich, Karl T. Eppinger, Steven D. (2008). Product Design and Development. McGraw-Hill Education. 4th Edition. Evolutionary prototyping er et prototype paradigme, der bygger på at det endelige produkt skabes i en iterativ proces, hvor man starter med den mest basale prototype og udbygger denne over tid. Der kan udarbejdes flere prototyper samtadig, så der kan arbejdes med forskellige aspekter samtidigt. Disse bliver så fusioneret sammen til det endelige produkt. Evolutionary prototyping kræver dog mere arbejde for sikre kvaliteten af de enkelte elementer, da det er vigtigt at de forskellige dele af prototypen til sidst er i stand til at arbejde sammen. Det er dog mindre komplekst end det lyder, hvis man sikrer, at koden er bygget op i blokke, der håndtere klart definerede arbejdsopgaver med klart definerede ind og output. Samtidig er det vigtigt at sikrere sig at opbygge elementerne med fleksible objekts orienteret kode 5 5 Pomberger, Gustav. Bischofberger, Walter. Kolb, Dieter. Pree, Wolfgang. Schlemm, Holger. (1991). Prototyping - Oriented Software Development Concepts and Tools Side 14 af 61!

15 En metode inden for Evolutionary prototyping, som har særlig interesse for dette speciale er extreme prototyping. En metode der i sin enkelhed består af tre faser. En mockup fase, hvor man bygger statiske html sider, eller i ekstreme tilfælde bare bruger billeder, der kan klikkes på, så man kan danne sig et indtryk af produktet. Derefter genererer man simuleret data og skaber en interaktiv version af fase 1, til sidst bygger man servicen og bygger systemet bag ved færdig Agile software development Agile software udviklingen tager essentielt set principperne fra Evolutionary prototyping. Metoden deler processen op i korte faser med minimal planlægning og uden nogen form for langsigtet planlægning. Hver ittereation deles op i timeboxes hvor teamet arbejder sig igennem et helt software udviklingsforløb. Et timeboxforløb vil normalt tage imellem 1 og 4 uger, og teamet gennemløber normalt flere forløb på vejen mod det endelige produkt. Formålet med metoden er at man hurtigt kan optimere på produktet og derved minimere risikoen for at udvikle et produkt, der ikke opfylder de krav brugeren må have. 3.5 Sarasvathys fem principper Sarasvathy fremhæver fem områder, der adskiller effectual tænkende fra causal tænkende. Det er fælles for disse områder, at causal tænkning hjælper med at vælge, mens effectual tænkning hjælper med at skabe muligheder Bird in the hand Hvad kan jeg ellers gøre? - Frem for at starte med et forudbestemt mål og derefter afsætte de nødvendige midler, og så finde dem mest effektive, billigste og hurtigste metode til at nå målet, bygger bird in the hand princippet på at effectual tænkende, vil starte med at se på de midler de har til rådighed og ud fra disse finde en løsning. 8 6 Beck, Kent. Andres, Cynthia. (2004) Extreme Programming Explained: Embrace Change. Addison-Wesley Professional. 2ed edition. 7 Sarasvarthy, Saras D., 2008, Effectuation - Elements of entrepreneurial expertise, s Sarasvarthy, Saras D., 2008, Effectuation - Elements of entrepreneurial expertise, s Side 15 af 61!

16 Affordable loss Hvad har jeg råd til at miste? - Affordable loss er en viderebygning på det faktum at effectual tænkende arbejder ud fra de midler de har til rådighed. Det betyder også at de ser på hvad de har råd til at miste og så for det bedste ud af det. Dermed arbejder effectual tænkende ud fra at minimere tab, frem for at se på hvor hurtigt man kan vokse og hvor meget man kan tjene Crazy quilt Hvem kender jeg der kan hjælpe? - Det gælder om at finde de rigtige partnere. Ideer og projekter vokser gennem ens netværk. Ingen kan alt selv og for at skabe succes må man bringe andre mennesker ind i et projekt og få dem til at føle et ejerskab i projektet. Jo flere mennesker man kan få til at føle et ejerskab, jo mere værdi kan man skabe for alle parter Lemonade principle Et amerikansk ordsprog siger: When life gives you lemons, make lemonade Den tankegang ligger bag lemonade princippet, til forskel for causal tænkende, der forsøger at undgå alt uventet, forsøger effectual tænkende at udforske det uforudsigelige og bruge de muligheder, der opstår Pilot in the plane Fremtiden består af dem der skaber den! - Effectual tænkning bygger generelt på en ide om uforudselig kontrol - en tangegang, hvor man forsøger at styre de elementer af fremtiden man har mulighed for at påvirke. I modsætning til causal tænkning, der bygger på at forudsige alt det fremtiden, som det kan indberegnes nu.21 Sat på spidsen, kan man sige at causal tænkning er som en computer, hvor der arbejdes efter et givet system og et givet mål og alt hvad der dukker op af interessante mellemregninger, der ikke er taget højde for i forvejen ignoreres. I modsætning til effectual tænkning, der mere bygger på 9 Sarasvarthy, Saras D., 2008, Effectuation - Elements of entrepreneurial expertise, s Sarasvarthy, Saras D., 2008, Effectuation - Elements of entrepreneurial expertise, s Sarasvarthy, Saras D., 2008, Effectuation - Elements of entrepreneurial expertise, s Side 16 af 61!

17 tanker som kendes fra den klassiske ryksækrejsende, der køber en fly eller togbillet, og hvad der sker derfra, vil tiden vise Big data Big data er et relativt nyt begreb og det er svært at finde en definition i litteraturen og endnu sværere at finde en definition, der er bred enighed om. Men den der ser ud til at være bredest enighed om er data with volume, velocity and variety 13 en definition der støttes af store spillere i markedet som IBM og af analytikere som IDC. Definitionen fokuserer på tre karakteristika, der kendetegner big data. Volume peger på mængden af data der skal være til stede; velocity, påpeger med hvilken hastighed dataene skal analyseres; og variety er bredden af forskelige typer af data, der skal analyseres så som tekst, video, lyd, web logs og så videre. Big data anses som at værende af de største muligheder inden for informations- og kommunikationsteknologien med en vækst fra 3.2 milliarder i 2010 til en forventet værdi på 16.9 milliarder i Altså en branche med en forventet vækst på ca. 40% p.a. 14 I dette speciale ligger vores fokus inden for big data i ultra-high-speed data manipulation, hvor målet er at kunne give real-time data feedback Sarasvarthy, Saras D., 2008, Effectuation - Elements of entrepreneurial expertise, s Butler, Brandon. Defining 'big data' depends on who's doing the defining. 14 Vesset, Dan. Worldwide Big Data Technology and Services Forecast 15 Vesset, Dan. Worldwide Big Data Technology and Services Forecast Side 17 af 61!

18 4. Handling og erfaringer I dette afsnit vil jeg redegøre for hvad vi gjorde, hvor det gik galt og hvad vi fandt ud af hen af vejen. 4.1 Cast.li produktet. Hvordan opstod ideen og produktet? Som med de fleste startups opstår produktet ikke gennem en stor undersøgelse af markeder og eller en analyse af huller i markedet. De fleste startups arbejder ud fra et problem, som ophavs manden til ideen selv har observeret. For selv om der findes startups, der opstår ved at en gruppe af mennesker går sammen og siger skal vi ikke lave noget sammen, så er langt de flest startups basseret på en observation, en underen eller en ideen til et produkt eller en løsning. I cast.li s tilfælde var manden bag, Lasse Chor, en af mine gode venner, jeg tidligere havde lavet lidt forretninger med. Lasse Chor arbejder rigtig meget med online markedsføring og medier og her observerede han en problemstilling. Problemstillingen består i at når man sender information rundt, var det for det meste en bestemt del af en artikel eller lignende, som man sendte rundt, der var interessant, og selv om man som afsender forsøgte at forklare, hvad det vigtige i artiklen var, så blev den bid af information stort set altid tabt i det sekund man sendte linket til artiklen. Denne irritation over at hver dag brugte relativt lang tid på at gennemlæse en masse tekst, der enlig ikke havde noget med det han arbejde på at gøre affødte spørgsmålet hvorfor findes der ikke en overstregningstus til internettet?. På dette tidspunkt var Lasse Chor og jeg, ved at gøre klar til en startup bootcamp i Aarhus ved navn Startup Weekend, et koncept hvor man over en weekend forsøger at tage ide til produkt. Man pitcher en ide fredag, de ti ideer flest kan lide forsøger man så at lave til en virksomhed inden søndag. Vi besluttede os for at tage ideen om den online highlighter med om ikke andet for at se om vi var de eneste, der kunne se ideen, hvis ikke var der nok ikke noget i det Ideen gik videre og endte blandt de 10 bedste og da de deltagende i startup weekenden skulle vælge hvad de helst ville arbejde på, stod vi pludselig med det største af de ti hold. Det på trods af at vi fredag faktisk ikke vidste om det overhovedet ville være teknisk muligt at udvikle en overstregningstus til internettet. Nogle af dem der besluttede sig for at hjælpe os viste sig at være meget dygtige udviklere, så søndag stod vi Side 18 af 61!

19 med en prototype, der viste, at en overstregningstus til internettet var teknisk muligt og vi vandt prisen for bedste pitch. Produktet var på derværende tidspunkt alt andet end brugervenligt. Det ville faktisk nok ikke være en overdrivelse at sige man skulle have været med til at lave det, for at forstå hvordan det virkede. Den tekniske løsning havde også et antal problemer og i tiden lige efter startup weekend udviklede vi en smule på produktet og udviklede en teknisk bedre løsning, men energien omkring produktet døde hurtig hen. Efter sommerferien i 2011 skete der det et medstifteren i min virksomhed valgte at flytte til København grundet endt studie og efter virksomheden mest af alt har været et studie job valgte vi at lukke virksomheden. I sammen periode skete der lignende ting for flere af folkene bag arbejdet fra Startup Weekend. Og vi besluttede os derfor for at se på om der enlig ikke var forretning i den her idé. Derfor besluttede jeg mig endvidere for at vinkle mit speciale mod udviklingen af cast.li produktet. 4.2 Hvad vidste vi ved start? På tidspunktet for specialets start havde den tideligere version af produktet været offentligt tilgængelig på vores hjemmeside og et antal brugere havde også prøvet tooled, men de tre primære tilbagemeldinger vi konstant fik var 1) Hvordan virker det? det var hovedsageligt folk, der ikke havde en stor indsigt i webudvikling og/eller software generelt og de kunne simpelthen ikke finde ud af at aktiver tooled. 2) Det virker ikke! Dette var desværre korrekt og hang sammen med den korte udviklingstid, der gjorde der var så mange fejl i koden at det simpelthen ikke var pålideligt nok for folk. Vi havde mange tekniske problemer, der resulteret i rigtigt mange underlige problemer, og disse skræmte brugere væk fra at bruge tooled aktivt. 3) Sidst, men ikke mindst, var der rigtigt mange, der kunne se ideen, men for dem var problemet, at den data de fandt og overstregede blev væk, så selv om de nu kunne markere det vigtige, så havde de et nyt problem. Når de markerede noget så fik de et short link 16 fra os men hvad skulle de så gøre ved det. Informations indsamling var meget fin, men hvordan skulle man finde tilbage til det man markerede? 16 Et short link er et system der tager en lang adresse et en hjemmeside, et såkalt url, og erstatter det med en kort url der indeholder færre tegn. Side 19 af 61!

20 De 2 første punkter var vi godt selv klar over. Målet til startup weekend havde været at lave noget, der beviste ideen var teknisk mulig og det var i det store hele lykkedes. Men det 3. punkt kom mere bag på os, vi havde enligt set tooled som et socialt delingsværktøj, der gjorde det lettere for brugeren at dele den vigtige del af noget information med folk, men når man så på det som et indsamlings/delings værktøj, var der pludselig meget mere perspektiv i produktet. Det gav også afsenderen et meget højere incitament for at markere indhold da de også vil kunne bruge det senere. 4.3 Start! Da vi starter på at arbejde med produktet er det med to klare teorier. 1) Vi har et produkt som en stort udsnit af folk vil finde anvendeligt, særligt mange studerende. 2) Den data vi vil være i stand til at indsamle omkring hvad der er vigtigt på en bestemt hjemmeside, vil kunne skabe en stor værdi på længere sigt, da vi vil kunne anvende det til at lave realtime trend analyser omkring indholdet på specifikke sites, information der vil gøre os i stand til at lave alt fra bedre søgemaskiner, bedre online reklamer, bedre underrubrikker til aviser og meget mere. Det faktum at mange studerende kunne se anvendeligheden i tooled, kunne hvis udnyttet rigtig, vise sig at være en ren guldgruppe rent marketings- og udbredelsesmæssigt. Økonomisk var det mere diskutabelt, de fleste studerende har masser af tid og vil gøre meget for at få noget gratis, men de færreste af dem er villige til at betale ret meget for noget. Uanset mener vi at de studerende er et godt sted at starte, hvis udnyttet rigtigt, så vi gik i gang med at se på hvad de studerendes behov var og hvordan de ville bruge værktøjet. Det skulle fokuseres til opgaver, man skulle markere og gemme de vigtige dele af artikler, til en fældes gruppe sammen med ens medstuderende og så skulle værktøjet kunne outputte databassen som en videnskabelig litteratur liste. En relativt simpel kravsliste, hvis grund funktionaliteten havde virket som den skulle. Det gjorde den bare ikke endnu, så vi beslutte os for at tage et forløb på en måned til at få grund funktionaliteten til at virke og for at få den første anvendelige prototype henvendt til de studerende til at køre. Efter som vi havde haft den tideligere prototype ude blandt et antal studerende valgte vi at bygge den første prototype basseret på deres input. Side 20 af 61!

21 Vi valgte at følge den agile system development life cycle (SDLC) model, en model som Scott W. Ambler, en af fædrene til agile software udviklingen, stod bag. 17, 18 Efter tankerne for SDLC starter vi med at analysere på om projektet har noget potentiale og hvorvidt det er værd at gå videre med. Dele af denne undersøgelse omfatter de faktorer der er observeret forud på grund af projektets historie, men et spørgsmål, der stadig står hen i det uvisse er hvorvidt der er et realt forretningspotentiale i produktet og hvor bredt produktet appellerer. Vi har allerede set interesse i produktet fra studerende, men er der andre brugergrupper som ville finde produktet interessant? Ovenstående to spørgsmål har stor betydning for produktets fremtid. Samtidig har spørgsmålet omkring produktets appel til andre brugergrupper en relativ stor betydning, når det kommer til produktets økonomiske perspektiver. På den baggrund gik vi ud for at se om vi kunne finde andre og mere økonomisk interessante brugergrupper, samtidigt kastede vi også bolden ud i vores netværk for at se om andre kunne se en anderledes anvendelse af produktet, som vi ikke selv havde tænkt på. Vi så selv hurtigt muligheder indenfor flere forskelige brugergrupper, så som konsulenter, forskere, politikere og hele kommunikationsafdelinger. På dette tidspunkt var også første gang, hvor vi blev gjort opmærksom på, at fakta findes uden for kontoret, med en særligt henvendelse, der var ekstra interessant. Figure Flow i produktet 17 The Agile System Development Life Cycle (SDLC). Scott W. Ambler. 18 Manifesto for Agile Software Development. Agile Alliance. Side 21 af 61!

22 Figure Agile software development Kilde - Beck, Kent. Andres, Cynthia. (2004) Extreme Programming Explained: Embrace Change. Addison-Wesley Professional. 2ed edition. Side 22 af 61!

23 Henvendelsen fra Ole Bach Andersen 19 direktør i firmaet Newsperience som kunne se en mulighed for at anvende tooled som en del af en applikation han var i forhandlinger med et støre dansk publikations hus omkring. Nærmere bestemt en e-bogs læser, hvor i det skulle være muligt at dele udsnit af bøgerne med ens venner og bekendte gennem sociale medier. Ideen fra det større danske publikationshus s side var, at den oprindelige læsers venner og bekendte på de sociale medier, fandt en interesse i de udsnit der blev delt af den oprindelige læser og forhåbentligt ville det få dem til at købe resten af bogen. Dette var en noget anderledes forretningsmodel, end vi indledningsvis havde set for os. Den viste samtidig også, at der var en interesse for at betale for adgang til teknologien bag vores produkt. Vi undersøgte også hvorvidt der var spillere i markedet, der var villige til at betale for den data vi potentielt ville være i stand til at levere. Også denne potentielle forretningsmodel var der interesse for, blandt andet fra flere danske aviser, der kunne se idéen i at udnytte dataene til at optimere på deres artikler. 20 Eftersom vi på dette tidspunkt stadig ikke havde et færdigt produkt at sælge, valgte vi ikke at gå for langt op mod toppen. Dette specielt fordi de udmeldinger vi havde fået i stor stil var positive og tog godt mod både ideen og prototypen på produktet. Formålet med de indledende øvelser, gik derfor mest af alt ud på at se om der var potentiale i produktet, og det stod hurtigt klart at det var der Prototype - studerende (1) For at bygge prototypen til de studerende, begyndte vi nu på at definere hvad der skulle til for at de studerende ville se en ide i at bruge vores produkt. Indledningsvis havde vi selv en teori om, hvad der skulle til og vi havde en del inputs fra de studerende fra tiden efter startup weekend. Selv om det var ustruktureret viden, så gav den et klart billede om hvor vi skulle hen. Vores første prototype skulle kunne noget i stil med den illustration som ses herover. Det skulle være muligt for brugeren at oprette en bruger, installere tooled, logge ind, markere tekst fra andre sider, dele links og have en profil, der viste ens egne markeringer. Ideelt set skulle man også være i stand til at oprette grupper, men på daværende tidspunkt, ville det 19 Bilag 1 20 Bilag 2 Side 23 af 61!

24 ikke var det ikke en let opgave at løse da vores bagvedliggende database, ikke var organiseret på en måde der gjorde deling på tværs af brugere let. Arbejdet gik derfor i gang med vores første evolutionary prototype. 21 En prototype, der skulle være så robust, den også kunne indgå som del af det endelige produkt. En beslutning vi havde truffet for at minimere time to market selvom det ville øge kravene til prototypens kvalitet. Cast.li produktet er et produkt, hvor langt hovedparten af den kode, der kunne blive relevant at ændre over tid er frontend code 22. Det betyder at det kode, der skal skrives i forbindelse med skabelsen af en prototype, ville være den samme kode, der skal til for at skabe det endelige produkt, så arbejdsbyrden ved at skabe en evolutionary prototype ville totalt set ikke være meget støre end arbejdsbyrden ved at skabe en traditionel prototype. Ved at dele koden op i hvad der kaldes object orienteret classer 23 vil vi efterfølgende være i stand til at rette i dele af koden uden særligt store problemer og uden at skulle skrive hele koden om. En model der ville gøre os i stand til at arbejde noget hurtigere og samtidig skabe produktet i iteration og konstant teste produktet på slutbrugeren og derved gøre at risikoen ved at lancere produktet meget lavere. Målet med den første prototype var nødvendigvis ikke at lave det mest brugervenlige værktøj, men derimod at finde frem til hvilke funktioner, der skulle være i den først udgave. Vores energi blev derved ikke brugt på at vejlede brugeren i at bruge produktet, men mere integrationen af funktionerne, sagt med andre ord, vi startede altså med at lave en horisontal prototype, hvor vi hurtigt stykkede dele af produktet sammen på denne nedenstående grafisk meget simple side: 21 Crinnion, John. Evolutionary Systems Development, a practical guide to the use of prototyping within a structured systems methodology. 22 Software består i hovedereglen af tre lag front end, back end og en databasse. Back end er der magien forgår det er manipulationen af de input brugeren giver systemet, i vores system kan det eksempelvis være det system der går ind og finder ud af hvad der er tekst på en side. front end er interaktionen med brugeren det er det man ser som bruger ser, det kan være en hjemme sides. databasen er der hvor information er gemt i vores tilfælde er bliver castende gemt i en databasse. 23 En objekts orienteret codnings metode der gør man kan kalde funktioner og give den et defineret input og så få et defineret output. Side 24 af 61!

25 Figure Første prototype En side, der er så simpel det næsten er pinligt. De forskellige links på siden gjorde ikke mere end det lige var nødvendigt at de skulle kunne og Group siden virkede faktisk ikke rigtig, den gav blot dem vi testede siden på, en ide om at funktionen var på vej. De brugere vi testede denne prototype på, gav os hurtigt nogle ideer til hvad de ønskede af generel funktionalitet, for selv om brugerne generelt gav os ret i bredden af tooled, var der nogle væsentlige pointer, der kom frem angående hvordan produktet burde struktureres. Pointerne blev delt op i need to have og nice to have : Need to have - Det burde være muligt at gemme i en form for mapper eller bruge tags - Tidslinjer fungerer rigtigt skidt og ting bliver væk i dem - Det duede ikke at man skulle loade siden igen når man aktiverede tooled - Man skulle kunne se hvad man havde markeret. - Man skulle kunne fortryde ens markeringer - Det skulle være muligt at kommenter ens cast - Det skulle være muligt at markere mere end en passage Side 25 af 61!

26 Nice to have - Det ville være fedt hvis man kunne bruge det i pdf - Mulighed for at markere billeder - Dele video og lyd Når vi så på listen over ideer, så handlede de fleste om hvordan man løst de forskellige delopgave, mens kun en handlede om ekstra funktionalitet, nemlig muligheden for at markere ind til mapper. En forøgelse der i sin essens handlede om at organisere ens markerede information. Denne mulighed hang til dels sammen med at dele cast og til dels sammen med opbygningen af ens profil, og på en eller anden måde skulle disse organiseringersmuligheder også hægtes sammen med tooled, da det er i tooled at den første organiseringen forgår. Netop dette ønske virkede til at være en funktionalitet, der skulle binde de forskellige dele sammen og derfor virkede det som værende det sted vi skulle starte udviklingen af den næste generation af prototypen Prototype - organisering (2) Vores fokus skiftede nu til hvordan vi kunne sikre, at brugerne ville være i stand til at finde tilbage til det de havde markeret. De inputs vi havde fået fra brugerne havde i høj grad centreret sig omkring en form for organisering i mapper eller noget lignende. Flere af de mere teknologisk kyndige, havde også omtalt muligheden for at bruge tags til organisering, det var dog sværere lige umilddelbart at se en løsning, der ikke øgede produktets kompleksitet væsentligt. At blive nød til på den måde at komplicere produktet var noget vi meget nødigt ville, for det var blevet klart for os at det allerede nu var rigeligt komplekst som det var og vi var bange for at hvis at miste brugere, hvis det blev sværere at bruge produktet. Som en mulig invester meget rigtig sagde i konkurrerer med Copy & Paste, så det skal være lige så let Rasmus Bjerngaard Seed Capital Side 26 af 61!

27 Derfor brugte vi lang tid på at overveje alle Figure Tool design mulige forskellige løsninger. Vi undersøgte nøje nogen af dem, som vi syntes havde gjort det godt, så som dropbox og Google+ men efter mange forskellige koncepter, slog det os at facebook havde svaret. Metoden kendes fra når man vil tagge en anden bruger i facebook så laver man og så begynder man at skrive navnet, systemet forslår så selv resten af navnet. Ved at integrere et tag system i vores tool, hvor tooled selv havde en liste over de tags man havde brugt før og derudover at lave et system, hvor man kunne dele casts med et bestemt tag med andre, Ville man være i stand til at samle deling og organisering i en funktion der forekom umilddelbart simpel og let forståelig. Disse tags kunne så blive brugt til at organisere ens profil sammen med metadata omkring ens cast, så som hvilket domæne et cast kom fra, eller hvem forfatteren på artiklen var, eller noget helt tredje. Det vi forstillede os var at funktionen i sig selv skulle give værdi for den enkelte bruger og at funktionen ville skabe et incitament for, at brugeren ville bruge det fra starten. Det der var vigtigt for os, var at brugeren på forskellige stadier kunne bruge den samme funktion forskelligt, afhængigt af deres egne behov og ved at bygge mapper, deling og organisering ind i en simpel funktion, ville brugerne kunne anvende det på den måde som de fandt lettest, uden at have et værktøj med en massen knapper de aldrig selv brugte. Denne logik opstod tildels ud fra princippet i Metcalfe's lov, der siger at værdien af et netværk, er lig antal brugere i anden ganget med en konstant. Eller sagt på en anden måde, hvis ingen du kender har installeret cast.li, så skal tooleds primære funktioner gøre, du vil bruge produktet. En enkelt bruger skal ikke have en følelse af at brugerens venner burde benytte cast.li for at brugeren kan udnytte tooled fuldt ud. Der skal med andre ord helst ikke være noget barriere, der stopper den enkelte bruger fra at investere tid og ressourcer i at bruge tooled, da de sociale dele af tooled først bliver aktuelle, når der er nogle andre brugere at være sociale med. Når brugeren begynder at få venner til at Side 27 af 61!

28 benytte tooled, skal den aktivitet du har haft før, understøtte det sociale ellement og ved at du allerede har organiseret det markerede med tags, kan brugeren blot dele et af disse tags med en ven og så er din tidligere arbejdsproces ikke spildt. Brugeren kan altså fortsætte med at gøre det vedkommende plejer. Ved at bruge tags til at organisere og gøre klar til deling, bygger vi meget ovenpå en tankegang, der er kendt fra eksempelvis Dropbox, hvor du kan gennem en fil i en mappe og så bliver den delt, men ved at bruge tags kan vi dele med flere, svarende til at have en fil i flere mapper. Og det kan være flere dele mapper eller bare flere kategorier til en selv. Samtidig slipper vi for at have mange forskellige sider til grupper, mapper og profiler, men kan få alt til at foregå på en side, hvor man bare ved at trykke på et tag, kan se hvad der er markeret med lige præcis det tag. Vi havde nu fundamentet til vores næste generation af prototype, som kan ses herunder: Figure Flow mellem tool og profil Side 28 af 61!

29 Erkendelse Det var ved at være februar og vi var ved at være klar med anden prototype, da jeg fik tilsendt en række youtube klip. Klippende var af Steve Blank, en tidligere serieiværksætter, og nu undervisser på blandt andet Stanford og Berkeley. 25 Videoerne handlede om noget jeg enligt havde hørt før, nemlig at startups ikke er små virksomheder og at startups primære opgave er at søge efter en respektabel forretningsmodel. 26 Dette vidste jeg for så vidt godt, før vi gik i gang og det var tildeles også derfor vi i cast.li ikke valgte en udviklingsmetode som vandfalds metoden eller stager gate eller noget lignende, men i stedet valgte den mere fleksible metode agile software development. 27 Vi havde sat vores arbejdsgange som en udviklingsafdeling for en vi virksomhed. Med et mindset som om vi havde kunder der ville betale for vores produkt, så snart det var klart. Det var imidlertid ikke tilfældet. Vi havde kundegrupper, der var interesseret i den data som mange brugere i vores system kunne generere. Disse mulige kunder var sågar klar til at betale rigtigt meget for det. Vores mulige kundegrupper var, derfor efter vores vurdering, nok til vi var gået i execution mode. Men det ville ikke være en forretningsmodel, vi ville kunne bygge en rentabel forretning på lige foreløbig. Vi kunne naturlig vis forsøge at få investorer ind, men de krævede en eller anden form for tracktion og selv om en kraftig vækst i bruger massen kan være interessant, så ville det være svært i det nuværende marked at få investeringer basseret på en formodning om økonomisk gevinst hvis x, y, z faktorer falder i hak. Så selv om vi havde set et stort potentiale i projektet til at starte med, så havde vi taget en kæmpe risiko ved at starte et projekt, der ikke havde en ordentlig forretningsmodel. Betød det så vi havde gang i et helt forkert projekt? Nej, for projektet løste et problem og der var folk derude, der var klar til at betale for vores løsning. Vi havde fokuseret på at udvikle den tekninske løsning på problemet og vi havde en vision mange kunne se et perspektiv i, så grundlaget var på plads. Vi skulle dog finde en kundegruppe, der ville betale fra dag 1 og selv om vi havde et forlag, der kunne se ideen så var det ikke tilstrækkeligt. Vi kunne ikke engang drive virksomheden på det, den eneste løsning på problemstillingen var, at finde en skalerbar forretningsmodel Smith, Preston G. Flexible product development: building agility for changing markets. Side 29 af 61!

30 Det vi havde brug for, var ikke en produktudviklingsmodel. Det vi skulle bruge var en virksomhedsudviklingsmodel, hvor vi kan tage et startup og transformere det til en lille virksomhed. I den tidligere nævnte video nævner Steve Blank Business Model Canvas. 28 En model jeg var blevet gjort opmærksom på nogle måneder tidligere, men i min omgangskreds sker den slags ofte, så jeg havde ikke taget mig særligt af det. Business Model Canvas består i alt sin enkelthed af 9 simple bokse, som vist herunder: Figure Business Model Canvas Kilde: Osterwalder, Alexander & Pigneur, Yves. Business Model Generation. En model der i alt sin enkelthed splitter en forretningsmodel op i de elementer, der skal falde på plads for at omdanne et startup til en virksomhed. Indtil nu havde vi ladet os forblinde af særligt et element, nemlig den der betegnes som Key Activitis. Vi havde fokuseret på at udvikle et produkt basseret på nogle positive kunde udmeldinger. Isoleret set var det vi havde lavet ind til nu fint, vi havde et produkt, der var relativt kundeorienteret og vi havde brugere, der kunne se værdien. Men vi havde glemt alle de andre elementer, 28 cast.li/ov Side 30 af 61!

31 der også skulle på plads for at produktet vil blive en succes. Ikke fordi vi ikke viste det skulle være der, men fordi vi havde arbejdet omkring en model, der var designet til at skabe et produkt, hvor det vi virkeligt skulle lave var en virksomhed. Produkt udviklingsdelen var bare en vigtig, men stadig lille del af en meget større opgave. Selv om vi i starten havde været inde og berøre forretningsmodellen havde fokus mest af alt været at finde frem til interessenterne og se om der var potentiale i projektet. To ting der helt sikker var, hvis man var en stor virksomhed der havde råd til at investere i projektet, men som det så ud nu ville det blive rassende dyrt at nå frem til et punkt, hvor vi havde en gangbar forretning. Selv om vi på daværende tidspunkt havde en utrolig lav burn rate, så ville det ikke være muligt at opretholde. Så vi startede med at se på den model vi havde. Ville det være mulig at skabe en indtjening tidligere i forløbet og opretholde den nuværende model på længere sigt? Vi begyndte derfor med at analysere den model vi havde benyttet indtil da til bunds. Generelt set havde vi godt styr på den værdibasserede højre side af canvased, men hvad der skulle til for at nå derhen? Venstre side haltede dog noget mere. Side 31 af 61!

32 Figure Business Model Canvas - cast.li Vi havde en model der gav brugerne en real værdi uden det kostede dem noget. Problemet var forsinkelsen i indtjening, det ville tage år før projektet ville nå break even, og vi havde ingen penge til at nå frem til dette punkt. Men vores value proposition over for både brugere og content providerne 29 gjorde at de fandt produktet interessant. Udfordringen var at skabe en model med en anden omkostnings- / indtjeningsstruktur og eftersom brugerne fandt produktet interessant, så kunne vi jo overveje at få brugerne til at betale for produktet. I den mest simple løsning, kunne brugerne købe sig adgang til hvad kunne betegnes som en online overstregnings touch, spørgsmålet var bare var det noget brugerne ville være klar til at betale for? Vi satte en simpel hypotese op, brugerne vil betale et lille beløb for produktet hver måned vi spurgte en række brugere, som tidligere havde prøvet vores produkt og viste dem vores anden generations prototype. Resultatet fra vores lille undersøgelse viste at nogle faggrupper kunne se nok potentiale til at betale for produktet, men langt fra alle. Derudover pegede mange på at de gerne ville havde det som et arbejdsredskab og at det måtte være op til deres arbejdsplads at betale. Andre kunne slet ikke se værdi nok for dem 29 De sider der blev markeret og delt fra. Side 32 af 61!