In search of compromises: how to please different customers
Taking into account the needs of different customers within the same product is an incredibly difficult task. You encounter it when choosing functions or ways to implement almost every product. Designing in a changing world with changing criteria for success may not be easy, but there are several creative approaches that can make it easier.
Recently, I had the experience of very successful communication with the CEO of a growing company (> 150 developers). When developing its product line, the company regularly encounters the problem of determining the balance of functionality - that which is necessary for end users, as opposed to that which is important for IT professionals. This question is most relevant in a developing company, when resources are limited and it is very important to win their first paying customers.
I deliberately used the expression "as opposed to." Most often we consider such conflicts to be binary, “or / or.” Such is the nature of the engineering view of such problems. Sales people / marketers, on the contrary, often see it more as an “and” when the most desired result is to satisfy the needs of each type of customer. 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 usually considered that IT professionals and end users are in opposition (by the way, I have never particularly favored the terms “user” and “end user” - one wise program manager with whom I had the pleasure to work, once remarked that "there is only one industry that calls its customers" users ", let's not be like it". ( user - English jarg. "narik", approx. lane. ) IT-specialists think that end users exist only in order to be the cause of cons . Nuts information or to overload the network end-users (let's call them ordinary people) believe that the sole purpose of "IT people." - do not let them work again, the reality is not so categorical.
')
Nevertheless, we are constantly faced with the need to make concessions during the compilation of the list of functions and, as a consequence, the product development plan. In fact, it is easy to list the different types of customers of almost any modern product:
Not all categories of potential customers will be relevant for every product, and not all types are given 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, rather than focusing on personality traits, it’s enough to plan and evaluate a product simply by defining a general category in a broad sense. "Persons" will be involved later.
In industries that are 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 involve separation of use in work or for personal needs, or switch between these functions several times a day, present a particular problem for product developers (and marketing specialists). The work within the framework of this trend of consumerisation and pushed me to write this post.
Regarding the development for such a scenario, the product plan may suffer due to the following problems in planning or in the approach:
The key to the problem of compromise is to decide in advance that you will go to them. In fact, product development is always a trade-off in many dimensions - in fact, it can be presented as a series of trade-offs and related decisions.
The cross-cutting themes of this series of articles are the need to uncover problems when drawing up a plan and get ready in advance to make a choice. Than to consider this as a micro-management in the “waterfall approach”, the team needs to come to the principles that will guide it in the process of making daily decisions. Principles and plans work better than budgets, structures, or lists of requirements. Principles are what smart and creative people can effectively use as a tool for resolving 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 work. The principles show the team the starting and ending points and give tips on how to make decisions as you move towards the final result.
Suppose, for example, that the budget approved by you indicates how much resources will be allocated for People, how much for IT people. On paper it looks good. It seems that this is an easy way to decide in advance how to eliminate conflicts and tension.
However, this may have the opposite effect, since it is not a holistic plan for what the product should be. In fact, this impedes the implementation of a holistic plan, since in this case, your first decision will concern the division of resources. 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 evil intent, but simply a natural consequence of the allocation and accounting of resources.
A similar dynamics can occur if you divide a command, for example, by the 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 difficult problems — such an approach can create difficulties.
Conflicts and tensions, in fact, arise from a resource-based approach: people naturally shift choices and decisions to management and resource allocation tools rather than acting on a jointly compiled product plan.
Based on the information on how to develop a decision-making framework outlined in the 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 select ideas for functionality and determine cost as a way to create a holistic view of a product. It can be used with different people in the organization or even with clients / partners.
Making such a list, you can go further. It will not be superfluous to improve the list of proposed ideas, using your knowledge in the description of the functional and detail. It is useful at this stage to develop a catalog of functions that, in your opinion, can be effectively conveyed to a wide audience of customers.
For example, for large projects, you can organize a presentation in a master class for clients in which you tell about a product. For the first generation product, these functions can be posted on the information page of the site or even included in the content of the product review that you will offer to journalists.
It is possible to gain an understanding of the concessions that you made in relation to different types of customers by comparing all the functions of the product with the types of consumers you have defined. It is easy to present in the form of a table or even a list drawn up on the board.
Each function should appear in the list only once - the same “feature” should not be presented as implemented for more than one category of customers. It will make you decide who needs it most. Functions themselves naturally arranged in places. For example, management functionality will be assigned to IT professionals, and simplicity - to end users.
At this phase, most products will find the inevitable "bias" in the direction of one type of customer. Next, the whole team must mentally go back and think about whether the compromises were determined correctly.
Then repeat this process and make sure you really get a holistic plan. As soon as you get close to it, you can allocate resources. Of course, the process does not end there. With an improved view of the plan and resources, you can move on. The quality of implementation is then enhanced based on the resources available, and this is better than the idea generation and planning based on them. In contrast to the characteristic “waterfall approach”, a good planning process is a process of iterations, combining and parallel cross-cutting activities in different areas.
Perhaps all this sounds good. By implementing all this, you will cope with the task of allocating resources and determining the boundaries of a product 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 bury your head in the sand and just say that there is no conflict. Assume, for example, that end users will appreciate the lack of features left out to please IT professionals. Or that IT specialists will somehow get used to the fact that the device automatically 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 accept that in every release you cannot please everyone. But there will always be the next one. Therefore, to determine the right trade-offs in development, you need a set of principles and product architecture that you can use as a basis.
It is extremely important to understand the long-term strategy - 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 script or the solved problem looks convincing, advanced users will extol the product. They, as a rule, are quick on the feedback and immediately throw up a bunch of suggestions on how to increase the flexibility of the product or add functions. 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 at the design stage, you will be wasting a project. A famous example is that the first version of the smartphone was released without the copy / paste function. But the designers knew exactly how the new design language would continue to develop. Understanding the directions of development was very important, and facilitated the implementation of this function — without compromising the overall ease of use, which was the main advantage of the entire 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 going. If you compare modern OS platforms with how they looked 10 years ago, you will see that many architectural differences were the result of compromises in architecture. App stores, sandboxes, reseller APIs — all this was invented to create an architecture that would become more secure, safe for the end user, and allow devices to work longer on battery power.
Today, looking at these architectural changes and comparing with how it all began, we can easily see the difference. But, think about how much you had to discuss and plan for this - this was a turning point in the approach. Platform creators had a hard time making these compromises, based on this new approach. A creative approach to new requirements is the secret to understanding the evolution of your product over time.
It is important to have a tool in the form of a set of product principles - design language, architectural solution patterns, customer value suggestions. These principles not only guide the development team, but also help explain to customers why you went to these trade-offs. This will not facilitate the dialogue and will not force people to agree with your decisions. However, when discussing, it will be clear what goals your product is intended to achieve.
Amazing changes are occurring in our industry today with the advent of "BYOD" (Bring Your Own Device - allowing the use of personal devices in the workplace to access corporate resources). This is a completely new level of conflict that has to be resolved. Since the end of the 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 problems to be solved.
Now users can bring their personal devices to work, work from home or find their own ways to perform their tasks outside the boundaries of the corporate network / software / technology. It does not change corporate or government requirements for reliability and security. This does not change the decision rules for IT. Their internal customers have a choice, and it’s very interesting to see how this choice overlaps with product development conflicts.
It is akin to how the API and the capabilities of the OS change, forcing, perhaps, some categories of customers to reconsider their expectations, as well as devices and software change their architecture. At the planning stage of the product, 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 the 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 of designing a product for many types of users.
The only thing you can be sure of is that there is no “right” choice of compromises that could satisfy all customers. This is the essence of development for different types of consumers. That is why product development is also a social science.
Today, one of the hottest debates is about how to balance the needs of the company's IT services and the community of people using the products within that company. This is a major shift in the industry due to a wave of products that allow it to operate outside the scenarios controlled by the IT service.
It is absolutely certain that the changing needs of organizations are not in protecting their digital assets or maintaining the integrity of the corporate network — or even managing the overall use of corporate resources (the balance of work and non-work activity). These requirements now do not just remain relevant - in the modern world they are more important than ever, because any leakage of client or financial information may result in international news or supervisors.
The changes lie in the fact that people working in companies have easy access to tools that allow them to do what they need. At other times, the acquisition of servers, licensing of software, its launch on-site and working with them required the help of IT services 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 against" these tools is a political approach. You can block TCP / IP ports or doubtful network traffic (and, of course, block the download of client applications on managed computers), but even this does not solve the problem. Access to the network is easily obtained via a WiFi / 4G access point or via a phone in shared mode.
The usual methods of blocking devices no longer work. In the world of mobile devices and, perhaps, even a multitude of operating systems, there is no clearly defined point where it is necessary to block, and of course, this can not be realized.
Someone sees freedom in this, someone - 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 this product, it will be easier for people to find and share tools with their colleagues for solving their business problems.
The difficulty in developing is to define a new architecture that would take into account the real situation: if you are too hard to hit one of the directions when designing, then you will be stumped. If you focus on giving people maximum opportunity, your product may either be confronted with IT policies or, worse, with an active corporate analyst community company 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 those are always just a click away.
This is where design principles come into play. What is the management scheme implemented now - is there anything that is implemented by IT companies that reduces the attractiveness of corporate use in comparison with the home or, for example, with BYOD? Perhaps measures like an exorbitant number of logon scripts or complex network access restrictions that cause people to avoid using the network and instead choose the path of least resistance? Or are these features of personal settings that are applicable both on home PCs and because “everything is different” at work, does a person try to use a home computer for work?
Given this environment and the variety of possible solutions, which architecture will be able to take into account the shortcomings of existing approaches to corporate network management and offer a more suitable option, while at the same time ensuring security?
Can I 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 employee requests?
Such questions 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 compromise
Recently, I had the experience of very successful communication with the CEO of a growing company (> 150 developers). When developing its product line, the company regularly encounters the problem of determining the balance of functionality - that which is necessary for end users, as opposed to that which is important for IT professionals. This question is most relevant in a developing company, when resources are limited and it is very important to win their first paying customers.
I deliberately used the expression "as opposed to." Most often we consider such conflicts to be binary, “or / or.” Such is the nature of the engineering view of such problems. Sales people / marketers, on the contrary, often see it more as an “and” when the most desired result is to satisfy the needs of each type of customer. 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 usually considered that IT professionals and end users are in opposition (by the way, I have never particularly favored the terms “user” and “end user” - one wise program manager with whom I had the pleasure to work, once remarked that "there is only one industry that calls its customers" users ", let's not be like it". ( user - English jarg. "narik", approx. lane. ) IT-specialists think that end users exist only in order to be the cause of cons . Nuts information or to overload the network end-users (let's call them ordinary people) believe that the sole purpose of "IT people." - do not let them work again, the reality is not so categorical.
')
Nevertheless, we are constantly faced with the need to make concessions during the compilation of the list of functions and, as a consequence, the 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 those who will apply your product. It is not usually assumed that these People have a high level of skill in using the product. These are typical customers. Of course, all other clients are people too :-) The difficulty that everyone faces is to present their clientele beyond the framework of a typical consumer.
- IT professionals . IT pros buy, install and support most products. They may also be responsible for the infrastructure or equipment necessary to use the product / service. And IT specialists defend the interests of people in the companies they support.
- The 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 an 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, write blogs 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, customization capabilities, and so on. Pay attention to how this can play against IT pros who need as little as possible of such functions, or People who these very possibilities can confuse.
- Trading partners . Many products are sold directly to people or IT departments. But there are a lot of those for whom intermediaries are needed in order to sell them, support or accept payments from customers. In the case of products that require advertising, these people will be your advertisers. This creates another stress factor, which is often talked about in our industry - advertising in applications and on websites, which is important for partners, but may not be particularly like, for example, People.
- Markets Many products are designed to meet the needs of a global customer base. But even in the scale of the global economy, there are major differences in the functions and scenarios applicable in different countries and regions.
Not all categories of potential customers will be relevant for every product, and not all types are given 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, rather than focusing on personality traits, it’s enough to plan and evaluate a product simply by defining a general category in a broad sense. "Persons" will be involved later.
In industries that are 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 involve separation of use in work or for personal needs, or switch between these functions several times a day, present a particular problem for product developers (and marketing specialists). The work within the framework of this trend of consumerisation and pushed me to write this post.
Regarding the development for such a scenario, the product plan may suffer due to the following problems in planning or in the approach:
- Focus on only one type of client . Sometimes the approach is only to simply take and hold the line, saying to ourselves "we focus on the end user." Often, this default approach is applied to most products. For some products, there is a clear idea of ​​the target audience and a clear strategy. Then “some opportunities” follow, aimed at pleasing other types of potential customers. You can rationally justify this by combining the types of customers and adopting a statement like “Developers are just People who can write code” as a basis.
- Do a little bit of everything everywhere . It may happen that the product is not very well thought out, and the organization or party that provides pre-financing, eventually begin to indicate how the product should be focused on a particular type of customer. For example, if you select several developers for each segment and let them plan independently from each other, the chances that all the functions will be able to be combined in the end are sharply reduced. Most likely, then these functions will compete or conflict in the course of development.
- Develop a plan (and partially implement it) and then, in the process, realize that you missed a client . We have already discussed the need to combine engineering and marketing efforts. Some plans are created, taking into account only the development approach, which does not pay off, and as soon as the product begins to take shape, panic from the series “we have no functions for X” inevitably begins, where X is a type of client who is “indifferent” during . Meetings. Panic. "Finishing" at the last moment. Does not work.
The key to the problem of compromise is to decide in advance that you will go to them. In fact, product development is always a trade-off in many dimensions - in fact, it can be presented as a series of trade-offs and related decisions.
Get ready to make a choice
The cross-cutting themes of this series of articles are the need to uncover problems when drawing up a plan and get ready in advance to make a choice. Than to consider this as a micro-management in the “waterfall approach”, the team needs to come to the principles that will guide it in the process of making daily decisions. Principles and plans work better than budgets, structures, or lists of requirements. Principles are what smart and creative people can effectively use as a tool for resolving 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 work. The principles show the team the starting and ending points and give tips on how to make decisions as you move towards the final result.
Suppose, for example, that the budget approved by you indicates how much resources will be allocated for People, how much for IT people. On paper it looks good. It seems that this is an easy way to decide in advance how to eliminate conflicts and tension.
However, this may have the opposite effect, since it is not a holistic plan for what the product should be. In fact, this impedes the implementation of a holistic plan, since in this case, your first decision will concern the division of resources. 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 evil intent, but simply a natural consequence of the allocation and accounting of resources.
A similar dynamics can occur if you divide a command, for example, by the 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 difficult problems — such an approach can create difficulties.
Conflicts and tensions, in fact, arise from a resource-based approach: people naturally shift choices and decisions to management and resource allocation tools rather than acting on a jointly compiled product plan.
An approach
Based on the information on how to develop a decision-making framework outlined in the 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 select ideas for functionality and determine cost as a way to create a holistic view of a product. It can be used with different people in the organization or even with clients / partners.
Making such a list, you can go further. It will not be superfluous to improve the list of proposed ideas, using your knowledge in the description of the functional and detail. It is useful at this stage to develop a catalog of functions that, in your opinion, can be effectively conveyed to a wide audience of customers.
For example, for large projects, you can organize a presentation in a master class for clients in which you tell about a product. For the first generation product, these functions can be posted on the information page of the site or even included in the content of the product review that you will offer to journalists.
It is possible to gain an understanding of the concessions that you made in relation to different types of customers by comparing all the functions of the product with the types of consumers you have defined. It is easy to present in the form of a table or even a list drawn up on the board.
Each function should appear in the list only once - the same “feature” should not be presented as implemented for more than one category of customers. It will make you decide who needs it most. Functions themselves naturally arranged in places. For example, management functionality will be assigned to IT professionals, and simplicity - to end users.
At this phase, most products will find the inevitable "bias" in the direction of one type of customer. Next, the whole team must mentally go back and think about whether the compromises were determined correctly.
Then repeat this process and make sure you really get a holistic plan. As soon as you get close to it, you can allocate resources. Of course, the process does not end there. With an improved view of the plan and resources, you can move on. The quality of implementation is then enhanced based on the resources available, and this is better than the idea generation and planning based on them. In contrast to the characteristic “waterfall approach”, a good planning process is a process of iterations, combining and parallel cross-cutting activities in different areas.
Conflict Design
Perhaps all this sounds good. By implementing all this, you will cope with the task of allocating resources and determining the boundaries of a product 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 bury your head in the sand and just say that there is no conflict. Assume, for example, that end users will appreciate the lack of features left out to please IT professionals. Or that IT specialists will somehow get used to the fact that the device automatically 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 accept that in every release you cannot please everyone. But there will always be the next one. Therefore, to determine the right trade-offs in development, you need a set of principles and product architecture that you can use as a basis.
It is extremely important to understand the long-term strategy - 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 script or the solved problem looks convincing, advanced users will extol the product. They, as a rule, are quick on the feedback and immediately throw up a bunch of suggestions on how to increase the flexibility of the product or add functions. 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 at the design stage, you will be wasting a project. A famous example is that the first version of the smartphone was released without the copy / paste function. But the designers knew exactly how the new design language would continue to develop. Understanding the directions of development was very important, and facilitated the implementation of this function — without compromising the overall ease of use, which was the main advantage of the entire 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 going. If you compare modern OS platforms with how they looked 10 years ago, you will see that many architectural differences were the result of compromises in architecture. App stores, sandboxes, reseller APIs — all this was invented to create an architecture that would become more secure, safe for the end user, and allow devices to work longer on battery power.
Today, looking at these architectural changes and comparing with how it all began, we can easily see the difference. But, think about how much you had to discuss and plan for this - this was a turning point in the approach. Platform creators had a hard time making these compromises, based on this new approach. A creative approach to new requirements is the secret to understanding the evolution of your product over time.
It is important to have a tool in the form of a set of product principles - design language, architectural solution patterns, customer value suggestions. These principles not only guide the development team, but also help explain to customers why you went to these trade-offs. This will not facilitate the dialogue and will not force people to agree with your decisions. However, when discussing, it will be clear what goals your product is intended to achieve.
Amazing changes are occurring in our industry today with the advent of "BYOD" (Bring Your Own Device - allowing the use of personal devices in the workplace to access corporate resources). This is a completely new level of conflict that has to be resolved. Since the end of the 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 problems to be solved.
Now users can bring their personal devices to work, work from home or find their own ways to perform their tasks outside the boundaries of the corporate network / software / technology. It does not change corporate or government requirements for reliability and security. This does not change the decision rules for IT. Their internal customers have a choice, and it’s very interesting to see how this choice overlaps with product development conflicts.
It is akin to how the API and the capabilities of the OS change, forcing, perhaps, some categories of customers to reconsider their expectations, as well as devices and software change their architecture. At the planning stage of the product, 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 the 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 of designing a product for many types of users.
The only thing you can be sure of is that there is no “right” choice of compromises that could satisfy all customers. This is the essence of development for different types of consumers. That is why product development is also a social science.
Example: corporate issue
Today, one of the hottest debates is about how to balance the needs of the company's IT services and the community of people using the products within that company. This is a major shift in the industry due to a wave of products that allow it to operate outside the scenarios controlled by the IT service.
It is absolutely certain that the changing needs of organizations are not in protecting their digital assets or maintaining the integrity of the corporate network — or even managing the overall use of corporate resources (the balance of work and non-work activity). These requirements now do not just remain relevant - in the modern world they are more important than ever, because any leakage of client or financial information may result in international news or supervisors.
The changes lie in the fact that people working in companies have easy access to tools that allow them to do what they need. At other times, the acquisition of servers, licensing of software, its launch on-site and working with them required the help of IT services 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 against" these tools is a political approach. You can block TCP / IP ports or doubtful network traffic (and, of course, block the download of client applications on managed computers), but even this does not solve the problem. Access to the network is easily obtained via a WiFi / 4G access point or via a phone in shared mode.
The usual methods of blocking devices no longer work. In the world of mobile devices and, perhaps, even a multitude of operating systems, there is no clearly defined point where it is necessary to block, and of course, this can not be realized.
Someone sees freedom in this, someone - 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 this product, it will be easier for people to find and share tools with their colleagues for solving their business problems.
The difficulty in developing is to define a new architecture that would take into account the real situation: if you are too hard to hit one of the directions when designing, then you will be stumped. If you focus on giving people maximum opportunity, your product may either be confronted with IT policies or, worse, with an active corporate analyst community company 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 those are always just a click away.
This is where design principles come into play. What is the management scheme implemented now - is there anything that is implemented by IT companies that reduces the attractiveness of corporate use in comparison with the home or, for example, with BYOD? Perhaps measures like an exorbitant number of logon scripts or complex network access restrictions that cause people to avoid using the network and instead choose the path of least resistance? Or are these features of personal settings that are applicable both on home PCs and because “everything is different” at work, does a person try to use a home computer for work?
Given this environment and the variety of possible solutions, which architecture will be able to take into account the shortcomings of existing approaches to corporate network management and offer a more suitable option, while at the same time ensuring security?
Can I 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 employee requests?
Such questions 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.
Source: https://habr.com/ru/post/169901/
All Articles