 Hi. Now, most companies like to claim that they design around the user's needs. It seems obvious, right? The problem is, very often they don't. Does anyone remember Sony's TV remote control for the Google TV? It had like 100 buttons on. It was impossible to use. Well, how about the Nokia N-Gage? A mobile phone and games console all in one. Sounds great, but the speaker and microphone one decides. So that means you had to make a phone call and it looked like you were holding a book up to your ear. It didn't work at all. Well, our next speaker has spent a decade developing his own methodology to create real user-oriented products. He is Vyacheslav Kovalevsky. He's Senior Engineering Manager at Facebook. Or do we say Meta? I think we'll stick at Facebook, right? And he's here with us today, so welcome. Thank you. You're actually right. It's now Meta. Yes. Are you all set? Yes, absolutely. I'm ready to go. It's 4am in the morning on my side, but I have enough coffee to keep me going. My goodness. You have your coffee. You keep yourself refueled. Well, you look great. Here, we're getting ready for lunch here, so we're getting nervous. So it's a tough time for everyone. Okay, okay. So I will try to stick to my schedule. Okay, thank you. Hello, everyone. My name is Vyacheslav, short name Slava. So full disclosure, I'm not officially speaking on behalf of my employer. And I came here to present a framework, a technique that I've been using for roughly 10 years now. But I have summarized all the learning that I got from building four big orgs. And what I mean by building four bigger organizations, I mean a group of team that at least have three teams with at least several hundred cross-functional folks. Now, the talk will be summarizing the partners for different reasons. I obviously cannot be very, very specific in examples, but I have put together a generalization that definitely will help. So for whom this talk, first of all, engineers who would like to go faster in your company and understand business better. For engine managers who would love to improve collaboration with your products. For engine managers who do not have a PM and they have to effectively work as a PM and define the vision, define the strategy for the product. And managers who just want to lead the product, not just execute what product tell them to execute TLs who neither have engine manager or they don't have a PM and they have to assume the troll for quite some time. And finally, anyone who wants to build and lead the product and be successful with that. Let me start with problem statement. And by the way, if you will get one thing from this talk today, always start with a problem. This probably one main thing if anything else you should remember at least that part. So in order to define the problem that user oriented development process is solving very, very quick prerequisite. Let me show you this chart. This chart is quite interesting and visualizes one of the problem in industry that you need to tackle even before you aiming to create a successful product. Now access here x axis here is time wise y axis is something you're measuring with your product doesn't matter doesn't matter what and I apologize, but does my slide moving it doesn't look like my slide that changing can someone confirm that it's actually changing yes okay now I can now I can see the apologize for that. Okay, so the why is something that you're measuring it doesn't matter matter matter what exactly that the green one is obvious success if you actually have this exponential growth curve and your product is showing that results obviously product is successful. Now the red one is obvious the end you need to close it, whatever you were building clearly it's not working out. Now the biggest problem in the industry right now is this don't be much. When you kind of have some usage, but since you never have defined what success looks like for you. It's not going. And to be honest, I've been long time in the industry to be an numerous amount of meetings where the product or PM or even CEO opens up with a chart that shows Oh for my feature my product we have X amount of users. Such meeting always resisting to ask, but how much have you expected is this is more than you expected or less. How much have you expected to call a successful lunch or successful usage. And without that number and without that number a number is meaningless you can call up front. It is huge success or a huge failure, because you don't have a reference point to compare us. So this talk that you when you're building anything actually have a good understanding of this particular particular part of the chart as a leader you'll have one specific job to define metrics and the expectation one particular metrics that's that important for the business that important for the org and specifically outline green field which means that product is successful and blue field here which means that we will discuss if we want to do proceed with this or maybe we need to pivot. And to be fair, as I like to say anyone who I support defining this chart is one of my p0 goals. And in fact, how I as a manager who support the group should be measured by growing income of the folks that working that working in my org, because if I define this chart correctly this means that they working on the things that important for the business. And if their income is not growing that means that either I messed up. I haven't defined this chart right and it's actually not that important for the business, or the work doesn't recognize the input from the folks, both of them need to be need to be fixed. Now, now we're ready to outline the problem that user oriented development process action aim to solve. Have this chart in place. The problem statement. When we are building product services features, we're often not connecting to the success of our customer success. That's a problem statement many of the folks might think no when we build our product we actually do connect our success with customer success. But in reality that's not the case and this is what you GP trying to solve I will talk later why people think that they doing it and why it's not actually true and how to make the true. So this is a problem. Now let's move to your GP and let's discuss how to solve it. So user oriented development process is a technique that consists different different steps and the simplest way to outline it is to actually take an example and walk you through very, very particular example how you developing product with all the stages that the UDP has. Now, I will be talking about task tracker. Let's take an example at task tracker. As I mentioned in the beginning user into the welcome process always starts with a problem. So, in the moment we will start outlining what problem we're going to solve. But for the sake of the story, I want you to outline what we will end up building so let's imagine that we end the universe where there is no task tracker, and we are building the business that need to build a test tracking system for our customers. So, let's do it your GP way and show how exactly it should be done according to the framework that I'm talking about. First step and then define the main problem that you want to solve and the metrics how you're going to measure the success. Let me briefly pause here and I want to define main problem. Main problem is a problem that customers want to be solved now and it doesn't have any problem that need to be solved earlier. Let me give you an example. I imagine that I can tell you that I can increase ratio of pet project that you developing that will reach the production. The reason open statistics assess that eight out of 10 pet project that any of us doing at home, never reach the light of the day and never reaches the production. That's the problem. And imagine for a second, I have a solution for that problem. And it will cost you $5 per month. Let's put aside right now whether you believe that the solution work or not, let's assume I do have it. Would you be willing to spend that $5 per month knowing that yes, instead of the eight failed projects per pet projects per quarter, for example, I can reduce it to two. So, eight out of 10 pet projects that you have will reach the production you actually will deliver them. Now, if you, if you're ready to spend money on this particular solution to solve this particular problem, that's the main problem for you. You might have many other problems, problem at work, problem for your customers for your business. But if you're ready to invest in this specific one is the main one. You don't have any other blockers. In our concurrent universe where no one have ever created Task Tracker, the problem would be like this. 60% of the software project are delivered with 60% time delays and usually 400 over budget. That's actually more or less real problem that existed in the market before the market starts developing different technique of developing software. And here's another problem. 80% of the project personal projects could not be delivering the delivered and released only two out of 10 pet project ever got released. So this is a starting point we have defined the problems. Now I want to mention that we probably we will progress in this talk towards the enterprise focus, due to several reasons. One, it's a lot of me to showcase a clear difference between user and customer. One enterprise markets quite often have much, much more money. The third one, the same technique can be applied for non enterprise market but it's likely similar way you can combine several of the steps so it's slightly more interesting to dive in the enterprise first. So we establish a clear problem. That's the problem that we want to solve and we now need to establish connection with the customer. So that we need to figure out for each particular industry we need we want to solve this problem for. If you don't know the industry that's fine just pick the broadest possible category for our example let's assume we're taking self driving car industries. So within that industry, let's assume that we have found two specific customers to whom we can talk to and confirm that they do have this problem that we want to solve for them. So usually the first point where people who doing more canonical developers starting pushing back and saying wait, we don't have a product, and you're already asking me to build the direct relationship with with external customers and the answer is yes. So the thing about this, the following way, if you cannot establish direct communication with the customer at this point and actually gets customer excited about the problem that you willing to be solving. Why you think that you will be able to establish relationship with the customer when you have a prototype. In fact, not many things will change prototype usually is not something that the customer can can can start using right away. So the interest level will not be higher. Therefore, a lot of the a lot of the products or a lot of the teams or companies using these things that they don't have a prototype as procrastination technique. Just to wait later that no one wants exactly the solution or no one actually has this problem later on when when so much money in time spent. The trick here to find several customers within the industries that can be more or less representative of the whole industry, you don't have to aim for this engagement for two biggest one. But someone who represented industry as a whole, and the same time would be willing to have a deep engagement with you. Let's assume you found the phone the folks and it's only you how but again let's assume now you have a deep engagement. Second step to identify restriction under which you working. The restriction usually imposed by government or by CEO or by someone who in this particular industry in this particular company can decide which standards you have to comply in order for the company to even look on your product. For example, it could be GDPR. And if we do solving a problem problem of task tracking, we very likely will have to store data that qualified under the data that GDPR governments or or HIPAA that actually have several requirements in the software that process store medical informations or other things. Now this is a very important point that often overlooked overlooked the key here that you don't have to build solution to the problem that better that any solution on the market right now. So what you actually have to build is a solution that's better than any other product that's passing these requirements. This is very important part because usually when, when people start doing start doing their products they looking on. All the competitors in the market and trying to compete with them, which is which is which is wrong. If the customers need to have to have GDPR approved products. They need to be better than any service that also support GDPR and that's usually much more subset of the products. Now, one of the last but not the least before actually talking with the user going to click your button is integrators. Imagine within the customer that will be in charge of taking your product and onboarding the whole company on your product. They will ultimately decide whether your product comply with the restriction that they have inside of the company. Imagine that you have a product that reduce project budget over on from 400% to 300% that we just mentioned that's the key problem for them. However, even though it's reduction it's improvement, it will take three years and five million stone board. And suddenly this team might start thinking and actually calculating if reduction reduction of budget over on from 400% to 300% is actually worse because now they have to invest years of years of work. And on top of that spend five millions. Now, they can enforce things like for example, Active Directory, let's assume that the company using Active Directory for the sake of authentication. When you never talk to this team and you delivered your product, you might not have this ability to might not need you might need to redesign this completely from ground up even to be able to integrate with Active Directory certification for your for your products. When you have established this direct communication you found all these restrictions, only now, you actually would be focusing on talking to the users that will be actually clicking buttons within your product, and figuring out the minimum viable solution for that users that satisfy all the requirements that we just have discussed. This is a very important point and I'm pretty sure that everyone, if you ever have worked in any big companies, you know this, this situation when you're looking at the tool, it doesn't matter I'm pretty sure there is a tool like that in any companies and you thinking, whoa, this tool is horrible. I know so many tools that are better, that are right now on the market. Why, why we're using this, why we're using this task tracker, why we're using this system for vacation tracking or whatever. This specific chart explained that because you are the user but you're not the customer, the customer should actually gave a green light might have a very specific requirements for the security of the tool that can be used within that particular enterprise that you are part of. Now, after going through all this process, and keep in mind we're trying to solve the problem of budget of runs and planning. The next step is to find the simplest possible solution that solve that problem. And this is a key part that also quite often overseen and I will speak later in more details why. For example, we can actually use Google Workspace Google Docs with Google Cloud platform that has the ability to implement identification through the active directory. Now together it's finally give you a platform where that you can use that is HIPAA compliant that is GDPR compliant to track tasks. You can also use a spreadsheet within Google Workspace where you can use the put a task where you can put assignee, and it actually will qualify as for everything that that is needed. Now I want to mention one thing in almost any groups that I ever have built we established the interesting pattern of reviewing designs because this is a part where you designing the solution with with your group. In many many cases, in the classical canonical development design doc will include discussion of the technical solution whether this particular long term solution will solve or will deliver required user experience. And usually proposing to to have a design doc that's specifically focused on these four aspects is the clear problem statement when engineering group actually designing something I want to learn if they do understand very clearly what the problem that they're solving prove that the problem is the main problem solution and finally prove that proposed solution is the simplest one. It's quite unusual to see a product on the market that got failed because they choose the wrong database, but it's quite often that the product have failed because they choose their own problem. And yet, on majority of the reviews we reviewing solution we reviewing all the time on the market, are we choosing the right database. Are we choosing the right system for sending the messages between between front and back and or different components of the system. Instead of your reviewing. Are we solving the main problem, or are we solving the main problem in the simplest possible way. What is this simplest possible possible way established and in our particular example turns out we don't even have to build anything we can use a workspace we can use a GCP service that integrates active directory. Now we can onboard user. As you can see there is no even quote unquote development phase here I always saying on board user because again in the processes that I would strapping I usually connecting directly developers who are developing solutions directly with the customers and hold them accountable to solve particular problem for particular customer, and if you have to build the service for that to solve the problem. So be it we will build the service, but time to time we might need to update dogs or we might need to build the just a solution time to time we just need to build the feature. And now after that you start cycling and repeating that after the first morning customer in our in our work and come to you and say okay how we can assign the task for the user. We will loop it again. Next question may be where I can see all my tasks and indeed Google Docs doesn't have the one page where you can go and see all the tasks that sign to you. At some point you will figure out that you're building completely custom UI using Google Docs as a back end and some point you will realize that you no longer need to use Google Docs in the back end fact this is a wrong back end if you now have your own site you redesigning back end from scratch, and you end up with something that looks like this. With this example, usually when I presenting it to folks that never work with me never see the success of user and development process don't know that the background, there are two reactions to the pushback or start using it in the wrong way. And I want to address both of them. First, why people think this is bad idea to do things with this framework. Now imagine the space of features that you can build you have this this this black screen right now is a space of features you have a starting point which is nothing you have we want which is a product that you can actually scale and sell on the market. In our example of moving to Google Docs first we actually moved away completely away from that product that we end up building we moved to Google Docs we build it then we build some task page that shows you all the tasks that you have. And at some point we actually arrived to be one. And when majority of the people looking at this, the first, the first question okay, why not to do this, we have time of the tons of the wasted work we we we're not going to use many of the things that would be will have to drop tons of them. So why not to design everything properly and directly go to be one as fast as we can. This is the most common question that you, you might be hearing a lot you also will try to start practicing your DP. However, if you will recall, and we actually honest with yourself and when you deliver your successful product and you will go back and start thinking where you wanted to go. You will realize that you would want you wanted to go somewhere like that. Your idea where we want should be was completely in different place. And after delivering it you would have to go back because suddenly you have learned that your customers absolutely need active directory sign in. And they cannot use it. But there was a design choices that prevent you to integrate with active directory sign in. So now you have to redesign tons of the things and go back. So, of course, people who ever been through this process with budget overruns with manual runs with processes when you kind of delivering we want and then spending a year or two fixing it to make sure that it's actually usable that it's actually successful product. Obviously, when they see this picture they will try to tell no no no no no no no. We have tons of this best practices that specifically prevent you from from doing this wrong wrong pattern of development you should go directly directly to be one less design everything correctly. And so on so on so on. There will be tons of the gatekeepers that will specifically emphasize that. So this is the first one and the reason and the reason why why people react to this is way because this scheme is optimizing learning. Even if you have some magical way of knowing where we want is so let's assume that you actually know precisely where we want is so you don't have this problem going to the wrong direction. That's what we saw on the previous slide. Even in this case, there is a time difference between you starting development and you actually reaching be one. And this means that the problem that exists on the market might not exist by the time you're delivering it. So even if you know where we want is you still need to go the route that allow you to have faster first delivery to your customers and start the boarding. And then they hearing quite often isn't this an over optimization one one particular customer. Are we taking and building something for just one customer that will be hard to generalize. Now, let's take up again the example of features so let's assume this is a space of the features that we can implement and this white circle is the set of the features that particular customer need in order to start using your solution into the problem. Now let's take second customer that the second customer and again set of features that you need in order that customer needs in order to start using your solution obviously sort of. If you have an amazing department that investigating the market very likely they can give you this. However, what will. I don't want to say fail you, but is this is the fact that each of the customer has these small nuanced requirements that while they are infrequent, they are blockers which are the customer to use it. So, again, active directory. What if only 10% of the market needed active directory yeah you can probably can say just 10% 30% let's move to V2 let's let's do it later. The same might be for requirements of supporting supporting GDPR, not because it's geographically location related, we can move it to V2. And you delivering product that covers 80% of the requirements but none of the customer can use it. What I found in the past and this rule of thumb work for the decade and I'm sure will work for the next decade as well. It's much simpler to build the product around one customer and end up having generalized solution, then to try to build generalized solution that actually can be used by at least one customer day zero. The second one is less likely, nevertheless, everyone trying to do so. I still not sure why. Now the second question is how about the long term projects. Oh, looks like what you're proposing some ways about taking small hacks putting them together releasing taking small hugs and and and repeat. This is not exactly the case. Let's take a timeline and let's see the same that you building three services for again solving three problems. In reality when you have a timeline you're building project one project to project three. You might find yourself that if you messed up it's least one of the project that takes more time and you have finished amount of the development team. So, yeah, you're still waiting to start project to UDP is about fixing this timeline and making look more like this, where you solve problem number one was just updating doc you found the hack. Then you found the hack for problem number two and you finally arrive at the problem that requires actually building a services. So if you do need to build the service you building them. This is a common misunderstanding problem doesn't mean the simplest possible way to solve the problem doesn't mean that the simplest way is always a day or week or quarters actually might be multi year effort and that would be a simplest possible way to solve the problem. In order to illustrate that I do need to provide the hierarchy of the problems, and I will do it quick because I quickly running out of time. On the lowest level you have a problem that customer facing with your product something like oh I don't like the color of the background. Now there is a middle level of the problem is problem that customers solving with your product. Why they even choosing your product. And finally, what I like to say is a problem behind the problem is in our case, 80% of the project missing the deadline that what they care about. And now is a subsequent they found that in order to fix that they need the issue tracker they don't have issue track. And you constantly moving in between this level you're solving the first level the smallest level when you run out of this problem you're taking the main problem from the next level and so on and so on. Now the main people, as I mentioned some of the people push back some of the people using in the wrong way, and only few practicing it right. So what does it mean to use your DP in the wrong way. First thing that I've seen the most. We have the amazing tool technology solution. Now let's find the problem that this solution is solving working backwards from the solution instead of working backwards from the problem I called it problem geniuses. Now, if you know about five problems the market that you need to show off, and you stick around them, you have a clarity. However, very smart people, they all like to do so. And I actually didn't know but I don't know why but every every really smart people in the market, they like to emphasize the problem out of the context. If you take any problem out of the context, you can usually sell it as a very important one because out of the context, yes, we all five problem at the key to the world, we all and we need to solve all five of them but again if you're taking any problem out of the context. In the example of the test structure let's say gun chart, we need a gun chart for task and yes this is very important problem you can find the customers who will tell you, we need a gun chart. But again, you shouldn't be solving gun charts visualization until you have active directory or if you have GDPR compliance, yeah that yeah that. But if you will take it out of the context. Now what happens. Imagine that you have a someone that that trying to push your work in towards solving this specific problem let's do a gun chart. Let's emphasize this feature. Time passes you have another team that delivered GDPR compliance later they delivered active directory solution. And now finally that team that has a proven track records of solving problem pragmatically will be the team that will solve the gun chart visualization. And now you have a genius who actually was predicting that we need a gun chart was telling you that we need to gun chart, but no one was listening to that person. And now you have completely another team that delivering gun chart visualization. This quite often makes people unhappy and you need to be aware of this and preempted by describing how you doing your prioritization, because this might lead to a very interesting dynamic in the teams, because people kind of saw that this needs to be done up front but nevertheless they might not be the one that end up doing it. And so on so on. Now the second one I put the word user my my goal and therefore now it's user re-empt. You can again say that user will be able to see the dependency we have a gun chart. It doesn't mean this user re-empted because as we saw the user has completely different beast of problem statement right now. Ignoring class mile integration. This is one of the important parts where you develop the product but you're not onboarding the customers. This is a key difference between UGP normal execution and normal execution is just delivering the product according to the spec you've done onboarding the customers include this last mile integration well you will encounter you will discover additional problems that you need to solve as you progress. Finally, using different audience for verifying the problem and delivering solution to it's one thing to ask a student which problem you have when you when you developing deep learning solutions and other things to deliver it and try to sell to a big enterprises, you need to have the same audience. I'm going to skip last part because a way over time. But if I would be to give one advice how to start revisits your tasks and make them a problem list. Never have a task list have a problem list figuring out how to solve them later. Connect your developers directly with the customers for whom they solving the problem. This is very specific to any org that they are built each software developer I see always connected directly with a customer and expectations for the AC. Solve this particular problem for this particular customer. And yes, if it requires to be able to service we will be able to service. I'm going to skip the cop and go directly to question time for system there is several small things, but we unfortunately don't have time so thank you. There is a link for Facebook Facebook group specifically dedicated to GDP when you can read more, ask me questions. Since it's five I am on my side, I apologize I probably wouldn't be able to hang up by a lot. Any questions that we might have and to be fair, I'm not sure where to check them. Okay, Slava, thank you so much for your time, especially at such an uncomfortable morning hour. So thanks very much for that. I would like to ask you, Slava, I guess this methodology of yours is primarily based upon your own experience and what you've seen with your own eyes over your career, but have you also been influenced by other people's work? So who would they be? Oh, of course, of course. So, mostly, it's, sorry, it takes me a moment to recall the authors, but I would highly suggest to read the books, antifragility, I would highly suggest to read the book. Ooh, effectively the same author about, oh, and of course, Black Swan. I forgot, I forgot the author, I really heard of all of his names, but that idea of the fact that events with low likelihood has a disproportional impact on our life was the key idea here because the whole idea to prioritize learning and move as fast as you can, because the longer time between you start and you're delivering, the more chances that there will be a Black Swan that completely ruined your plan. Doesn't matter how good the plan is. And that's actually a foundation on top of which the whole framework got created. How about the work of Christensen, for example, and his jobs to be done framework? You're familiar with that? Actually, actually, I only heard and read several articles, but no, and thank you. Thank you for pointing out. I definitely will check it out. Much of what you were saying reminded me of that. In particular, his talk about his work with McDonald's when he was brought in as a consultant, and they had a specific challenge for him was that they wanted to sell more milkshakes, and they had tried lots of things in the past, like, for example, changing the flavors, changing the size, obviously changing the prices, merchandising, marketing plans, all kinds of things. Nothing had really boosted milkshake sales. And when Christensen came in, he asked the very question that you did to start with the problem. So why are people actually buying milkshakes? What is the purpose of the milkshake? Or what is the job that the milkshake is doing? It's the way he defines it. And there were some assumptions that, of course, milkshakes are drunk by kids. Families are going in and buying milkshakes for their kids. But in fact, what he discovered is that people were often buying milkshakes in the morning as something that was nourishing and that they could put in the car and it wouldn't spill. And so actually, the problem that the milkshake was solving was very different to the one that had been assumed. So I could see how that was tying in with what you were talking about anyway. Absolutely. This is the key problem in people starting with a solution and trying to find the problem. And obviously that never works well instead of actually finally discover what the key problem, what the main problem, and start doing that. Absolutely. That reminds me also of a joke where there was a man driving. I think he wanted to get to the airport and he stops and asks for directions. And the person gives him directions by saying, well, if I were you, I wouldn't start from here. That's what came to my mind as you were showing this very nice chart with the start leading up to the V1. So Slava, thank you so much for your time. We are actually getting very nervous ourselves because we are overriding by 10 minutes and we have lunch. We have very hungry stomachs here in Spain. Lunch is absolutely sacred. So people are getting very stressed here. I wish you all the best. Thank you so much for this wonderful talk and for your insights. And to the rest of us.