Sharing Knowledge: From Product Manager to Engineers

Have you heard? My new book Continuous Discovery Habits is now available. Get the product trio's guide to a structured and sustainable approach to continuous discovery.

This is the second post in a four part series on Sharing Knowledge in Product Management. The first part looked at sharing knowledge from customers to product manager. This part examines from product Mangers to engineers. Part three will examine from engineers back to product managers. Finally, part four will look at from product managers back to customers.

Assuming all goes well, between customers and the product team, this is still only the beginning. The product team has to share this newly acquired knowledge with the engineering team in the form of product requirements. For many product managers, the synthesis of customer knowledge into product requirements is an intuitive process. However, many engineers want to give feedback and be involved in the product definition phase, but they lack the wealth of customer knowledge that the product team has.

To further complicate the matter, engineers and product managers share little common knowledge and often approach problems from very different viewpoints.  Product managers are well versed in the whole business and are primarily focused on solving a customer problem. While engineers may also be interested in solving a customer problem, their primary focus is on developing a sound technology solution. These interests do not always line up.

Hislop’s (2009) boundary classification helps to understand these differences. He defines three types of boundaries between groups: syntactic boundaries, semantic boundaries and pragmatic boundaries. In the simplest cases, the boundary between product managers and engineers is merely syntactic. Both groups share the same interests, approach the problem the same way, but merely lack common knowledge. Often times, overcoming this boundary can be as simple as translating from the customer jargon to terms the engineering team can understand.

Other times, however, the boundary can be more complex. In some instances, both the product team and the engineers share the same interest, meeting the customer need, but interpret the data differently, meaning a semantic boundary separates the two groups. This typically happens when the data is incomplete. For example, many companies evaluate web traffic to guess at their customers’ intent. Product managers will often come up with a very different interpretation of this data than engineers. Engineers have a wealth of technical knowledge about the product, while product managers have a wealth of knowledge about the customer. Each knowledge base influences their interpretation of the data.

For syntactic and semantic boundaries, product and engineering teams use a variety of boundary objects to help span theses borders. Hislop (2009) explains that boundary objects can help to develop the area of overlap between the two communities.  Product teams often write persona documents, fictional customer snapshots that convey the customer need, the context in which the need occurs and enough information about the customer, that they are transformed from an abstract idea to a concrete (if fictional) person. When a disagreement or open question arises, both the product and engineering team can use the persona to shift their focus from their own perspective to that of the fictional customer. It helps both groups step outside of what they know and think like their customer.

Product teams also run usability studies, recorded sessions where the customer tries to tackle a problem by using the product, while being observed by the product team. Video footage of these sessions is often very effective at sharing rich customer information with engineering teams. Because engineers are so close to the product, they work on it day in and day out, it is easy for them to lose perspective on what is easy and what is hard. At times, nothing short of video evidence will help in convincing an engineering team that a customer does not share the same level of product knowledge as they do.

In rare cases, a pragmatic boundary may exist between product managers and engineers, meaning they don’t even share a common interest. This can happen when a company has not set a clear goal or vision and different members of the organization have defined the customer problem differently or favor different solutions. In these cases, it often requires input and facilitation from other areas of the company for product and engineering teams to overcome this boundary.

As was the case between customers and product managers, engineers must also have competence trust in their product team. They must trust that they have the requisite skills to correctly identify the customer problem and verify that the proposed solution is a suitable one. If the product manager gets this wrong, it comes at a high cost for the engineering team, as their work goes wasted. Similarly, product managers must be careful to retain this trust and not abuse their position to promote their own interests, but instead promote the interests of their customers.

In the next post, I’ll take a look at the flow of knowledge from engineers back to product managers. Stay tuned. Was this helpful? Please let me know what you think in the comments.

References

• Cross, Parker, Prusak, Borgatti (2001) “Knowing what we know: Supporting Knowledge Creation and Sharing in Social Networks,” Organizational Dynamics, Vol. 30 No. 2 pp 100-120
• Hislop, D. (2009). Knowledge Management in Organizations. New York: Oxford University Press
• Newell, David, Chand, (2007) “An Analysis of Trust Among Globally Distributed Work Teams in an Organizational Setting,” Knowledge and Process Management, Vol. 14, No. 3, pp 158-168