How technology and social sciences help plan
Not long ago, Steven Sinofsky (ex-vice president of Windows at Microsoft) began a blog in which he shared his thoughts about products, product development and management.
We, with the kind permission of the author, decided to start translating his articles. We present to your attention the translation of the first article in this series.
One of the major problems in the creation of technological products is that in order to bring a product or service to the market, it is necessary for brilliant engineers to achieve brilliant results - and they cannot know whether their choice will lead to success or failure. This seems obvious, but often such a snag is the main culprit of the tension in the development team or just any group.
Note: Speaking of "engineer", by this we mean all the specialized skills necessary to create a product, including development, testing, design, and more. Moreover, by “sales” or “marketing” we mean all the specialized skills that are required to transfer the product to customers and support it - this is a whole range of skills and responsibilities that are extremely important. No matter how many specializations exist, the boundaries between roles are always fuzzy - which is good.
')
Every non-engineer who has communicated with an engineer at least once knows how difficult it is (or unpleasant) to hear that “something is possible and something is not”, or that “it’s right, that’s pointless, but this is more stupid nowhere. ” Similarly, every engineer is familiar with the trouble of communicating with a sales person, salesperson, or customer who insists on “doing just that”, but cannot reasonably explain why. This is commonly referred to as “natural stress” or “organized balance of power” affecting a team.
But who needs this “organized stress”? Even when you just do, what should, you already have enough stress - why add a new one, which, moreover, can’t be eliminated?
Deal with this is not easy. Of course, you can send engineers to consumers or force salespeople to sit at meetings on architecture, but this is ridiculous and does not affect the specified problems and circumstances of each of the parties. In fact, there is no simple solution, since reality is based on experience, culture, and sometimes a time frame for different members of the development team. Than to take natural tension as something inevitable, to rely on bikes or to try to combine the team's DNA, you can find a more correct approach.
If under the team you understand a handful of guys who come to work to make difficult decisions every day (and night!), Then the most important for her will be a shared and detailed outline of the overall product plan. Historically, software planning has not yet matured to the level of planning at which it is located in most other engineering areas (construction, transportation). For the most part, this can be considered a plus - this is the very “soft” part of the software, which makes its development brisk, flexible and able to quickly adjust to the current situation. This is akin to how in the sphere of blogs and social media it is possible to reformulate a product message addressed to customers much faster than in the days of protracted development and print advertising. Again, this is good.
But, if each of the approaches in a team increases its creativity and flexibility, then chaos will not take long to wait. And, even worse, if everything is confused and does not converge at all, mutual accusations begin. And along with performance assessments or operational meetings, a problem that has arisen as a slight disagreement very quickly becomes a stumbling block or even a completely “political issue”. Sometimes you are amazed how quickly even those people who were genuinely intent on working together can start to suffer from the so-called “natural stress”, which then turns into a complete disorder in work.
The plan of what the team is working on may be difficult and complicated. Can. But should not. In other words, the plan is “the basis for decision making”. It is easy to create such a plan that will tell you how wonderful the result will be and how wonderful it will be to make money on it. This is the easy part of the plan.
Another simple part is the enumeration of everything that will not be done - so that everyone understands the idea, inverting what is planned to be realized. It sounds a bit strange. I remember how I first learned about the method of deliberately describing everything that is not part of the project’s goals. It reminded me of solving a puzzle - and perhaps this specific tool is useful for some development teams. If you listed the goals of the project, is it then necessary to talk about “non-goals”? The same goes for ranking tasks or plans by priorities. Often, when you see lists of tasks / goals with priorities, it is unclear which of them will be implemented (All mandatory and somewhat optional? Most mandatory?, Etc.). It would be best to simply list what you undertake to actually accomplish, since, by and large, I do not think that at least some of you have been working on projects with an excess of time or money!
The difficult part in preparing a plan is to formulate why the product is created and how it will become successful. This side is related to the social sciences, and engineers have a hard time with them. You cannot prove that any development will be successful in the market because there are no equations that would regulate its behavior. Similarly, the role of the technologist is to delineate the trajectory of technology development in a world that may differ from the one in which we live now and from the reality in which people spend money today. This is a social aspect that is difficult for sales and marketing staff.
For any project whose scope goes beyond a team of several people or is complex, the first step is extremely important - to formulate “how” and “why” a product is created, not just “what” is created. The reality is that each member of the team benefits from a description of the situation and the motivation to implement the project. Armed with such information, we get the basis for deciding how to implement the details of the project, their priority, how the product will be positioned or sold, and the like. It's amazing how often you see engineers who know exactly what “needs” to do, without having a well-thought-out “product history”, why it is being created. Equally, as you often meet and marketers who know what kind of story will sell well, but do not know how to create it. The meaning of the plan is to create a basis explaining “how” and “why” , but not “what” to do.
Of course, everything changes. Writing code is harder than we would like. Competitors occupy empty seats. Customer attitudes are changing. In fact, any project will go through a phase of revising the sections and changing the details of the plan. The most unobvious feature of the plan is that its very existence means that you have the tools to change it, jointly, as a team . The lack of a plan creates chaos, recriminations, evasion of responsibility, which we all know well. The plan does not imply rigidity, but, like any tool, it can be used incorrectly. There are people who believe that the plan is something that cannot be knocked out with an ax. There are also people who, on the contrary, think that this is just a starting point and everything in it must be mobile. Product development is a dynamic system with plans that define interdisciplinary reference points for the team as a whole.
When developing a plan, it makes sense to consider:
When looking at this system there are three things that are worth mentioning.
First, a plan is not a primary business goal, according to which you need to “get N% from Y”, where Y is users, money, or some unit of measure of a share. Also, this is not “to fasten 5 such and such features”. These are possible ways to evaluate success, but not the main thing in terms of. The most important thing in the plan is to solve the problem: either one that arose because of customer dissatisfaction (formulated need) or one that the team foresees in advance (unstated need).
Secondly, the plan is a product of teamwork. Even the development of the plan itself requires the coordinated efforts of the whole team. It can be said that the plan is not a “top down” (from executives to executives) and not a “field generated” (crowdsourcing) solution. Planning is a process, rather, requiring joint actions “from above,” “from below,” and “from the middle.” The best plans are those that bring together the most successful ideas from the widest range of people involved in product development.
Thirdly, it may be tempting to present the plan as a diagram in PowerPoint and take every step of the slide. Many plans are written this way :-) The only correct approach to planning is to write a plan in words, in Word, and then make sure that it has a sequence and a meaning. The process of writing a plan is just as important as the ideas themselves contained in it. Perhaps this is a topic for future posts.
When the team has a common understanding of all the issues outlined above, the next step can be done together. There are two key parts of the plan that bring everything together and help connect the “development plan” and the “social science”.
There are many other parts of the plan - the business plan itself, a marketing plan, a PR plan, a pricing structure, technical support training and sales materials, an operational and scalability plan, a test plan, a self-host plan, and many others. All of the above describes some measures that will help the work of the whole team, if taken before the actual start of the project. When a team enters a resonance, then much can be done together and in advance. It is simply a system designed to ensure that the first goal set unites team members at the same stage of work.
No matter how we like, the magic recipe does not exist. If he had been, every plan would have been drawn up according to him and worked perfectly. No product is being developed again, therefore our ability to experiment together and create / modify individual product samples is limited. All that we have is experience and the ability to pay special attention to the situation and the existing reality when developing a product.
PS Thanks for reading. This post is the first in this blog training process. I would welcome feedback on the tone, structure and approach to the story. All these are complex topics, and perhaps I see more halftones and nuances than a clear “answer to the question.” Let me know what you think about it.
PPS This is a general post, and not about something specific, implemented in the past or present.
We, with the kind permission of the author, decided to start translating his articles. We present to your attention the translation of the first article in this series.
One of the major problems in the creation of technological products is that in order to bring a product or service to the market, it is necessary for brilliant engineers to achieve brilliant results - and they cannot know whether their choice will lead to success or failure. This seems obvious, but often such a snag is the main culprit of the tension in the development team or just any group.
Note: Speaking of "engineer", by this we mean all the specialized skills necessary to create a product, including development, testing, design, and more. Moreover, by “sales” or “marketing” we mean all the specialized skills that are required to transfer the product to customers and support it - this is a whole range of skills and responsibilities that are extremely important. No matter how many specializations exist, the boundaries between roles are always fuzzy - which is good.
')
Natural stress (sic!)
Every non-engineer who has communicated with an engineer at least once knows how difficult it is (or unpleasant) to hear that “something is possible and something is not”, or that “it’s right, that’s pointless, but this is more stupid nowhere. ” Similarly, every engineer is familiar with the trouble of communicating with a sales person, salesperson, or customer who insists on “doing just that”, but cannot reasonably explain why. This is commonly referred to as “natural stress” or “organized balance of power” affecting a team.
But who needs this “organized stress”? Even when you just do, what should, you already have enough stress - why add a new one, which, moreover, can’t be eliminated?
Deal with this is not easy. Of course, you can send engineers to consumers or force salespeople to sit at meetings on architecture, but this is ridiculous and does not affect the specified problems and circumstances of each of the parties. In fact, there is no simple solution, since reality is based on experience, culture, and sometimes a time frame for different members of the development team. Than to take natural tension as something inevitable, to rely on bikes or to try to combine the team's DNA, you can find a more correct approach.
If under the team you understand a handful of guys who come to work to make difficult decisions every day (and night!), Then the most important for her will be a shared and detailed outline of the overall product plan. Historically, software planning has not yet matured to the level of planning at which it is located in most other engineering areas (construction, transportation). For the most part, this can be considered a plus - this is the very “soft” part of the software, which makes its development brisk, flexible and able to quickly adjust to the current situation. This is akin to how in the sphere of blogs and social media it is possible to reformulate a product message addressed to customers much faster than in the days of protracted development and print advertising. Again, this is good.
But, if each of the approaches in a team increases its creativity and flexibility, then chaos will not take long to wait. And, even worse, if everything is confused and does not converge at all, mutual accusations begin. And along with performance assessments or operational meetings, a problem that has arisen as a slight disagreement very quickly becomes a stumbling block or even a completely “political issue”. Sometimes you are amazed how quickly even those people who were genuinely intent on working together can start to suffer from the so-called “natural stress”, which then turns into a complete disorder in work.
The plan of what the team is working on may be difficult and complicated. Can. But should not. In other words, the plan is “the basis for decision making”. It is easy to create such a plan that will tell you how wonderful the result will be and how wonderful it will be to make money on it. This is the easy part of the plan.
Another simple part is the enumeration of everything that will not be done - so that everyone understands the idea, inverting what is planned to be realized. It sounds a bit strange. I remember how I first learned about the method of deliberately describing everything that is not part of the project’s goals. It reminded me of solving a puzzle - and perhaps this specific tool is useful for some development teams. If you listed the goals of the project, is it then necessary to talk about “non-goals”? The same goes for ranking tasks or plans by priorities. Often, when you see lists of tasks / goals with priorities, it is unclear which of them will be implemented (All mandatory and somewhat optional? Most mandatory?, Etc.). It would be best to simply list what you undertake to actually accomplish, since, by and large, I do not think that at least some of you have been working on projects with an excess of time or money!
The difficult part in preparing a plan is to formulate why the product is created and how it will become successful. This side is related to the social sciences, and engineers have a hard time with them. You cannot prove that any development will be successful in the market because there are no equations that would regulate its behavior. Similarly, the role of the technologist is to delineate the trajectory of technology development in a world that may differ from the one in which we live now and from the reality in which people spend money today. This is a social aspect that is difficult for sales and marketing staff.
What's the plan
For any project whose scope goes beyond a team of several people or is complex, the first step is extremely important - to formulate “how” and “why” a product is created, not just “what” is created. The reality is that each member of the team benefits from a description of the situation and the motivation to implement the project. Armed with such information, we get the basis for deciding how to implement the details of the project, their priority, how the product will be positioned or sold, and the like. It's amazing how often you see engineers who know exactly what “needs” to do, without having a well-thought-out “product history”, why it is being created. Equally, as you often meet and marketers who know what kind of story will sell well, but do not know how to create it. The meaning of the plan is to create a basis explaining “how” and “why” , but not “what” to do.
Of course, everything changes. Writing code is harder than we would like. Competitors occupy empty seats. Customer attitudes are changing. In fact, any project will go through a phase of revising the sections and changing the details of the plan. The most unobvious feature of the plan is that its very existence means that you have the tools to change it, jointly, as a team . The lack of a plan creates chaos, recriminations, evasion of responsibility, which we all know well. The plan does not imply rigidity, but, like any tool, it can be used incorrectly. There are people who believe that the plan is something that cannot be knocked out with an ax. There are also people who, on the contrary, think that this is just a starting point and everything in it must be mobile. Product development is a dynamic system with plans that define interdisciplinary reference points for the team as a whole.
When developing a plan, it makes sense to consider:
- The current state of the product . If you are updating an existing product, then there should be a joint understanding of how the current product is accepted by the market. What are its strengths and weaknesses - both technical and in terms of business? Work on this part of the plan should be done by those responsible for selling and supporting the current product.
- Business opportunity . Where do consumers spend money? Where would they like to spend it? For competing products - how are they sold? Most teams have people who have a deep understanding of the monetization and pricing structure for the product, and it is they who need to work out this aspect.
- Competition . Everyone needs to understand the competition . It is not from the category of things that can be managed on a whim, everyone in a team should know internal and external competition and constantly use competing products. Many plans suffer from the fact that people superficially try the products of competitors and do not concentrate on why buyers can choose it. And do not forget that competition can be "subversive" and offer a product with "less" functionality, but using a different way to get money ( sometimes and in general a different business scheme - approx. Lane ). The development of this part of the plan requires teamwork.
- Partnership . The creation of any technological product is based on cooperation. Building a platform, application, hardware or software requires collaboration with developers, hardware manufacturers, manufacturers or component suppliers, after-sales installation / support (for corporate products), and so on. Even simple things like a plug-in model or an extensibility API need to be carefully considered if you want them to be part of the team's solution system. This section of the plan also requires the work of the whole team.
- Industry trends . As soon as the team begins to think about the trends in the development of technology, everything that the social sciences are taught to develop a plan is used. What is the time frame? What is the probability that the trend will actually manifest? What are the benefits / omissions for the project, if the trend shows up and if not? These are important questions. But it is extremely important to agree in advance on what currents the product should “swim out”, and to speak it in as much detail as it is necessary for understanding by all members of the team. This is where the nuances of the plan come into play. Today, in each plan you can come across the concept of “mobile”, but the question becomes much deeper when it comes to how to act - how it relates to monetization, what platforms there will be, dependence on the explorer - all this is sure to be spoken.
- Description of success . What does success look like? As an element of planning, it is sometimes useful to combine all of the above and write a blog announcement (that is, in fact, a press release). Would they believe it? How will competitors react? Developers need to think about what will be success for them in terms of simultaneous users, transactions, or performance in addition to features. To determine success, all work together.
- Schedule . Every good project starts with a schedule. And in most projects, it is soon revised. In any planning, the real problem will be to pre-select a schedule, the reality of which you sincerely believe the whole team, and then use the above measures to find compromises that will help to meet deadlines. Having distributed the amount of work in accordance with the schedule and setting realistic deadlines, you can later change it due to unforeseen circumstances, maintaining the normal working condition of the project. Since the development of the plan is iterative, the schedule is dictated by the plan - no need to take a plan, and then decide what may not work out (or how long it will take), as in the waterfall model.
When looking at this system there are three things that are worth mentioning.
First, a plan is not a primary business goal, according to which you need to “get N% from Y”, where Y is users, money, or some unit of measure of a share. Also, this is not “to fasten 5 such and such features”. These are possible ways to evaluate success, but not the main thing in terms of. The most important thing in the plan is to solve the problem: either one that arose because of customer dissatisfaction (formulated need) or one that the team foresees in advance (unstated need).
Secondly, the plan is a product of teamwork. Even the development of the plan itself requires the coordinated efforts of the whole team. It can be said that the plan is not a “top down” (from executives to executives) and not a “field generated” (crowdsourcing) solution. Planning is a process, rather, requiring joint actions “from above,” “from below,” and “from the middle.” The best plans are those that bring together the most successful ideas from the widest range of people involved in product development.
Thirdly, it may be tempting to present the plan as a diagram in PowerPoint and take every step of the slide. Many plans are written this way :-) The only correct approach to planning is to write a plan in words, in Word, and then make sure that it has a sequence and a meaning. The process of writing a plan is just as important as the ideas themselves contained in it. Perhaps this is a topic for future posts.
Build a bridge
When the team has a common understanding of all the issues outlined above, the next step can be done together. There are two key parts of the plan that bring everything together and help connect the “development plan” and the “social science”.
- Large bets . Each project is based on 1-2 large stakes. These can be new technologies, representing a qualitative leap in comparison with the past, or new areas of products. Such goals are more than just a “planned improvement” (relative to your own previous version or a competing product from the same field). It is very useful to describe them in advance, because this will mean that these are the only major goals that you set for the project. Large stakes, as a rule, are an invariable part of the plan: a plan cannot exist without them, and it is unlikely that you will add other large-scale goals in the course of its project implementation. Thus, major goals are the foundation from which it will be possible to build on in future decisions regarding the project. It is tempting to put many big tasks at once, but even the largest projects can not have more than two - remember that if a team undertakes to achieve some large-scale goal, it should by all means do it, or, in other words, the essence of the project is , to perform exactly this task.
- Development plan A development plan can be considered a plan of feasible opportunities (“features”), but it is better understood as a scenario of actions viewed through the prism of development. If you look at it from the sales department or marketers, then the development plan should sound like “we have solved such and such problems”, which can be relatively easily turned into a “history” of the project / service or “positioning”. It would be nice to separate the engineering plan from the organizational structure and present in it the efforts that the whole team will take (if possible). Nowadays even the simplest application consists of a frontend / application / interface and a backend / service / service, and often entire teams (or individuals) also work on them. If the goals of creating a product are formulated as a combination of everything that you do together, and not just a set of individual actions, it will also help unify the development plan and, ultimately, the business and marketing strategy.
There are many other parts of the plan - the business plan itself, a marketing plan, a PR plan, a pricing structure, technical support training and sales materials, an operational and scalability plan, a test plan, a self-host plan, and many others. All of the above describes some measures that will help the work of the whole team, if taken before the actual start of the project. When a team enters a resonance, then much can be done together and in advance. It is simply a system designed to ensure that the first goal set unites team members at the same stage of work.
No matter how we like, the magic recipe does not exist. If he had been, every plan would have been drawn up according to him and worked perfectly. No product is being developed again, therefore our ability to experiment together and create / modify individual product samples is limited. All that we have is experience and the ability to pay special attention to the situation and the existing reality when developing a product.
PS Thanks for reading. This post is the first in this blog training process. I would welcome feedback on the tone, structure and approach to the story. All these are complex topics, and perhaps I see more halftones and nuances than a clear “answer to the question.” Let me know what you think about it.
PPS This is a general post, and not about something specific, implemented in the past or present.
Source: https://habr.com/ru/post/167195/
All Articles