We prototype the code. Lecture on FrontTalks
Happy holidays, friends! In preparation for the start of the new working year, we are completing a series of materials from the FrontTalks 2018 conference. This is a lecture by Andrei Salomatin filipovskii_off , a developer from Polychops. Andrei proposes a balanced approach to prototyping: to turn from artisans who carry out orders into researchers into learning to work with uncertainty and, perhaps, to keep their sanity even without a clear plan.
- Hello! I would like to talk about prototyping: why do prototypes, what we get from this and how to do them, by examples.
I'll start with a little story. In 2012, I joined this startup, a wonderful deer. We had something like an advertising platform, I came as a Java developer. It is clear that large volumes of traffic, interesting tasks, the team is just freaky - everything is fine. We have been working for about eight months, with our heads on the keyboard, we are doing very cool features, we quickly turn everything around. But in 2013, the deer goes up with its hooves.
What happened? I thought about it for a very long time, afterwards I went to work as a front-end and back-end developer for different companies, then I was a team leader, then a product manager. He worked in startups, and in outsourcing companies, in large enterprises. Mainly focused on startups.
I also did some of these projects. I was lucky to work on MoscowJS, Frontend Union Conf and RadioJS. Maybe we overlap with you somewhere. Now I am doing Code Podcast, a podcast in English about general programming concepts, and Polychops, a project for musicians that works in a browser and helps you practice with the instrument, get more time and practice.
What happened to HeyMoose? The company had very smart people who are now working as senior developers at Microsoft or have become a service station. We did what we did best: we solved complex technical problems quickly and interestingly. But something went wrong.
And something goes wrong with a lot of companies, especially startups. Startups mostly burn out for two reasons: either they don’t understand the product, they miss something with the product, or they run out of money. They often run out of money because they are looking for a product and cannot find it for a long time.
But why is custom development in outsourcing companies not closing? Or why aren't large enterprises closed? It seems they are slower. As a rule, teams there are at least less motivated. What is the difference? The mechanisms of work are the same: in custom development, we write TK or ask TZ to customers, they paint it, give it to us, we make layouts, code, fiddle - the same process. What is in a startup, that in large companies there can be ejail practices. Everything is the same. So why do startups burn out?
Let's first imagine a hypothetical situation: the product manager comes to us and asks if we can forget the metronome, which will work in the browser, make a sound with a periodic interval and synchronous visualization, so that different lights sparkle in tempo with the metronome. And so that all this is accurate, regardless of what is happening on the computer, other processes, etc.
Who is 100% sure that we can do this by using the browser and the browser API? Not a single person. Who is 80% sure that we can probably do this? 3-4 hands. Who is sure 50 to 50? Most. Who is sure that we can not do it at all? Decently.
The following example. Suppose we are working in another company on a mobile bank. We think more about the product and think that we need to grow the number of users who use our mobile bank. We came up with a feature: now the user can share a purchase or account replenishment in social networks. A money came to him, he is like that on Facebook - look, I got a money. Do you think this will help attract more users? Who is 100% sure of this? No one. Who is 100% sure that this will not help us in any way? Two or three hands. The rest is somewhere in between.
And the last example. We do cloud service, we open our company. The cloud service will collect logs from projects, from the frontend and backend in small and medium business, aggregate them, machine learning, AI and all that. We will sell it. Who is sure that this is a 100% success or a 100% loss? A couple of people.
There is only one correct answer to all these three questions: "probably." In the answers to some of the questions, we are 50-80% sure. A lot depends on the context, on execution. The same metronome with visualization - I worked on it, it cannot be made so that it works in all contexts: for example, with Bluetooth headphones. But you can do for two or three generalized cases. In my understanding, this is “probably” - and there is a reason for which startups are closing, for which HeyMoose went up with its hooves. Maybe we will do something good, or maybe we just waste time. And we have no way of understanding how confident we are of what we are doing.
A bit of theory. What is the difference between customized development and startup? The difference is in context. We are in this context of uncertainty, we have the probability of success and the likelihood of failure. It’s like if we try to use the same methods and practices when we run on the earth and when we run in space without gravity. It would seem that we are running, but nothing happens. What are we doing wrong?
This uncertainty comes from three main directions. It comes from the market - because we do not know clearly what other companies are engaged in the aggregation of logs. Maybe this market is already captured by someone? What is the demographics on the market, what are the prices? Uncertainty can come from a product. We do not know what the problem is with our client and how to solve it. This is from the example of a mobile bank. We seem to have an understanding, but we are not sure whether users have this problem and how to solve it.
And there are issues of implementation. An example with a metronome. We do not know 100%, it is theoretically possible or not.
Or another example. We do not have a problem with the market or product if we invent a cure for cancer, which is just a pill - taken and healthy. But there is a huge amount of uncertainty about how to implement this pill. We are in the fog of war, but at the same time we behave as if fog does not exist, because we have the same principles that work in custom development. We simply move them into our context of uncertainty.
We pretend that this fog does not exist, there is no uncertainty. And we are trying to predict the future. When I started working as a product manager, I was amazed after the development process how much product product manager should be doing fortune-telling. When you report to the director or to someone else, you should look confident, should say that we will do it or that, take the market by September, everything will be hurt. All such - well done, all thought out. Although, in fact, I understand that there is nothing of this, I am just wondering about the cards and trying to look confident. We do not have a work culture with uncertainty, with probability. Plus, to look like experts, we need to constantly strive for reputation, to be confident, to talk about what we have to do, instead of what we have to check, or about what we are not sure.
We, especially developers, still have a tendency to think about what we know, understand and can control. As developers, we love to plan architectures, think about the future, don't repeat yourself, pattern programming and all that.
Designers are also sick of it. They like to think about the future, make perfect layouts, etc. We are experts, although in reality we may need to become someone else.
How do we deal with uncertainty? What methods of struggle do we have? The first method is the most important - to put all the cards on the table, to recognize that we are not sure of any question. We may be 50% sure, but to test the hypothesis, we need two days. Then why don't we just go and test a hypothesis? We may be 90% sure that the product will soar, but we need eight months to import this product and test the hypothesis. Will we just go and check? Or maybe think about how to reduce uncertainty to 90 or 100%?
This is the first way. You need to hang a badge of this uncertainty, say how big or small it is, how much work is needed to resolve it, etc.
The second way that humankind has been working for the last 500 years is a scientific method. It is not perfect, there are some bugs there, but this is the best mechanism we have at the moment. The scientific method says: to resolve uncertainty, we first guess, invent a hypothesis based on our conclusions, then we think up an experiment that confirms or disproves this hypothesis, then we start the experiment, look at the numbers and understand whether our hypothesis is true.
In development, especially in the frontend, we have a unique opportunity to run these experiments at very high speeds. This method is called prototyping. Prototype - a way to deal with uncertainty. This is not an invention of the product, not the creation of something perfect that users will use. This is an opportunity to learn more about the world around us. We will know this by creating illusions. The prototype is an illusion, not a product. We kind of build the scenery on the theater stage or on the stage for making movies. This is just an illusion. The goal is to reduce uncertainty.
Prototyping works in two contexts: in the context of implementation, when we do not know theoretically in terms of the API, whether it is possible or not, and in the context of the product, when we do not know what problem the user has and how to solve it. Prototyping doesn’t work much in market research - Excel exists for this.
The point is that when we are working on a prototype, we need to abandon the way to think like experts. We need to forget these programming patterns, we need to forget how we make perfect products - because we don’t make them. We are trying to do research, become scientists.
So instead of thinking through architectures, we need to find a way to iterate very quickly. Instead of approximating and thinking about the future, you need to think about how to crank it now, in a short time.
Instead of thinking about my reputation, what will happen if I say that I am sure or not sure ... Instead, you need to give up your reputation and become newcomers. Dunce. How do we do it? What specific things can we apply to become newcomers?
The first and most important point is feedback. Even before we plan our prototype, draw a layout or something else, we think about who we will show these mockups or prototype to, how we will test the product, what we are trying to get from this experiment. The shorter this feedback loop, the better for us.
An example from personal life. Productive Mobile is a company I have recently been working in as a startup; they have come up with a platform that allows you to make a mobile application from a website in such a drag and drop way. We sold it to large corporations, because they have products like SharePoint or SAP that cannot be used on a mobile phone, pinch zoom, that's all. We offered them an option: you can make a mobile application based on a real site, say, in a week. The problem is that we had a very strong development team and a very long sales cycle. When you sell a Daimler-size or BMW-sized product, the sales cycle is at least 8 months. During this period, a team of talented developers can cut a lot.
What have we done and what has helped us? We created a mini-team of users within our company who used the product. And the number of features that we began to make and release has decreased. But at the same time, the quality of features has increased n times. And when we came to our user and said that we have such and such a platform, let's try it, for some reason emergency situations ceased to arise when we are like this: we didn’t think about it, this is something new. We began to make features that actually began to bring results. This is due to the fact that we simply reduced the feedback loop.
An example with a metronome, the Polychops project I'm working on now. First of all, we created in a short time a video that was posted somewhere on the Internet. In it we asked how this concept is to you, what do you think about it. According to reviews, we not only appreciated how interesting it is. We also received leads that we could communicate with, who could be invited to make phone calls, interviews, give them a prototype, etc.
We try to get feedback very early. And not just any feedback, but qualitative, not quantitative.
What is the difference? Quantitative feedback is AB testing, binary results, when either Option A or Option B is winning. That's all we can get from quantitative cycles. It is as if we are in a dark room and nothing is visible, but we have a laser pointer. From time to time we shine it in the corners, we highlight some points and we understand what is in them.
What would we like instead? A user who describes this dark room, who knows it much better than we do. We need high-quality interviews, calls, something else to get information from users in expanded form.
An example of a company that relies heavily on quantity feedback is Booking.com. In my opinion, there is something to work on their website.
One of the prototypes of the project I'm working on is a feature with which a person can record himself and at the same time reproduce himself the way he played under the metronome - good or bad. We invented this feature because we asked for high-quality feedback from people who tested the prototype. One of the people wrote that everything is great, I like the part with the metronome, but it would be cool to export this track with the metronome as a sound track. We are - it is illogical, why? He says: “I insert it into my program for working with music, then I record myself over it, and then I can hear whether I get into a rhythm or not.” We are - this is brilliant.
But instead of just exporting, we decided to test the hypothesis. We talked with people, asked if they listened to themselves at all when they were playing with the metronome. Many people said that yes, we often have one program - a metronome, another program - a voice recorder on the phone or somewhere else, we just record and listen to ourselves. We are - we are programmers, we can connect it in one application. As a result, we got this feature. We would never have guessed it if we simply performed the AV testing.
The most important part of the prototype is the interface. In a global sense. If we have some kind of service with some kind of API, then our interface is an API, then what the user interacts with. If we are working on a metronome, our interface is the visual part and sound. If we work simply on a mobile application, our interface is a visual interface. In the prototype, the interface is the only important part. Everything else we can forge, replaced by plush.
Another example from Productive Mobile. At some point, we decided to rewrite the internal API in this mobile application’s drag and drop editor. The API allows JS to revive some difficult parts of your mobile application. As a product manager, I could just write a specification and give it to the developers. I am sure that in a maximum of a month everything would be ready, tested and wonderful. But we decided to try another way. We just documented the API that we had in our head, on paper, and gave this paper to the people who were involved in the creation of mobile applications. They asked: if you had such an API, how would you in theory build your applications?
They took another paper, they checked everything on it. Without implementation. The API did not work at this stage. So we cranked 5–10 iterations before we realized what form API should be. We saved a lot of time on implementation. Already after we understood the form, we documented the specification, and we have inserted it. Everything was great.
Another example from the metronome. The very first idea for Polychops is a metronome for working with polyrhythms. We made the first prototype in about 20 minutes and wrote in Flash. That's how he looked. There was even a sound. We just went and showed it to fellow musicians, asked - how do you even? This is the only important thing.
Then we did a real metronome in the browser, it all worked, animation, blah blah, everything is beautiful.
But it took about a month and a half, and the previous prototype took 20 minutes.
Focus on the interface.
To save time, use a design system. A quick example from Polychops.
On the left, the initial prototype, where we just have all the buttons, we have thought through the whole interaction ourselves. After some time we decided that we needed menus, navigation, dropdowns, something else. We could sit down and think over with designers every dropdown, every button, but this is a huge amount of time, which in principle we do not need to spend. Therefore, we took a ready-made design system, took a material-design, everything is perfectly documented from them. Screwed, all is well.
Steal. Steal not from competitors. Do not steal from competitors. If something works for competitors, you do not need to check it, you just need to copy it. Steal from products that are parallel to yours, which are not exactly your product, but something similar.
Another example from Polychops. The recording interface is almost muffled from existing audio software such as Logic. Naturally, we have greatly simplified it, but people already understand how to use Logic, which means they can understand how to use Polychops.
In the process of prototyping you go into debt. For example, do not refactor. I will say very contradictory things.
My rule is this: until I copied a piece of code at least three times, I can't stand anything in abstraction. Because what seems the same at first glance may be different afterwards.
I will excavate the component into three parts, see how it will evolve. In the end, maybe these are three different components. Or maybe this is one abstraction, but I’ll understand clearly what form this abstraction is, what its parameters are, etc.
Tests are a specification. When we prototype, we look for the specification, we have no opportunity to write tests. We also do not refactor, so we forget about the tests.
One thing that is worth abstracting is frameworks and libraries. But here it is for your taste and color. For example, React is very difficult to abstract. If you write on React, everything will be on React. But ideally to write in such a way that if you, for example, want to switch from Redux to Apollo, you will not have any problems. This will help the division into smart and stupid components. Abstract libraries and frameworks.
And - do not go bankrupt. Ultimately, all that we do with technical debt is lending time from the future of ourselves. The meaning of this duty is to test some hypothesis and understand in which direction we are going. But as soon as we understand the direction, we need to go back, and either rewrite everything, or rewrite individual pieces, abstract, cover with tests. It is important to explain this to the product manager, director, etc. When you show something that glitters and works great, they are - everything, tomorrow we will start in production. From the very beginning, even before we started working on a prototype, explain that this is a prototype, just a decoration.
So, we have a context of certainty and uncertainty, probability. And it does not make sense to work on the same principles in both contexts. It is important to indicate how much certainty we have. It is important to designate the number - probably based on the project, task or company.
When we are in the context of certainty, we have an implementation mode. We make the best product we can make. We are experts. And when we are in the context of probability or uncertainty, then we are in research mode. This is a different mode. He has other tasks. The task of the study is to find the specification, resolve the uncertainty. To do this, we need to become beginners, open the mind.
What are the results? “So what?” - this was one of the complaints when we drove the report. What did it lead to?
Results are not important. The decision process in the context of uncertainty means much more than the result. This is the nature of probability. If we have a 10% chance that we will be successful, and we just fall into that 10%, and we say that we knew the result from the very beginning - then we should not work that way.
Or another situation. Maybe we are 90% sure that this is the right decision. Then we launch it in production and we understand that nobody needs it, we are in this 10%. Decision making process - it is important for us to learn how to manage it, learn how to improve it. The results will come.
Specific results in the products I have been working on recently. In Productive Mobile, one of the most important results is that we did not make features. With a huge number of features, we decided after a quick prototype that it was garbage, we don’t understand something, we don’t know, or it just doesn’t work for users.
Here is one of the specific examples. Almost all applications in Moldova are written in React, most of them in React Native. But the application we are generating is React, not React Native. At some point we are: "Damn, it would be cool to rewrite everything to React Native, we have performance, applications will be cool." As developers, we were interested.
What we decided? We decided to do an experiment. Rewrote, maybe 10 main components in the system on React Native and tried to see how the final mobile applications look and behave with these React Native fragments. It turned out that we spent about two or three weeks on this, perspire, be healthy, and there are very few benefits. We also realized that we will support this code, and this is very difficult, and in fact it is not “write once - use anywhere”. In fact, for Android and iOS, you need to write separate fragments. This is not ideal and in our case it would not work exactly. Or we would spend, maybe, a year to rewrite everything and then still support it. For me, the main result is that we did not do something, did not spend time on something. And time is money.
Well, and now, only in November last year, the Republic of Moldova raised a large round of investment ... But why talk about money?
Polychops started two or three months ago, it’s too early to talk about the results. For me, personal pride is that we have just started, and we already have people who have tried the application, they are interested, they already use it. We communicate with these people for two or three months, as much as working on a prototype. And they offered a lot of features. For me, this is the most important moment.
I hope you try it yourself too. Maybe you do not work in a startup, but your company has projects in which there is uncertainty. It is important for me that you think about it, talk with your team, with your managers, think about how to work with uncertainty, how to build your processes, improve the decision-making process, and stop spending time on things that are not needed.
If you manage all this and you make a great product, I hope at some point I will be one of your very happy users. Thank.
Quantitative feedback is AB testing, binary results, when either Option A or Option B is winning. That's all we can get from quantitative cycles. It is as if we are in a dark room and nothing is visible, but we have a laser pointer. From time to time we shine it in the corners, we highlight some points and we understand what is in them.
What would we like instead? A user who describes this dark room, who knows it much better than we do.
- Hello! I would like to talk about prototyping: why do prototypes, what we get from this and how to do them, by examples.
I'll start with a little story. In 2012, I joined this startup, a wonderful deer. We had something like an advertising platform, I came as a Java developer. It is clear that large volumes of traffic, interesting tasks, the team is just freaky - everything is fine. We have been working for about eight months, with our heads on the keyboard, we are doing very cool features, we quickly turn everything around. But in 2013, the deer goes up with its hooves.
What happened? I thought about it for a very long time, afterwards I went to work as a front-end and back-end developer for different companies, then I was a team leader, then a product manager. He worked in startups, and in outsourcing companies, in large enterprises. Mainly focused on startups.
I also did some of these projects. I was lucky to work on MoscowJS, Frontend Union Conf and RadioJS. Maybe we overlap with you somewhere. Now I am doing Code Podcast, a podcast in English about general programming concepts, and Polychops, a project for musicians that works in a browser and helps you practice with the instrument, get more time and practice.
What happened to HeyMoose? The company had very smart people who are now working as senior developers at Microsoft or have become a service station. We did what we did best: we solved complex technical problems quickly and interestingly. But something went wrong.
And something goes wrong with a lot of companies, especially startups. Startups mostly burn out for two reasons: either they don’t understand the product, they miss something with the product, or they run out of money. They often run out of money because they are looking for a product and cannot find it for a long time.
But why is custom development in outsourcing companies not closing? Or why aren't large enterprises closed? It seems they are slower. As a rule, teams there are at least less motivated. What is the difference? The mechanisms of work are the same: in custom development, we write TK or ask TZ to customers, they paint it, give it to us, we make layouts, code, fiddle - the same process. What is in a startup, that in large companies there can be ejail practices. Everything is the same. So why do startups burn out?
Let's first imagine a hypothetical situation: the product manager comes to us and asks if we can forget the metronome, which will work in the browser, make a sound with a periodic interval and synchronous visualization, so that different lights sparkle in tempo with the metronome. And so that all this is accurate, regardless of what is happening on the computer, other processes, etc.
Who is 100% sure that we can do this by using the browser and the browser API? Not a single person. Who is 80% sure that we can probably do this? 3-4 hands. Who is sure 50 to 50? Most. Who is sure that we can not do it at all? Decently.
The following example. Suppose we are working in another company on a mobile bank. We think more about the product and think that we need to grow the number of users who use our mobile bank. We came up with a feature: now the user can share a purchase or account replenishment in social networks. A money came to him, he is like that on Facebook - look, I got a money. Do you think this will help attract more users? Who is 100% sure of this? No one. Who is 100% sure that this will not help us in any way? Two or three hands. The rest is somewhere in between.
And the last example. We do cloud service, we open our company. The cloud service will collect logs from projects, from the frontend and backend in small and medium business, aggregate them, machine learning, AI and all that. We will sell it. Who is sure that this is a 100% success or a 100% loss? A couple of people.
There is only one correct answer to all these three questions: "probably." In the answers to some of the questions, we are 50-80% sure. A lot depends on the context, on execution. The same metronome with visualization - I worked on it, it cannot be made so that it works in all contexts: for example, with Bluetooth headphones. But you can do for two or three generalized cases. In my understanding, this is “probably” - and there is a reason for which startups are closing, for which HeyMoose went up with its hooves. Maybe we will do something good, or maybe we just waste time. And we have no way of understanding how confident we are of what we are doing.
A bit of theory. What is the difference between customized development and startup? The difference is in context. We are in this context of uncertainty, we have the probability of success and the likelihood of failure. It’s like if we try to use the same methods and practices when we run on the earth and when we run in space without gravity. It would seem that we are running, but nothing happens. What are we doing wrong?
This uncertainty comes from three main directions. It comes from the market - because we do not know clearly what other companies are engaged in the aggregation of logs. Maybe this market is already captured by someone? What is the demographics on the market, what are the prices? Uncertainty can come from a product. We do not know what the problem is with our client and how to solve it. This is from the example of a mobile bank. We seem to have an understanding, but we are not sure whether users have this problem and how to solve it.
And there are issues of implementation. An example with a metronome. We do not know 100%, it is theoretically possible or not.
Or another example. We do not have a problem with the market or product if we invent a cure for cancer, which is just a pill - taken and healthy. But there is a huge amount of uncertainty about how to implement this pill. We are in the fog of war, but at the same time we behave as if fog does not exist, because we have the same principles that work in custom development. We simply move them into our context of uncertainty.
We pretend that this fog does not exist, there is no uncertainty. And we are trying to predict the future. When I started working as a product manager, I was amazed after the development process how much product product manager should be doing fortune-telling. When you report to the director or to someone else, you should look confident, should say that we will do it or that, take the market by September, everything will be hurt. All such - well done, all thought out. Although, in fact, I understand that there is nothing of this, I am just wondering about the cards and trying to look confident. We do not have a work culture with uncertainty, with probability. Plus, to look like experts, we need to constantly strive for reputation, to be confident, to talk about what we have to do, instead of what we have to check, or about what we are not sure.
We, especially developers, still have a tendency to think about what we know, understand and can control. As developers, we love to plan architectures, think about the future, don't repeat yourself, pattern programming and all that.
Designers are also sick of it. They like to think about the future, make perfect layouts, etc. We are experts, although in reality we may need to become someone else.
How do we deal with uncertainty? What methods of struggle do we have? The first method is the most important - to put all the cards on the table, to recognize that we are not sure of any question. We may be 50% sure, but to test the hypothesis, we need two days. Then why don't we just go and test a hypothesis? We may be 90% sure that the product will soar, but we need eight months to import this product and test the hypothesis. Will we just go and check? Or maybe think about how to reduce uncertainty to 90 or 100%?
This is the first way. You need to hang a badge of this uncertainty, say how big or small it is, how much work is needed to resolve it, etc.
The second way that humankind has been working for the last 500 years is a scientific method. It is not perfect, there are some bugs there, but this is the best mechanism we have at the moment. The scientific method says: to resolve uncertainty, we first guess, invent a hypothesis based on our conclusions, then we think up an experiment that confirms or disproves this hypothesis, then we start the experiment, look at the numbers and understand whether our hypothesis is true.
In development, especially in the frontend, we have a unique opportunity to run these experiments at very high speeds. This method is called prototyping. Prototype - a way to deal with uncertainty. This is not an invention of the product, not the creation of something perfect that users will use. This is an opportunity to learn more about the world around us. We will know this by creating illusions. The prototype is an illusion, not a product. We kind of build the scenery on the theater stage or on the stage for making movies. This is just an illusion. The goal is to reduce uncertainty.
Prototyping works in two contexts: in the context of implementation, when we do not know theoretically in terms of the API, whether it is possible or not, and in the context of the product, when we do not know what problem the user has and how to solve it. Prototyping doesn’t work much in market research - Excel exists for this.
The point is that when we are working on a prototype, we need to abandon the way to think like experts. We need to forget these programming patterns, we need to forget how we make perfect products - because we don’t make them. We are trying to do research, become scientists.
So instead of thinking through architectures, we need to find a way to iterate very quickly. Instead of approximating and thinking about the future, you need to think about how to crank it now, in a short time.
Instead of thinking about my reputation, what will happen if I say that I am sure or not sure ... Instead, you need to give up your reputation and become newcomers. Dunce. How do we do it? What specific things can we apply to become newcomers?
The first and most important point is feedback. Even before we plan our prototype, draw a layout or something else, we think about who we will show these mockups or prototype to, how we will test the product, what we are trying to get from this experiment. The shorter this feedback loop, the better for us.
An example from personal life. Productive Mobile is a company I have recently been working in as a startup; they have come up with a platform that allows you to make a mobile application from a website in such a drag and drop way. We sold it to large corporations, because they have products like SharePoint or SAP that cannot be used on a mobile phone, pinch zoom, that's all. We offered them an option: you can make a mobile application based on a real site, say, in a week. The problem is that we had a very strong development team and a very long sales cycle. When you sell a Daimler-size or BMW-sized product, the sales cycle is at least 8 months. During this period, a team of talented developers can cut a lot.
What have we done and what has helped us? We created a mini-team of users within our company who used the product. And the number of features that we began to make and release has decreased. But at the same time, the quality of features has increased n times. And when we came to our user and said that we have such and such a platform, let's try it, for some reason emergency situations ceased to arise when we are like this: we didn’t think about it, this is something new. We began to make features that actually began to bring results. This is due to the fact that we simply reduced the feedback loop.
An example with a metronome, the Polychops project I'm working on now. First of all, we created in a short time a video that was posted somewhere on the Internet. In it we asked how this concept is to you, what do you think about it. According to reviews, we not only appreciated how interesting it is. We also received leads that we could communicate with, who could be invited to make phone calls, interviews, give them a prototype, etc.
We try to get feedback very early. And not just any feedback, but qualitative, not quantitative.
What is the difference? Quantitative feedback is AB testing, binary results, when either Option A or Option B is winning. That's all we can get from quantitative cycles. It is as if we are in a dark room and nothing is visible, but we have a laser pointer. From time to time we shine it in the corners, we highlight some points and we understand what is in them.
What would we like instead? A user who describes this dark room, who knows it much better than we do. We need high-quality interviews, calls, something else to get information from users in expanded form.
An example of a company that relies heavily on quantity feedback is Booking.com. In my opinion, there is something to work on their website.
One of the prototypes of the project I'm working on is a feature with which a person can record himself and at the same time reproduce himself the way he played under the metronome - good or bad. We invented this feature because we asked for high-quality feedback from people who tested the prototype. One of the people wrote that everything is great, I like the part with the metronome, but it would be cool to export this track with the metronome as a sound track. We are - it is illogical, why? He says: “I insert it into my program for working with music, then I record myself over it, and then I can hear whether I get into a rhythm or not.” We are - this is brilliant.
But instead of just exporting, we decided to test the hypothesis. We talked with people, asked if they listened to themselves at all when they were playing with the metronome. Many people said that yes, we often have one program - a metronome, another program - a voice recorder on the phone or somewhere else, we just record and listen to ourselves. We are - we are programmers, we can connect it in one application. As a result, we got this feature. We would never have guessed it if we simply performed the AV testing.
The most important part of the prototype is the interface. In a global sense. If we have some kind of service with some kind of API, then our interface is an API, then what the user interacts with. If we are working on a metronome, our interface is the visual part and sound. If we work simply on a mobile application, our interface is a visual interface. In the prototype, the interface is the only important part. Everything else we can forge, replaced by plush.
Another example from Productive Mobile. At some point, we decided to rewrite the internal API in this mobile application’s drag and drop editor. The API allows JS to revive some difficult parts of your mobile application. As a product manager, I could just write a specification and give it to the developers. I am sure that in a maximum of a month everything would be ready, tested and wonderful. But we decided to try another way. We just documented the API that we had in our head, on paper, and gave this paper to the people who were involved in the creation of mobile applications. They asked: if you had such an API, how would you in theory build your applications?
They took another paper, they checked everything on it. Without implementation. The API did not work at this stage. So we cranked 5–10 iterations before we realized what form API should be. We saved a lot of time on implementation. Already after we understood the form, we documented the specification, and we have inserted it. Everything was great.
Another example from the metronome. The very first idea for Polychops is a metronome for working with polyrhythms. We made the first prototype in about 20 minutes and wrote in Flash. That's how he looked. There was even a sound. We just went and showed it to fellow musicians, asked - how do you even? This is the only important thing.
Then we did a real metronome in the browser, it all worked, animation, blah blah, everything is beautiful.
Video with metronome Polychops
But it took about a month and a half, and the previous prototype took 20 minutes.
Focus on the interface.
To save time, use a design system. A quick example from Polychops.
On the left, the initial prototype, where we just have all the buttons, we have thought through the whole interaction ourselves. After some time we decided that we needed menus, navigation, dropdowns, something else. We could sit down and think over with designers every dropdown, every button, but this is a huge amount of time, which in principle we do not need to spend. Therefore, we took a ready-made design system, took a material-design, everything is perfectly documented from them. Screwed, all is well.
Steal. Steal not from competitors. Do not steal from competitors. If something works for competitors, you do not need to check it, you just need to copy it. Steal from products that are parallel to yours, which are not exactly your product, but something similar.
Another example from Polychops. The recording interface is almost muffled from existing audio software such as Logic. Naturally, we have greatly simplified it, but people already understand how to use Logic, which means they can understand how to use Polychops.
In the process of prototyping you go into debt. For example, do not refactor. I will say very contradictory things.
My rule is this: until I copied a piece of code at least three times, I can't stand anything in abstraction. Because what seems the same at first glance may be different afterwards.
I will excavate the component into three parts, see how it will evolve. In the end, maybe these are three different components. Or maybe this is one abstraction, but I’ll understand clearly what form this abstraction is, what its parameters are, etc.
Tests are a specification. When we prototype, we look for the specification, we have no opportunity to write tests. We also do not refactor, so we forget about the tests.
One thing that is worth abstracting is frameworks and libraries. But here it is for your taste and color. For example, React is very difficult to abstract. If you write on React, everything will be on React. But ideally to write in such a way that if you, for example, want to switch from Redux to Apollo, you will not have any problems. This will help the division into smart and stupid components. Abstract libraries and frameworks.
And - do not go bankrupt. Ultimately, all that we do with technical debt is lending time from the future of ourselves. The meaning of this duty is to test some hypothesis and understand in which direction we are going. But as soon as we understand the direction, we need to go back, and either rewrite everything, or rewrite individual pieces, abstract, cover with tests. It is important to explain this to the product manager, director, etc. When you show something that glitters and works great, they are - everything, tomorrow we will start in production. From the very beginning, even before we started working on a prototype, explain that this is a prototype, just a decoration.
So, we have a context of certainty and uncertainty, probability. And it does not make sense to work on the same principles in both contexts. It is important to indicate how much certainty we have. It is important to designate the number - probably based on the project, task or company.
When we are in the context of certainty, we have an implementation mode. We make the best product we can make. We are experts. And when we are in the context of probability or uncertainty, then we are in research mode. This is a different mode. He has other tasks. The task of the study is to find the specification, resolve the uncertainty. To do this, we need to become beginners, open the mind.
What are the results? “So what?” - this was one of the complaints when we drove the report. What did it lead to?
Results are not important. The decision process in the context of uncertainty means much more than the result. This is the nature of probability. If we have a 10% chance that we will be successful, and we just fall into that 10%, and we say that we knew the result from the very beginning - then we should not work that way.
Or another situation. Maybe we are 90% sure that this is the right decision. Then we launch it in production and we understand that nobody needs it, we are in this 10%. Decision making process - it is important for us to learn how to manage it, learn how to improve it. The results will come.
Specific results in the products I have been working on recently. In Productive Mobile, one of the most important results is that we did not make features. With a huge number of features, we decided after a quick prototype that it was garbage, we don’t understand something, we don’t know, or it just doesn’t work for users.
Here is one of the specific examples. Almost all applications in Moldova are written in React, most of them in React Native. But the application we are generating is React, not React Native. At some point we are: "Damn, it would be cool to rewrite everything to React Native, we have performance, applications will be cool." As developers, we were interested.
What we decided? We decided to do an experiment. Rewrote, maybe 10 main components in the system on React Native and tried to see how the final mobile applications look and behave with these React Native fragments. It turned out that we spent about two or three weeks on this, perspire, be healthy, and there are very few benefits. We also realized that we will support this code, and this is very difficult, and in fact it is not “write once - use anywhere”. In fact, for Android and iOS, you need to write separate fragments. This is not ideal and in our case it would not work exactly. Or we would spend, maybe, a year to rewrite everything and then still support it. For me, the main result is that we did not do something, did not spend time on something. And time is money.
Well, and now, only in November last year, the Republic of Moldova raised a large round of investment ... But why talk about money?
Polychops started two or three months ago, it’s too early to talk about the results. For me, personal pride is that we have just started, and we already have people who have tried the application, they are interested, they already use it. We communicate with these people for two or three months, as much as working on a prototype. And they offered a lot of features. For me, this is the most important moment.
I hope you try it yourself too. Maybe you do not work in a startup, but your company has projects in which there is uncertainty. It is important for me that you think about it, talk with your team, with your managers, think about how to work with uncertainty, how to build your processes, improve the decision-making process, and stop spending time on things that are not needed.
If you manage all this and you make a great product, I hope at some point I will be one of your very happy users. Thank.