In search of compromises: how to please different customers
- Transfer
Considering the needs of different customers within the same product is an incredibly difficult task. You encounter it when choosing features or ways to implement almost every product. Designing in a changing world with changing criteria for success can be difficult, but there are several creative approaches that can make it easier.
Recently, I had the experience of very successful communication with the CEO of one developing company (> 150 developers). When developing its product line, the company regularly encounters the problem of determining the balance of functionality - the one that is necessary for end users, as opposed to the one that is important for IT professionals. This issue is most relevant in a developing company when resources are limited and it is very important to win your first solvent customers.
I deliberately used the expression "as opposed to." More often than not, we consider such conflicts to be binary, “either / or”. This is the nature of the engineering view of such problems. “Salesmen” / marketers, on the contrary, often see this more likely as “and,” when the most desirable result is to satisfy the needs of each type of client. In practice, the boundaries between what needs to be done and what can be done are much less clear.
This is natural, since it is generally believed that IT people and end users are in opposition (by the way, I never really liked the terms “user” and “end user” - one wise program manager with whom I had the pleasure to work, once noted that "there is only one industry that calls its customers" users ", let's not be like it" (user - English the ling. Narik, approx. trans. ) It seems to IT professionals that end users exist only to be the cause of information leaks or to overload the network. End users (let's call them simply People) believe that the only goal of IT people is to prevent them from working. Again, in reality, everything is not so categorical.
However, we are constantly confronted with the need to make concessions when drawing up a list of functions and, as a result, a product development plan. In fact, it is easy to list the different types of customers of almost any modern product:
Not all potential customer categories will be relevant for any product, and not all types are listed in this list. Sometimes there are intersections: for example, often IT professionals are also enthusiasts and / or advanced users. Often, the term “person” is used to indicate the type of client. This is a good approach, but often instead of focusing on personality traits, it’s enough to define a general category in a broad sense to plan and evaluate a product. "Persons" will be involved later.
In industries characterized by a combination of physical products and physical distribution channels, products are segmented and offered with different characteristics at different prices for different customers. Software and hardware products that are used mixed or do not imply a separation into work or personal use, or switch between these functions several times a day, present a special problem for product developers (and marketing specialists). Work in the framework of this trend of consumerization has prompted me to write this post.
Regarding development for such a scenario, a product plan may suffer due to the following problems in planning or in approach:
The key to compromise is deciding in advance that you will agree to them. In fact, product development is always a compromise in many dimensions - in fact, it can be represented as a series of compromises and related decisions.
The cross-cutting themes of this series of articles are the need to address issues in the preparation of a plan and prepare in advance to make a choice. Than consider this micro-management in a “waterfall approach”, the team needs to come to principles that will guide it in the process of making daily decisions. Principles and plans work better than budgets, structures, or requirement lists. Principles are something that smart and creative people can effectively use as a tool to resolve conflicts that are inevitable when developing a product. Budgets and requirements are more like weapons that can be used against other parties to slow down the work. The principles show the team the start and end points and give advice on how to make decisions as you move towards the final result.
Suppose, for example, that the budget you have approved indicates how many resources will be allocated for People, how many for IT people. On paper, it looks good. This seems to be an easy way to decide in advance how to resolve conflicts and tensions.
However, this can have the opposite effect, as this is not a holistic plan of what the product should become. In fact, this impedes the implementation of a holistic plan, since in this case your first decision will be about sharing resources. Those responsible for these resources will continue to try to fulfill exactly their part of the plan instead of thinking about the whole project. This is not their malice, but simply a natural consequence of the distribution and accounting of resources.
A similar dynamic may occur if you split the command, for example, into front end / back end or interface / services. This is a good structure, but it should be created in the context of a holistic plan. Laying it before the plan itself appears, and then hoping that the plan will solve complex problems - this approach can create difficulties.
Conflicts and stress, in fact, arise from an approach based on resource budgeting: people naturally shift choices and decisions to management and resource allocation tools instead of acting on the basis of a jointly drawn up product plan.
Based on the information on how to develop the decision-making framework outlined in a previous post , the same tools can be used to cross-check the plan for each type of client.
We discussed a tool that allows you to highlight ideas regarding functionality and determine value, as a way to create a holistic view of a product. It can be used with different people in an organization or even with clients / partners.
Having compiled such a list, we can go further. It will not be superfluous to improve the list of proposed ideas, using your knowledge in the description of functionality and detail. It is useful at this stage to develop a catalog of functions, which, in your opinion, can be effectively conveyed to a wide audience of customers.
For example, for large projects, you can organize a presentation in the framework of master classes for clients in which you talk about the product. For a first-generation product, these functions can be posted on the website’s information page or even included in the content of the product review that you will offer to journalists.
You can gain an understanding of the concessions that you made regarding different types of customers by comparing all the product features with the types of consumers you defined. It is easy to imagine in the form of a table or even in a list drawn up on a blackboard.
Each function should be listed only once - one and the same “feature” should not be presented as implemented for more than one category of customers. This will make you decide who needs it most. The functions themselves will naturally be put in place. For example, management functionality will be assigned to IT specialists, and simplicity - to end users.
In this phase, most products will find the inevitable “skew” towards one type of customer. Further, the whole team needs to mentally go back and think about whether compromises were correctly identified.
Then repeat this process and make sure that you really have a complete plan. Once you get close to it, you can allocate resources. Of course, the process does not end there. With an improved presentation of the plan and resources, you can move on. The quality of implementation is then improved based on available resources, and this is better than idea generation and planning based on them. Unlike the characteristic “waterfall approach”, a good planning process is a process of iterations, combining and parallel cross-cutting actions in different areas.
Perhaps all of the above sounds good. By implementing all this, you will cope with the task of allocating resources and defining product boundaries relative to different types of customers. However, this does not solve one very serious issue. What if the client needs a conflict?
You can try to hide your head in the sand and just say that there is no conflict. Assume, for example, that end-users will appreciate the lack of opportunities omitted to please IT people. Or that IT specialists will somehow get used to the fact that the device arbitrarily downloads extensions. Of course, this number will not work.
Since product development never ends - the release becomes only a point on the time axis, especially today, in the context of continuous development cycles - you need to calmly relate to the fact that every release will not please everyone. But there will always be the next. Therefore, to determine the right trade-offs during development, you need a set of principles and a product architecture that you can take as a basis.
It is crucial to understand the long-term strategy of where your product is heading. Most products, when they are new, receive a mixture of praise and criticism, for example, from advanced users. If the scenario or the resolved problem looks convincing, advanced users will praise the product. As a rule, they are quick to get feedback and immediately throw up a bunch of suggestions on how to increase the flexibility of the product or add features. They like it.
In the process of product design, the designer must first know the direction of development. How do you learn how to add functionality and improve manageability? If you have no ideas on this subject at the design stage, you will design in vain. A famous example - the first version of the smartphone was released without copy / paste. But the designers knew exactly how the new design language would develop further. Understanding the development directions was very important, and facilitated the implementation of this function — without compromising the overall ease of use, which was the main advantage of the whole design. But we could easily stumble upon a conflict of functionality and ease of use.
Code architecture or architectural approaches play a key role in understanding where you are today and where you are moving. If you compare the platforms of modern operating systems with how they looked 10 years ago, you will see that many architectural differences were the result of compromises in architecture. Application stores, sandboxes, intermediary APIs - all this was invented to create an architecture that would become more secure, safe for the end user and allow devices to run on battery power longer.
Today, looking at these architectural changes and comparing with what it all began with, we can easily see the difference. But, think about how much you had to discuss and plan for this - it was a turning point in the approach. It was not easy for the creators of the platforms to make these compromises, proceeding precisely from this new approach. Creative approach to new requirements is the secret of understanding the evolution of your product over time.
It is important to have a tool in the form of a set of product principles - a design language, architectural decision templates, consumer value offers. These principles not only guide the development team, but also help explain to customers why you made these compromises. This will not facilitate the dialogue and will not force people to agree with your decisions. However, during the discussion it will be clear what goals your product is intended to achieve.
Amazing changes are taking place in our industry today with the advent of BYOD (Bring Your Own Device - permission to use personal devices at workplaces to access corporate resources). This is a whole new level of conflict that must be resolved. Since the late 90s, the essence of administration has been reduced to “blocking” or “controlling” the devices used. This was correct in the framework of the existing situation and the problems being solved.
Now users can bring their personal devices to work, work from home or find their own ways to carry out their tasks outside the boundaries of the corporate network / software / technology. This does not alter corporate or government requirements for reliability and security. This does not change the decision rules for IT. Their domestic customers have a choice, and it’s very interesting to see how this choice overlaps with product development conflicts.
Akin to how the API and capabilities of the OS are changing, forcing, perhaps, some categories of customers to reconsider their expectations, as well as devices and software are changing their architecture. At the stage of product planning, the development of such an approach to architecture that will be convenient in the long term is the main thing that will help to find the necessary compromises in the design.
This is an engineering component in conflict resolution - sometimes not just new functions, but new approaches to architecture define your new trajectory. This new trajectory defines new ways to design a product for many types of users.
The only thing you can be sure of is that there is no “right” choice of compromise, thanks to which it would be possible to satisfy all customers. This is the essence of development for different types of consumers. That is why product development is also social science.
Today, one of the most heated debates flares up over how to balance the needs of the company's IT services and the community of people using products within the company. This is a major shift in the industry due to a wave of products that allow you to act outside the scenarios controlled by the IT service.
It is absolutely certain that the needs of organizations are changing not in protecting their digital assets and not in maintaining the integrity of the corporate network - and not even in managing the common use of corporate resources (balance of work and activity not related to work). These requirements do not just remain relevant right now - in the modern world they are more important than ever, since any leakage of client or financial information may result in international news or interest supervisory authorities.
The change lies in the fact that people working in companies got easy access to tools that allow them to do what they need. At other times, the acquisition of servers, licensing of software, its on-site launch and work with them required the help of an IT service and, often, resources. Today, tools such as cloud storage, peer-to-peer interaction, CRM or even online stores are available in a couple of clicks, and all you need is a (corporate!) Credit card, and sometimes you can do without it.
The only regulatory mechanism that can be used to “fight” these instruments is a political approach. You can block TCP / IP ports or dubious network traffic (and, of course, block the loading of client applications on managed computers), but even this will not solve the problem. Access to the network is easy to get through a WiFi / 4G access point or through a phone in shared mode.
The usual methods of locking devices no longer work. In the world of mobile devices and, possibly, even many operating systems, there is no clearly defined point where you need to block, and of course, this can not be realized.
Someone sees this as freedom, someone sees chaos. And smart developers see this as an opportunity. This is a good opportunity to develop a product that solves this problem and is able to provide an architectural solution for IT, allowing them to do what is required of them; and at the same time, thanks to such a product, it will be easier for people to find and share tools with colleagues to solve their business problems.
The difficulty in developing is to define a new architecture that would take into account the real situation: if during design you hit too much in one of the directions, then drive yourself into a dead end. If you focus on giving people the maximum opportunity, your product may either run into IT service policies or, even worse, with an active company of the corporate analytics community against it. If you focus on the needs of IT people, it is possible that they will turn a good product into a closed or customized solution that will force end users to go to competitors - and they are always just a click away.
This is where design principles come into play. What management scheme is implemented now - is there anything implemented by IT companies that reduces the attractiveness of corporate use compared to home or, for example, BYOD? Perhaps measures like an exorbitant number of logon scripts or complex network access restrictions that make people avoid using the network and choose the path of least resistance instead? Or is it the possibility of personal settings that are applicable on home PCs, and because at work “everything is different”, a person tries to use a home computer for work too?
Given such an environment and the variety of possible solutions, which architecture can take into account the shortcomings of existing approaches to corporate network management and offer a more suitable option, while ensuring security?
Is it possible to control the device without changing the user experience? Is it possible to block a software product, leaving only vital functions, thereby reducing the number of calls to technical support - so that IT people are not torn between their work and the appeals of employees?
Such issues need to be raised when trying to reconcile the obviously contradictory needs of IT and people who use modern products and services. Deep immersion in such nuances during the development of your product can help create a truly competitive advantage for your product or service.
Customer Interest Compromise
Recently, I had the experience of very successful communication with the CEO of one developing company (> 150 developers). When developing its product line, the company regularly encounters the problem of determining the balance of functionality - the one that is necessary for end users, as opposed to the one that is important for IT professionals. This issue is most relevant in a developing company when resources are limited and it is very important to win your first solvent customers.
I deliberately used the expression "as opposed to." More often than not, we consider such conflicts to be binary, “either / or”. This is the nature of the engineering view of such problems. “Salesmen” / marketers, on the contrary, often see this more likely as “and,” when the most desirable result is to satisfy the needs of each type of client. In practice, the boundaries between what needs to be done and what can be done are much less clear.
This is natural, since it is generally believed that IT people and end users are in opposition (by the way, I never really liked the terms “user” and “end user” - one wise program manager with whom I had the pleasure to work, once noted that "there is only one industry that calls its customers" users ", let's not be like it" (user - English the ling. Narik, approx. trans. ) It seems to IT professionals that end users exist only to be the cause of information leaks or to overload the network. End users (let's call them simply People) believe that the only goal of IT people is to prevent them from working. Again, in reality, everything is not so categorical.
However, we are constantly confronted with the need to make concessions when drawing up a list of functions and, as a result, a product development plan. In fact, it is easy to list the different types of customers of almost any modern product:
- People . This is a wide range of people who will use your product. It is usually not assumed that these People have a high level of skill in using the product. These are typical customers. Of course, all other customers are also people :-) The difficulty that everyone faces is to present their clientele outside the framework of a typical consumer.
- IT professionals . It is IT people who buy, install and support most products. They may also be responsible for the infrastructure or equipment necessary to use the product / service. And IT people defend the interests of people in the companies that they support.
- Developers . Developers contribute to the writing of add-ons or use the API to create solutions that are tailored to specific needs. For many products, developers form a critical part of the ecosystem and often form the basis of its success.
- Advanced users / enthusiasts . These guys know the product far and wide. Often they teach others how to use it, subscribe to news and sit on forums, blog and write articles about your product. These are your fans. Advanced users also have wishes (requirements!) For functionality in terms of how to improve management, personalization options, and so on. Pay attention to how this can play against IT pros who need as few features as possible, or People who might be confused by these very features.
- Trading partners . Many products are sold directly to people or IT departments. But there are many who need intermediaries to sell them, to support or accept payment from customers. In the case of products that require advertising, these are your advertisers. This creates another stress factor, which is often referred to in relation to our industry - advertising in applications and websites, which is important for partners, but may not really like, for example, People.
- Markets . Many products are geared towards meeting the needs of a global customer base. But even across the global economy, there are serious differences in the functions and scenarios applicable in different countries and regions.
Not all potential customer categories will be relevant for any product, and not all types are listed in this list. Sometimes there are intersections: for example, often IT professionals are also enthusiasts and / or advanced users. Often, the term “person” is used to indicate the type of client. This is a good approach, but often instead of focusing on personality traits, it’s enough to define a general category in a broad sense to plan and evaluate a product. "Persons" will be involved later.
In industries characterized by a combination of physical products and physical distribution channels, products are segmented and offered with different characteristics at different prices for different customers. Software and hardware products that are used mixed or do not imply a separation into work or personal use, or switch between these functions several times a day, present a special problem for product developers (and marketing specialists). Work in the framework of this trend of consumerization has prompted me to write this post.
Regarding development for such a scenario, a product plan may suffer due to the following problems in planning or in approach:
- Focus on only one type of client . Sometimes the approach is simply to take and draw a line, saying to ourselves, "we focus on the end user." Often this approach is applied by default to most products. For some products, there is a clear idea of the target audience and a clear strategy. This is followed by “some opportunities” aimed at catering to other types of potential customers. You can justify this logically by combining the types of customers and taking as a basis a statement like “Developers are just People who can write code.”
- Make a little everywhere . It may happen that the product is not very well thought out, and the organization or the party providing the preliminary financing, as a result, begins to indicate how much the product should be focused on a particular type of client. For example, if you allocate several developers for each segment and let them plan independently, the chances that all the functions will eventually be combined are greatly reduced. Most likely, then these functions will compete or conflict during development.
- Develop a plan (and partially implement it) and then in the process realize that you missed the client . We have already discussed the need to combine engineering and marketing efforts. Some plans are created, taking into account only the approach from the development side, which does not pay off, and as soon as the product begins to take shape, inevitably a panic begins in the series “we do not have functions for X”, where X is the type of client who is “not liked” during development . Meeting. Panic. "Finishing" at the last moment. Does not work.
The key to compromise is deciding in advance that you will agree to them. In fact, product development is always a compromise in many dimensions - in fact, it can be represented as a series of compromises and related decisions.
Get ready to make a choice
The cross-cutting themes of this series of articles are the need to address issues in the preparation of a plan and prepare in advance to make a choice. Than consider this micro-management in a “waterfall approach”, the team needs to come to principles that will guide it in the process of making daily decisions. Principles and plans work better than budgets, structures, or requirement lists. Principles are something that smart and creative people can effectively use as a tool to resolve conflicts that are inevitable when developing a product. Budgets and requirements are more like weapons that can be used against other parties to slow down the work. The principles show the team the start and end points and give advice on how to make decisions as you move towards the final result.
Suppose, for example, that the budget you have approved indicates how many resources will be allocated for People, how many for IT people. On paper, it looks good. This seems to be an easy way to decide in advance how to resolve conflicts and tensions.
However, this can have the opposite effect, as this is not a holistic plan of what the product should become. In fact, this impedes the implementation of a holistic plan, since in this case your first decision will be about sharing resources. Those responsible for these resources will continue to try to fulfill exactly their part of the plan instead of thinking about the whole project. This is not their malice, but simply a natural consequence of the distribution and accounting of resources.
A similar dynamic may occur if you split the command, for example, into front end / back end or interface / services. This is a good structure, but it should be created in the context of a holistic plan. Laying it before the plan itself appears, and then hoping that the plan will solve complex problems - this approach can create difficulties.
Conflicts and stress, in fact, arise from an approach based on resource budgeting: people naturally shift choices and decisions to management and resource allocation tools instead of acting on the basis of a jointly drawn up product plan.
An approach
Based on the information on how to develop the decision-making framework outlined in a previous post , the same tools can be used to cross-check the plan for each type of client.
We discussed a tool that allows you to highlight ideas regarding functionality and determine value, as a way to create a holistic view of a product. It can be used with different people in an organization or even with clients / partners.
Having compiled such a list, we can go further. It will not be superfluous to improve the list of proposed ideas, using your knowledge in the description of functionality and detail. It is useful at this stage to develop a catalog of functions, which, in your opinion, can be effectively conveyed to a wide audience of customers.
For example, for large projects, you can organize a presentation in the framework of master classes for clients in which you talk about the product. For a first-generation product, these functions can be posted on the website’s information page or even included in the content of the product review that you will offer to journalists.
You can gain an understanding of the concessions that you made regarding different types of customers by comparing all the product features with the types of consumers you defined. It is easy to imagine in the form of a table or even in a list drawn up on a blackboard.
Each function should be listed only once - one and the same “feature” should not be presented as implemented for more than one category of customers. This will make you decide who needs it most. The functions themselves will naturally be put in place. For example, management functionality will be assigned to IT specialists, and simplicity - to end users.
In this phase, most products will find the inevitable “skew” towards one type of customer. Further, the whole team needs to mentally go back and think about whether compromises were correctly identified.
Then repeat this process and make sure that you really have a complete plan. Once you get close to it, you can allocate resources. Of course, the process does not end there. With an improved presentation of the plan and resources, you can move on. The quality of implementation is then improved based on available resources, and this is better than idea generation and planning based on them. Unlike the characteristic “waterfall approach”, a good planning process is a process of iterations, combining and parallel cross-cutting actions in different areas.
Conflict Design
Perhaps all of the above sounds good. By implementing all this, you will cope with the task of allocating resources and defining product boundaries relative to different types of customers. However, this does not solve one very serious issue. What if the client needs a conflict?
You can try to hide your head in the sand and just say that there is no conflict. Assume, for example, that end-users will appreciate the lack of opportunities omitted to please IT people. Or that IT specialists will somehow get used to the fact that the device arbitrarily downloads extensions. Of course, this number will not work.
Since product development never ends - the release becomes only a point on the time axis, especially today, in the context of continuous development cycles - you need to calmly relate to the fact that every release will not please everyone. But there will always be the next. Therefore, to determine the right trade-offs during development, you need a set of principles and a product architecture that you can take as a basis.
It is crucial to understand the long-term strategy of where your product is heading. Most products, when they are new, receive a mixture of praise and criticism, for example, from advanced users. If the scenario or the resolved problem looks convincing, advanced users will praise the product. As a rule, they are quick to get feedback and immediately throw up a bunch of suggestions on how to increase the flexibility of the product or add features. They like it.
In the process of product design, the designer must first know the direction of development. How do you learn how to add functionality and improve manageability? If you have no ideas on this subject at the design stage, you will design in vain. A famous example - the first version of the smartphone was released without copy / paste. But the designers knew exactly how the new design language would develop further. Understanding the development directions was very important, and facilitated the implementation of this function — without compromising the overall ease of use, which was the main advantage of the whole design. But we could easily stumble upon a conflict of functionality and ease of use.
Code architecture or architectural approaches play a key role in understanding where you are today and where you are moving. If you compare the platforms of modern operating systems with how they looked 10 years ago, you will see that many architectural differences were the result of compromises in architecture. Application stores, sandboxes, intermediary APIs - all this was invented to create an architecture that would become more secure, safe for the end user and allow devices to run on battery power longer.
Today, looking at these architectural changes and comparing with what it all began with, we can easily see the difference. But, think about how much you had to discuss and plan for this - it was a turning point in the approach. It was not easy for the creators of the platforms to make these compromises, proceeding precisely from this new approach. Creative approach to new requirements is the secret of understanding the evolution of your product over time.
It is important to have a tool in the form of a set of product principles - a design language, architectural decision templates, consumer value offers. These principles not only guide the development team, but also help explain to customers why you made these compromises. This will not facilitate the dialogue and will not force people to agree with your decisions. However, during the discussion it will be clear what goals your product is intended to achieve.
Amazing changes are taking place in our industry today with the advent of BYOD (Bring Your Own Device - permission to use personal devices at workplaces to access corporate resources). This is a whole new level of conflict that must be resolved. Since the late 90s, the essence of administration has been reduced to “blocking” or “controlling” the devices used. This was correct in the framework of the existing situation and the problems being solved.
Now users can bring their personal devices to work, work from home or find their own ways to carry out their tasks outside the boundaries of the corporate network / software / technology. This does not alter corporate or government requirements for reliability and security. This does not change the decision rules for IT. Their domestic customers have a choice, and it’s very interesting to see how this choice overlaps with product development conflicts.
Akin to how the API and capabilities of the OS are changing, forcing, perhaps, some categories of customers to reconsider their expectations, as well as devices and software are changing their architecture. At the stage of product planning, the development of such an approach to architecture that will be convenient in the long term is the main thing that will help to find the necessary compromises in the design.
This is an engineering component in conflict resolution - sometimes not just new functions, but new approaches to architecture define your new trajectory. This new trajectory defines new ways to design a product for many types of users.
The only thing you can be sure of is that there is no “right” choice of compromise, thanks to which it would be possible to satisfy all customers. This is the essence of development for different types of consumers. That is why product development is also social science.
Example: Corporate Problem
Today, one of the most heated debates flares up over how to balance the needs of the company's IT services and the community of people using products within the company. This is a major shift in the industry due to a wave of products that allow you to act outside the scenarios controlled by the IT service.
It is absolutely certain that the needs of organizations are changing not in protecting their digital assets and not in maintaining the integrity of the corporate network - and not even in managing the common use of corporate resources (balance of work and activity not related to work). These requirements do not just remain relevant right now - in the modern world they are more important than ever, since any leakage of client or financial information may result in international news or interest supervisory authorities.
The change lies in the fact that people working in companies got easy access to tools that allow them to do what they need. At other times, the acquisition of servers, licensing of software, its on-site launch and work with them required the help of an IT service and, often, resources. Today, tools such as cloud storage, peer-to-peer interaction, CRM or even online stores are available in a couple of clicks, and all you need is a (corporate!) Credit card, and sometimes you can do without it.
The only regulatory mechanism that can be used to “fight” these instruments is a political approach. You can block TCP / IP ports or dubious network traffic (and, of course, block the loading of client applications on managed computers), but even this will not solve the problem. Access to the network is easy to get through a WiFi / 4G access point or through a phone in shared mode.
The usual methods of locking devices no longer work. In the world of mobile devices and, possibly, even many operating systems, there is no clearly defined point where you need to block, and of course, this can not be realized.
Someone sees this as freedom, someone sees chaos. And smart developers see this as an opportunity. This is a good opportunity to develop a product that solves this problem and is able to provide an architectural solution for IT, allowing them to do what is required of them; and at the same time, thanks to such a product, it will be easier for people to find and share tools with colleagues to solve their business problems.
The difficulty in developing is to define a new architecture that would take into account the real situation: if during design you hit too much in one of the directions, then drive yourself into a dead end. If you focus on giving people the maximum opportunity, your product may either run into IT service policies or, even worse, with an active company of the corporate analytics community against it. If you focus on the needs of IT people, it is possible that they will turn a good product into a closed or customized solution that will force end users to go to competitors - and they are always just a click away.
This is where design principles come into play. What management scheme is implemented now - is there anything implemented by IT companies that reduces the attractiveness of corporate use compared to home or, for example, BYOD? Perhaps measures like an exorbitant number of logon scripts or complex network access restrictions that make people avoid using the network and choose the path of least resistance instead? Or is it the possibility of personal settings that are applicable on home PCs, and because at work “everything is different”, a person tries to use a home computer for work too?
Given such an environment and the variety of possible solutions, which architecture can take into account the shortcomings of existing approaches to corporate network management and offer a more suitable option, while ensuring security?
Is it possible to control the device without changing the user experience? Is it possible to block a software product, leaving only vital functions, thereby reducing the number of calls to technical support - so that IT people are not torn between their work and the appeals of employees?
Such issues need to be raised when trying to reconcile the obviously contradictory needs of IT and people who use modern products and services. Deep immersion in such nuances during the development of your product can help create a truly competitive advantage for your product or service.