Produktprioriteringer, OKR og begrensninger i rammeverk med Ex-Googler, Kahoot, og nå Ardoq: Melissa Mills

Køhut Before that, she worked at a startup called Involve, and before that she was eight years at Google as a global product lead. Welcome, Melissa. Now you're making me sound old. Yeah, but you're definitely not old. No, no, no. And like I just said before we started, that you have this superhero name, Melissa Mills. Oh yes, that's because you said the alliteration, which I did not know until now. Yeah, and it's a really cool name. Så hvordan er tingene på Ardok de siste dager, Melissa? Tingene er gode. Ja, vi er i krukset av Q3-planeringen, så... It's always intense, but it's always really fun to think about what you're going to build next. So yeah, it's an exciting time. Yeah, and actually Erik, your CEO, has been on this podcast before. Oh, no way! Now I feel really cool. Yes, but you're sort of more of like an operator. You actually execute in the... hver dag med produktmanagerene på Ardok. Hva er direktorat for produktmanager? Hva gjør hun? Ja, sikkert. På Ardok coverer jeg produktteamene og designteamene. And I am making sure we get our stuff built. So I get a lot of feedback from the leadership and the executive suite. And they help infer and provide guidance in what we need to prioritize. And then I work with these teams in coaching and managing them to make sure we build really cool stuff for our customers. So Ardok is a B2B company. Yeah. But you used to work at Kahoot, which is a B2C company. Is there a difference there? In terms of product management? So... Typisk er den største forskjellen, eller den mest generelle forskjellen, mellom B2B og B2C, er at i B2B, beslutningsmakeren ikke nødvendigvis er ender. Så i B2B, personen som kjøper produkten, kan være CIO, men dagligvis kan det være enterprisearkitektene, i fallet for Ardok. I B2C, er direkte kjøpere kjøpere. Så i Kahoot, var det samme. Og så, som jeg sa, At Google, it was technically a B2B product. Our customers were these companies, but they were ultimately selling to either additional companies or to individuals. So when I was at Google, I worked on our apps products, and our customers were major app companies like Facebook and Lyft and Uber. And so we had to not only understand the B2B side of things, but also the B2C. Yeah, but is it different in terms of product management as a field, or is it sort of the same, but just different? Ja. Ardok har ikke 15 millioner brukere eller noe annet, for eksempel. Så da kan vi ha forskjellige feedback og guidninger. Vi kan ha kontrakter som er om å oppstå, eller vi kan ha nye kunder som vi prøver å klose, og da må vi finne ut hvordan vi kan gjøre at vår produkt fungerer for alle disse ulike kontraktene. Og da kan vi jobbe med kundersuksess-manager for å hjelpe oss i å samle denne feedbacken. Så det er mer en manual feedback-løp? Det er det. Data er der, men det er ikke på samme volym. Så du må bruke det Ja. Så, ironisk, når du arbeider B2C- You are actually receiving data which you can analyze. But when you're booking B2B, you actually need to be more of a people's person to understand what the person behind the title actually needs. Totally. You always need qualitative and quantitative feedback. But the idea is that with B2C, you're dealing with large volumes. And so if I do purely qualitative feedback, I might not get enough of a comprehensive view of the pool. Så det jeg skulle gjøre, er å begynne med data, se på volumen, og da bruke det til å innføre noen innsikter, og da validere de innsiktene med fokusgruppen, eller fokus-bidrag. Så gjør du alt det? Gjør en produktmanager alt? Like fra å samle data, og gjøre intervjuer, til å faktisk kreere et produkt? Ja. I would say no. Because we need a lot of help. I feel like our job is essentially to at the end of the day everyone's job at the company is to make sure we're building good products for our users. There's the Google mantra, focus on the user. That couldn't be more true. It's really critical that everyone, whether it's an engineer, whether it's a data person, whether it's the customer or even the product manager, has to be focused on the user. And Hvor produktmanageringsføringen finner seg i er at vårt jobb er å sikre at vi tilbyr god valg til våre kjøpere og å støtte utgiftene i prosessen og å skabe denne gode veien. Så hvis vi har noen departementer som kan støtte oss i denne prosessen, det er fantastisk. Hvis det er noen departementer som trenger mer hjelp, så ja, du må rulle opp dine høyder og finne ut hvordan du kan hjelpe. Vi må sikre at vi bygger gode løsninger, og alle er en del av den prosessen. Og hvis en enkel gruppe eller departement er i forhold til det, så må vi alle jobbe sammen for å sikre at vi kan jobbe sammen for å gjøre dette til å skje. Vi alle trenger hverandre. Så det er ingen måte at produktmanageren kan gjøre det hele, men vårt jobb er å sikre at vi fyller de gapene, og vi støtter hvor vi må til, for å sikre at denne veien er skrevet. Så er du også en advokat for brukeren? Ja, men alle i verksakene bør være advokater for brukeren. Hvis det ikke var for brukerne, så ville vi ikke være her. Denne verksaken ville ikke eksiste. Men mantraet, at man skal fokusere på brukeren. Ja. Så hvorfor må du si det? Er det ikke så vanlig? Ja, jeg vet det. Ja. Jeg håper det er ok. Hvordan skaper du en produktroadmap? Hva er en produktroadmap? Hvordan skaper du den? Hver eneste sammenheng har ulike måter å sette opp produktkjøp. Jeg elsker å følge en kvartalsmodell hvor vi bygger en kvartalskjøp hver kvartal. Vi planløper hver kvartal, så som jeg sa, vi er i midten av Q3-planen nå for å bestemme hva vi skal bygge. I en slags drømscenario hvor det ikke er interrupser, ingen eksternaliteter, scope all the opportunities proactively, build estimates, and then build a roadmap that then highlights the top solutions based off these problems you've assessed. So you suggest, for example, at the start of the year, these are the type of products we're going to create this year. Yeah, or like, again, user centricity. At the start of the year, you go, okay, this is our user journey. We see a ton of attrition at these different stages. There's clearly something that's problem for the user here, how can we solve that problem? So then we go, okay, these are the top three problems we have to address, and then product works in planning to think, okay, then these are the solutions we're going to build for these three problems. Is it like, do you work a year at a time? It depends. At Google, we could, because it was more of a waterfall approach. Literally, you could release, if you released even... Ja. Hvis jeg planlegger alt perfekt i en år, og ikke har skrevet noen mulighet til å forbedre denne rådmapen i en år, så vil det være veldig vanskelig for støtteholdene, ledelsen og eksekutivene. Hva om noe kommer fra investerere? Hva om det er noe stort enn en kompetent gjør? Det vil ikke være noe infleksibilitet der. Vi må sørge for at dette businesset kan overleve utenfor en år. Så forbedringen er veldig kritisk. Så du trenger en kortere, hva kaller du det, kadens? I would love to get to a point where we have so much predictability that I can anticipate what we're going to do a year from now. We're not there yet. At least I haven't found that dynamic yet. So you have quarterly... Quarterly is great because things take time to build. Engineering takes time to build things and to make sure it's executed and implemented properly. You can typically release a decent amount of stuff in a quarter. It gives you a great opportunity to do an assessment. This is a significant amount of work we've released. Did this add value? Did this improve the situation? What could we have done better? And then there's this whole concept of retrospectives that product managers use to evaluate. I love retrospectives. It gives you a chance to formelle revy og ha en ærlig samtale om hva som kan gjøres bedre. Og det hjelper å holde ting i sjekke, for å sikre at det du gjør er i riktig direksjon. Så, vil du like å appellere dette retrospektivet etter lanseringen av et produkt, eller vil du appellere det under ... under kvartet? Hvis vi ikke vil vise noen to måneder på noe som ikke kan fungere, har vi litteralt dette månedlige møtet for å sikre at vi kan holde oss høyere på det. I love that, because then I can adapt faster, and I can make adjustments faster, and I can create a good feedback loop with the day-to-day people I work with, that I can then align with the leadership on. So then if they are concerned, or maybe we have to squeeze something in the roadmap, I know what's feasible or not feasible, because I have this regular cadence with the day-to-day operations. So basically, for example, let's say at January, you have identified these three major problems, som for eksempel holder brukeren fra å bruke produktet. For eksempel. Ja. Eller de tre viktigste tingene du må utvikle for å gjøre produkten bedre for brukeren. Ja. Men du har bare ressurser til å gjøre en av disse. Ja. Så vi skal snart snakke om privatisering. Ja. Ok, så du velger en? Ja. Og hva gjør du da i denne kvartalen? Hva ser den første uken ut som? Og hva ser uken ut som i forhold til privatisering? opp til du lanserte produktet? Ja, for sikkert. Jeg prøver å gi et godt eksempel. For eksempel, i Ardok, vi... La meg forstå det. Som produktmanager må du ikke bare være involvert i utføringen, men også i planløsningen, som du snakker om, og bestemme hva du prioriterer og hva du bygger. Og ofte, hvis du investerer i å definere problemet, og virkelig forstå problemet, og da bygge en plan rundt det, kan det minimere overfløyelser. For utfordringen er at du aldri jobber med perfekt informasjon. Selv om vi planligner og forteller at det er perfekt, og vi vet hva vi gjør, så kommer det alltid ting. Kanskje det er noen større tekniske rådgrep som vi har utført i utføringen. Kanskje i designen vi forstår at vi har misset en veldig kritisk steg i designprosessen. Eller at en designkomponent er misset. Ting skjer. Så ... The more planning you have up front, the better, and it's a balance because we can't plan forever. So a great example is at RDOC, we have gotten a lot of user feedback around how our onboarding process can be challenging. And so it's about how can we improve that onboarding process. Takk for at du så på. Det handler om access-pattern. Det kan være at vi må ta noen beslutninger, som at traversalen ikke fungerer, så vi må gjøre noen forandringer, eller at vi forstår gjennom user-testning at traversalen vi prototyper kan ikke fungere. Vi må forstå disse forandringene. I kvartalene planlaterer vi for denne slik ting. Does that make sense? It makes sense, totally. Is that helpful? Is that a clear example? Yeah, yeah. We actually also talked about this before we started to record. All the shit happens. Totally. A great example is literally, I joined RDoC, and then the month I joined RDoC, OpenAI kind of came up. And what we realized is that Ja. Hvis vi tenker at dette er vårt rådgave i tre måneder, vi vil ikke endre noe, så gjør det oss en beskyttelse for våre brukere. Da ChatGDP kom ut og åpnet opp denne utrolig kraftige oppfølgelsen med store språkmålmodeller, så forstod vi at vi hadde å leverere denne informasjonen. Vi hadde å bruke disse utrolig kraftige ressursene til å bygge bedre løsninger. Så vi gjorde en hackathon, og vårt teknisk team kom med noen veldig utrolig ideer. And we're able to put them out in the market and able to get demos out in a short period of time for our customers. If we had stuck to our roadmap, then our customers would have waited even longer to get these great resources. And that's not fair to them. So we have to be able to adapt to that. Yeah, so how do you find ideas? How do you... Find the solutions, so you have the problems. You mentioned hackathon. Yeah, so I feel like that's the million dollar question for product management. It's tough, there's no perfect answer for that. Like, you know, when you're learning product management, you might take a product management course, you might go, okay, here's this shape-up framework, here's the reforgement framework, here's all these different models, this is what I'm going to implement. But in reality, at the end of the day, Ja. Men la oss si at det var en perfekt utopi. Perfekt utopi, ok. Ja, og du prøver å finne en løsning til et problem. Hva er de forskjellige strategiene til å gjøre det? Jeg tror at det første steget er å sørge for at du har en veldig klar definisjon av problemet. When you're getting customer feedback, customers have a tendency to say what they want in the form of solutions. You know, oh, this feature isn't working. I want this the way company X has this. And so you're already getting imperfect feedback. And as a product manager, it's so easy and so tempting to just be like, oh, well, we just need to build, you know, we just need to build X for this. This will solve this. And the idea then is you're not really building for a problem. You're building for a solution. And so as you start to build, you don't have that clarity and focus on what the problem is. Do you think that's a big problem? 100%. 100%. No, I mean like in real, like, do you think a lot of companies are actually doing this? Yeah, absolutely. Because it's so tempting. Like, it's... Hvorfor er det så dårlig? Vi alle vil gjøre det rette. Vi alle vil bygge gode løsninger for våre brukere. Vi alle vil implementere ting snabbt og effektivt. Så noen ganger er det veldig lett å si, åh, selvfølgelig, liksom, «Dette kjøpene har spørsmål A, selvfølgelig må vi bygge spørsmål B. La oss bare bygge spørsmål B.» «Ja, la oss bare avslutte sprinten. Vi har løsningen. Kjøpene har fortalt oss løsningen.» «Men da er utfordringen med det at når du bygger, har du ikke en god definisjon av hva du prøver å løse. Og da har du ikke en god måte å messe om du løser det eller ikke. Så da har du dette som heter skåp-kripp. Hva det betyr er at når du bygger... Så dette problemet blir en stor monster? Ja, og så bygger du for alltid. Og så Again, typical thing. I think everyone goes through this. Like, I've been through this. Every product managers have made this mistake at some point, and to be honest, we all make this mistake, because it's so easy to solution so early. So, this is where you really have to stop yourself and check yourself, and really focus on the problem. So, this is where defining the user problem, focusing on user stories is so critical. What is a user story? A user story is when you describe the situation as a user. So, for example, I would say, um... Hva er et godt forbehold? Ta et forbehold fra Kahoot. En user story fra Kahoot. Ok, så som en partikant, når jeg prøver å logge inn i spillet, har jeg en svær tid til å tilføye spillet. Hva er en pin? Ideen er at det er en simpel ansvar. Å, du prøver å finne pinen. La meg bare putte dette opp i fronten. Men når du putter det i en user story, realiserer du at Det tar produktmanageren ikke i fokus på at jeg trenger en løsning, jeg trenger å få jobben gjort, jeg trenger å jobbe. Det tar dem i perspektivet av brukeren, så du kan bedre identifisere brukerproblemene. Igjen, det mantra, fokus på brukeren. Det hjelper deg å tenke som en bruker. Og så går du gjennom denne brukerjourneyen, så kan du bedre forstå ruten av problemene. Så i stedet for å løse for feedback, prøver du å løse mot en rute. Så jeg prøver å tenke på ... Så det er en beskrivelse av problemet fra brukernes perspektiv? Korrekt. Og alle må tenke på det på denne måten. For det er ikke sånn vi tenker på daglig. Når du runner ditt eget eget sted, tenker du ikke om alle operasjonene du må forhandle med, alle møtene du må ha i dag, hvilke spørsmål du får, eller hvilken feedback du må få til å stegne din beskrivelsebasis. Ideen er at når du forandrer mantraet, og tenker på det som bruker, så forandrer det mindsetet. Vi er ikke programmet til å tenke sånn på en daglig basis. Så jo mer vi tenker sånn, jo mer vi kan forbedre det. Og å gå tilbake til min poeng om hvordan alle trenger denne ekstreme kjøpelsen. Vi alle trenger å tenke sånn. Ingeniøringen bør tenke på brukere i brukerstorien. Salesbygd bør tenke på brukere i brukerstorien. Når jeg arbeider med våre salesteamer og våre kommersielle teamer på Ardok, jeg har alltid spurt dem om hvordan de er i brukerstorien. Har du vært i en kompani, du trenger ikke å nevne navnet, men har du vært i en kompani hvor ikke alle tenker på brukere? Hvorfor er gravitasjonen avgjort fra kjøpene? I've never met a person who hasn't had to work late one day. That happens to everyone. You have a lot of stuff, and then on top of that, like me, I have to go home to my kids after this. So the problem with companies are humans. Yeah, exactly. And again, we're all human. Human error is a thing. We are 100% prone to human error. I'm I'm not a perfect product manager. I make a ton of mistakes, but I hope that I have teams that are also helping me catch my mistakes and warning me about it so that we're supporting each other. Okay, sorry, I deflected there. I took a detour there. No, you can take a little one. But you were user stories. You have to explain the problem in the user story. And don't take the user's suggestion to a solution as a Totally, and again, like I said, we're prone to human error, we're prone to mistakes, and we're even prone to solution earlier. Everyone wants to be adding value, everyone wants to come up with good ideas. How do you know we have the right solution? When do you have the right solution? That's a great question. Sometimes you don't. That's why you have to do user testing, and you have to do validation. So you have a user story, and that one, okay, so let's say you have a user story. How do you know this is a good user story? Så typisk, som jeg sa, selv før du går til user story, har du problemdefinisjonen. Hva er problemet vi prøver å løse? User kan ikke komme ut av onboarding-fløyet, som et eksempel. Og så er ideen, hva betyr det? Og så er det der du bremmer det opp i user stories. Og du snakker om alle de ulike typerne av user. Noen ganger som en partikant, som en admin som logger inn som en host. For eksempel Facebook, tenker du det som en markedsplass, som en user. I Google tenker vi det som anvendere, som end-usere, som individuer på search. Så du tenker på alle de ulike user-storiene. Hvem som kan interagere med dette problemet, du skriver ned alle disse user-storiene. La meg forstå litt. Hvordan vet du når noe er et problem? That goes back to the performance. So for example, and that's where the data, that goes back to the data and qualitative conversations. So when I'm trying to decide what to build, I want to make sure that my users are actually taking a step back even further. There's this thing called a happy path. Det er brukt i utviklingen. Du må sikre at det du bygger, den viktigste veien for brukeren, er alltid operasjonelig og alltid fungerende. Vi kaller det den glade veien. Den må eksiste. Den må alltid være operasjonelig. Den glade veien er egentlig veien til brukeren til å komme til den veldig kritiske momenten som gir valg til dem. Noen ganger kaller jeg det aha-momenten. Når du bruker et produkt og du sier, ah, dette er hvorfor det var valuert. Det er egentlig hva valget av produktet er. Når du skaper den aha-momenten, vil du you want to track that path to get you there. And then, if you're seeing a ton of attrition through that path, that means less and less users are getting to that really powerful moment. What does attrition mean? It means that as users, as you're losing users on that path. So for example, like if... You're an application and you're trying to sell stuff. I'll use Kahoot, it's a great example. We know the most powerful part of the product is when a teacher hosts a game. So we call it a host. You want to be able to get them to host a game in their classroom. Because when they launch the game and they host it in the classroom and the kids are playing, you see the energy. You see the value of the product. It's that moment you see why people want to use this product every day. Så hva er veien til å få til å hoste en game? De må logge inn, de må skrive en akkount, de må signere opp, de må finne en kahut, de må velge å spille den kahuten, eller kanskje de skriver en kahut selv, det er spesifikt for deres lekture. Så dette er den mest kvalifiserte veien? Korrekt. Det er som om produktmarkedet er en vei til å finne en vei til å finne en vei til å finne en vei til å finne en vei til å finne en vei til å finne en vei til å finne en vei til å finne en vei til å finne en vei til å finne en vei til å finne en vei til å finne en vei til å finne en vei til å finne en vei til å finne en vei til å finne en vei til å finne en vei til å finne en vei til å finne en vei til å finne en vei til å finne en vei til å finne en vei til å finne en vei til å finne en vei til å finne en vei til å finne en vei til å finne en vei til å finne en vei til å finne en vei til å finne en vei til å finne en vei til å finne en vei til å finne en vei til å finne en vei til å finne en vei til å finne en vei til å finne en vei til å finne en vei til å finne en vei til å finne en vei til å finne en vei til å finne en vei til å finne en vei til å finne en vei til å finne en vei til å finne en vei til å finne en vei til å finne en vei til å En ting vi fant ut da vi jobbet på Kahoot, var at vi fant ut i noen steder i spillet at hvis vi gav bort noen av disse steder, så så vi en større sannhet at en lærer skulle hoste. Men hvordan vet du at det er et problem? For noen mennesker gjør det, ikke sant? Hvordan vet du om det er et problem? Så, noen ganger kan du gjøre det bare gjennom data. "Åh, se på disse drop-off-ratene, de er ganske høye." Og igjen, hvordan vet du om det er et høyt drop-off-rat? Benchmarks, generelle data, men du kan også valide det gjennom kjøpmedbillig. igjen, dette er der du trenger kvalitativ og kvantitativ feedback. Ja. I don't know where to find the games. Is there like a benchmark in terms of drop-off? Shouldn't it be like... Is there a universal benchmark? At least 10% should move on to the next step. Yeah, I think there's no such thing as 100%. Like 100% users continue on to the next step. I've never seen that in my life. I think the benchmarks are quite... Det er ikke noe universalt kunnskap, i min mening. Det er kanskje noen artikler på internett som sier at det er noe, og at dette er det som bør være, men jeg har ikke forstått det enda. Jeg mener at hvis ingen bruker ditt produkt, er det en god indikasjon at det er et problem. Det er det. Da vil jeg forstå at du ikke har en produktmarked som fitter. Det er en annen utfordring. La oss si at 100 mennesker begynner å reise, og da 10... finner det. Jeg vet ikke om det er et problem eller ikke. Men det er der du kan spørre for user-fidback. Så ut av de 90, hvorfor stoppet du? Og hvis du hører den samme temaen hver gang, så har du en klar dropp. Det er klart et problem. Ok, så dette er en god prosess. Du ser noe som du tror er et problem, så du må valide det, ikke sant? Tror customer-fidback. For du vet ikke om det er et problem. Ok. Men igjen, du har ikke alltid mye data med en B2B-kompani som vi snakket om. Så da kan du få mye kjøpmedbøy, og da kan du se en samme tema, og da kan du si, jeg vil dyve inn i dette. Jeg vil doubleklikke på dette. Og da vil jeg se noen av dataene i systemet, se på performansene, og se hva alle mine andre kjøpmedbøyere gjør. Og da kan jeg se om det er en kontinuerlig behandling. Så det er om å lege på både. Og så er det ideen... Det neste problemet å løse er... Det er klart det er et problem her. Hva skjer egentlig? Og der kommer user-historiene inn. Og der vil du tenke på... as many user stories as possible that really reflect that problem. What if you're coming in as a decision maker like a CIO? What if you're coming in as an enterprise architect? Or in Kahoot's instance, that's for Ardok, in Kahoot's instance it's like what if I'm coming in as a teacher? What if I'm coming in as a student? What if I'm coming in as a personal user for fun? And then you think about all those user stories and then based off of that you would work with Ok, så problemet er høy drop-off på stedet. The user story is an explanation of that problem in terms of the user. Yeah, it's like the why. Like as a user, this is what I go through. And then you go, oh, that explains why this is a problem. Okay, and then when you have the user story, then let's say you nail the user story. Let's say you put it into a machine, and the machine says, yes, it's the right user story. How do you now create the solution? Yep, so then as a user story, you have a very clear definition, so then you can put key performance indicators, like metrics against it. So, okay, Jeg forstår at brukere ikke kan hoste spillet fordi vi skaper de ekstra stegene. La oss sette et mål for å finne ut en løsning som kan redusere stegene til å lansere spillet med én eller to klikk. Nå har du en veldig klar skjerm, en klar objektiv og god kontekst bak disse objektivene. Nå kan teamet jobbe på å finne ut hvordan man kan løse det. Og hvilken løsning vi bygger, kan vi teste, vi kan bruke userintervjuer, vi kan løse den på en AB-test, du kan løse den bak en featureflagg, og du har en veldig klar måte å messe om det vil addere valg eller ikke. Fordi du putter sammen suksesskriterier. Så du vet ikke om løsningen kommer til å fungere? Nei. Jeg vil lov til å tenke at alle løsninger jeg har bygget har vært perfekte, men nei. Du vet aldri hvordan brukere vil reagere. Du er ikke enda bruker i slutten av dagen. Du prøver å være dem, men du er ultimativt ikke dem. Ok, så resultatene på KPI-ene vil si om det fungerer eller ikke. Korrekt. Og hvis det ikke fungerer, må du gå tilbake til skjermen og gjøre nyheter. Ja, men det er så viktig, for det er en veldig god innsikt. Helt punktet er at vi bare prøver å gjøre oss selv... service to our users. And if we were wrong, at least we know we're wrong, and then we can improve upon that. That's also really helpful. Is that mentality prevalent in terms of does product managers think like that? Because a lot of leaders don't think like that. Because they think, oh, it was a big mistake. I'm not going to get promoted. Maybe. Maybe. Jeg tror dette er der, igjen, å gå tilbake til rådmapper og planlegging. Hvis jeg var å bygge en rådmapp for en hel år, og jeg var å runne denne hele prosessen over en år, det er en hel del press. Hvis det feilte, det er en hel år av jobbloss. Jeg ville føle meg krap om det hadde skjedd. Så dette er hvor, ved å skopere det kvartalig, og da prøve å gjøre jobb på en månedlig basis, så er det mindre av en impakt. Å nei, vi har løst en måned. Det er vanskelig, men vi har hatt større problemer. Så det gjør at det er ok å feile, hvis det er særlig små, og progresjonalt, eller inkrementalt. Og det betyr også at det er greit med det, at du får løsninger til dine brukere tidligere. Så vi snakker mye om å løse ting i milestones. Jeg kan løse en del av en løsning, eller en del av en løsning, Do you release the solution to everybody, or just to a small fraction of your users? Totally depends. It depends on the solution. Sometimes you have to release, like... Like at Kahoot, we had some issues, like when two-step authentication came out, we had to release that to all of our users. That was necessary. That was a EU requirement that came down, so that had to be sent out to everyone. But if you're doing something like part of the user journey and part of the user flow that doesn't have critical requirements like that, there's definitely no harm in releasing it behind either a feature flag or an A-B test, or even just testing with a couple of users before launching to mitigate that impact of launching to everyone. Yeah. Det tar mindre press på det, så hvis ideen er god eller dårlig, er det ingen stor del. Jeg tror ikke vi har lagt ut delen av å lage ideer. Du har user-storien. Hvordan skaper du ideer? Obviously you could use chatGDP. It's definitely a helpful assistant. And assuming what you're asking, chatGDP is compliant within the company policies. Yeah, so I think Så det støtter inn i planløsningen og kreativt prosess, og i utdannelsesstasjonen. Noen ting er ganske vanlige til skåp. La meg forstå det. Ingenting er vanlig. Men når det er veldig definerbare problemer, så kan veien til løsningen være mer klar. Men noen ganger er det ikke så klar. Så en god eksempel er... Ja. Alternativt er det en annen måte å gjøre dette. Det er en god konsept som heter The Sprint. Det er av Jason Knapp. Det begynte med Google Ventures. Han har faktisk vært på denne podcasten før. Er du seriøs? Ja. Wow. Jake Knapp. Ja, Jake Knapp. Jeg er bekymret for min pronostikker. Wow, det er... That's really... So you're standing on the... I feel like a million bucks right now hearing that. No, but it's really... That also is a very user-centricity model. So it allows you to just be really creative. And what's nice about those types of exercises, you literally stop your day-to-day work just to kind of pretend to be a user and think like a user. That takes a week. It does. We've done modified versions. So what we do is... Vi vet allerede noen av de problemer vi må løfte. Og vi har allerede noen klare behov i stedet. Og noen ganger har vi de rene rene. Og så har vi noen av dem pre-vettet først. Og det holder det ikke til en hel uke. Men jeg vil argumentere at en uke også er utrolig. Jeg vil lov til å komme til et sted hvor vi kan gjøre det for full uke. Og se fullt valg av det. Ja, for det tar mange ressurser fra organisasjonen også. Det er det. Det er veldig køy. Så igjen, å gå til dette punktet om inkrementasjon. Det er definitivt... Det er sikkert inkrementalt, men det er fortsatt mye å spørre om. Hvor har du funnet den beste løsningen, fra din erfaring? Å, det er en god spørsmål. Du vet, for å generalisere, når jeg er på løsningsstasen, er de beste løsningene jeg har kommet opp med, når du har alle i rommet. Jeg har egentlig vært der hvor vi har hatt denne ingeniøren, designeren, meg, og vi har også hatt denne selskapere i kallet, eller i rommet, som har bestemt det. Fordi når du har denne diversiteten av ideer, Så en workshop med alle... Hei, er du en CEO eller CTO i et vekstselskap og trenger flere utviklere? Da vet du at det er ganske krevende å finne dyktige utviklere i Norge. Men håpet er heldigvis ikke ute. Cefalo er et norsk outsourcing-selskap som har klart å bli en av de aller beste arbeidsgiverne for seniorutviklere i Bangladesh. Cefalos spesialitet er å rekruttere og bygge langsiktig utviklingsteam sammen med den norske kunden. Og det å ha faste utviklere gjennom Cefalo skal i praksis oppleves som å ha egen ansatte. Så er du interessert i å høre mer om å ha eksterne utviklere, så vil Cefalo gjerne ta en veldig hyggelig prat med deg. Så sjekk ut cefalo.no, altså C-E-F-A-L-O.no. Again, we should have done more user stories, but I had already a solution in mind of what we should probably do. But what I found was the discussion, and the engineers came up with a really, really great solution. And it was a really clean and effective solution. It was way better than what I had thought of. Like, there's no way we wouldn't have come up with that together. But what was great is also, because I was in the room with them, I could help in teeing that up as well. Like, as they were vetting and scoping it, I was setting expectations with stakeholders, so that we were able to kind of Teksting av Nicolai Winther our product doesn't... So essentially the challenge we had was they wanted to use it for a trivia contest asynchronously for up to 10,000 employees. And our product had a cap of 2,000 instances per game. So we needed to figure out how to make this product scale for this instance. And... Historisk har det alltid vært en tro at det er svært å skjelde over 2000 brukere i en game. Det er svært, det er ikke mulig å gjøre. Så jeg forstod at det ikke var en mulighet. Men da vi kom inn i rommet, hadde vi en klart skjelse av behov. Dette er de kritiske behovene av brukeren. Dette er også typiske behov for B2B-kustomer som prøver å bruke produkten på denne måten. Og vi var i rommet, og en av de forskjellige var at vi skulle bare gjøre dette. Og originalt var det noen diskusjoner og resistanse, men gjennom konversasjonen og diskusjonen og utfordringen, så utførte vi at det var kanskje den beste løsningen. Så hva er løsningen til å bare tilføye 0 til totalet? Det var en veldig teknisk løsning. Og hva var ditt løsning? I'm too embarrassed to say. I had some idea of kind of breaking up the product into different groups, but I think that would have created more headache and noise. It would have created more complexity, 100%. But this is also why I'm really glad we were all in the room together to figure that out, because this is ultimately what's going to be best for our users. Yeah, so he actually proposed a solution to -for å gjøre en forandring i OS? Solutionen han kom med var å forbedre forandringer i tekstakken. Så utfordringen var hvordan vi kunne gjøre dette uten å reshape tekstakken- -siden vi hadde tidligere forstyrrelser. Vi vil aldri gjøre noe i en år. Dette er en solusjon som du sikkert aldri... I don't know the tech stack as well. Not at all. We had multiple engineers in the room, and they were able to check each other, and we didn't come up with the agreement to that solution in that conversation, but rather the next step was to investigate it. Because again, we're a team. At the end of the day, we want to do best by our users. We all need to be looking out for each other. So then it was about, how can we divvy up the work to investigate if this is truly possible? The stress tests, the the technical scope, how can we make sure we're challenging each other so that our tech stack can still be operational, and that the rest of our users aren't hurt by this. So let's say you're a 10-person startup. Yeah. Should everyone be involved if it's a problem in the happy path? I think when you're a 10-person startup, you're wearing so many different hats. I can't imagine there being somebody... who shouldn't be part of that. Like there's always exceptions, like maybe you have somebody who's an expert at this one particular thing, and that's their area, and they can deliver a ton of work, so maybe that may not make sense. But it's really about playing to the strengths of the team, and figuring out how you can solve that. So your answer is yes? I think so, but again, there's always edge cases, like classic product management, I'm like, nope, never, you gotta be adaptable to every instance. Yeah, you have a gravitation towards edge cases. Or at least acknowledging that edge cases are... I'll say that, yeah, people are people at the end of the day. And each person has different strengths and weaknesses. And I want to create an environment in which we're going to build the best outcome for our users. And most likely having everyone in the room is there. But if somebody wants to focus on a different aspect of the job, and that's their area of strength, and it doesn't necessarily apply, then we can divide and conquer as well. So it's just about finding that balance. Ja. Det er alltid en risiko med alt vi bygger, og det er alltid en mulighet for at vi må ha til å forandre tiden for noe annet. Så, i alle fall, det jeg gjorde var at jeg skjønte dette med stakholdere. Jeg har også skjønt noen av de andre optsjonene vi tenkte på, og hvorfor vi ikke var så motivert av dem, eller hvorfor vi synes at de ikke er så sterke optsjoner. and then kind of present it to them. Okay, so you present alternatives. 100%. Not just one solution. Well, yeah, totally. Because even though this might have been the best technical solution, the stakeholders might have more knowledge to something I'm not privy to. Like maybe there's another customer coming down the pipe that's also going to have a similar request and needs some other aspect or requirement. Like maybe the investors have a different direction based off of competitors in the space. Like I'm not quite sure. So the whole point is I'm trying to transfer the knowledge Teksting av Nicolai Winther her er det slags ting vi forstår, og det er derfor vi er mest nødvendige med denne. Så bestemmer de stakholdere dem? Ja, i noen måter. Jeg tror det er alt om å bringe tilgjengelighet. Vi prøver å gjøre det bedst av våre brukere, og vi vil bygge en kompani som skaler. Så det kan være ting som, som jeg sa, jeg er ikke nødvendig med. Så det er om å ta dem inn i konversasjonen. Men skal de ikke komme inn litt tidligere? Skal de ikke være i rommet? I møtet du snakket om, hvor alle var present? Nei. Potensielt, på en 10-person-startup, kan CEO-en være i huden og i det graden av detalj. Hvis du tenker på at det er en horizontal og en vertikal aksis, så er det en bredd og en dypt til kjærlighet. Når vi går inn i detaljene, så må ledelsen ikke ha å vite om det. about rate limits. But they may want to know the general access of what you're trying to get. So the depth of knowledge and the depth of detail may not be as necessary. So they could be in the room, but most of that conversation might not be effective for them. Of course, it depends on... You wouldn't have Larry Page in the room. No, no. It also just depends on the issue, too. Maybe this is a really critical issue. This accounts for 80% of our customers. Then they should be in the room. It really depends. And that's... Jeg hater å si det, men det er ultimativt det. Produktmanageringsmålet er ikke... Det er ikke en perfekt sauce til dette. Når du presenterer løsningene til stegholdere, De burde nok ha vært involvert i å definere problemet. 100%. Så de var en del av det, for sikkert. Som jeg sa i dette eksempelet, noe av det var predefint. Det kom ned. Dette dealet ble satt. Her er noen kjede behov. Dette er noen ting de er interessert i. Så stekholdere er en krucial del av å definere problemet. 100% Ja, for hvis de ikke er du kan ikke bare vokse opp med noen løsninger til en problem de ikke er til å forstå. 100% Og igjen, jeg snakker om et spesifikt eksempel her hvor noe ble predefint du kan ha det på en mer standardisert basis. Så på RDoC følger vi OKRs Objektiv og kjøpresultat og jeg elsker denne modellen fordi det clearly defines to me what leadership is trying to solve. Can you explain this model? Totally. In 20 words. Try my best. Chat give it to you. You should ask her, not me. So essentially, objectives and key results, the idea is it provides... utslipp og regler til hvordan du evaluerer en kompani. Og når du har disse utslippene og reglene definert på ulike nivåer i en kompani, kan det hjelpe å sikre at du på en daglig basis prioriterer det rette. Så et objektiv er noe du prøver å løse. Vi vil drive mer engasjement i plattformen. Og så vil kjøpresultatene bli større og større. x part of the platform usage by 10%. Decreasing the amount of support tickets by x. So the key results are, what are the numbers that will indicate that we are achieving the objective? Correct, and they're measurable, which is really critical. So that helps you definitively know whether or not you're hitting it. And again, if you're not hitting it, that's still extremely insightful. So the idea is that At Ardok, we follow the objectives and key results. Leadership sets those at the top every quarter. And then I'm aware of some of the planning, and then in product we also set our own targets. And we have to make sure those align up to the company objectives. If we're not tied up to the company objectives, then what are we doing? So the leadership sets the objectives and the key results. Yes. So let's say they hand it to you, and what do you do with it? So then, oftentimes the objectives are tied to really critical needs of the business. And so then it can help me in informing product and what we can do to make sure we're defining that. Yeah. Så er du, er du like, er du taking care of one of the key results, for example? I've set my own objective that has key results that are measured against that, but that objective should align to the company objective. It should align to the key results of the company as well. I actually don't have a specific key result that I'm tied to, but this is also where Vi har denne kontinuerlige feedback-lupen. Så hvis de ikke hitter de kjørende resultatene, så kan vi alltid evaluere og finne ut hva produktet kan gjøre for å gjøre det bedre. Så du har dine egen objektiv? Korrekt. Så du har objektivene av de menneskene, og da har du de kjørende resultatene. Og da har du objektivene der? Så det vi har er at vi har produktteam, vi har produktmålene, og vi har krossfunksjonale teamer. Ja. And so we do this in planning. And so right now we did a big review last week, and now we're kind of evaluating now, okay, based off this company objective, and what we're trying to focus on in the product, how can we align these teams? So right now what we're focused on, like I said, is, let me rephrase that, it's a balance because Vi prøver å skaffe fleksibilitet slik at vi kan løpe problemet til det beste vi kan, som alignerer seg til forholdene til en kompani. Men vi prøver også å gjøre det ikke så bredt og ambiguelt hvor vi prøver å gjøre alt. Nå er fokus på produktet rundt et par steder i userjourneyen vi vil gjøre bra. Og vi vil at hver team i noen måte, form eller form, ligner seg til de korte, kritiske stedene. And that's the focus. Because again, we also only have a quarter. Like, we can't fix the entire product in one quarter. So to that spirit of incrementality, we're taking these two steps of the user journey, focus on those, and then at the end of the quarter, we'll decide whether or not we're able to move the needle or not in those two steps. So this question is pretty, it's what you call it, it's It's a leading question. Yeah. So, what benefits are there to having a C-suite that are organized and have good OKRs? Yeah, so around this product planning like we talked about and building the roadmap, Eller la meg forstå det. Gjør det det lettere for deg? Ja, exakt. Så... Product management, du er i midten. Du prøver å sikre at alle dagliggjørende mennesker, som ingeniører, PM'ere, designere, alle spiller til sine strengter, og de opererer bra. Du prøver også å alignere med stakholdere og lederskap, fordi du vil sikre at du driver valget for lederskapet. Og... Ideally you have some predictability around that. Okay, I've built my roadmap for three months. Here's what I'm going to build. I'm excited to see this through. I have never been in a company where there hasn't been some externality that has shaped the roadmap in the quarter. It happens. A customer could be at risk. There's this whole market shift in AI. There's always something that could happen. Do you wait to the next quarter or do you act immediately? Well, it depends, but Det er en balanse. Hvis det er en mulighet til å gjøre service til våre kunder, så bør vi gjøre det. Men hvis det vil skje en stor del støt og slå ned produktiviteten av teamene, så er det også en risiko. Det er ingen klare ansvar her. Det er ingen klare ansvar, men dette er også vår t-punkt med lederskap. Du kan enten ha normen som reaktiv lyd, og hvis lederskapen ikke er sammenlignet og koordinert på det, så kan det bare være en del reaktiv ting som går ned, hvilket kan gjøre det veldig vanskelig å planle en rådmap. Men hvis de er organisert, og de planligner, og de har struktur rundt hva de gjør, så kan det gi struktur, det kan trikle ned og gjøre struktur for resten av teamene. La meg høre, hvilken lederskapteam er mer organisert, Harderk eller Kahoot? I don't think there's a direct answer because they're just such different companies and they're trying to solve different things. Again, Kahoot's in a unique position where they're trying to target B2C automated users and automated revenue, but then they also have a B2B business. And they've also done all these acquisitions. Like when I was there, we acquired Clever, which was, they have something like I think like 60 or between some, they have more than half of the entire school districts tied to their product in the United States. So that was a huge shift in making sure our sign-on flows worked with clever sign-on flows as an example. Did you use OKRs in the community as well? Vi brukte dem på Google, jeg forstår. Det er ikke inventert på Google, men det er et stort eksempel på... Det er John Doerr som skrev boken? Ja, «Measuring What Matters». Jeg har egentlig ikke enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda enda end one, it's something I'm familiar with, but two, it creates more structure and autonomy where I'm still accountable to the leadership. I'm still accountable to the stakeholders. They've given me this directive that this is their way of measuring the company. So whatever I do this quarter has to direct to that. Whatever the teams do has to direct towards that. If we're not directing towards that, then we're not achieving our goal. But I have autonomy to figure out how to solve that. So then I can go, okay, my area of strength is I know product and I know our users, and I'm focusing on our user journey. Where is it breaking? How can I make an impact on our user journey that's going to get us the biggest bang for our buck on this outcome? And again, like I said, there's noise. So when you've really invested in the OKR process, it can work really, really well and create predictability. But even then, like I said, noise happens. Things happen. And everyone... Jeg tror at når du går inn i denne forventningen med det i mindre... Eller hvis du går inn med denne slags forventning... You can adapt and you can adjust easier. What happens when you have to pivot the product? Pivoting is hard. What is pivoting? Pivoting is essentially when you change direction. When you're focusing on something else and you're changing to a different direction. Sometimes it can be small. You realize our solution doesn't align to the product. to the original problem we're trying to solve based off this user feedback. We need to pivot to our solution. Kind of like when I gave that example with Kahoot, when the idea I had was actually not the strongest idea, we pivoted. But in some cases, you might even have to pivot within a company. And when you're in a relatively younger company, there's a greater likelihood of pivoting, because product market fit is just so difficult to achieve. Yeah, so pivoting is more of a strategical move, right? Correct. It's a bigger move. Like, okay, we... Ja, ja, ja. Du vil sikre deg at ditt mål er å prøve å drive valg til dine brukere, og noen ganger... You might have to completely rethink that strategy. Because you were at the start where you didn't have product market fit. Correct. So I joined really early. It was either pre-seed or just around series A. I was really drawn to it. They were trying to drive user engagement, employee engagement. So what did this startup do? So originally they were trying to drive employee engagement by trying to bring in partnerships with non-profits locally to try and create... Ja. I was really motivated to try and do something professionally that was also for good. But ultimately they didn't have product market fit. So how didn't they have product market fit? Some signals for example it was hard to it was really difficult to sell and it was hard to get customers in the door. And then when we did get customers in the door the feedback requests were these huge lists and they weren't consistent and they all had different things. And Så det puttet oss i en posisjon hvor det var veldig vanskelig å skjelde. Og når jeg ser på det, så var det bare store indikatorer at vi ikke virkelig hadde en naturlig flow og path av userbehav. Og så forstod vi at vi hadde å forstå hva vi prøvde å løse. Og så for å gå gjennom denne prosessen, meg og founderne, vi intervjuet 300 potensielle kustomer eller aktuelle kustomer for å virkelig vette hvilke problemer de var i forhold til. Ja. Så du må forklare det, for det de gjorde var at de var tilbakegjørende med forholdsorganisasjoner til å drive opp jobben. Ja, men igjen, den kritiske faktoren der var at vi ville drive opp jobben. Så vi trakte mye på hva jobberne gjorde og hvordan jobberne var tilgjengelige i en forhold. Så det er denne parten som er kjærlighet? Ja. One of the solutions, potential solutions. Correct. So you went back to the original... The employee engagement piece. How do we drive this behavior? And then we realized that there was a disconnect between the employee level and the leadership level. And One example that we saw was sometimes the disconnect between the sales activity and what the end stakeholders wanted. And this was at a time when we were actually also looking into AI. I had done the whole machine learning course with Andrew Ng, one of the founders who had an AI thesis basis, and we thought this is an opportunity where we could potentially build an NLP model to try and help and create more informed decisions or solutions that could create more informed outcomes. Så hva er et eksempel? Så vi utførte en klassifikasjermål ut av det, for å identifisere samme trenger og performanceaktivitet fra salg, for å undersøke understand and build trends around that. So like, here's the key insights we see from top performers. And we found that performed really well. And that it had a stickiness factor where the customers were very invested in it and they were continuously eager to see more. And I think that's what they've built their entire company off of moving forward. Like if you check out their website, it's all about just trying to understand customer centricity, like customer retention. And, creating that engagement using AI, which is super cool. That's pretty different from charity. 100%. But again, it's about doing right by our users and doing right for these companies. We've got to make sure... The Reforge model talks about three things. You need to have commercial value, you need to have product quality, Ja. You often connect the solution to the company. ikke problemet. Det var også en B2B-modell. Som vi sa i begynnelsen, kan dine beslutningsmaker og end-usere være ulike. Så du må fortsatt selge produkten. Vi må fortsatt få kontrakten solgt. Vi skal ikke være her om vi ikke kan få kontrakten solgt. Men samtidig må vi sørge for at jobbene er engasjeret og bruker den. Og gi valg for deres dag-til-dag-jobber også. Så hvis du har problemer med salg, og du forstår at dette ikke går som det burde gå, så er det tid for å stoppe opp og tenke på å intervjue potensielle kunder som du gjorde. Ja, vi gjorde 300 i alle fall. Jeg tror det var noen mer, men det var bare for å være veldig tøff. Vi ville... Var det alle i en kompani som intervjuet, eller var det bare en liten team som gjorde det? Det var en liten team, men alle i kompaniet var en del av løsningen. Når vi bygde disse modellene, hadde vi alle labellet med oss for å bygge det. Men det var et team-effort, for sikkert. Ja, like again, to that point, you can't, it's a balance between getting the right people in the room, but also making sure everyone's included, because that's where you get the best ideas. Yeah. Ja, ok, så da har du pivittet til denne nye løsningen, og nå er denne kompani stille å fungere? Ja, de gjorde en annen runde av fondsavgjøring, og så er det alltid et godt sign. Jeg har ikke riktig holdt meg i touch med det. Dette var alt i Statsen i Kalifornien, og jeg har flyttet fra Kalifornien til Norge, og jeg hadde to barn, så det er ulike prioriteringer, men det ser ut som om det går veldig bra. Ja, ok, så har du aldri drømt om å begynne en start-up? Oh, I don't know. Not right now. I'm really happy where I am, and my kids are a lot. Yeah, that's two startups. That's a lot, yeah. Yeah, your kids. But I think the big thing here is in product management, you're kind of, like I said, you have this view of the assembly line because you work with so many people. So for me, like, I love being in an environment where I'm working with really great people, and where we're all challenging each other in the right way, and trying to solve hard problems. Ultimately, again, I think if you asked me that question five years ago, I would have been like, yes, I'm going to be a CEO, yes, I'm going to launch my company, but... Right now it's about just trying to solve good problems and having a good time doing it, and being with people who I can enjoy solving them with. I mentioned that we were supposed to talk about prioritizations as well. We touched upon that. But just to make it... We can do it quickly. So... There are a lot of prioritization models which tells you how to prioritize if you need to decide between two, for example, product features. Totally. I think we even talked about rice in Moscow. There's many. You told me that there is one framework that actually works every time. Men det er ingen framgang. Nei, jeg er bare skriven. Nei, nei. De framgangene er greie. De er en god startpunkt. Det er den klassiske akademiske versus realitet-situasjonen. Og igjen, hvis jeg var i en perfekt samfunn som ikke hadde reaktive nødvendigheter, og som kunne følge en vannfall-modell perfekt, så er de modellene briljante i denne sensen. Men ultimativt, I just came up with a new what I call it not a slogan but a quote you can quote me on this I'll take it so Things happen will eat frameworks for breakfast. Okay, there you go. We'll eat frameworks for breakfast. I love it. Isn't there that classic culture? There's another quote about that. Exactly. Culture eats strategy for breakfast. Yes, exactly. Jeg elsker det. Det er godt tid, siden dette er morgenen. Så det er fordi du er en stor proponent av at ting skjer. Totalt. Jeg tror det store er at i slutten av dagen er folk folk. Vi er mennesker. Vi er vanskelig til menneskeer. Og Det er ingen perfekt system fordi av det. Jeg vil tenke at det er en framgang som kan løse alle mine livsproblemer, eller i alle fall mine businessproblemer. I slutten er vi alle vant til dette menneskebehevet. Det er bare om å støtte hverandre og sørge for at vi alle ser ut for hverandre og prøver å løse det, og å holde hverandre ærlige. Så Kanskje du har ulike valgene i forhold til kommersiell fit, user fit og kommersiell fit? For eksempel 0-10, og så kan du rate de ulike funksjonene, og så vinner du den høyeste skjermen. Så userfit, hva er userfit? Det handler mer om user-sensitivitet. Ideen er at det må gi mening til brukere. Så commercial-fit er vanlig. Det må gjøre penger for business. Product-fit betyr at det må fungere innen produktet. Jeg kan ikke være i... gaming software, and then suddenly pivot to commercial brick and mortar stuff. So feasibility. Exactly. And then the last one is user centricity, meaning it has to fit within the user's needs. So I could be in edtech, for example, and I could put something in there about healthcare, but if it doesn't align to the user's needs, like they're coming there to try and play games, they're not really going to care about this, they're not really going to adopt it. So that's more of an extreme example, but the idea is that it has to fit... It has to be easy enough for the users to understand when they're coming in with the mindset of using your product so that it adds value to them. Where they're going, oh yeah, this is why I'll use this product. Yeah. So, but, if I understand you correctly, you have almost never been in a situation where there are no externalities that you need to consider. No, not really. I think Google is probably the one that's closest to that environment because... Again, the scale you have at Google is enormous. And so when you release a feature, if there's anything wrong with it, not only do you lose the opportunity revenue of that feature, but then it could impact, because it's all one product, like the AdWords problem is all one platform, it could have negative implications to other components of the system. So everything is done very cautiously because of that risk. Um, so in that sense that required a lot of planning and a lot of investment, but there were still reactive things. Like I remember when we were trying to launch that, we realized we were originally going to target, um, Exactly. Ja, exakt. Men igjen, du kan forstå at det kunne være reaktivt, du kan forstå at det ikke var reaktivt fordi det teknisk ikke ble lagt ut. Men igjen, det er hele poenget. Vi er i en verden hvor ting skjer, og vi blir kastet av overraskelse. Og som mennesker blir vi kastet av overraskelse hver dag. Og det er bare om å støtte hverandre og prøve å finne ut hvordan vi kan mitigere disse overraskelsene. Ja. Ok, Melissa, vi stopper her. Jeg vil gjerne invite deg tilbake, for det er mange ting vi kan diskutere. Det er greit. Jeg håper dette var hjelpende, og jeg håper dette var hjelpende for dine lærere. Vi får se. Vi vil være itererende og testere av dette. Absolutt. Vi fikk innstillinger til produktutvikling, The roadmap creation, prioritization, how to pivot when your startup doesn't have product market fit. But also we delt into the how you go from a problem to a solution. The journey. Yeah. Yeah. Så takk for at du var med, Melissa. Takk for at du var med. Jeg ønsker deg det beste på Ardok. Jeg hører at det går veldig bra. Å, jeg håper det. Vi får se. Stå fokusert. Takk for at du var med, og god lykke. Vi snakker igjen i fremtiden. Takk for at du var med, Lukas. Takk. Hei, hvis du likte denne episoden, så abonner på den og gi den gjerne en 5-stjerners rating med dine tanker. Hvis du er interessert i temaene vi tar opp på denne podcasten, så anbefaler jeg deg å gå inn på skifter.no. Og hvis du mener vi fortjener deg, så kan du gjerne støtte oss ved å abonner på Skifter. Takk for at du hørte på, og så sees vi neste uke. Hei, er du en CEO eller CTO i et vekstselskap og trenger flere utviklere? Da vet du at det er ganske krevende å finne dyktige utviklere i Norge. Men håpet er heldigvis ikke ute. Cefalo er et norsk outsourcing-selskap som har klart å bli en av de aller beste arbeidsgiverne for seniorutviklere i Bangladesh. Cefalos spesialitet er å rekruttere og bygge langsiktig utviklingsteam sammen med den norske kunden. Og det å ha faste utviklere gjennom Cefalo skal i praksis oppleves som å ha egen ansatte. Så er du interessert i å høre mer om å ha eksterne utviklere, så vil Cefalo gjerne ta en veldig hyggelig prat med deg. Så sjekk ut cefalo.no, altså C-E-F-A-L-O.no.