How technology and social sciences help plan

Original author: Steven Sinofsky
  • Transfer
Not so long ago, Steven Sinofsky (ex-vice president of Windows at Microsoft) started his blog in which he shares his thoughts on products, product development and management.
With the kind permission of the author, we decided to start translating his articles. We present to your attention a translation of the first article in this series.

One of the large-scale problems in creating high-tech products is that in order to bring a product or service to the market, brilliant engineers need to achieve brilliant results, while they cannot know whether their choice will lead to success or failure. This seems obvious, but often such a snag is the main culprit for the tension in the development team or just any group.

Note: By “engineer,” we mean all the specialized skills needed 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 a product to customers and its support - 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 - and that's good.

Natural stress (sic!)

Every non-engineer who has talked with an engineer at least once knows how difficult (or unpleasant) it is to hear that “something is possible, but something is not”, or that “it is right, it’s pointless, but it’s stupid nowhere to go. " In the same way, every engineer knows the troubles of communicating with a sales specialist, seller, or consumer, who insists that "you need to do this," but cannot at least reasonably explain why. This is commonly referred to as the "natural stress" or "organized balance of power" affecting the team.

But who needs this "organized tension"? Even when you just do what you should, you already have enough stress - why add a new one, which, moreover, cannot be eliminated?

This is not easy to handle. Of course, you can send engineers to consumers or force “sales people” to sit at meetings on architecture, but this is ridiculous and does not affect the problems and circumstances of each of the parties in any way. In fact, there is no simple solution, because reality is based on experience, culture, and sometimes time frames for different members of the development team. Rather than accepting natural tension as inevitable, relying on tales or trying to combine the DNA of a team, you can find a more correct approach.

If by team you mean a handful of guys who come to work to make difficult decisions every day (and night!), Then the most important thing for her will be a shared and detailed outline of the general plan of the product. Historically, software planning has not yet matured to the level of planning at which it is located in most other engineering areas (construction, transport). For the most part, this can be considered a plus - this is the “soft” part of the software that makes its development brisk, flexible and able to quickly adapt to the current situation. This is akin to how in the field of blogs and social media to reformulate a product message addressed to customers can be much faster than during the long development and print ads. Again, this is good.

But, if each of the approaches in the team increases its creativity and flexibility, then chaos will not take long. And, even worse, if everything is confused and does not fit in any way, mutual accusations begin. And, coupled with a performance assessment or operational meetings, the problem that arose as a small disagreement very quickly becomes a stumbling block or even a “political issue”. Sometimes one wonders how quickly even those people who were sincerely set to work together can begin to suffer from the so-called “natural tension”, which then turns into a complete disorder in work.

Planof what the team is working on may look difficult and complicated. Can. But should not. In other words, a plan is “the basis for decision making”. It is easy to create a plan that tells how wonderful the result of the work will be and how wonderful it will be to make money on it. This is the easy part of the plan.

Another simple part - listing everything that will not be done - so that everyone understands the idea, inverting what is planned to be implemented. It sounds a little strange. I remember the first time I learned about the method of intentional detailed description of everything that is not included in the project’s goals. It reminded me of solving a puzzle - and perhaps this specific tool is useful for some development teams. If you have listed the goals of the project, then is it necessary to talk about “non-goals”? The same applies to ranking tasks or plans by priority. Often, when you see lists of tasks / goals with priorities, it is not clear which of them will be implemented (All mandatory and somewhat optional? Most mandatory? Etc.). The best thing would be to simply list what you undertake to really accomplish, because, by and large, I don’t think

The difficult part in preparing the plan is to formulate why the product is created and how it will become successful. This side belongs to the social sciences, and the engineers with them are tight. 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 outline the trajectory of the development of technology in a world that may differ from the one in which we now live, 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 up

For any project, the volume of which goes beyond a team of several people or is difficult, the first step is extremely important - to formulate “how” and “why” a product is created, and not just “what” is created. The reality is that each team member only benefits from a description of the situation and motivation for the implementation of the project. Armed with such information, we get the basis for making decisions on how to implement the details of the project, their priority, how the product will be positioned or sold, and the like. It is amazing how often you see engineers who know exactly what “needs” to be done, while not having a well-designed “product history”, why it is being created. As well as how often you meet marketers who know what kind of story will sell well, but don’t know how to create it.The meaning of the plan is to create a framework that explains how and why , but not what needs to be done.

Of course, everything is changing. Writing code is more difficult than we would like. Competitors take up empty seats. Customer views are changing. In fact, any project will go through a phase of revising 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, together, as a single command. 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 a plan is something that cannot be cut down with an ax. There are also people who, on the contrary, think that this is just a starting point and everything in it should 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, there must be a shared understanding of how the current product is being accepted by the market. What are its strengths and weaknesses - both technical and from a business point of view? Work on this part of the plan should be done by those who are responsible for the sales and support of 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 deeply understand the monetization methods and pricing structure for the product, and it is they who must work out this aspect.
  • Competition . Everyone needs to understand competition . It is not from the category of things that can be controlled by intuition, everyone in the team must know the internal and external competition and constantly use competing products. Many plans suffer because people superficially try competitors' products and do not concentrate on why customers can choose them. And do not forget that competition can be "disruptive" and offer a product with "less" functionality, but using a different way to get money ( sometimes and generally a different business scheme - approx. Per. ). 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, hardware manufacturers or suppliers, after-sales installation / support (for enterprise products), and so on. Even simple things like the plugin model or extensibility APIs must be carefully thought out if you want them to be part of the team’s decision system. This section of the plan also requires the work of the entire team.
  • Industry trends. As soon as the team begins to think about trends in technology development, everything that social science teaches regarding the development of a plan is used. What is the time frame? What is the likelihood that the trend will really appear? What benefits / omissions will appear for the project if the trend manifests itself and if not? These are important questions. But to agree in advance on which streams the product should “float out”, and to say this in as much detail as it is necessary for all team members to understand, is extremely important. This is where the nuances of the plan come into play. Today, in every plan you can meet the concept of “mobile”, but the question becomes much deeper when it comes to how to act - how it relates to monetization, what platforms will be, the dependence on the browser - all this must be said.
  • 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 an announcement on a blog (that is, in fact, a press release). Would they believe it? How will competitors react? Developers should consider what will be successful for them in terms of concurrent users, transactions, or performance in addition to features. To determine success, everyone works together.
  • Schedule . Every good project starts with a schedule. And in most projects, it will soon be revised. In any planning, the real problem will be to pre-select a schedule, the reality of which you wholeheartedly believe in as a whole team, and then use the above measures to find compromises that will help you meet deadlines. Having distributed the amount of work in accordance with the schedule and setting realistic deadlines, you can subsequently 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 - there is no need to take the plan and then decide what might not work out (or how long it takes), as in the waterfall model.

There are three things worth mentioning when looking at this system.

Firstly, 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 for a share (market - approx. Per. ). Also, it is not “to fasten 5 such and such features”. These are possible ways to measure success, but not the main thing in the plan. The most important thing in the plan is to solve the problem: either one that arose due to customer dissatisfaction (formulated need) or one that the team foresees in advance (unformulated need).

Secondly, a plan is a product of teamwork. Even the development of the plan itself requires the coordinated efforts of the entire team. We can say that the plan is not a “lowered from above” (from executives to executors) and not “locally 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 combine the best ideas from the widest circle of people involved in product development.

Thirdly, it may be tempting to present the plan in the form of a diagram in PowerPoint and take every step on the slide. Many plans are written like that :-) The only true approach to planning is to write a plan in words, in Word, and then make sure that it has a sequence and meaning. The process of writing a plan is just as important as the ideas themselves. Perhaps this is a topic for future posts.

Building a bridge

When a team has a common understanding of all the issues outlined above, the next step can be taken together. There are two key parts of the plan that bring everything together and help connect the “development plan” and “social science”.

  • Big bets. Each project is based on 1-2 large rates. These may be new technologies representing a quantum leap in comparison with the past, or new product areas. Such goals are more than just “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 rates, 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 process of its implementation. Thus, large goals are the foundation from which it will be possible to build on, making future decisions regarding the project. It’s tempting to set many big tasks at once,
  • Development plan. A development plan can be considered a plan of feasible opportunities (“features”), but it is better to understand it as a scenario of actions viewed through the prism of development. If you look at it from the side of the sales department or marketers, the development plan should sound like “we have solved such and such problems”, which can be relatively easily turned into the “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 whole teams (or individuals) also work on them. If the goals of creating a product are formulated as the totality of everything you do together,

There are many other parts of the plan - the business plan itself, the marketing plan, the PR plan, the pricing structure, materials for training technical support and sellers, the operational and scalability plan, the test plan, the self-host plan and many others. All of the above describes some measures that will help the work of the entire team, if you take them before the actual start of the project. When a team enters into resonance, much becomes possible to do together in advance. This is just a system designed to ensure that the first goal set unites team members at the same stage of work.

No matter how we want, there is no magic recipe. If he was, each plan would be drawn up according to him and worked perfectly. No product is re-developed, so our ability to experiment together and create / modify individual product samples is limited. All that we have is experience and the opportunity to pay special attention to the situation and the existing reality when developing the product.

PS Thank you for reading. This post is the first in this blog, the learning process. I will be glad to receive feedback regarding the tone, structure and approach to the narration. All these are complex topics, and, perhaps, I see more semitones and nuances than a clear "answer to the question." Let me know what you think about it.

PPS This post is of a general nature, and not about anything specific, implemented in the past or present.

Also popular now: