Learning through the exchange of observations
In a continuation of the translation of the first article by Steven Sinofsky on product development , a translation of his second article, on the importance of sharing experience in the product development team.
The exchange of raw information is an important component of creating a strong cohesive team. This makes it possible for everyone to see the input data and on the basis of them to draw their own conclusions, whether they are new plans or a change of course in existing ones.
In this post, I share some thoughts and experiences on how to compile a trip report in the context of product development.
')
From the very beginning of my business trips, my managers always needed trip reports in exchange for the opportunity to go somewhere at the expense of the company. Regardless of whether you are a manager or not, sharing new information and your observations from the trip (whether it is a site visit, a round table for consumers, an exhibition or a conference) is a way to contribute to a common understanding of products and technologies.
The report is just a collection of words and materials, it is far from a list of further actions, since they can be formulated only by collecting data from different points of view and considering all the consequences. In fact, when developing a product, it’s wrong to rush to embody all the considerations that someone “brought” from one of the business trips or someone’s personal point of view (and it doesn’t matter who the team wrote this report). This is just a story, and to turn it into concrete steps - a change of plan or a change in the composition of possibilities - a separate work is needed.
There is no “right” way to write a report. Most often, its format, structure and details should be determined by what kind of event it is: do you build a structure by technology type or supplier, by consumers or consumer topics, by conference sessions, by technical subsystems, or something else?
The report also does not have to be short, especially if the trip was informative. If you want to present excerpts in the format of key points (a bulleted list), there are several options. For public speaking, you can quote a blog or a couple of articles that correspond to your point of view. For a closed meeting, it also makes sense to make a detailed report and bring it to the team members, but also consider an oral version of the report. The list of key points is itself successful in order to highlight the main points, or as a brief outline of the entire report. However, if you submit a report only in this form, there is a risk that raw data will not be given enough, and your listeners may take them for conclusions that you yourself learned from a business trip. Keep in mind that the time spent writing a report is also a time for a deeper understanding of the experience you have gained.
Personally, I really appreciate the use of pictures. Visiting sites where you directly inspect the products themselves (examples of application screens, paper systems, demonstrations of devices in action, photos of the physical environment), it is very useful to show what you saw. Well, if you can show a good slide or graphics from one of the conference sessions. As for trade shows, it’s a pleasure to show off their products. Video is, of course, good, but some report formats may not be adapted for this.
It is often argued about how many hyperlinks can be in a report (links to Powerpoint presentations, videos, or product information). It depends on how much the readers or target audience will need more detailed information about the subject. It is clear that you should always be ready to provide it, but I do not think that the report will benefit from the fact that it will be filled with blue underlined phrases or information will be missed - simply because “click here, and everything is written there” . If you, for example, are talking about hardware, and some of its characteristics (such as weight, Megahertz, Watts) are so important, then just include them in the report itself.
There are two nuances regarding privacy / intellectual property to keep in mind when writing a report. First, always be careful about whether you have the right to record and then transfer information to someone. You must obtain permission to use any photo (from client sites or conferences, and sometimes even from some exhibition stands). Secondly, when you submit your report to other people, make sure that you act in accordance with the company's policy in disseminating information.
Whether you use email, attachments, file sharing, OneNote in SkyDrive (for sending to a small group) or a blog for internal use depends on the corporate rules adopted by your organization. A blog is good because in this case all your reports are stored in one place regardless of their type, and you always know where to look for them. The main thing - without clogging the mail of colleagues, to make sure that the data is available to all team members or the necessary audience.
The manager or the leader will not forget to remind his team that the report on the conference or other event (unless otherwise specified is different) is just information for reflection, and not a change in work plan, not a guide to action, nothing more than just sharing information. Those who are responsible for this should act - using the data that you provided along with other sources. If you get feedback, it’s best to publish it separately from the report itself.
We decided to limit the translation of the first part of the article with the main tips that are directly related to the topic of product development. The second part of Stephen's article is a report from CES 2013. It can be found in the original source . But, if this part is interesting for everyone in the translated version, we will translate it.
The exchange of raw information is an important component of creating a strong cohesive team. This makes it possible for everyone to see the input data and on the basis of them to draw their own conclusions, whether they are new plans or a change of course in existing ones.
In this post, I share some thoughts and experiences on how to compile a trip report in the context of product development.
')
Why do travel reports?
From the very beginning of my business trips, my managers always needed trip reports in exchange for the opportunity to go somewhere at the expense of the company. Regardless of whether you are a manager or not, sharing new information and your observations from the trip (whether it is a site visit, a round table for consumers, an exhibition or a conference) is a way to contribute to a common understanding of products and technologies.
The report is just a collection of words and materials, it is far from a list of further actions, since they can be formulated only by collecting data from different points of view and considering all the consequences. In fact, when developing a product, it’s wrong to rush to embody all the considerations that someone “brought” from one of the business trips or someone’s personal point of view (and it doesn’t matter who the team wrote this report). This is just a story, and to turn it into concrete steps - a change of plan or a change in the composition of possibilities - a separate work is needed.
Approaches
There is no “right” way to write a report. Most often, its format, structure and details should be determined by what kind of event it is: do you build a structure by technology type or supplier, by consumers or consumer topics, by conference sessions, by technical subsystems, or something else?
The report also does not have to be short, especially if the trip was informative. If you want to present excerpts in the format of key points (a bulleted list), there are several options. For public speaking, you can quote a blog or a couple of articles that correspond to your point of view. For a closed meeting, it also makes sense to make a detailed report and bring it to the team members, but also consider an oral version of the report. The list of key points is itself successful in order to highlight the main points, or as a brief outline of the entire report. However, if you submit a report only in this form, there is a risk that raw data will not be given enough, and your listeners may take them for conclusions that you yourself learned from a business trip. Keep in mind that the time spent writing a report is also a time for a deeper understanding of the experience you have gained.
Personally, I really appreciate the use of pictures. Visiting sites where you directly inspect the products themselves (examples of application screens, paper systems, demonstrations of devices in action, photos of the physical environment), it is very useful to show what you saw. Well, if you can show a good slide or graphics from one of the conference sessions. As for trade shows, it’s a pleasure to show off their products. Video is, of course, good, but some report formats may not be adapted for this.
It is often argued about how many hyperlinks can be in a report (links to Powerpoint presentations, videos, or product information). It depends on how much the readers or target audience will need more detailed information about the subject. It is clear that you should always be ready to provide it, but I do not think that the report will benefit from the fact that it will be filled with blue underlined phrases or information will be missed - simply because “click here, and everything is written there” . If you, for example, are talking about hardware, and some of its characteristics (such as weight, Megahertz, Watts) are so important, then just include them in the report itself.
There are two nuances regarding privacy / intellectual property to keep in mind when writing a report. First, always be careful about whether you have the right to record and then transfer information to someone. You must obtain permission to use any photo (from client sites or conferences, and sometimes even from some exhibition stands). Secondly, when you submit your report to other people, make sure that you act in accordance with the company's policy in disseminating information.
Whether you use email, attachments, file sharing, OneNote in SkyDrive (for sending to a small group) or a blog for internal use depends on the corporate rules adopted by your organization. A blog is good because in this case all your reports are stored in one place regardless of their type, and you always know where to look for them. The main thing - without clogging the mail of colleagues, to make sure that the data is available to all team members or the necessary audience.
The manager or the leader will not forget to remind his team that the report on the conference or other event (unless otherwise specified is different) is just information for reflection, and not a change in work plan, not a guide to action, nothing more than just sharing information. Those who are responsible for this should act - using the data that you provided along with other sources. If you get feedback, it’s best to publish it separately from the report itself.
We decided to limit the translation of the first part of the article with the main tips that are directly related to the topic of product development. The second part of Stephen's article is a report from CES 2013. It can be found in the original source . But, if this part is interesting for everyone in the translated version, we will translate it.
Source: https://habr.com/ru/post/168163/
All Articles