How To Figure Out What To Build First

Jan Tryggvason at UXDX Community: Stockholm. Video: https://youtu.be/0U66XW8dfbs

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.

Parental leave in Colombia and an integrations product

[00:00:11] I'm going to talk about a time I was helping a company to figure out what their products should be from the start. It's not going to be anything from Nordnet or my previous work. It's actually going to be from the time I was on parental leave. We were actually just discussing parental leave before the break and how awesome it is. So I went on parental leave with my wife to Colombia. This is a picture of [pocket at Sun][?] Barranquilla, and we were in Barranquilla, Colombia, where Shakira is from, actually. And also I was watching football, as you can see.

[00:00:55] Before we went there, I was like, okay, it's nice to be on parental leave, but it might become a little bit too boring maybe. So I asked my wife, okay, do you know anybody I could work with? And luckily she found some people, otherwise I wouldn't be holding this presentation. It was her friend from high school's company, a consulting company. They make websites and apps and all that stuff, and they basically wanted to start trying to build their own products.

[00:01:32] They were really good developers and designers and everything, but they had always been working with the model of the client telling them what to do. So they hadn't actually worked a lot with building their own products, and that's where I came in and helped them. This is their office in Barranquilla, on the top floor. It's closed because it gets insanely hot in there.

[00:02:03] What they were trying to do is that they saw a problem that a lot of SaaS companies, like Salesforce or Slack or invoicing software or anything that's online, need to have lots of integrations with other services, other SaaS companies, and that takes a lot of time. So their goal was to try to sell something to their clients, potential clients, so that they could sell integrations in days and not in weeks or months, because it usually takes a lot more time than you think it will.

[00:02:42] And what they wanted to sell was that those companies should focus on their core functionality, which is building the actual product that they are selling their customers, if they're selling sales software or financing software, anything like that. And of course, when you have a lot of integrations, it's easier to retain your customers, because if you have thousands of customers, they all have their own preferences on what other platforms they want to connect with. So it's very important that you build these connections with other apps. That's what they wanted to do.

[00:03:20] And they had actually started working on their product for maybe three or four months. So they had figured out, or at least they thought that they had figured out, what they wanted to build. It's slightly complicated, so I'll just go really quickly, just so you get some context. They wanted to have a host, which is the SaaS company, and they would want more integrations, because integrations give more customers and more customers give money. And they would want to have the install button, so when you press the button it sends information to another software. And they would have an app store, so that you can see all the integrations, download them and all that stuff. And in the end they would give a better user experience and keep their customers.

[00:04:17] Then they would have the developers that would actually build the APIs for the hosts and for the receiving application, if their API is already in the service, and then they would do the whole integration part. And then they would have the end users that would install the applications and just get more out of the app and enjoy it.

Story mapping down to the core

[00:04:45] This is what I was presented with, and it was a little bit tricky to understand. They had thought about a lot of different things that they wanted to do. Like the developers should be able to be third-party developers, they should be able to sell their apps to new customers. It was very, very complicated, and they were trying to figure out if people wanted to actually buy this software. So they had a huge product set already, and they didn't know if people actually wanted it.

[00:05:22] When I went there, my goal was basically to get to the point where they could sign three reference customers as fast as possible, and make sure that the customers want to pay for the service. That's what I was aiming at, and hoping that I would be able to get there during my time, since it was still limited.

[00:05:41] When I went there, I basically thought, okay, let's just step back and let's try to do some user story mapping, because I think user story mapping is a very, very nice technique to be able to understand the user journey. Jeff Patton wrote a book about it, and he said it's all in how you slice it. Is there somebody who has done user story mapping here? Quite many. So I guess some of you know this.

[00:06:18] In the story map, at the top you have user activities. This is an example: let's say that you're building some kind of web email and calendar app, and you have things like organizing email, managing emails and managing calendars. And in each of those activities you have the tasks that you might want to do, like searching emails and filing emails, and composing and deleting and reading and viewing. But in all of this you can actually do more. When you compose, you can send basic emails, you can send HTML emails. And this way you can build a map of different types of features that you can give to users.

[00:07:06] The thing with story mapping is also that you can divide it into different types of releases. Like, what's our walking skeleton, what are the first things we should build so that we can see if people actually want it? And you could say, okay, if you can create and send a basic email, and open an email, and maybe look at appointments, maybe that's our first version or something like that.

[00:07:32] We did this exercise, and we had the CEO and we had the developers and designers, and this is what we came up with. We didn't do the prettiest planning here yet. When I saw this, I could see that there were different increments of the huge user journey that we could focus on. I'm not going to go into the details here, but this is basically, in some words, how it looks in my hand.

[00:08:11] We had onboarding. We had setting up the APIs in the service, so that you could do the connections between the two services. We had adding a JavaScript on the SaaS side, so you can present whatever button that you want there. And you would have third-party developers, their logins and how they would work and everything. They had an app store, and they also had, okay, we need some analytics for our hosts.

[00:08:46] When looking at this, the goal is still to be able to say, okay, will users pay for this service? And remember that their goal was to get integrations really, really fast. So in order to get three customers, what do we need? Do we need onboarding? No, I don't think we need to really work on onboarding, because we're probably going to just onboard them manually and give them accounts. There's no need for focusing on that part.

[00:09:12] Setting up APIs, that is something, because that's basically the core of the service. So that was something that they were required to build. But the idea was not to give access to the SaaS companies or the hosts, because then you can build it yourself, and you can get a better understanding of how everything works, basically dogfooding your product before you actually release it to the public.

[00:09:44] Adding the JavaScript, yeah, well, that's pretty much the only thing that the reference customer should be able to do: adding JavaScript on their site so that they can insert the buttons there. And third-party developers, no, that's way too much. There's no need to think about those kinds of things at this point, if you don't know if the customers even want to pay for this service, and if it actually even works, connecting the two different services in a good way.

[00:10:18] App store, similar. No need to think about that, also because you probably don't have all your integrations through the service anyway, so why spend time on that? And analytics, same. It's nice, but it's not the core thing. So basically what you end up with is these two things. It's very much less, and it's still a lot of work. So I think that made them say, okay, this is what we're going to focus on actually building.

Testing the experience with potential customers

[00:10:54] But that's not it. We also needed to figure out, okay, how do the users actually want to work with this? Because that part was just part of it, and this is more about how the buttons would look. So we were thinking about use cases, and we did have some companies that were already interested, or at least wanted to be testing it. So we were thinking about different use cases and what the users would like to do, and we were talking with the potential customers.

[00:11:36] Then we created some hi-fi mocks, probably some lo-fi as well, but in the end it was hi-fi mocks of, this is what we think that the user experience should be, and this is how it should look. We went back and forth, and finally we figured out that, okay, yeah, this is very nice. And then of course, when showing this, we needed some InVision experiences, so you can actually see, okay, this is how it's going to work. And it was really, really nice.

[00:12:10] What we found out was that, previously, the company thought, okay, we're just going to have one button and that will do all the things. But actually they needed automated triggers. Say that you have contract software, for example, where you have contracts, and when somebody signs a contract, you want to send that to application Y, maybe your CRM software, saying that somebody approved it. And they also wanted to have what we call the user-triggered actions.

[00:12:55] Sometimes you just need a button, but sometimes you also need a drop-down menu button. And sometimes, and this one was more of an extra, let's say that you have a CRM application, and sometimes your application needs more information on where to put it. So you need forms, so that you could choose, okay, I want to send this to deal number one or deal number two, or something like that. So we found out about that.

[00:13:27] So what happened? I presented all this information, and we talked about it, and they were like, yeah, okay, this looks good. But they actually had to rewrite most of the stuff, because they had already been working on it for quite a while, but they didn't really know exactly how the user experience should be, or how it should work at all. So they had to rewrite a lot of the code, and it delayed them, of course, quite a lot.

[00:14:09] Learnings: make sure you understand the user needs of the product that you want to build. And one more important thing is to find the most critical value and start from there, and then start building from there. So that was it, thank you.