MLP (Minimum Loveable Product)

Juan Munoz at UXDX Community: Copenhagen. Video: https://youtu.be/dBB-F5wTzFQ

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.

What Pleo is and who uses it

[00:00:00] I want to apologize to all UX if I say something wrong, or if I say something that bothers you. I'm a developer, I'm not an expert on UX, but I suffer the UX designers. I'm trying to be proactive, so I'm going to try to explain what we suffer and what we don't like when we're building MVPs, and what we like. Let's see if we can make a talk, and after the talk we can discuss a little bit about what I said and what you think about it.

[00:00:43] A minimum lovable product, or how to build an MVP that uses lots[?]. Usually the minimum lovable product is just the next step of an MVP. I can call it a complete MVP with all the features or niceties that we want to add to the MVP. But it's not an MVP, it's the next level.

[00:01:06] First of all, let me explain what Pleo is. You already explained it, but Pleo is a prepaid-card[?] solution that automates the expense components of the firm[?]. That's what we get from the web page. What we are trying to do is give all the users, all the employees of the company, credit cards. So they don't have to pay in advance when they have to book a flight to the office in San Francisco. It's like the company is ready for it.

[00:01:41] And then what we provide is a system that the bookkeepers and the administrators of the company are happy with. Because once you've booked, you get the receipt, then you take a picture, and then everything is done. The bookkeeper is happy, the admin is happy because everything is collected[?], and the user is happy because they don't have to pay in advance for two months.

[00:01:59] As I said, we have four different users. We have the admin, the responsible person in the company, usually the CFO or the CEO, who is loading money into Pleo and managing the team. Then we have the employees, who are spending the money that they are administrating in Pleo. And then the bookkeeper, the one making sure that everybody uses the money, but they have to use the money.

[00:02:28] That's what Pleo is. But how? We have to make an MVP of this, and Pleo is managing money, and an expense processor, and a lot of different things that make Pleo not the simple app that has these features, but one that has a lot of things. So let's build an MVP of that.

What an MVP means to a developer

[00:02:54] Before starting to build an MVP, as a developer you have to understand what an MVP is. And then you get this reference from this book that almost everybody has read, The Lean Startup from Eric Ries, saying that an MVP is a version of the product that enables a full turn of the build, measure, learn loop with a minimum amount of effort and development time.

[00:03:18] Let's try to understand it. The first part is a version of the product that enables a full turn of the build, measure, learn loop. As a developer, it's like, okay, I need to build something that is going to change in one month. So let's try to make it in a way that I can change it in one month, and then another month, and then another month, and then get some input and do changes. Let's build something that is easy to modify.

[00:03:43] But then on the other side, you get this part: with a minimum amount of effort and development time. It's like, okay, there's something wrong in this definition. I have to do something that I can work with in a month, but I have to do it in less than a month, because that's what they are asking me for.

[00:04:01] So that's what we understand in the end: could you please develop something quick and good that we can learn something from? Yeah. But... there are some concerns that as developers we have to raise, because we have to build this, and it's not simple to build. I want to address some examples of things I suffered and how we did it at Pleo, and that's why I'm giving this talk today.

Scope, and do one thing right

[00:04:32] Scope, scope, scope. Please. I heard so many times that we want to build a new... and, for example, in fintech, we want to disrupt the banking industry. What does it mean to disrupt the banking industry? Please, could you just scope a little bit? This is an MVP. We haven't even got the angel investment yet. So please, let's try to find a solution, one to identify what we want to solve.

[00:05:00] And that's something that was clear from the beginning, and the CEO and the CTO had it pretty clearly in mind. We want to solve this specific problem, which is expense management. We're not going to reinvent the wheel. We're not going to build a bank. We're not going to do something else but this specific thing, and we're going to start from there.

[00:05:19] And that's a pretty good point, because then as a developer you can understand, okay, we have to build something that does something, but I can see the idea and try to build an MVP based on that. Then you can go that way.

[00:05:38] And another thing is, do one thing right. It doesn't matter if your MVP has a thousand features or a hundred features, but if they're half the way done, or the experience of the user is pretty poor, then it's better not to release that MVP. I'd rather build something that is amazing in terms of the experience of the user, but only does that.

[00:06:02] For example, in the case of Pleo, the first version was an app where, when you do an expense, you get a push notification, you take a picture, and you upload that picture to the system. That's it. And that already solved the first problem I mentioned, because we want to solve expense management. We have an expense, we have the picture, which is what the bookkeeper needs, and then we upload that. And then we have an MVP of the product.

[00:06:31] And people can start to iterate on that. What if we add now a list of expenses? What if we add details of expenses, so I can add a project, I can add a note: I have this coffee that I invited this specific customer to. You can iterate from there and get to something bigger. But the first iteration is, this is the problem I'm going to solve.

Prioritize, and who owns priorities early on

[00:06:55] Prioritize. This is the biggest pain I ever had in this world of development, which is this. We have to talk to designers and UX and prioritize things. As a developer, you get this designer with a lot of animations, a lot of nice features, a lot of things, and you have the time. It's like, okay, I have to build this in one week. That doesn't work. I have to sleep at some point.

[00:07:24] So you get to the designers like, okay, I don't want to do this. I can do that in one week. This is not nice. But then you can say that. I mean, you can tell the designer, we don't do this, this and that, and that's the thing: you have to offer him something.

[00:07:39] Juan: Yeah, please.

[00:07:40] Audience: What kind of... do you work agile?

[00:07:43] Juan: We try to work agile.

[00:07:46] Audience: But don't you then have a product owner?

[00:07:49] Juan: Yes, we do.

[00:07:50] Audience: You should prioritize a lot.

[00:07:52] Juan: Yes, but I'm talking about MVP. I'm talking about an earlier stage. When you're a company of five people, you don't get to have a product owner. When we are at the stage that we are 50, we are Senders[?], for example. How many product owners do you have at Senders[?]?

[00:08:11] Audience: The entire company?

[00:08:12] Juan: Yeah.

[00:08:13] Audience: A lot.

[00:08:15] Juan: So the scope of this talk is just the MVP. This starting point where you have a CEO, you have maybe a CTO, and you don't have even money to pay the developer for, and you have an external UX designer that you hire.

[00:08:32] Audience: Yes, so we have 65 people here that covers product design, DevOps, engineering, sales and advocacy, and we have four product managers and a product director. So roughly four to five people in a company of this size, 60, 65 people.

[00:08:50] Juan: So for example, at Pleo at this stage we have 50 people and we have two product managers, product owners, you can say, I don't know how you call it, and we have a team of 12 developers. But in the beginning, there wasn't even a designer. There was just a couple of developers, one doing the app and the other one doing the backend, so all the infrastructure with the banks and so on.

[00:09:11] That's why I'm saying that if you get the point, you have a designer doing the design and so on, so you have to give it some feedback. As a developer, I can do this, this and that, and that's the scope. Of course, when you reach that point and you have product owners, you don't have to say anything. But until that point, we have a lot of iterations to go through.

Don't improvise, and build a beta community

[00:09:32] Don't improvise. That's something that I experienced personally, and I can tell you about that. We built an app, and in that app you can either have a login or an anonymous user. That's fine. That's what the requirements were in the beginning. Fine.

[00:09:48] But then, when you have the first version, okay, the MVP is ready, here you have it, and they say, yeah, but we want that if an anonymous user decides to sign up, we store all his data and put it in his profile. It's like, well, that's not what we talked about in the beginning. What we talked about in the beginning is you can have anonymous users, and an anonymous user doesn't own any data. That's the user: anonymous, and that's what it is. So when you sign up, you lose everything. And then you have the users, so you get all the benefits of doing the login.

[00:10:20] But then don't do that. I mean, that comes true[?]. That took me like two weeks to figure out how to do. And the plan was to release two weeks before. So we were two weeks later on the release of the MVP because they decided to add this extra feature. And of course, they pay, they decide, but still, then don't come with these issues.

[00:10:42] Build a beta community. This is where you gather your feedback about the MVP. Before actually releasing your MVP to everybody, you should test it with some people. Because it might be that at this stage you are building something that nobody likes, or the experience is really bad. But if you can gather feedback, that's what you're really going to use to iterate and get to the point of this lovable MVP.

[00:11:15] And do different things from the others. This is how Pleo looks like. It's expense management, so it's fintech, banking, so it's kind of this, sorry, boring area, where everything is blue, like business blue, and gray, blackish. And then we decided to go pink and white.

[00:11:40] The reason is that people say, what is this pink app you have there? People will ask about the pink, and what is this pink, and everybody starts talking about the pink thingy and so on. That's something that is really important. Don't build the same app. Don't try to build Airbnb. Don't try to build Spotify. Don't follow those aside[?]. Try to make something new, and you can't be fair[?]. Otherwise, you're just building another thing that, well, okay, nobody will talk about it.

Useful, buildable, remarkable

[00:12:07] I will resume how to build an MLP, or minimum lovable product, as these three things. Build something useful: something that is actually solving a problem of someone. Don't build, or don't try to build, something that tries to solve a lot of different things, because you will not solve all these things in the first version. Try just to solve the first issue.

[00:12:38] So what we did at Pleo: expense management. You make an expense, you get the push notification, you take a picture, you upload, you're done. You don't have to fill in this horrible spreadsheet with, I spent this month this, because of that.

[00:12:58] Buildable. You have to scope. You have to really make something that you can make in the time frame you have to do it. Otherwise, you can just iterate and iterate and iterate and it will never release.

[00:13:10] And the third thing is, make something remarkable. Make something that people will talk about. Because otherwise, you just build something and then you are another one of these two billion apps that there are in the App Store. That's everything I have to share with you. Thank you very much.