Minimum requirements of investors for the technical side of projects
Venture investors evaluate startups offered for investment on all these three components in order to get an impression of the startup's prospects and the ability of its team to achieve its stated goals:
- The business component (the goals of the project as an economically successful enterprise, ways and methods of achieving them) are described in the business plan.
- Technical component
- A team is people who have sufficient knowledge, skills and experience (some in running a business, others in technologies used by a startup) to achieve the goals set for a startup.
Investors are looking for all these 3 components of a startup to be harmonious and balanced, and, usually, the absence or insufficient development of any of the components leads to a refusal to finance. After all, even the most competent technical implementation may not lead to the economic success of a startup, and the most thoroughly calculated and thought-out business model can be negated by the technically illiterate implementation of the project - the most banal example when the project started abruptly and successfully, but constantly "lies", unable to withstand a heavy load.
In order to be sure that both business development plans and plans for the development of the technical component of the project are clearly defined and will be implemented, investors want to see what has already been done at the moment: for a business plan, preliminary contracts with customers can serve as such confirmation, and for the technical component of the project - the current model of the invention or developed software for Internet projects. Venture investors do not finance naked ideas and do not take startups at their word: they need confirmation that the team has thought everything through, planned and is able to implement it - both in terms of business and in terms of technical implementation. And all this can be done only by a competent team, without which any startup, even a very well-funded one, is almost certainly a future bankrupt.
But what about creating technically complex projects? It is good if the founders of the project include a well-coordinated team of highly qualified programmers who are willing to spend several months to develop a project without attracting investment. And if not? If there is only one highly qualified technician in the team who cannot do the project alone, but will be perfectly able to find and coordinate a hired development team? After all, it is very expensive to develop a project that is initially designed for huge loads, and which it is not possible to develop progressively, starting with a small attendance. Is it really necessary to find these funds ourselves and completely make the project so that it is not a bare idea, and only then go to investors? Not quite so: I have already written that the stage of the project idea is the pre-seed stage of startup development, and the seed stage consists of several stages, the implementation of the first of which - the creation of a prototype of the project and drawing up a technical task based on it - can already give the startup every right to claim that the project has left the bare stage ideas. The most important thing is that the investor will agree with this. Investors, of course, are more pleased to see a ready-made developed system, however, as all venture investors with whom I spoke noted in an interview, the minimum technical component of projects necessary for them is the presence of a prototype of the project, TK and a member of the startup team who is able to lead the development of highly loaded projects.
The first thing to do is to develop a prototype of the project's user interfaces and, based on it, draw up a TOR. How this is done is very well described in Yuri Vetrov's blog, which is specifically for IdeaBlog.ru I have compiled a brief overview of this process with a link to more articles on my blog, in which the issues described are discussed in more detail. So, an overview of the user interface design process from Yuri Vetrov:
Designing user interfaces. A brief overview of the processThe key activity of my department at Artics is designing user interfaces.
Basically, these are web technologies - web applications, portals, intranet sites, web 2.0 services, etc. The design process itself is quite extensive - both in terms of the number of stages, and the factors that are taken into account in its course, and the tools used. I described a lot of this in my blog. And for IdeaBlog, I have compiled an overview of the entire process and its features.
The design goal is to get a clear vision of what the system interface should be. This is necessary in order to determine what functions the system under development will have. Secondly, it is necessary to give developers clear instructions on how to make the system.
It is important to answer the key questions:1. For whom and for what this system.
Who is its main audience and what tasks does it solve for this audience? What are the goals of creating a product and what are the tasks facing it? What is important for the success of the product, and what is secondary?
2. What should be in the system and what it should be able to do. What features does it give the user and what functions are needed for this? What operational, consumer and other qualities are important for the successful operation of the system?
3. How the system looks and works. How to distribute the functions of the system to specific pages and what is the sequence of these pages? How will the user work with these functions? What are the technical features of these functions?
Someone saves on detailed design, someone does not consider it important. This often leads to increased development costs - the functions of the system do not stick together into a single and understandable whole. This means that the result will not be very high-quality both in terms of consumer qualities and in terms of stability of work - you will constantly need to plug holes. It's like climbing stairs in complete darkness - you need to feel every step instead of just taking it and calmly climbing up. You can stumble or step in the wrong place. If the product is unique and highly demanded or is aimed at an audience that cannot refuse to use it, consumer qualities may not be in the first place. But if the market is competitive, the satisfaction from using the product should be on top.
- The first step is a pre-project analysis. We need to understand what needs to be done after all. And understand not only the developer, but also the initiator of the project. Often the idea sounds quite general. And when it comes to explaining what needs to be done, no one can say it. Therefore, the target audience, functionality and other details of the project are discussed in detail and recorded.
- After that, you can already accurately assess and plan the work. Often an assessment is given without a preliminary analysis. And then the nerves of both the customer and the developer are burned faster than calories on an exercise bike. If the project is long-term, it should be launched in several stages. This should also be considered when designing the interface - will the product be complete if only half of its capabilities work?
- Then we start designing directly. The main document that is obtained as a result of this process is detailed page diagrams (wireframes). They show what each page of the system is, what are the features of its operation. After that, you can start working on the design. In addition, you can prepare a description of the operation of the pages - use cases. They describe in detail the algorithm of the user's work with the site - this will greatly help developers.
- But the best design result is an interactive prototype of the system. This is a working model of the user interface - it includes the main pages and processes of the system. Despite the fact that this is only an imitation of work - data is not saved and there is no work with the server at all - the prototype allows you to understand how the system works without reading tons of documentation. In addition, it is important to check the correctness of design decisions. Usability testing is great for this, and it's better to do it based on something as close as possible to the final result. It is much cheaper and easier to analyze and correct design errors in the prototype than to subsequently edit the final program code and catch the errors that have appeared.
With a prototype in hand, you can communicate with future investors and partners long before the launch of the system. And this communication will be much more substantive. To do this, a presentation is often prepared and a prototype will not only be an excellent addition to it, but also part of the demo package itself. In it, you can show not only the business plan and development strategy of the company, but also present the system itself.
This is not the end of the design work at all. The terms of reference and other project documentation are being prepared, the system architecture and technological solutions are being thought out, the development and the process of working on the project are planned. But this is a story for a separate material.
Portal "Eternal youth" www.vechnayamolodost.ru11.12.2007