Launch With Continuous Learning

Kraen Hansen at UXDX Community: Copenhagen. Video: https://youtu.be/XJT67E33LQI

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Launching in a continuous delivery context

[00:00:00] I'm going to be talking about launching. I wanted to talk about launching a product from a continuous delivery context, and that's kind of what I feel this idea of UXDX is to me. At least that's my interpretation. It's something about giving continuous user experience, involvement in a development process, and continuously building. And this is called continuous delivery.

[00:00:43] The format that I'm going to be using is, I'm going to be talking a little about defining how I see launching in this context. I want to help you maybe rethink the term launching in this context. Then I'm going to be talking a little about the experiences I have, some failures, some successes, and some learnings that I got from those.

[00:01:12] Just full disclosure, I'm 29 years old. I haven't been building tons of products and launching all of them. So that's one of the learnings, that it takes time. And I'm not going to be standing here and telling you all the cool startups that I launched. That's not what this talk is about.

Developer, designer, programmer

[00:01:33] Kraen: I want to learn first just a little about you guys. The previous speaker asked how many were developers. I want to ask, who here identifies themselves as a programmer? Okay, cool. And who here identifies themselves as a designer? Okay. Somebody here identifies with neither. I want to hear why. Who didn't raise a hand? Yeah? What do you identify as?

[00:02:02] Audience: Product manager.

[00:02:03] Kraen: A product manager. Okay, yeah. Okay. Well, that's good. Great. Well, who here identifies themselves as a developer? Is that a business? No, I'm sorry. It's an interesting question.

[00:02:19] Kraen: So, for me, I identify myself as a developer with a preference for programming. Okay? So this is a thought provocative thing. In the original idea of a definition of Scrum, the developer teams consisted of developers, and a developer was somebody developing the product. Okay? Whatever it took to develop the product. And I feel, whenever I hear somebody say the developers do this or that, they are often talking about programmers, in my experience.

[00:02:51] Kraen: I think if we start redefining the term developer and take into account the whole thing about developing a product, designers are also developers with a preference for design. And that also allows a programmer to start designing stuff, or attempt user researching or something like that, because they are a developer. They are developing the product and part of that is designing it. Okay. That's just one thing that I wanted to get out. It's something about skills that you have versus the role that you fill, and those two are two separate things.

Background

[00:03:27] This is a slide about me. I programmed all my life, and one effect of that is that I'm obsessed about words. I spend a lot of time figuring out what my variables or methods are called. And one of those obsessions, of course, is the developer versus designer versus programmer. That's one of my obsessions. I'm going to come into some other obsessions about words later.

[00:03:56] My background: I have a master's degree in computer science. Interesting talk about the science of UX, and how I have a degree in science but I'm not considering myself a scientist per se. So that's maybe something to think about. That's my background, in software engineering, basically.

[00:04:21] I used to be a partner, advisor and developer at an agency called Social Square. I worked there for five years. Previously it was called Bit Blueprint, that was when I started it, before the merge into Social Square. We developed products and services for larger corporations, companies like the National Museum of Denmark, the Copenhagen Municipality, mainly Danish organizations. A lot of web, some apps, stuff like that.

[00:04:53] We also experimented a lot with process. I became a certified Scrum master in that company, and we started experimenting with something called Holacracy, which is a system to govern the whole organization and iterate the rules and processes that we have in the company. So I was very focused on the process as well there.

[00:05:17] Then I decided to leave the consultancy world and join Realm as a software engineer. Realm is a database company. We built a database that runs on mobile phones, and you can synchronize, you can work on the database when you're offline. You can enter stuff into the database and once you get online it will synchronize, and you can edit the data in real time. It's going to be synchronized across devices and stuff like that.

[00:05:49] What I work on is the developer facing tools for that database. So I have a UI, where some of my colleagues are working on an API as the interface. They're shipping a product to developers and the API is some of that user experience, but I'm working on the more UI heavy stuff.

[00:06:13] I'm also going to mention that I have a wife that is a customer experience designer in a bank, and we met at university. That's probably also why I'm constantly reminded that design is important, because she's telling me that. And I actually think that's a really good thing for a programmer, to be married to a designer. This is my Twitter handle and this is my email, and I also put it here on the slides. Feel free to write anything to me.

When are we launching?

[00:06:49] Kraen: So I'm asking, when are we launching? Defining the term launching. I want to hear from the crowd. When do you consider a product being launched? Any ideas? When is it launched? Yeah, when is it launched?

[00:07:07] Audience: When it's live.

[00:07:08] Kraen: When it's live. When it's actually being used. Our users are experiencing it. So, when it's live, when people are using it. What do you think? Same. Yeah?

[00:07:16] Audience: When we do a commercial launch before. It can be silent.

[00:07:20] Kraen: So a commercial launch is also a thing. Yeah?

[00:07:23] Audience: When somebody outside of the team that have built it are using it.

[00:07:26] Kraen: So, somebody outside the team is using it. Yeah?

[00:07:29] Audience: It's in production.

[00:07:31] Kraen: It's in production. In production, trademark. That's it. Yeah?

[00:07:35] Audience: When you start routing DNS traffic to the service that we have. When we do the marketing push. When we start getting traction. When we go GA, general availability. When we say we officially have launched the product. Or, at the end, when this mayhem stops.

[00:07:56] Kraen: That's when we're launching. I think there's a lot of different ways to see launching. It's a very ambiguous word, which is of course also why people get confused when they're using the word. So it's actually interesting, I think, that we have this talk about launching at the end of a Monday conference, in a continuous launching or continuous delivery context.

[00:08:21] Kraen: So for me, this is a quote. This is maybe a more enterprise way of saying it: if you're not embarrassed by the first version of your product, you've launched too late. And this is really a hot line[?] on LinkedIn. And in the startup world, this is what we say: fucking ship it. Basically, I want to have you rethink launching. In a continuous setting, launching is not something you do at the end. It's something you do maybe the first day, maybe the second day, if you decide on a temporary version of the thing that you're launching. Try to get it, just get it out, so you have something to reference.

[00:09:08] I'm going to talk more about why you want to do it. So just understand that launching is something you do every day, ideally, and it's something you want to do yesterday.

Why launch early and continuously

[00:09:20] Why do you want to launch early and continuously? It's to get started on learning with actual users, actual data. You want to avoid building stuff that isn't used. So you can start monitoring what is actually used, or this small 10% of the feature that we build, are people actually clicking that button at all? It should be in less and more time [?].

[00:09:44] I would also say it helps recruit, or it could help recruit, early adopters. When you're building your product you can also build your user base, and use the product as a tool to engage with the early adopters in the market and learn from those as well, and have them rally around your product, just like you did, I think. That's me.

[00:10:03] This is getting a shareable point of reference, so a URL that you can tell your stakeholders to look at: this is where we are, doing the thing that we're doing. That could be a client in a consultancy context.

[00:10:24] It could be something you want to do to position yourself before your competitors, saying we're doing this thing, even though it's crap, but we're doing it, and you should be scared because we're coming for this market. They can also bite you. And then this closed beta thing, like launching where you have a signup page, everything looks great, but you're not allowing the users into the product, only the selected few that you really want to engage.

Why not launch early

[00:10:53] So, why not launch early? This is just some of the things that I came up with when I brainstormed. First impressions last. If you build something very crappy, it might be hard to convince the early adopters that had a bad experience to come back and retry. So that might be something that you want to take into consideration.

[00:11:22] I said it feels like inviting strangers to a party while you're wearing your pants. It feels uncomfortable doing something like that, and that could be something your stakeholders feel, not just you.

[00:11:34] This thing about revealing your intentions to a competitor: it might not be nice that they know that you're trying to take their market, and maybe you want to keep that a secret.

[00:11:47] And then this thing is actually something that I'm still thinking about with one of my products, Realm Studio, one of the products that I'm helping build. When we're doing continuous launching, it's hard for a user to discover that we did something, that we launched a feature. They just get an update. If we're not telling them how the product changed or what they should revisit, it's harder. So that's something you need to keep in mind, at least.

Questions on early launching

[00:12:17] Kraen: Okay. I'm going to talk a bit about these things. Is there any questions to the first couple of slides? Yeah?

[00:12:29] Audience: Does it make a difference with the market that you're aiming for, whether you can launch early or whether you really have to wait before launching? I was thinking, if I'm making it for a social network, then yeah, I mean, once you can tell if it's possible; like working for a bank, maybe [?].

[00:12:46] Kraen: If it makes a difference or not: I think it makes a difference for your stakeholders, the people paying for the thing. There's a cultural difference, I would say. But I don't think, from a user adoption, product development point of view, I don't know if there's a difference. But of course, from a stakeholder's perspective, there might be some differences. Anything else? Yeah?

[00:13:14] Audience: I'm just commenting on the last one. Users might need an update to realize —

[00:13:17] Kraen: Oh, yes.

[00:13:18] Audience: As a designer, that will also leave me, if I actually need to notify users that we launched this, might it actually do it right, sort of actively looking for it or missing it in the workflow. So, just, you know.

[00:13:33] Kraen: It might be a first impression that lasts, and people tried this thing but it didn't really do what they wanted it to do. We have a feature in Realm Studio about exporting the schemas from the database. That's not something you do every day. And if you had a bad experience, you're not going to try it again, necessarily. So we want to tell you that we actually improved it.

[00:13:54] Audience: Just one last point I would say about why I am also a bit reluctant to do fast launches, is that you're wasting people's time, their patience. If the product is too early, then you're asking them to engage and test it and give you feedback. Definitely like guinea pigs then. How do you solve that? You used a cake for me [?], but how do you make sure you don't waste people's time?

[00:14:29] Audience: I mean, like Juan[?] said, right? If you're not able to move your MVP or MMP or whatever to a state where it actually provides value, then you won't get valuable feedback. Then you're just proving some arbitrary technical thing.

[00:14:44] Audience: Then you are wasting people's time by building the thing, right, in the first place?

[00:14:48] Audience: No, I think there's a critical point, right, where until it actually solves a real need, then that you can make sort of technical ends meet doesn't really make a difference to anyone.

[00:15:00] Kraen: I think my answer would again be the research. The balance. The research.

[00:15:05] Audience: Or the research. The research. The research.

[00:15:07] Kraen: The research before, to find that, to prove your concept. It has a potential to build value, before building. Yeah.

[00:15:15] Audience: They don't find value interesting. Yeah.

[00:15:18] Kraen: Makes sense. Cool, I'm going to go on.

Failures: the notebook

[00:15:21] So, this was the brief for the talk, also talking about failures and successes and learnings. And this is hard to talk about, because it hurts, and this is bragging. And then the learnings, I might be aware of some of them and some of them are hard for me to remember, but I'm going to try anyway.

[00:15:38] This is something about failures. This is my primary failure. Do any of you guys know what this is? Yeah, what is it? It's a notebook, a Moleskine notebook. Exactly. So, I had one of those, and now I'm using Google Keep.

[00:16:02] Oh, can we do something about this, so it's not shut off in five minutes? I think you just need to hit a button or something on the remote. Thank you.

[00:16:16] So, one of my continuous failures is that I'm writing down my ideas in a notebook, and I'm not launching them. I'm not even trying them out. I'm not even talking to people about the thing that I might want to launch at some point, right? So this is, I think, the most often failure that I do: I envision something and I don't do it. And that's something that is happening to me a lot, and I don't know how to solve it yet. We're just devoting more time to it. But it's one of my continuous failures.

A municipality project: designers in the sprints

[00:16:54] This is another case. We did a project for a municipality. We were building an app. We won a tender, so they had a spec. We convinced them that we should do agile, and we actually convinced them that we should involve designers in the sprints.

[00:17:15] We had an idea where we had two product designers, UX designers, on the team, on the developer team. They should, first of all, do user research, and they should envision what items on the backlog should come in, what should go out, how should we change priorities. And when the programmers iterated and built product, the more designing developers should look back and say, okay, how did this thing that we wanted to build, how did that actually work and affect the usage of the app in real life?

[00:17:51] We actually built a team, like a panel of cyclists. It was an app about cycling. We actually had them use the app. We rode with them and we rode with the app ourselves. I, as a programmer, rode with the app on my bike. I think that was a really good process.

[00:18:10] The only problem is that it's very hard to stick to the plan if you're learning. What I mean by that is that the customer had a plan at the beginning, at the tender. They had stakeholders that expected them to follow the plan, although we agreed that we should be agile and all those things. And that creates friction if you try to stick to a plan, and you can see it's obvious that from this user research we should do this differently. But sometimes it's hard to balance your stakeholders versus the product that you're building.

[00:18:50] It was also hard, like a concrete thing, it was hard to translate the findings from a user into an item on a backlog. It was kind of hard for us. I don't know why. It might be because the backlog was filled already with a lot of ideas from the customer. But that was just something we had a hard time doing.

[00:19:12] And also the releasing, the launching part of this was hard, because we were in a regime where they wanted to hand over the passwords for signing the app and putting it on the app store. They wanted to do that in the end, eventually. So we built some apps that we shipped to beta testers, but we couldn't get allowance to actually ship the app continuously, which was a struggle.

[00:19:38] Another case was actually an open source project, where we tried to involve programmers and designers in one big pool. We teach them some process and we wanted them to take on this project and build a communal platform for themselves. Somebody was paying for us to facilitate that. And that was very interesting in this whole UXDX context.