The Art Of Prioritisation In Product Development

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

Most of my life I 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 wrong things over and over again. So 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 in iZettle. Shortly about iZettle, iZettle is a Swedish FinTech company that started in 2000, by providing mobile payment solutions for small businesses in Sweden. Today we are in 12 different markets helping merchants all over the world to 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 what does it bring to our end users. The opportunities are really amazing, ten weeks ago I got a very powerful stakeholder, and currently, I am focusing my full attention on this very loud individual, and we're trying to figure out our way of working with her. By the way, she is somewhere here today, and right now we work with you and we're a short sprint from 1 to 3 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 do 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. If you keep prioritizing over and over again something wrongly, you don't want to do it. You need to fail fast and correct the situation as soon as possible and of course, this requires a lot of teamwork. 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, boring stuff now, is the process of deciding on 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 customer loves 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.

Let me invite you to the world of my team, well we are called user journey and we are maybe one of the biggest product teams in iZettle, but definitely, the most international one. Our team includes mobile and web developers, we are quite back end heavy, we have UX and visual designers, analysts and agile coaches, product managers, and we are purely cross-functional and quite autonomous. As a growth team we don't really own any specific product, but, rather on a specific part of a customer journey from registration to activation, and all systems and platforms behind it. That is why we usually focus on improvements rather than on building new products. Since we work with registration, onboarding, and experience, and as you already know iZettle is a FinTech company we have compliance, security all of those risks. They are all on our asses constantly and we have to prioritize really wisely between providing the best possible user experience while not sending our founders to jail. I would like you to think about your biggest fear in product development. What is that?

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? So, we tried different frameworks, and we ended up with this one, we call it a cooking process. Almost everything that comes to the sprint backlog goes through this process first, you might see it’s all starting from a problem hunting stage. To be honest we don't really hunt anything because usually, problems hunt us but ideas, technical improvements, customers' pain, jobs to be done, different requests, learning points, market trends, results of research. It all comes from all possible channels and 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, so let's have a closer look into the first part of this process.

As a result of the problem hunting stage, we end up with something that we call, the pool of options. It's basically during this process we filter out absolute no-go and put everything in one list. I really like word options because at that moment, the team is not committed yet to taking it further, and the word option is actually highlighting it to everyone. Then we move on to the problem validation stage and that's where we filter quite a lot, maybe from hundred percent of things that come into this process, only twenty percent actually continues and end up in a 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 to prioritize. Let's go through them one by one, the first one is the art of collaboration, since our ownership domain, my team 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 logistics, and sometimes ignoring those requests is almost impossible, that's where the art of collaboration might help.

When I started at iZettle, it was two and a half years ago, my team was just four engineers and myself. Very quickly I realized that the team is constantly interrupted, people from other teams were coming to us asking small questions, sending slack messages, so the team actually was working as an information hub. I invited all of the stakeholders to have the talk in one room for the first time, 20 people came, and stepping into this room wasn't so great. It's actually felt like stepping into a lion's den. It turns out to be that most of our stakeholders had no idea about the existence of each other, even if they were representing the same teams. They had very different opinions on what teams should and shouldn't do. How did we solve it? We picked one champion per one department, and we started to work with them in very close collaboration, invested in their understanding of agile principles the way of working. We walk them through our ongoing research and projects. I think the previous presenter was telling about it, you should invest and explain your stakeholders and explain how you work. We did a similar thing and as a result, we have got highly engaged individuals, who are experts in their domains and they don't miss any demo. They contribute to our development processes and they sometimes even sit with us, because of this extra effort into our collaboration, stakeholders shifted from requesters to become contributors.

That allows us to be very fast, not just on a day-to-day basis but in critical situations as well. Let me walk you through such a situation. In order to become an iZettle customer or an iZettle user, every merchant needs to complete specific steps of onboarding. On that slide, you can see conversion from registration to activation on one of our markets, as you see it was growing quite significantly. In fact, it actually was doubling which is super exciting for me, and here are the proxy metrics which contribute to this final conversion. Each proxy metric represents a specific step that customers need to complete before they reach the activation point. By the way, this is a screenshot of a real dashboard. This is how my team can monitor conversions on an everyday basis. Last September, we were testing a new concept of onboarding for Android users on eight different markets and it was an experiment meant to be for 10%. We launched it with the A/B test and on seven markets everything went as expected with conversions, but on one market we very quickly detected a drop, so we started to analyze what was going wrong and we figured out that we were missing a very important market difference.

We had no idea about this market difference before the launch, in a situation like this, you usually have two choices either to roll back or to fix it and start reiterating it very quickly. After calculating the risks, the team decided to reiterate 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 all were very transparent about how many users were going to lose if we did not fix the problem and that was the best motivation. In the morning we were building a hypothesis, by the evening we actually were releasing an experiment and 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 were coming to the office, we had new information coming in, 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 hundred percent of incoming users and we fixed it very quickly because adrenaline was keep rolling us. This ended up in doubling their conversion for the entire market, not just for this ten percent on we were initially experimenting on. And because of our great collaboration with stakeholders who were willing to take the risk and jumped on board immediately. Invest in your relationship 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.

Moving on to the next principle, the art of saying no. Do you remember this framework from before? There is one very important difference, it is the “no bucket”. As you already know, we don't really have a problem with incoming ideas and requests. We rather have a problem of filtering out what not to build, and at any stage of this process anything can actually end up in the “no bucket”, even if it's already the Jira and ready to go to the sprint, we still can send it there, we still can kill it. But we cannot send something to the “no bucket” to kill it if we don't understand the requested problem deep enough. That is where the importance of “why” plays its role, I assume in this audience everyone knows about the importance of “why”, but the question is, do you really use it on an everyday basis? There is an example: Our support is reaching out to us and asking to have one more payment option in the check-out of our web-shop today, like by the end of the day. We, of course, ask “why”, and the answer is because users are calling, pissed off. They would like to pay with invoice, we asking well, why didn'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, so “aha” we actually need to fix what is there. We need to fix the credit card payment rate before we actually introduce any new payment options. That is how you arrive at the solution-based requests, like adding more payments option as soon as possible by the end of the day, to a problem state. Some of our users can't pay for hardware and my team might solve this problem differently which could be cheaper for us or better for our customers, so 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 state. It's very challenging but it is definitely going to pay back.

So why it is 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, after asking why even a hundred times you end up with answers such as, well, we should do it because it is an industry trend or because high-level executives came up with this idea a shower or because everyone agrees that it is a good idea. All of this is considered by my team as a weak signal and 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 values is to question everything.

What else end up in “no bucket”. For me, there are three different “no buckets”, “not us bucket”, “not at all bucket”, and “not now bucket”. On that slide, you can see questions that are usually asked by 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 goal end up in the “not us bucket”, requests that are not related to our team domain also end up there, and the last bucket is “not now” usually, ideas which are worth trying or problems worth solving, they end up there and we keep them for later. Why? Sometimes, conditions are not ready such as resources, or maybe the market is not ready for this product or this idea.

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. It is a shit funnel, it is a shit fan, and it is a shit umbrella. I really think that as a product manager or a team leader it is your job, not just to pick up the most valuable problems to be solved but to protect your team and help them focus, ship, and build what was planned. If you don't know how to say no and start playing a fan or a funnel then your team will suffer for sure, by focusing on the art of saying no, we ended up with a clear and transparent way of filtering requests. We also increased the quality of solutions because it helped the team to focus on important things.

The last one is the art of keeping focus, we all aim for measurable things, we like to measure things. If it's not measurable, it's something not for us. For me, focus equals time so, in order to optimize my team time, we limit time for the decision-making process, and to do that, we ended up with two principles. One is consent, not consensus. So as you know my team is very diverse and we all come from different backgrounds, sometimes for us to agree on something is super hard. 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 an absolute agreement, we rather follow the consent principle and don't waste time in endless discussions.

Another principle, this one I think it's a very well-known principle many companies already use it but in order to suit my team better, we actually change it to this one: Disagree and Experiment. Whenever we face the wall and schedule and limited time for decision-making have passed, we quickly jump into experimenting. We formulate the hypothesis and validate it as quickly as possible, so even if the hypothesis was wrong from the very beginning, we definitely going to collect valuable insights and data which will help us to end up with a better decision in the next iteration. That could be your way out from endless discussions and whenever data comes it will be clear what to do next.

Following those principles, we managed to limit time for decision-making and that helped our team to focus more and to ship better solutions to our customers. I walked you through small improvements that helped my team to prioritize better. Remember the story about the potato business over the summer, which I was doing? 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 piano I got a bike. Thank you so much for listening and even laughing and please get in touch with me if you want to discuss your prioritization tricks and if you are interested in iZettle, we actually hiring. I'm not sure if I'm allowed to say that. Thank you.