At the FRIA online conference “How to build a technology-based business,” Zviad Kardava, responsible for developer relations at Google, spoke about the problems of technological start-ups in product development, product development and process management, and how they can be solved or avoided.

We live in a dynamic world where there is no time to hesitate: we try to quickly make MVP, enter the market, increase conversion and presence. This approach is justified, but in the process, the founders of a startup may have problems that will further interfere.
Three areas in which startups have problems:
1) Management and processes
If in a short time the team has grown from 5 people to 50, it does not work according to the previous scheme: you need to set new business processes and manage them - be able to prioritize the company and product, determine the key metrics of success indicators and "slump" of your company / product.
')
The most common error in processes is when CTO spends most of its time directly on development. Of course, the CTO should have good technical skills, and when there are only 3-5 people in a startup, it’s perfectly normal to participate in the development. But when there are already 50 people in the team, SRT should lead the development process, work closely with team leads of the development and testing departments, and not be engaged most of the time in developing directly. This person is a generalist who understands all the technologies, knows how to talk with the team and build the right development, tries his products and new technologies.
2) Product DevelopmentThere may be problems with the prioritization of features, testing and adaptation of the product. Tracking the development of the product helps us to understand whether we are doing the right thing: when a new version or feature is released, it is necessary to measure indicators, move with iterations and not dwell on one thing for a long time. Tracking and evaluating product metrics is very closely related to marketing: you can make a very good feature, but it's very bad to sell it, and vice versa to focus the team’s attention on developing features that nobody really needs. Such approaches as A / B testing and analytics allow you to understand customers and products.

For example, a company that tried to make a similar to Netflix for residents of low-income regions with a cheap subscription for mobile phones, saw with the help of analytics that there are quite a large number of users interrupting content playback a minute or less after they start watching when they first start. The team tried to release new features, change the design, apply machine learning, but the problem turned out to be much simpler: this group of users simply didn’t have any headphones with them. When they included content on the street or in a public place, they were just uncomfortable watching it without headphones.
3) DevelopmentVery often, developers like to build everything from scratch - in our country, programmers can solve any technical problems. But often it spends too much time. If ready-made components are in the public domain or for a fee, use them. This will allow you to focus on developing the unique features of your product. For example, if you are doing some kind of mobile application, it will often be enough to use Firebase. It has everything you need: analytics, hosting, pushy, database, Cloud function, tools for promotion, crush-reporting, tools for A / B testing, experiments, and much more. Cloud functions are often enough to implement simple backend logic. You do not need to create or maintain this infrastructure yourself, all you need to do is to correctly combine the components (this approach is called backend as a service and allows you to significantly save development time and entering the market).
Also, you should never save on development tools: they will help speed up your processes greatly. This applies not only to development environments (IDEs), but also to testing tools or infrastructure. For example, Github, Gitlab, Bitbucket allow CTO to do code review, get an issue and conveniently develop in a distributed team. If you decide to keep the code at home, set up a good repository, for example, Gitlab, take a decent hardware.
Own team or outsourcing?

Many startups targeting technology products and platforms often take outsourcing negatively. There are a lot of developers in Russia, high average market wages, but all this, together with extensive experience, does not guarantee that the developer will meet your expectations: anyone can make a mistake, and even people with great technical experience sometimes make wrong decisions and can fail team
Good engineers and programmers are often very bad designers. A good UI / UX is very important for the product, so you can easily outsource UI / UX, while leaving inhouse development, the main thing is to keep the balance.
It is important to understand what specific people or companies you need for outsourcing - private designers and specialists, small mobile development studios or large companies that specialize in outsourcing. I would not recommend large companies to small startups: as a rule, they have a different focus and principle of work.
What is wrong with the product: main problem areas
1) FrontendThe concept of frontend, conditionally, includes everything that at least somehow interacts with the user. In one case it can be a user interface in the form of a web or mobile application, in the other - an API of your platform, application, marketplace. A convenient API is a good UX / UI, which is very important. Next comes architecture, frameworks and languages.
One may argue more than one language, framework, or approach is better than another, but users do not care what your application is written on. The main thing for them is a beautiful and clear interface, fast work of the product.

What if the UX / UI is bad?
You can consult with the experts at outsourcing, invite the designer to make you a layout, test how the user interacts with the screens and switches from one page to another, and then modify the inhouse product and periodically consult with someone.
Testing usability with the help of friends is also one of the options for consulting on UX / UI. Try to give your relatives, for example, mom, test the application or web page. If she does not have any problems with use, and you do not need to prompt, it means that you are close to success.

New users need to adapt. If the application after installation immediately requests the user access to contacts, files, camera, he perceives this action as suspicious, because he does not understand why it is needed.
Good practice is when an application is launched without a request to access something and sends it only as needed and after the user has interacted with it for some time. For example, you have a gaming platform, after installation you offer the user to play the game, and in the process he understands that he can compete with friends and share the results. If the application starts to request access to contacts at that particular moment, it is likely that he will agree.
Another example is the platform on which to register. We all live in phones and on the go, so asking people to fill out a large and uncomfortable form completely is a bad strategy. Instead, you can add conversational UX (interactive user interaction): connect API.ai (dialogflow.com) or Facebook messenger. Then all the user needs is to log in from Facebook or via Google, and continue to answer questions by clicking on the buttons with the answer options. This allows the user to complete a form on the go.
A good UX / UI is:- Competitive advantage. People stop using some applications just because they are uncomfortable.
- Higher ratings: they bring higher conversion and monetization. If users like the app and it becomes popular, app stores add it to collections more readily. The better the platform, the fewer user support calls.
It is very important to be in trend and constantly monitor new technologies. For example, many people still do not know about Progressive web application, which is more than three years old. This is a very advanced web page that works quickly, also offline, and looks like an application on mobile devices. PWA can be added to the screen of your phone as an application, and they are fairly easy to develop. Progressive web applications also have a diverse set of APIs: Web payments, Web credentials, Web sensors, etc.

Web Payments helps to make a web page with a convenient subscription and payment without redirecting to the payment page. Web Credentials allows you to automatically remain in the system if the user at least once logged in to it.
Another interesting technology is Android InstantApps, a completely native application with all the functionality you don’t need to install: you can get it directly from the search, from the link, from the beacon, to the Telegram, and so on. After clicking on the link, the application opens instantly, and the user can buy, subscribe and do something. And only then - install the application, if you want. This enhances user interaction and increases market reach.
But keeping track of new technologies does not mean applying everything in a product. Lately, everyone really wants to use neural networks or declare it. This may be good for PR and marketing, but if the product is not aimed at these technologies, or you have no experience in them, you should not waste your time and try to make magic: you need to understand what you are doing and what specialists are doing.
If you need some standard things like voice recognition, transcription, translation, image analysis, etc., instead of developing and training your ML models, it is faster and easier to use ready-made ones. The Google Cloud Platform and other platforms have quality models with a good and easy API.
2) Backend and infrastructureIt is very important from the very beginning to lay the right architecture for Backend. Now everyone is guided by the so-called microservice architecture. This is an approach to building a backend, and not just one template, so different variations are possible, but, in general, this approach is justified.
In short, with the microservice approach, a single application (backend) is built as a set of small services, each of which works in its own environment and communicates with the others using lightweight mechanisms. Very often HTTP / REST is used for communication, but I recommend to look and learn GRPC - an open framework for remote procedure call that works on all platforms and with all languages and is much more efficient than HTTP. It is also extremely important to choose the right database.
All this will significantly save manpower and money, including hosting, because You can use cheaper containers instead of virtual machines, and also allow your backend to remain flexible and scalable.
There was a startup that chose MySQL, because one of the developers had experience working with this DBMS, and he thought that would be enough. Then it turned out that they need to store data in JSON format, and they had to do it in MySQL, although he does not know how to work effectively with JSON. Then someone offered to take MongoDB, because she has a document orientation. MySQL began to slow down, and without understanding the reason, they took PostgreSQL, because they heard that it is a good relational database. So they had three databases.

After some time, all three bases began to "slow down". And the team decided that critical and hot data could be kept in Redis (NewSQL). They also had an elasticsearch search engine ... Total: we have a startup with four separate databases. Maintain them quite uncomfortable and expensive.
The normal solution for such a startup would be PostgreSQL DBMS, which can work normally with both SQL data and JSON. In the ideal case, the team should have a separate database specialist - DBA. Or a person quite experienced in these matters, who knows such technical details.
Further there are frameworks, separate ready components, services and languages.
On the topic of choosing the right frameworks and, especially, languages, many copies are broken.
You need to choose a programming language by task or territorial basis: if you are not in Moscow or St. Petersburg, where you can find developers of any level, choose depending on your region: if there is a strong Node.js or Python-community in your region, and they fit your tasks - choose one of these. Search for Erlang programmers where there are none, is not worth it.
Many people neglect the practices of continuous integration and continuous delivery. This is not worth doing - they improve the quality of the product, reduce the number of bugs and help make the system and development process more “transparent” for all team members.
Next is the question: choose iron or cloud? It’s better to choose clouds, off-the-shelf services and platforms — ultimately, if used properly, they will be cheaper, save time, and by themselves are more accessible and profitable in terms of cost reduction.
The opinion that clouds are much more expensive than iron is unreasonable. If you recalculate and take into account all the capabilities of service providers, you will understand that they provide a good infrastructure and environment for interaction (for more information on how to choose a hosting for a startup,
read the IIDF in this material ).
When choosing a hosting, database and other infrastructure components, it is important to remember: the user doesn’t care what your application is written on and where it is hosted. The main thing is that it works quickly and allows the user to interact with the front end.
Even with a simple PostgreSQL, MS SQL or MySQL, you can solve most of your tasks. Stack Overflow, which is used by a huge number of developers, stores its data in 4 databases: the main (for all), auxiliary and two replicas. And this is enough for the livelihood of the whole Stack Overflow.
You can find a large number of tutorials and materials on architecture, CI / CD, DevOps approaches, containers, databases and scaling. The study of these things will not take much time, but in the future will greatly help reduce the time, costs and risks. Setting up containers instead of virtual machines also speeds up development, even if you have a normal architecture and have some kind of CI / CD: you don’t need to set up your environment every time, you just download the finished container, you can work with it, and then in the same container to test, release in production, and then scale.
API management is one of the most important problems of new products, which everyone has forgotten about. The easiest way to solve it for developers when there is no time to bother with complex things is to push the API into containers. This will allow not only API versioning, but also easy to scale with the load on different versions of the API.
You cannot count on high availability by relying on a single service provider.In today's world, any service provider may have problems. Therefore, the use of one provider or only your hardware leads to the fact that you cannot consider yourself as a highly available service or platform.
Using multiple service providers is an absolutely normal approach. For example, Kubernetes can be deployed to all clouds: Google Cloud, Amazon, etc., and you will have good service availability.
Think about scaling in advance.Of course, if you have a couple of virtual lovers now, then you can deploy a few more. But when you are aiming for rapid growth, this can lead to trouble: a monolithic application and a large number of users can become a problem.

It was the right strategy for selecting components at the very beginning that allowed PokemonGo to take a heavy load: they expected 5X traffic in the worst case scenario, while real traffic in the first days was 50X. To withstand such a load was possible thanks to Kubernetes and Cloud Datastore: Kubernetes can be deployed on almost all clouds, it has a huge number of users and a large community. And Cloud Datastore is a highly scalable NoSQL database that automatically scales to load your applications. You do not need to do anything and worry.

More information about the deployment and scaling PokemonGo can be found
on the link .
Summary:- Do not ignore user feedback and respond to them;
- Think of alternatives. For example, you can use conversational UX instead of classic registration forms;
- Use off-the-shelf components, services and platforms;
- Always do more for users than they expect.
On November 29, another Google representative, Amrit Dhir, Global Campus Operations Manager at Google for Entrepreneurs, will speak at the FRIA Russian Startups Go Global 2017 conference. He will share case studies and experiences gained while working with ambitious Google / Alphabet projects. Learn more about the event at the link .