A full cycle of works in a product company or why outsourcing is just a minor addition to product development. Probably, this is the best beginning of the answer to the frequently asked question, "what is the difference between product IT companies and outsourcing".
Of course, in order to become fully acquainted with the activities of the product company, you should spend at least 5 years working at such a company and being very involved and observant. However, I will try to broadly lay everything out within one article.
It doesn't matter whether we are talking about the idea of creating a new company or a new product in an existing company, there is always that first person who is eager to the idea and ways of its implementation. And this person is forced to be well-versed in many areas of the future project. He needs to be an engineer to create something, a marketer - to understand the demand and be able to offer the product, a seller - to select appropriate markets and sell the product, a QA - to meet the expected quality, a manager - to hire the first professional to the team, a support specialist - to communicate with users, an analyst - to collect the results of the first attempts, a designer - to create a decent appearance for the product, and so on.
Of course, you cannot combine dozens of professions in yourself and be at the top in all of them. Here I want to introduce as an example the popular dispute when Apple claimed that they released the thinnest, fastest, and lightest computer. Needless to say, there were immediately appeared specialists on the internet who compared it with a computer that is thinner than a MacBook, a computer that is faster than a MacBook, a computer that is lighter than a MacBook, etc. Yes, they were right, but if they walked with three laptops that are better than the MacBook in some ways, it certainly would not be convenient. So it is with the founder, he is far from being a guru in all areas, but this is not required to launch a business or a product. In turn, experience and understanding in all these areas are essential. Another option - a lot of colleagues with whom you have to implement the idea together. By the way, the search for relevant colleagues can be much more difficult task than to independently study the necessary directions.
Well, we imagine that there is a man with a worthy idea. Before he begins to implement anything, he begins to study the market: competitors, demand for the product, difficulties of entering the market, possible risks, and much more. As a result of the analysis, he forms a user's portrait and expectations for demand. By the way, exactly at this stage many companies abandon their ideas, realizing that they will not be able to enter the market or will not get the necessary flow of customers.
The goal of this step is to determine the complete list of requirements with sufficient details to proceed to the next steps.
When I planned to carry out the project myself, I allowed myself not to perform a number of works on creating documentation. These included: product description, specification, code documentation after implementation. However, there is also an obligatory document even for a single developer - it is a software design that describes the structure of the future product and the sequences of interaction of its parts. If the product starts immediately with a large team, the absence of at least one of the documents will lead to stupid time expenditures.
Imagine that a team of 20 people works without documentation. This means that there is one carrier of knowledge, to which all members of the team come and ask similar questions. In addition, they think that they carry out the task correctly, and by the end of the execution it turns out that the result does not meet expectations. Based on my experience, when working in the absence of all the documentation prior to the project start, the technical debt of the project will roughly correspond to the exponent, where the x-dimension corresponds to the team size.
However, don't be under the illusion that the written documentation will solve the described problem. The only result of writing documentation is the time and resources spent. Therefore, any published document must be accompanied by the team understanding and their consent with what was written.
The goal of this step is to create a complete set of materials necessary for planning work and hiring candidates according to the requirements of the product.
The point is optional, however, if it is to pass, it will be decisive in the product's fate. After all, worthy professionals who agree with the product idea will occupy themselves with it not according to the working day schedule. And if you make a mistake, the first 80% will not be as difficult as the second 80% :)
I had to deal with this situation very often. At the same time, the more one (hopefully, just one) of the team members wants to hide his mistakes, the later the product will come to the deadlock and it will be necessary to make drastic changes both in the technical part of the process and in the administrative one. In addition, the time spent cannot be returned, and the problematic employee will begin to dissolve rumors about the company after his dismissal.
By the way, if one manages to find professionals and who are involved in the company life, the leader will be able to heave a sigh of relief and take on the next direction of development.
The goal of this step is to create a team whose level of specialists will be sufficient to implement the product creation.
The very stage that one wants to jump over and rather start doing something, but no, the annoying leader makes it necessary to assess each task and determine where there is a risk of falling behind the plan. Have you often thought about the need to write the code on the "never look back" principle or as it is called in some methodologies - TDD? My experience in creating software consists of small products, and very large ones as well, consisting in turn of hundreds of technologies and dozens of programming languages. However, I have never seen the project executed in time and with corresponding functionality & quality without detailed designing and planning.
The most confident in their productivity and professionalism were those who worked on the TDD method and similar ones, when one writes functions first and, as necessary, adds the code around them. This approach may be not as bad, but it will hardly allow to meet the expectations of management and marketing.
The goal of this step is to draw up such a sequence of works so that each team member will understand what he should do and in which order, from whom to obtain input information, and to whom to deliver the results of his work.
The project implementation phase directly depends on the quality of the previous steps. Despite the opinion that the project manager is responsible for this phase, the responsibility rests with all team members. Everyone can accelerate the project through his participation or slow it down by hiding facts or not wanting to optimize the work. The smoothness of this stage depends on how literate and detailed the design is carried out and the sequence of tasks is planned.
In addition to the coding, the design is tweaked, product tests are conducted, demonstrations are held for potential users, opinion leaders, and company members.
The goal of this step is to successfully complete the planned work in accordance with the documentation.
Sometimes the launch starts with an open beta, aimed at testing the idea in real conditions and collecting the first reviews. More often, the product comes out as a complete solution along with large-scale marketing and PR campaigns. The development team takes a few minutes to catch their breath and rushes to fix all the newly emerged issues, and also modifies the tested ideas, if so is required by the market.
At this stage, the active phase includes the sales and customer service teams. If the first ones simply increase the product income, the latter puzzle out the issues and wishes of users, contact the team and turn the users' appeals into a new, higher-quality product update. By the way, in KeepSolid, the customer service team works 24/7 to provide the fastest possible solutions to users' issues.
The goal of this step is to release the product, make it well-known, and get feedback from users and media.
The launch of the product is just the foundation for its future success. Most products do not become popular for long after the first launch. Many require time to gradually gain positions, improve according to users' requests, and increase the functionality. All information about the product on the market is processed by analysts, marketers, technical specialists, sellers, etc. to search for gaps in product capabilities. This information becomes a description of the new product, which will be released as an update to the current one.
Here is an example of a beta launch of our new KeepSolid Sign product.
The goal of this step is to conduct the correction of mistakes and create a list of necessary changes & improvements to the product.
The above described steps relate to the cycle of works on the product. But this is not the company creation. The company develops departments that allow to create products without looking back at the rest of works. These include:
As I promised, all the steps are described in one small article, but each of them is another large article or even a book on a specific process. The only team management in the product company can be described endlessly. On this subject, you can find both small books on the Internet and entire training programs for 3-4 years with different approaches to people. Of course, it is impossible to explain all this in short, but I can only say one thing: the product company is difficult, interesting, exciting, developing, promoting, earning, career-building, and inspiring.