The “Tree Swing” Problem: Pitfalls of Cross-Functional Communication

In a meeting earlier this week, my mentor asked if I’d ever heard of the tree swing problem. I said I hadn’t. This came up in our conversation where I commented on how the task of getting various team members – engineers, designers, product marketing – on board with a proposed plan seemed straightforward and simple, but was actually much more complicated than I’d realized.

Many aspects needed clarification or additional details, and we were often out of sync even on small things such as terminology.

So what is the tree swing problem and how does it relate?

According to ZenTao Blog, “The tree swing analogy first came in the 1970s and many variants came later on different subjects, such as software and management. It depicts the difference of how each department interprets and implements a requirement in the development of a tree swing.”

As depicted in the image above, communicating within teams and across different departments can lead to different understandings in how to implement a solution. Recognizing that this was part of the challenge I faced, I went about trying to answer the question, “how do you address the gaps caused by different interpretations among team members and across departments?”

Here are a few things I’ve learned regarding the product development process and how it relates to each step depicted in the cartoon.

Knowing how to differentiate between what a customer wants (or says they want) and what they actually need is easier said than done.

When you talk to the customer (or, a technical account manager in some enterprise companies), keep in mind that they are viewing it as an opportunity to make sure their issues are heard and put on the agenda. They will always say certain features are a priority because it’s important to them.

However, due to time, money, engineering, and various other constraints, you can’t exactly just hand over what the customer asked for to the engineering team and have them build that. But, assuming you want to maintain a good relationship with the customer, you also can’t just ignore their input.

As a result, while input and feedback are valuable and important, they need to be evaluated within the larger scope of things. Some questions to ask could be:

• Is only one customer asking for this?
• If yes, how “important” of a customer are they?
• If no, how much of an issue is it for other customers?
• Is there a different way to solve the problem than the way the customer might have suggested?
• Does the request align with overall goals and plans? Is this the direction the company is moving in?

But how do you actually find out the answer to these questions? It’s complicated.

One way is to listen well and ask good questions to dig deeper in order to truly understand the problem. Last semester, I took a course I&E 352, Strategies for Innovation and Entrepreneurship and we talked a lot about the customer’s “job to be done”. According to Harvard Business Review, the concept is that rather than just buying a product, the customer “hires” it for a particular job. As in, there’s a difference in just having the nice features and what they actually need to use the product to accomplish, whether that’s business purposes like auditing/compliance or something else.

Essentially, try to focus on the problem, rather than the solution.

Have frequent conversations with the different teams such as design, engineering, customer service, product marketing, marketing, etc.

These meetings don’t have to be long, and the point is to make sure everyone is on the same page. A lot of assumptions are made on a daily basis and the more opportunities there are to challenge these the better. Sometimes, I don’t even realize I’m making assumptions until I have a conversation with team members and realize that we have different understandings and/or priorities. A lot of the meetings I attend or shadow on a daily, weekly, or bi-weekly basis are called “sync”. It’s only now that I realize why so many of the meetings I attend on a daily or weekly basis are called that - the natural tendency is to fall out of sync and our quick meetings help make sure we’re aligned and on the same page about what the goal or task at hand is.

Documentation

As a PM, you will write a lot of documents that people won’t necessarily read. This might be due to a lack of time or interest, but most of the time, discussions and decisions happen naturally during meetings. The state of a project can change rapidly over the course of a few meetings, and it’s easy for documents to lag behind.

However, documentation is still necessary for a few reasons: The primary way information is passed from one department to another is through documents. It’s useful in case someone working on the project now has to leave, or when someone else wants to pick up the project and get caught up on what has taken place. It’s important that the work is not dependent on the knowledge that one person has. I also learned this in my work last summer, where one of our app features was pushed back/ delayed since the person working on it was taking time off & none of the rest of us had touched that stuff at all & there was no written documentation on what was done / what needed to be done - we just had to wait.

Anyways, maybe all of this is a roundabout way of saying that I’m realizing a lot of my job is translation. Not from one language to another, but in the same way, translating customer needs in a way where the essence or meaning isn’t lost in translation but still preserved in the product delivered.