Round BWhy trying before building is essential to every startup
Round B
Why trying before building is essential to every startup
“In startups, which are limited in resources, there is no choice but to use a little impudence, creativity, trial and error, to refine what is worth investing in and what is an idea that sounds good but is not yet ripe to invest in,” writes Shaul Olmert
Technological product development processes are long and complex. These are relative terms, of course, long and complex relative to what? Well - relative to what the reasonable person expects. Sometimes I suggest some change in our product, and I’m informed by the development team that the change that seems so small and minor to me will take a whole week, or a month, or sometimes more, to implement. It seems so simple on the face of it, but it always turns out that this simplicity involves research, design, code writing, integration, testing, corrections - in short it is anything but trivial. Of course, there are also things that are developed relatively quickly and easily, but the more advanced the product, the more complicated the process usually is. In recent decades, modern development methodologies have evolved, enabling faster development in flexible and modular product development environments. But even in these environments, almost any new development needs to fit into a complex system and make sure there are no conflicts, and seemingly simple tasks take a long time and require a lot of resources. This reality makes life difficult for a company that has made innovation its calling card because it lessens the ability to be spontaneous, respond quickly to changes, and market needs, and produce something that works in short sprints as the organization grows and the product develops.
This is where the methodology we have adopted from the world of marketing comes into play - try before you commit. Just like a gym that allows you to come for a trial workout before purchasing an annual membership, a clothing store that allows you to measure the clothes and make sure it fits before you buy, or a video game that you can play its first level or two before you purchase it, in the world of development, too, a way has been found to make sure that the product meets a real market need before devoting precious resources to a long process of development and implementation.
Imagine you were using a particular app like Wolt for example, and after choosing dishes to order from a restaurant you would have the option to turn your order from a one-time order, to an order that is automatically repeated on a weekly basis on a specific day and time per week. And suppose you liked that idea, and you pressed the right button to make the order permanent, and then you would get a message like, "The service is not yet available, check back soon." A little frustrating, right? But if Wolt were really considering developing such an option, the development would be complex and include lots of components to support it - an option to edit and cancel the regular order, an option to skip a shipment or two, to adjust the system to receive future orders, train service staff to answer reordered questions, and more. The development time of a service of this type can take between a month and six months, involve many factors (legal consultant, designer, developers, software testers, etc.), lead to delays in the development and integration of other features in the product, and more.
So maybe before committing to a project of this magnitude, it is better to first make sure that the users really want it? In that case, I would recommend that Wolt implement the offer as part of the user experience, get the user to go through the whole process of approving the order, approving the price and payment details, and only at the last minute, when he is convinced that he is receiving this new service, that’s when you politely notify them that service is not yet available.
So why frustrate our users? Because after frustrating a relatively small number of users (and you can always compensate them with some small discount on their order or something like that), we get a very reliable indication from the market that our product is really needed. If we have seen that users have already made the purchase decision, gone through all the steps and taken a commitment to the service offered - this is a sign that they really want it, and it is worth it for us as an organization (in this case, Wolt) to invest and commit to its development.
At the time when I ran the online commerce business at Nickelodeon in the United States, I did something like this on our digital store website when I offered buyers the opportunity to add a personal dedication from one of the Nickelodeon characters to a gift they purchase, for an additional ten dollars. The results were unequivocal: Nearly thirty percent of buyers added this service, and while disappointed to find out later that the service did not yet exist, they gave me great confidence that it pays to develop the infrastructure needed to offer this service, which was launched about six months later and was very well received.
In the product of my current company Piggy, a mobile application that enables the creation and distribution of blogs in a “story”-like visual format, we wanted to test whether the degree of responsiveness to the work in the application would increase when the creation process is significantly shortened. To this end, we have developed a very initial (and to a considerable extent based on behind-the-scenes manual work) version of a "bot" that takes threads from Twitter and automatically turns them into “Piggys”, i.e. multi-page stories adapted for mobile consumption and designed as beautiful visual stories, and not just as chunks of 280-characters. We announced the existence of the bot and approached many Twitter users with an offer to tag the bot so that the system (and also some hardworking employees who stayed awake around the clock) would create for them a beautiful Piggy based on their Twitter content. A lot of people responded to the challenge, and in the following days the system created a Piggy for them semi-automatically. So what’s the point of putting out a product that still works very partially, involves manual operation and achieves mediocre results? The logic is that this experience has also helped us see that there is responsiveness and people are indeed interested in this development, we also get questions and feedback that help us pinpoint the future product before we invest in its development and also try all kinds of options, development rules, designs and the like. We learned, for example, that people would be happy for the Piggy produced for them to automatically appear in their account in the app, so that they could add their own polishes, designs and other elements (images, videos, animations, etc.). We also learned how sensitive users are to the artistic freedom that the bot takes in handling their texts. We also learned that adding a link to the original Twitter thread on the generated Piggy title page increases by hundreds of percent the chance that the Twitter user who connected the thread will share Piggy on his Twitter account, and more. These are all important lessons that have saved us a lot of development time and unnecessary delays later on.
The “try before you build” methodology is one of the relative advantages of a startup. When I did this while working at Nickelodeon, it did work, but I received quite a bit of criticism for "misleading consumers" at the trial stage, because in large corporations there is not much flexibility when it comes to trials. In startups, which are limited in resources, there is no choice but to use a little impudence, creativity, trial and error, to refine what is worth investing in and what is an idea that sounds good but is not yet ripe to invest in. And the beauty here is that the user community is not just a collection of passive consumers, but part of the process of formulating the product and adapting it to the market.
Shaul Olmert is a serial entrepreneur and the co-founder and CEO of mobile app developer Piggy. He formerly founded interactive content company Playbuzz Ltd. You can find his previous columns here.
