The Art Of Prioritisation In Product Development

Anna Sitnikova at UXDX Europe. Video: https://youtu.be/J1Jbk_8wHFs

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.

A potato business, iZettle and a very loud stakeholder

[00:00:05] That's such a big audience here. Good morning, everyone. Just before we get started, I would like to know a little bit more about you. Who is here today? Can I ask designers and UX people to raise their hands? Wow, amazing. Okay, product people, product managers, product owners? Much less. Okay. And developers? Even fewer. And there's about 10% who didn't raise their hands. I wonder who you are. You can scream, don't be shy.

[00:00:47] My name is Anna, and today we're going to talk about prioritization in product development. As I promised, a little bit about myself. When I was just six years old, I was really dreaming about a piano, but my parents were not able to afford one. So I decided to start my very first business. I convinced my grandfather to team up with me, and we started our potato delivery and selling business over the summer. This is something that helped me understand the value of the right prioritization quite early, because instead of playing like all the other kids, I was playing at the local farmers market, which looked similar to this.

[00:01:41] Most of my life I've spent in the world of entrepreneurship, and I have a huge graveyard of dead startups which I co-founded. So yes, I know how to fail, I know how to fail fast, and I prioritized the wrong things over and over again. That's why maybe my experience might be relevant for you today. For the last two and a half years, I have been leading one of the biggest product teams at iZettle. Briefly about iZettle: it's a Swedish fintech company which started in 2010 [?] by providing mobile payment solutions for small businesses in Sweden. Today we are in 12 different markets, helping merchants all over the world take quick payments and get everything they need to grow their business. Just recently we got acquired by PayPal. We joined the PayPal family, and we are super excited about this acquisition, especially about what it brings to our end users. The opportunities are really amazing.

[00:02:45] Ten weeks ago I got a very powerful stakeholder, and currently I am focusing my full attention on this very loud individual. We're trying to figure out our way of working with her. By the way, she is somewhere here today. Right now we work in very short sprints, from one to three hours, with very short feedback loops. So if I start sleeping on the stage, please wake me up, because I am on the second sprint today already. If we make a mistake in prioritization, we have a very short window to correct it until she is satisfied, because if she is not, the entire development team will be affected quite significantly. And if we keep prioritizing something wrongly over and over again, you don't want that. You need to fail fast and correct the situation as soon as possible, and of course this requires a lot of teamwork.

[00:03:51] I ask myself: does my work with Lisa sound similar to product development? Well, I guess so, because the cost of being wrong and wasting resources on something that doesn't bring a return on investment might significantly affect your business. That is why improving your prioritization together with your development team should be your absolute priority. For me, prioritization, the boring stuff now, is the process of deciding what to do next in order to achieve our goals. To be honest, there are plenty of prioritization frameworks online, and if your business is growing, your customers love your product and your stakeholders are satisfied, maybe you don't need any frameworks. Maybe the intuition of your team leader is the best recipe for success.

The user journey team and its cooking process

[00:04:41] Let me invite you into the world of my team. We are called User Journey, and we are maybe one of the biggest product teams at iZettle, but definitely the most international one. Our team includes mobile and web developers; we are quite backend heavy. We have UX and visual designers, an analyst, an agile coach and a product manager. We are purely cross-functional and quite autonomous. As a growth team, we don't really own any specific product, but rather a specific part of the customer journey, from registration to activation, and all the systems and platforms behind it. That is why we usually focus on improvements rather than on building new products. Since we work with registration and the onboarding experience, and as you already know, iZettle is a fintech company, we have compliance, security, all of those risks on our shoulders constantly. We have to prioritize really wisely between providing the best possible user experience and not sending our founders to jail.

[00:05:55] I would like you to think about your biggest fear in product development. What is it? My biggest fear in product development is to build something that customers don't need. But how do we as a team know what to build next? We tried different frameworks and ended up with this one. We call it the cooking process, and almost everything that comes to the sprint backlog goes through this process first. As you might see, it starts from a problem-hunting stage. To be honest, we don't really hunt anything, because usually problems hunt us. Ideas, technical improvements, customer pains, jobs to be done, different requests, learning points, market trends, results of research: it all comes from all possible channels. We don't really have an issue with the incoming flow of ideas. We rather have an issue with focusing on what to build next.

[00:06:58] Let's have a closer look at the first part of this process. As a result of the problem-hunting stage, we end up with something we call the pool of options. During this process we filter out the absolute no-gos and put everything in one list. I really like the word options, because at that moment the team is not committed yet to taking it further, and the word options actually highlights that to everyone. Then we move on to the problem validation stage, and that's where we filter quite a lot. Maybe from 100% of the things which come into this process, only 20% actually continue and end up in the prioritized list of problems. That's where most of the drama and action happens, because we need to filter; we have to say no to many things. In order to solve this drama, we came up with three principles. This is something that helped us prioritize, so let's go through them one by one.

The art of collaboration

[00:08:02] The first one is the art of collaboration. Since my team's ownership domain is very customer-facing, we pay a lot of attention to signals from end users, by checking reviews, doing surveys, monitoring conversions and organizing user interviews. But the most vocal requests actually come from our internal stakeholders, like marketing, sales, risk, support, legal and logistics, and sometimes ignoring those requests is almost impossible. That's where the art of collaboration might help. When I started at iZettle two and a half years ago, my team was just four engineers and myself, and very quickly I realized that the team was constantly interrupted. People from other teams were coming to us asking small questions, sending Slack messages, so the team was actually working as an information hub. I invited all the stakeholders to talk in one room. For the first time, 20 people came, and stepping into this room wasn't so great. It actually felt like stepping into a lion's den. It turned out that most of our stakeholders had no idea about each other's existence, even if they were representing the same teams, and they had very different opinions on what the team should and shouldn't do.

[00:09:26] How did we solve it? We picked one champion per department, and we started to work with them in very close collaboration. We invested in their understanding of agile principles and our way of working, and we walked them through our ongoing research and projects. I think the previous presenter was talking about it: you should invest in your stakeholders and explain how you work. We did a similar thing, and as a result we have highly engaged individuals who are experts in their domains. They don't miss any demo, they contribute to our development processes, and sometimes they even sit with us. Because of this extra effort in our collaboration, stakeholders went from requesters to contributors, and that allowed us to be very fast, not just on a day-to-day basis but in critical situations as well.

[00:10:31] Let me walk you through such a situation. In order to become an iZettle customer or user, every merchant needs to complete specific steps of onboarding. On this slide you can see the conversion from registration to activation in one of our markets, and as you see, it was growing quite significantly. In fact it was actually doubling, which is super exciting for me. Here are the proxy metrics which contribute to this final conversion. Each proxy metric represents a specific step which the customer needs to complete before they reach the activation point. By the way, this is a screenshot of a real dashboard; this is how my team monitors conversions on an everyday basis.

[00:11:19] What happened there is that last September we were testing a new concept of onboarding for Android users in eight different markets. It was an experiment meant to be for 10%; we launched it as an A/B test. In seven markets everything went as expected with conversions, but in one market we very quickly detected a drop. We started to analyze what was going wrong, and we figured out that we were missing a very important market difference, and we had no idea about this market difference before the launch. In a situation like this you usually have two choices: either roll back, or fix it and start iterating very quickly. After calculating the risks, the team decided to iterate, which is really scary. Thanks to all the stakeholders, because they immediately jumped on board and started to build and validate hypotheses together with us. We were all very transparent about how many users we were going to lose if we didn't fix the problem, and that was the best motivation.

[00:12:30] In the morning we were building a hypothesis. By the evening we were releasing an experiment. When we were leaving the office, the local market was waking up and starting to collect feedback from end users for us. The next day, when we came into the office, we had new information in order to move on to the next hypothesis. While doing those extremely fast cycles, we figured out several improvements for the entire market, for the entire 100% of incoming users, and we fixed it very quickly, because the adrenaline kept us rolling. This ended up doubling the conversion for the entire market, not just for the 10% we were initially experimenting on, because of our great collaboration with stakeholders who were willing to take risks and jumped on board immediately. So invest in your relationships with stakeholders and involve them in your processes. Of course it is very time consuming and relationship based, but it is definitely going to pay back.

The art of saying no

[00:13:41] Moving on to the next principle, the art of saying no. Do you remember this framework from before? There is one very important difference: the no bucket. As you already know, we don't really have a problem with incoming ideas and requests; we rather have a problem filtering out what not to build. At any stage of this process, anything can end up in the no bucket. Even if it's already in the "ready" column and ready to go into the sprint, we can still send it there and kill it. But we cannot send something to the no bucket to kill it if we don't understand the requester's problem deeply enough, and that is where the importance of why plays its role. I really assume that in this audience everyone knows about the importance of why, but the question is: do you really use it on an everyday basis?

[00:14:36] Here is an example. Our support is reaching out to us and asking for one more payment option in the checkout of our webshop, today, by the end of the day. And we of course ask why. The answer is: because users are calling, they're pissed off, and they would like to pay with an invoice. And we ask: but why don't they pay with what is there? Why do they want to pay like this? The answer is: users tried, but they failed. This is where the aha moment happens. Aha, we actually need to fix what is there. We need to fix the credit card payment rate before we introduce any new payment options. That is how you arrive from a solution-based request, like "add more payment options as soon as possible, by the end of the day," to a problem statement: "some of our users can't pay for hardware." My team might solve this problem differently, in a way which could be cheaper for us or better for our customers. In this example we only asked why twice, but sometimes you really need to ask a hundred times and keep asking why, why, why, before you get to the problem or hypothesis statement. It's very challenging, but it is definitely going to pay back.

[00:16:03] Why is it important to prioritize problems instead of solutions at that stage? Because your teams are the experts in the domain, and they will find the best possible solution for the situation. However, if after asking why even a hundred times you end up with answers such as "we should do it because it is an industry trend," or "because a high-level executive came up with this idea in the shower," or "because everyone agrees that it is a good idea," all of these are considered by my team as weak signals. We try to ignore them, even if it's challenging, especially with the high-level executives' ideas, and we try to send them to the no bucket right away. That is why one of my team's values is "question everything."

[00:16:56] What else ends up in the no bucket? For me there are in fact three different no buckets: the not-us bucket, the not-at-all bucket and the not-now bucket. On this slide you can see questions which we usually ask requesters or stakeholders in order to filter out some of the requests. Requests that don't make sense from the company vision and mission perspective usually end up in the not-at-all bucket. Requests that don't contribute to my team's goal end up in the not-us bucket, and requests that are not related to our team's domain also end up there. The last bucket is not now. Usually ideas which are worth trying, or problems worth solving, end up there, and we keep them for later. Why? Because sometimes conditions are not ready, such as resources, or maybe the market is not ready for this product or this idea.

[00:17:52] Of course, saying no is very difficult, and that's where your leadership skills come in. If you don't know how to say no, or if you're not saying no to things, then your team will suffer. As my team says, there are three types of leaders, based on how they affect or pollute the backlog, especially when the shit hits the fan. There is the funnel, there is the fan, and there is the umbrella. I really think that as a product manager or a team leader, it is your job not just to pick the most valuable problems to be solved, but also to protect your team and help them focus, to ship and build what was planned. If you don't know how to say no and start playing the fan or the funnel, then your team will suffer for sure. By focusing on the art of saying no, we ended up with a clearer and more transparent way of filtering requests, and we also increased the quality of solutions, because it helped the team focus on important things.

The art of keeping focus

[00:19:20] The last one is the art of keeping focus. We all aim for measurable things, right? We like to measure things; if it's not measurable, it's not for us. For me, focus equals time. In order to optimize my team's time, we limited the time for the decision-making process, and to do that we ended up with two principles. One is consent, not consensus. As you know, my team is very diverse, and we all come from different backgrounds, and sometimes agreeing on something is super hard for us. So instead of reaching 100% agreement, we follow this principle. Democratization of the decision-making process didn't work well for us, not at all. Plus, all decisions in product development, at least for us, are temporary. So instead of aiming for absolute agreement, we follow the consent principle and don't waste time in endless discussions.

[00:20:28] Another principle is this one. I think it's a very well-known principle, and many companies already use it, but in order to suit my team better, we changed it to this one. Whenever we face the wall and the scheduled, limited time for decision making has passed, we quickly jump into experimenting. We formulate the hypothesis and validate it as quickly as possible. Even if the hypothesis was wrong from the very beginning, we are definitely going to collect valuable insights and data, which will help us end up with a better decision in the next iteration. That could be your way out of endless discussions, and whenever the data comes, it will be clear what to do next. By following those principles, we managed to limit the time for decision making, and that helped our team focus more and ship better solutions to our customers.

[00:21:25] I walked you through small improvements that helped my team prioritize better. Remember the story about the potato business over the summer? By the end of the summer I actually got the money. But in fact, prioritization is a very dynamic process, and my goals changed, so instead of a piano I got a bike. Thank you so much for listening, and even laughing. Please get in touch with me if you want to discuss your prioritization tricks. And if you're interested in iZettle, we're actually hiring. I'm not sure if I'm allowed to say that.