Life After Launch: Keeping Your Product Alive

Matias Pietila at UXDX Europe. Video: https://youtu.be/wSR8CsvEUtw

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 happens after the MVP?

[00:00:02] Good afternoon. So glad to be here, and even more so, I'm glad that you are still here, because Duolingo is going to start their show at the same time. And now I see that you're leaving the building or something. Yeah, take your time. I'm going to talk to you about life after launch: how to keep your product alive. I come from a company called Qvik, from Helsinki, Finland. The funny thing here is that you don't know me, you don't know our company, you don't know our customers, so we're really starting from a blank slate here. The thing is, we have been doing this stuff for about 10 years now. We've seen some successes and some failures, and I'm trying to give you something useful from our learnings.

[00:00:53] Just to give you context: we build solutions for customers. They give us some money, and then they have their customers, and they bring the stuff to scale and try to get some more money out of that. The thing is to maximize the profit that is created, and we have seen it go the other way around as well. Back in the day we didn't care. We thought it's not our business, we're just building the apps or solutions or whatever for the customers. But we started understanding that actually we want to make sure that they succeed. We were young and needed money, so we have been building not really apps but stuff like scanning for you for a poem [?], and it's technically really complex and makes no sense at all. But yeah, we've been there.

[00:01:51] It's an interesting flow, how to get the product right. We've been talking about this stuff, and there are multiple approaches for that, but I think it's even more interesting how to build the right product, like we've been seeing here a lot. There are two interesting questions. The first one is how to make sure that we are solving the right problem. The other one is how we keep on learning after the first launch, how we keep the users in focus there, and that will be the topic of today.

[00:02:23] We should know MVP by now. Many companies argue that the jury is still out on whether you should be using the car metaphor or the donut [?] metaphor for that, but other than that it seems that we [?]... I don't know what this means. But then the question is, what happens after that? You have scoped down your first version of a product and you've shipped it, and now you're happy with your MVP out of the building. Very often what happens is that instead of chasing that bright light over there, you close the blinds and start building all the cool stuff that you have on your backlog, so many nice things that didn't make the cut for the first version. Have any of you seen this kind of behavior happening? Yeah, some have. Great.

[00:03:11] It leads to this kind of way of working where you have teams that are resources, pairs of hands, and the development is really backlog [?] driven. It's lacking collaboration between business and design and development. End users are not involved systematically, and products are basically defined in terms of features and not the solutions or needs that they are solving. For these two days we have been hearing discussion about this bright new way of doing things, and that's where we also want to take our clients. Here are some tips about that. We also see that it gets better results if you do things properly. These are real cases that we have been building.

Two fallacies after launch

[00:03:59] I like to use lean startup as a framework for building new stuff, even if you are not a startup or using that kind of scalable business model. It's a useful way of thinking about where you are in terms of the lifecycle of your product. If you subscribe to this jargon, you have problem-solution fit, and then you have product-market fit. Typically the fallacy is that people assume that when they have the MVP out of the door, suddenly they are already at product-market fit, even though at this point you should actually be iterating and learning from the market and getting your product to better match the real needs of your customers. The other fallacy seems to be that companies believe that if I only build more features and complete my whole backlog, then I will reach scale. Obviously that's not the truth. You need to be doing something other than that. So that's setting the scene, and I'm going to talk about two ways of addressing these needs.

Maintaining the roadmap

[00:05:01] One is maintaining the roadmap. The question seems to often be that you want to maintain a long-term vision, but at the same time you don't want to specify too much up front, because often those designs end up rotting in some kind of drawer. You never end up delivering them in reality, and then it's wasted effort. So you want to minimize doing specs but still have enough. Funnily enough, many people have been touching on the same kind of ideas already, like in the last talk.

[00:05:41] I think having some kind of customer journey is a good way of documenting the overall flow, and on that journey you can then have these concept ideas, or service components. Some people even call them feature cards. I don't like that term, because it's not about features but rather about solving a need. Here you document something you have discovered from the market when you did your research: what kind of business value there is, what kind of user value, what kind of implementation cost is entailed, and what kind of metrics you are tracking. This way you can cheaply write it down at this level, then just forget about it and move on.

[00:06:25] Other things you're going to need to help you maintain your vision: this is where we take some pre-existing stuff out of the oven, like a TV chef, because we have skipped the MVP and building the first version. We have some kind of vision document in place already by this time. We have our KPIs, we have user personas, we know what we are doing. The other thing we should have is some kind of design system containing the style guide for building stuff, and in the optimal case, reusable components, like people have been talking about here during the event.

[00:07:05] With these kinds of tools in place, we can then effectively manage our roadmap. When a need arises, when we know that we have to build something, we take the vision document, the service component and the design system, and we turn that into a UI spec. We specify it to a level where it's enough so we can start developing, but we don't overdo it, so that we still get developer input during the development of that specific user interface. So we're going from old-school waterfall, where you start with business, then design and then development, skipping the old-school agile, where you only do the business stuff once and then it's just building, to this kind of real, running lean way of working. There are many details we could talk about here, but I'm going to skip them and give you four takeaways.

A spec is like a vacation photo

[00:08:01] One is this postcard from Norway. I was there last summer. I think this is a nice metaphor from Jeff Patton, from the book User Story Mapping, where he says that a good specification is like a vacation photo. It means nothing to the observer, because they were not there, but it's a good way of having a discussion. You can explain how it works, and that's the way of actually communicating specifications. You can never write a spec that would communicate everything. If you have a light spec, people will complain it's not detailed enough. If you have a really detailed specification, they will say, "Too long, didn't read." People are never happy, so don't even try. Rather, have something that can work as the platform for discussion.

[00:08:56] Another thing for your definition of ready is that each story should have a real KPI and a plan for how to measure it. One good thing to do is to always prototype your stories before you ever get to developing anything, and actually test them with real people before committing to develop anything. And hand over specs in a smart way: tell stories, present, don't just find something in a document. And understand that you shouldn't finalize everything before starting development, but rather leave enough leeway so you can iterate with developers and find the perfect solution together. Designers will likely never know everything that is to be taken into account there.

The trip booking UI we never built

[00:09:41] I'm going to tell a quick story about maintaining your backlog and how to do this in practice. Once upon a time we were designing a user interface for a trip booking service. The background was that they had a desktop version and we had to make a mobile version of it. We tried to just take the same idea that was working on desktop to mobile directly, and then we saw that it wasn't working too well. You couldn't see the prices and availability quickly enough, and it was too hard to transition between product types. So we tried another version where we added more stuff to communicate the types and show the prices immediately, but it became pretty cluttered, and it was still hard to understand what these different types of products meant.

[00:10:33] So we created a separate screen or menu where you would select the kind of product you are choosing, but people didn't see the menu, and they still didn't understand the products. We started to see that actually the problem was in the product itself and not so much in the user interface. So we thought, what if we don't make you choose between products, but rather ask you questions that you know the answer to, like when are you coming back? If you say no return, it's a one-way trip. If you say same day, it's the day trip we were trying to solve for. If you say any day, it's a normal round trip. It was working better, but it was an unnatural way for people to think about how to book a trip, like "When am I coming back?"

[00:11:20] So we iterated it so that you just select your dates, and based on that the user interface adjusts. It was working really well and solved the need. Okay, the one-way trip was a bit harder to find, but we were happy with the iterated solution and the UI design breakthrough we had made there. The funny thing is that we then decided we actually didn't need it yet, because there were more important things to do. Two years went past and we never built that functionality. Then last spring it was again at the top of our backlog, and we were discussing whether we should build it now. I asked the PO, "Why are we doing it now, if we didn't do it two years ago? Why is it suddenly important enough to be built?" He took a look at the desktop data and the mobile data, and saw that mobile was already selling this trip type more than desktop, and decided, okay, we don't have to build it.

[00:12:22] The nice thing was to iterate a really well-working UI, but even more important was to understand that we don't need to build it. Okay, we could have killed it earlier, but it was still very important to be able to make that decision: let's not build something even though we have invested time in designing the user interface. That's something worth keeping in mind. As a designer you have to be happy to be able to kill your stuff. Even though it feels bad, it's an accomplishment, and you should congratulate yourself when doing it.

Focusing on the right metrics: the customer factory

[00:12:56] Now something about focusing on the right metrics. If we have this as the only way of documenting our product, it's useful for maintaining the long-term vision, but sometimes it's even more useful to see the lifecycle, how people are using your product and what kind of commercial metrics are related to that. I like to use this customer factory metaphor, which is adapted from the book Scaling Lean, and it's based on the pirate metrics model. Basically, you see your product as a factory that creates happy customers. You have the acquisition step, where you think about how you bring people into your system; how you activate them and make them happy; how you keep them coming back; how you incentivize them to tell their friends; and then how you actually take money out of them, or get sales. It's very simple, but it's a useful thinking tool to map your product around.

[00:14:00] You might be thinking about how you actually lower the threshold of trying out your product and how you minimize all the steps required for that. If you're doing apps, you might think of things like deferred deep linking, so if you come from the web, go to the App Store and install the app, you are automatically logged in. That's one way of lowering the threshold. Or you even have to think in terms of needing good enough ratings for your app so that people will download it. If your rating is below four stars, nobody will care. So it's not just the UI, it's about the whole product experience, how well it works and how it operates in the market. It's a good idea to follow these metrics and see how you are doing against benchmarks.

[00:14:48] The other step is activating people. Oftentimes you have different onboarding flows, but it's very important to think about what the most important thing is that you want people to do when they first open your service. For example, Tinder is known for really wanting you to get your first match as quickly as possible. How can they deliver that unique value to you so that you want to start using the service? So you shouldn't waste your onboarding on user interface instructions, but rather think about what you want the user to accomplish and what is useful for you as a company. It's also a matter of how you ask for permission for push messages. If you do it smartly, you can get a lot better results.

[00:15:32] Retention, of course, is a huge deal. There are different techniques, like push messaging and all that, but it's also about building the Hook Model and giving people logical reasons [?] to come back. That's something you really need to build inside the product and not just add as a marketing tool. For example, here we saw that when we added a loyalty card inside this travel application, the uninstall rates were reduced significantly. So give people reasons not to uninstall your application, if you are in the app business.

[00:16:14] Revenue is about making payments easy. Of course, Adrian was talking earlier here about how to do it smartly. It's also about finding some derivative currencies. It's not only about making sales. For example, these guys were able to notice that people who were using their app during a trip actually rated the whole trip experience so much better, having used the app there. So you can also quantify customer experience and see the value of it. When it comes to referral, it's not just about adding a share button, but actually thinking about what the reason is for the customer to share, how it will make them look, how to touch their feelings and emotions to really get them to share your stuff.

Mapping features to hypotheses and testing them

[00:17:04] One useful way I've found to approach this is to have these steps on the wall in a workshop, and then map what kind of features you have into these different phases, and see what kind of hypotheses you have connected with those features. Often you find out that many of the features just exist there and you don't even know why you have them. It's a good idea to actually ask why you think you have this functionality, and even better if you have metrics connected to those hypotheses. Often you see that you don't have metrics for everything, so it's a good way to analyze what you are doing and test it systematically.

[00:17:51] This kind of test card is a useful way of getting started: document what you believe will happen, how to verify it, and what you need to build to test your assumption. We've often been using a separate board for this, with experiments. For example, in Trello you can have different columns for the building phase, the testing or measuring phase and the learning phase, and see what's going on, and in those Trello tickets you can have these test cards. Just a handy little way of doing this in practice.

Your authentication often sucks

[00:18:32] One free tip: your authentication often sucks. I think it's something that's often skipped. People don't really pay enough attention to it, and it's very relevant both for your first-time user experience and for your returning users. You can reduce friction during onboarding, and you can reduce friction during recurring usage. Still, very often authentication is considered a solved problem, and you address it with minimum effort and don't care enough. So putting work into that is a good idea for almost any service. We recently helped one of our clients improve their login experience. Earlier on, "password forgotten" was one of the most visited pages on the whole site, and then this SSO solution was built to make it easier to log in, and we can see a dramatic result there. If you cannot see, I can zoom in a bit. Okay, so that was focusing on the right metrics.

Takeaways for designers, POs and developers

[00:19:46] Still, some takeaways. For designers, I think one implication is that you have to learn to embrace killing [?] features. You have to be happy when you have been able to remove something from the backlog and never build it, even though you really gave your heart to designing it. Another thing is that if you want to build something fancy, you will have to sell it. There needs to be a metric that it is improving, and you need to be able to justify why you need to do it. You also need to accept that sometimes fancy is not the correct answer. Sometimes you have to do a quick and dirty experiment, and you should be proud of that as well as a designer. And before designing anything, you should demand to know why we are doing this and how we will know we were successful.

[00:20:37] For POs, I would say that it's often the case that you know your business needs, but you don't tell them to your team. Teams are typically full of smart people, so it's a good idea to actually let them know. Sometimes it also happens that there are POs who don't even know why we're building something, and that is a hard situation. Then you really should focus on getting your facts correct first. This has been said many times today already, but when presenting requirements, don't communicate solutions, but rather use needs: tell what we need to solve, because your team is full of solution experts who can come up with cool ideas. And don't be afraid of sunk costs. Sometimes you have to scrap what you already did, and it's good for you and good for everybody.

[00:21:30] For developers, I would like to say: do not communicate your expertise by saying why something is hard. Also, do not try to communicate that you're smart by telling people that this spec is not solving everything, but rather tell how you would improve it, and be helpful. Don't see this as a war of some sort, which sometimes still happens. Like I said, if you have a better solution than what the designer was able to come up with, share it and let people know why it's better. Great design is a shared responsibility and everybody's mission in the end. The last point for developers would be that you might have to try a bit harder to demonstrate your worth as an analytical problem solver, because there are still people who see developers as smart pairs of hands that create code. But developers can be so much more, so you have to push harder. It's unfair, but it's a reality.

[00:22:40] To sum up: customer journeys and service components are a great way of managing your roadmap and your vision. Don't be afraid of sunk costs; you don't have to build everything that you have designed. Treat every launch as an experiment and try to prove yourself wrong. And growth is a shared responsibility, so everybody should know the goals and everybody should contribute. Thank you, everybody.