According to human resources specialists, IT in Romania is one of the few domains in which the number of available jobs has raised after the beginning of the economical crises and one in which companies compete for the best specialists.
The idea that keeps coming up is that in the competition with the low costs of the employees of other geographic areas (such as, for example, Asia), the solution is to migrate from outsourcing to one"s own products, or, in a less radical process, to change the relationship with the clients and turn the status of mere executant (such as it could be induced by the outsourcing model) into a status of consultant (which would turn the IT companies into partners for their customers).
Product Mindset represents a modern and challenging approach based on the idea of developing one"s own product applied in a context that is specific to providing IT services, by maintaining the main advantages of both directions.
This approach has both advantages and disadvantages and the purpose of this article is to present in detail the most important ones.
Before offering a detailed image of what product mindset would represent for the outsourcing area of the software industry, we will present some definitions.
Product mindset refers to the idea of extracting information about what the clients want from a product without them stating directly or exactly this thing, eventually developing a product they are happy with.
By contrast, services mindset represents the idea of achieving very well what a certain client wants and specifies. The clients voice the requirements and if these requirements are not well defined, successive questions are asked with the aim of clarifying all aspects.
The main difference between the two approaches is represented by the decisive involvement of the person developing the product to identify the features and define its final form. If the services mindset approach sees the development team as formed by mere (but very good) executants, product mindset sees the development team as a team of consultants for the development of the product, the client and the team becoming, thus, partners.
We will further detail some of the defining aspects of the companies that are services oriented (CoS) as compared to those of product oriented companies (CoP). For each of the two approaches we enumerated those aspects which seemed relevant to the subject of the present article. In the case of CoS, it often happens that a project lasts for several months, after which the members of the project team continue to work (together or not) to totally different projects, that belong to different domains and, why not, using totally different technologies (or the same technology, but different frameworks and versions). About 50-60% of the new employees will learn and will make the transition towards new technologies right from the beginning and almost all are likely to change the technology during the employment. In a very high percentage (90%) the candidates for the vacancies in CoS will not be interviewed by the team in which they will work.
By contrast, the applicants in CoP are interviewed much more carefully in order to see if they fit in with the team they will work in, both from the technical point of view as well as from that of personality. Furthermore, during the period of employment they will not change the technology and the team that easily.
CoP generally attach great importance to employee satisfaction and considers that the leave of one of them constitutes an important loss. The experience accumulated in time in the development of the companies" products makes a certain person hard to be replaced. On the other hand, in the case of CoS, the employees leave more often and seldom affect the company significantly. The low impact on the company is due to the fact that most of the times the CoS employees rarely develop expertise at product level, as mere programming knowledge is enough to carry out the tasks. On the other hand, the frequency of these often changes of jobs can be explained to a certain extent by the fact that the employee has the opportunity to work in time on different projects and in different teams within the company (the transition towards another company may seem an ordinary process). The dynamic technological context contributes in its turn to facilitate the changing of employer. In a CoP there is the possibility to work for a longer period of time on a very particular technology. In this context, the employees are much more interested in remaining and specializing within the company.
In the services oriented companies, the employees are evaluated according to the quantity of work they perform, the responsibilities they assume and the degree of client"s satisfaction. The connection between effort and promotion or remuneration is, generally, more clear. In the case of product oriented companies, the effort put to achieve the aims of the product is seen as a natural, basic activity. The promotion or a more significant leap from the point of view of the salary happens when other activities are performed, activities that are not connected to the natural work activity, such as article writing or keeping professional blogs, putting forth technical presentations within different events, etc.
Consequently, there is also a certain contrast in relation to the title of the position/ seniority occupied by the employees. The transition from junior programmer to intermediate and then senior programmer is done more quickly and more easily in CoS and it is directly depending on seniority. In CoP a person remains on a senior position constantly for a longer period of time and the number of years spent in a domain does not constitute an argument sufficient for promotion. The main argument is that of expertise in the domain in which the employee works.
Parenthetically, we have to mention that the position "earned" by a person in a CoP remains permanent and it strengthens in time. In CoS, with every new project, the position has to be reconfirmed and the client"s trust in the person that plays a certain role must be re-earned. As opposed to the new projects in CoP, where a person brings along their reputation gained during the previous projects, in CoS everything starts from zero and the client must be persuaded by the team"s quality as if there were no relevant past behind.
In another train of thoughts, CoS gains contracts before its competitors, by ensuring a quicker delivery of the same quality (and/or lower costs). In many cases, this is materialized in a sustained effort of the team and the completion of the project is celebrated by the team. CoP very rarely delivers the products on their deadline, but most of the times they are richer in features than it was initially planned.
Another interesting paradox is the fact that in CoS the projects are obtained upon proving the employees" professionalism and the history of references. However, for most of the newly obtained projects, new people will be hired for the project team, people whose professionalism has not been yet proven.
We will not find a company exclusively oriented towards its own products trying to obtain a maturity certificate. Why would it need the certification of an external organization when it is already developing new products on the market? On the other hand, such a certification assures the clients that the products achieved by a CoS are according to certain quality standards.
Financially, the CoS grow linearly along with the increase in the number of projects and the number of employees. However, the necessary of capital is low, since the money for the offered services will be received right from the beginning of the project. In CoP, financial growth is according to the number of clients and outlets for their products and the relation between the profit and the number of employees is much more favorable than in the case of CoS. Moreover, a bigger capital is necessary for the development, promotion and sale of the product. A special budget is allocated to marketing and sale.
In practice we are likely to never encounter one of the two approaches implemented in a pure manner. For each of the mentioned traits we can find valid counterexamples among the companies we see around us. This thing happens, on the one hand, because of the vision that some of the managers of companies have, but also, on the other hand, to some companies" lack of maturity, which sometimes leads to the implementation of wrong strategies, ignoring the context. Still, the essential features are maintained in most of the cases and they represent a very good starting point for the debate on product mindset.
One of the most interesting challenges is that of bringing together the advantages of the two above mentioned approaches and diminishing the disadvantages that derive from each of them. Their combination refers to introducing elements that are specific to services based project approach into CoP or to the implementation of a product based approach in CoS. There is also a third type combination, namely that in which we deal with a company oriented on services as well as on products, but this case can be reduced to the preceding cases if we do not take into consideration the departments that manage the products and the services of such a company.
We will focus below on the second type of combination, leaving the other two as subjects for a possible future article.
Product Mindset is a manner of approaching services which implies a significant value added to the provided services. It offers greater satisfactions to the clients and the gained profit is noticeably enhanced. In the case of IT industry, the client"s product or products are "adopted" by the company which implements such a product mindset and the software companies" involvement is no longer exclusively centered on execution. New roles appear, which double or sometimes even replace the ones that are naturally included in the client"s responsibilities (such as, for example, the role of product owner).
There are two elements specific to CoS that impose a certain inflexibility in the activity and require special attention when one wishes to implement a product mindset. First of all, there is the team"s reluctance to work with incomplete specifications. Generally, the team expects all the details concerning a feature (or a user story) to be clarified by the client before beginning its development. Arguing that this way they avoid wasting effort on developing and rewriting some parts of the application twice or several times, the project team postpones the development of some essential elements of the application, focusing its effort on a "ping-pong" exchange of emails or clarification meetings which can last forever. Product mindset project approach implies the implementation of features that have not been completely specified by the client. Obviously, this means knowing as well as possible the business domain of the client and at the same time it implies a higher degree of risk. However, this way, the development of important features is no longer impeded, since the client is now much more capable to identify its needs, having an already implemented example.
A second essential issue is represented by the project team"s incapacity to understand and follow through the client"s suggestions regarding the completion of a product or module to the detriment of its quality. A solution that is particular and not generic, flexible and adaptable (but which takes longer to develop), the maintenance of some components written in an "ancient" technology instead of rewriting and "updating" them, a partial implementation of some features or the incomplete testing of the product sometimes represent the clients" explicit requirements in order to force the meeting of some deadlines that are essential to the product"s fate. If they are not made to a team having a product mindset, such suggestions may lead to its members" frustration and even to the refusal of some of them to continue working on the project, as they complain about a supposed lack of professionalism. Solving this problem implies effort from both directions: the client has to be willing to share with the project team the elements that relate to the product"s life, but the team also needs to be interested in these aspects and not entirely focused on execution.
A product mindset approach helps long lasting collaborations between the CoS and their clients, as the latter see the development team as part of their own organization, crediting it with trust and respect. This togetherness, however, may result in an attachment, sometimes exaggerated, of the team members for the client and its product(s), some of them even considering themselves employees of the client and not of the services company they are part of.
Furthermore, some special attention must be paid to project completion, since such moments can actuate the resignation from the company by many of those who have developed a great attachment to the project.
The analysis of the implementation of a product oriented approach in a company whose activity is mainly oriented toward services is far from being an exhaustive one. However, the tackled aspects are relevant ones, as they influence decisively the path and success of a CoS in IT and the advantages of implementing such a combination are obvious. The manner of implementing this combination is, of course, another discussion as it greatly depends on the organizational culture and the internal procedures existing in each and every company.
by Radu Olaru
by Ovidiu Mățan
