The art of delivering a product "quickly and often"
“Several clearly expressed problems manifest as launch delays: too slow to work, misunderstanding of the problem, fear of having to deal with users, fear of condemnation, working with too many different things, excessive perfectionism. Fortunately, with all of this you can cope with a simple means — get yourself to start doing something pretty quickly. ” - Paul Graham“ 18 mistakes killing startups ”
When you go through the Y Combinator (YC) venture fund, one of the tips you receive is “start as early as possible”, i.e. start a business long before you think you are ready for it.
In my startup, we didn’t just follow this advice. We introduced it to an almost absurd degree to everything we did. In fact, the issuance of the product "quickly and often" is now the most desirable action of the company. This is the most dominant feature of the company, which, I believe, has contributed to our growth and the adoption of which can benefit almost every business.
')
Here I would like to share some tactical considerations about what this means and how it works.
Why does “issue quickly” matter?
The benefits of issuing a product are, hopefully, clear to everyone. Without such issuance, the company has no growth and - by definition - no startup.
The problem is that we all tend to give out the product too late and rarely. Several psychological factors act implicitly, but together preventing such extradition: pride, perfectionism, the spread of project boundaries, the fear of criticism, the fear of being rejected.
I went through it, having received my bitter experience. Looking back, I see that the very first product development in our company was ridiculously bad. We spent months working on something that had no users at all, based on the erroneous belief that there was a certain set of functions that we could develop and which would begin our growth.
As soon as we joined YC, it became obvious that the product we created simply does not work. (1) Since we wanted to survive, we had to set aside our first great creation and try something else.
Work on "v0", not on "v1"
We began to produce a series of newly created products, focusing on efficiency. Every time we started something that didn’t find users, we would roll back, work and launch something else. Every time when we refused some product, we strongly criticized ourselves for the time spent on it and spent less time on the next round.
Our ripening period of a “minimally viable product” shrank from three months to one week, one day, and finally reached several hours. At the end, it was our most minimal release — the only page that represented the file and address of our inbox, which gave us the bulk of success.
We called this release "v0". This “v0” is the first step towards a full vision of a product and the most minimal, approximately corresponding to the intended purpose version of what you are trying to create. It is clear that in your “v0” there will be a lot of obvious material missing, and this is fine, because what you develop contains prerequisites that will induce you, ultimately, to create the required things.
“V0” is the smallest fruit of your work, allowing you to say: “Well, this is what I have done. And How?"
Development of product characteristics "v0"
With a new product a lot of unclear: it is not known which of its properties will be important and which design or which implementation will work. Therefore, just as the accelerated launch of a product on the market (“issuing quickly”) is important for adjusting the product to the market, the rapid development of new product characteristics is essential for adjusting the characteristics of the product.
Sometimes these characteristics turned out to be so fundamental that when they were deleted complaints began due to lack of functionality. But that was what we needed: we didn’t spend any effort and quickly found out that customers need exactly this characteristic.
Using the carefully crafted layout and techniques of the “Wizard of Oz”, you can often disguise minimal functionality, saving time and technical resources, some of your most valuable assets as a startup.
The main downside of this approach is that your product will be perceived less mature and worked out than it could be. But the feedback — the information and experience gained from the “v0” release — far outweighs the possible small initial damage to reputation.
Mini demos
Using the concept of characteristics “v0”, we took a step in the direction we called “internal mini-demos”.
When someone is working on a new element with us, he should submit an extremely early version of this development for general discussion. We, using the projector, put it on the screen in the center of the office. Any employee who is free at this moment can, while at the giant screen, look and speak.
This usually means that the demonstration of a new element occurs after a day of work on it or even earlier. This could be some new part of the interface or even a hidden technical feature (“I press this button, and our entire infrastructure is being restored - great, eh?”). Mini demos are not just for running a larger part of the work. They are carried out constantly, as soon as something new appears that can be shown.
These mini demos are amazingly useful for many reasons. They:
It is important that the discussion of mini-demos is productive. The most useful comments are very specific and are based on some data or experience (for example: "Last time we released the interface only on icons. Many customers spent a lot of time to understand what a button does." Or "Our sales staff spends all day in the same window. We could make this window remember their preferences? ”). Beware of “looping on trifles” - do not let the discussion go to secondary and third-level directions with unimportant debate or criticism.
Just as the founders of the company initially beat off the quick delivery of the product, all employees first consider the issuance of a mini-demo difficult. The presentation of a messy, incomplete part of the work of the whole room of people who want to make a good impression, causes complete discomfort, especially for new employees who have just joined the team. However, I found that with the calm support and regular participation almost everyone falls in love with this way of working.
It works outside of information technology.
The concept of "issuing fast" is not only in technology. Successfully using a mini-demo for technical products, we moved this practice to everything in our teams. People go to the projector and submit their new spreadsheet for evaluating potential buyers, a new article from the customer help section, a hiring channel, the latest Zapier integration, and so on. Absolutely any kind of work can be presented and, indeed, presented as a mini-demo.
So that the process of submitting a mini-demo does not drown in dogmas or rules, we support its flexibility. Mini demos are not tied to any particular format. We jokingly call very small changes “micro-demos”; sometimes large-scale macro demos are issued. They can be submitted at any time. Often, over a cup of coffee, several people follow one another at a projector within a few minutes and show what has been gained in some direction this morning. Before sending the finished product, we conduct the final presentation of the mini-demo with "any recent considerations." The key is to make it interesting and useful for everyone.
Issuing everything “quickly and often” is our best practice in the company. Thanks to these mini-demos, we work better and faster. We hope that others will find this practice as attractive as we are.
David Mack is the co-founder and technical director of SketchDeck (YC W14), providing custom development and allowing companies to transfer their presentation materials to work “on the side” to professional developers. He holds a BS in Computer Engineering from the University of Cambridge and an MS in Mathematics and Computer Engineering from the University of Oxford.
Notes
(1.) If the situation with a project’s success is unclear, then three months without a distinct increase in the number of users is a valid alarm signal that it’s time to try something else.
When you go through the Y Combinator (YC) venture fund, one of the tips you receive is “start as early as possible”, i.e. start a business long before you think you are ready for it.
In my startup, we didn’t just follow this advice. We introduced it to an almost absurd degree to everything we did. In fact, the issuance of the product "quickly and often" is now the most desirable action of the company. This is the most dominant feature of the company, which, I believe, has contributed to our growth and the adoption of which can benefit almost every business.
')
Here I would like to share some tactical considerations about what this means and how it works.
Why does “issue quickly” matter?
The benefits of issuing a product are, hopefully, clear to everyone. Without such issuance, the company has no growth and - by definition - no startup.
The problem is that we all tend to give out the product too late and rarely. Several psychological factors act implicitly, but together preventing such extradition: pride, perfectionism, the spread of project boundaries, the fear of criticism, the fear of being rejected.
I went through it, having received my bitter experience. Looking back, I see that the very first product development in our company was ridiculously bad. We spent months working on something that had no users at all, based on the erroneous belief that there was a certain set of functions that we could develop and which would begin our growth.
As soon as we joined YC, it became obvious that the product we created simply does not work. (1) Since we wanted to survive, we had to set aside our first great creation and try something else.
Work on "v0", not on "v1"
We began to produce a series of newly created products, focusing on efficiency. Every time we started something that didn’t find users, we would roll back, work and launch something else. Every time when we refused some product, we strongly criticized ourselves for the time spent on it and spent less time on the next round.
Our ripening period of a “minimally viable product” shrank from three months to one week, one day, and finally reached several hours. At the end, it was our most minimal release — the only page that represented the file and address of our inbox, which gave us the bulk of success.
We called this release "v0". This “v0” is the first step towards a full vision of a product and the most minimal, approximately corresponding to the intended purpose version of what you are trying to create. It is clear that in your “v0” there will be a lot of obvious material missing, and this is fine, because what you develop contains prerequisites that will induce you, ultimately, to create the required things.
“V0” is the smallest fruit of your work, allowing you to say: “Well, this is what I have done. And How?"
Development of product characteristics "v0"
With a new product a lot of unclear: it is not known which of its properties will be important and which design or which implementation will work. Therefore, just as the accelerated launch of a product on the market (“issuing quickly”) is important for adjusting the product to the market, the rapid development of new product characteristics is essential for adjusting the characteristics of the product.
Sometimes these characteristics turned out to be so fundamental that when they were deleted complaints began due to lack of functionality. But that was what we needed: we didn’t spend any effort and quickly found out that customers need exactly this characteristic.
Using the carefully crafted layout and techniques of the “Wizard of Oz”, you can often disguise minimal functionality, saving time and technical resources, some of your most valuable assets as a startup.
The main downside of this approach is that your product will be perceived less mature and worked out than it could be. But the feedback — the information and experience gained from the “v0” release — far outweighs the possible small initial damage to reputation.
Mini demos
Using the concept of characteristics “v0”, we took a step in the direction we called “internal mini-demos”.
When someone is working on a new element with us, he should submit an extremely early version of this development for general discussion. We, using the projector, put it on the screen in the center of the office. Any employee who is free at this moment can, while at the giant screen, look and speak.
This usually means that the demonstration of a new element occurs after a day of work on it or even earlier. This could be some new part of the interface or even a hidden technical feature (“I press this button, and our entire infrastructure is being restored - great, eh?”). Mini demos are not just for running a larger part of the work. They are carried out constantly, as soon as something new appears that can be shown.
These mini demos are amazingly useful for many reasons. They:
- They advise developers in the right direction long before any significant distance is covered. Someone can easily get off the road at the beginning of the project.
- Combine the integrated experience of our team, allowing you to take into account a wide range of points of view and needs in each development of any property.
- Provide regular “gradual” forward movement of developments and help anyone better understand what other employees are busy with.
- Bring together people working in different places or traveling.
- Prevent unnecessary work when it comes to presenting ideas (for example, creating a PowerPoint slide show instead of just writing a few bullet points).
- Perform the role of a coercion function to put the material into work and promote it.
- They create a daily feeling of success and prospects of work.
It is important that the discussion of mini-demos is productive. The most useful comments are very specific and are based on some data or experience (for example: "Last time we released the interface only on icons. Many customers spent a lot of time to understand what a button does." Or "Our sales staff spends all day in the same window. We could make this window remember their preferences? ”). Beware of “looping on trifles” - do not let the discussion go to secondary and third-level directions with unimportant debate or criticism.
Just as the founders of the company initially beat off the quick delivery of the product, all employees first consider the issuance of a mini-demo difficult. The presentation of a messy, incomplete part of the work of the whole room of people who want to make a good impression, causes complete discomfort, especially for new employees who have just joined the team. However, I found that with the calm support and regular participation almost everyone falls in love with this way of working.
It works outside of information technology.
The concept of "issuing fast" is not only in technology. Successfully using a mini-demo for technical products, we moved this practice to everything in our teams. People go to the projector and submit their new spreadsheet for evaluating potential buyers, a new article from the customer help section, a hiring channel, the latest Zapier integration, and so on. Absolutely any kind of work can be presented and, indeed, presented as a mini-demo.
So that the process of submitting a mini-demo does not drown in dogmas or rules, we support its flexibility. Mini demos are not tied to any particular format. We jokingly call very small changes “micro-demos”; sometimes large-scale macro demos are issued. They can be submitted at any time. Often, over a cup of coffee, several people follow one another at a projector within a few minutes and show what has been gained in some direction this morning. Before sending the finished product, we conduct the final presentation of the mini-demo with "any recent considerations." The key is to make it interesting and useful for everyone.
Issuing everything “quickly and often” is our best practice in the company. Thanks to these mini-demos, we work better and faster. We hope that others will find this practice as attractive as we are.
David Mack is the co-founder and technical director of SketchDeck (YC W14), providing custom development and allowing companies to transfer their presentation materials to work “on the side” to professional developers. He holds a BS in Computer Engineering from the University of Cambridge and an MS in Mathematics and Computer Engineering from the University of Oxford.
Notes
(1.) If the situation with a project’s success is unclear, then three months without a distinct increase in the number of users is a valid alarm signal that it’s time to try something else.
Source: https://habr.com/ru/post/299028/
All Articles