Observation training

In the continuation of the translation of the first article by Stephen Sinofsky on product development - the translation of his second article, about the importance of sharing experience in the product development team.

Sharing raw information is an important part of building a strong, united team. This makes it possible for everyone to see the input data and draw conclusions on their basis, whether it be new plans or a change of course in existing ones.

In this post, I share some thoughts and experiences on how to write a travel report in the context of product development.

Why make 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, to share new information and your observations obtained during 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.

A report, this is just a set of words and materials, this is not a list of further actions, since they can only be formulated by collecting data from different points of view and considering all the consequences. In fact, it’s a mistake to immediately rush when developing a product to implement all the considerations that someone “brought” from one of the business trips or someone else’s personal point of view (and it doesn’t matter which team wrote this report). This is just a story, and to turn it into concrete steps - changing the plan or changing the composition of opportunities - we need a separate work.

The 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 the structure by type of technology 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 (bullet list), there are several options. For a public presentation, you can quote a blog or a couple of articles that fit your point of view. For a private meeting, it also makes sense to make a detailed report and bring it to the team members, but consider an oral version of the report. The list of key points in itself is successful in order to highlight the main points, or as a short outline of the entire report. However, if you present the report only in this form, there is a risk that the raw data will not be given enough, and your students may take them for the conclusions that you yourself have drawn from the business trip. Keep in mind that the time spent writing a report

Personally, I really appreciate the use of pictures. When visiting objects where you directly examine the products themselves (examples of application screens, paper systems, demonstrations of devices in action, photographs of the physical environment), it is very useful to show what you saw. It’s great if you can show a good slide or schedule from one of the conference sessions. As for trade shows, showcasing their products is a pleasure. Video is, of course, good, but some report formats may not be suitable for this.

People often argue about how many hyperlinks can be in a report (links to Powerpoint presentations, videos, or product information). It depends on how much more detailed information about the subject will be needed by readers or the target audience. It’s clear that you should always be ready to provide it, but I don’t think that the report will benefit from being full of blue underlined phrases or information will be missed in it, simply because “click here and everything is written there” . If you, for example, talk 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 confidentiality / intellectual property that should be kept in mind when writing a report. First, always be careful about whether you have the right to record and then pass on 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 present your report to other people, make sure that you act in accordance with the company’s policy regarding the dissemination of information.

Whether you use email, attachments, file sharing, OneNote on SkyDrive (for distribution to a small group) or a blog for internal use depends on the corporate rules adopted in your organization. The blog is good in that 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 is not to clog your colleagues' mail, to make sure that the data is available to all team members or the necessary audience.

It will not be out of place for a manager or leader to remind his team that a report on a conference or other event (unless otherwise specifically agreed) is just information for reflection, and not a change in work plan, not a guide to action, nothing more than a simple exchange of information. Those who are responsible should act - using the data that you provide on an equal basis with other sources. If you get feedback, it’s best to post it separately from the report itself.

We decided to limit ourselves to the translation of the first part of the article with basic 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 will be of interest to everyone in the translated version, then we will translate it as well.