Don't "Guess" How People in Other Roles Work

Home > Blog > Don't "Guess" How People in Other Roles Work

2020-05-31

Don't "Guess" How People in Other Roles Work

This article is part of the series: Ethical Product Developer

Spend a bit of your time to "learn" what they do, and talk to them, instead.

"Two courses every product manager should take"

In an audiobook "Inspired: How to Create Tech Products Customers Love, Second Edition¹" I've recently listened, the author stated that there are two courses every product manager should take:

Introduction to Programming
Introduction to (Corporate) Finance

It doesn't mean product managers should be capable as a professional engineer or financial specialist.

The point is that, as long as you're working in a cross-functional team, there is a clear need for effectively and efficiently collaborating with the others, and hence knowing their way of work & its difficulty makes the teamwork way more successful than unknowing.

Problem of guessing

For instance, the following scenarios show our work is clearly based on mutual collaboration among the team members working in different areas:

Product managers need to assess value, risk, and business and technical feasibility for prioritization.
Engineers want to know the accurate timeline and requirements for an application they're developing.
Designers have to deeply understand the users to deliver the right experience using the right technology.
Finance officers (and/or executives) must be clear on the risks and values tied to the product features, in consideration of corporate-wide business objectives.

Sales, marketing, legal, customer success — There are numerous variations of inter-role dependency in practice.

We all want to make sure if we're doing the right thing, and being confident about what their organization does would be highly important to be successful.

To work better together under the uncertainty, we see many people are trying to "guess" how people in other roles work:

Product managers guess how much this project is risky and valuable, and guess if engineers and designers are comfortable with their proposal.
Engineers guess what the requirements are and how product managers and designers come up with a product idea.
Designers guess how much difficult for engineers to make their design real.
Customer success team guess how internal stakeholders make a decision and try to strategically escalate their client's requests to them.
...

Problem is that your inference is likely to be too subjective and biased. As psychological research revealed, our way of thinking (and working, subsequently) is not that guessable like stimulus-response model simplifies.

I would say reverse engineering a person sitting next to you is much harder than we imagine.

Introductory course as a source of mutual understanding

If guessing is a bad idea, is there anything we can do to effectively capture collaborators' expectations and capability?

Well, why don't you just meet in person and talk to each other?

But it might be challenging as a first step; when we have no idea what others think and how they work as I illustrated above, your conversation is unlikely to go well since you're clearly not on the same page. That is, I don't know a "language" (i.e., protocol) your colleague follows in their roles, and I couldn't give enough respect to them due to the lack of understanding.

On that point, I strongly believe taking introductory courses in your unfamiliar fields is the most valuable first step we could take to deepen mutual understanding.

If product managers take Introduction to Programming, they understand how programming is a complicated task.
If engineers take Introduction to UX Design, they familiarize themselves with a typical design process and techniques.
If sales reps take Introduction to Product Management, they realize how products they're selling are created.
...

I can easily imagine these experiences help to fill a gap between two different roles, know each other better, and show appreciation in the relationship.

I know course materials are usually impractical and far different from the reality, but that's fine; we're not trying to be a professional engineer or designer at this point. If you felt something new in either a positive or negative manner, the findings bring you one step closer to the unknown job responsibilities.

What I learned recently — UX Design and Finance

For the reasons that I mentioned above, I have completed Introduction to User Experience Design and Finance for Non-Finance Professionals in the last two weeks.

The former might be too conceptual and research-focused, but the course nicely introduced an end-to-end process of UX design, ranging from requirements gathering and design alternative to prototyping and evaluation, and key practical techniques we could use. Since I see many overlaps between the UX design principles and product development best practices, I'm planning to learn more in this field to exercise something more practical.

Meanwhile, I paid for the latter Finance class to push myself to the completion, because I immediately noticed the subject is not so enjoyable for me. The course structure and professor were exceptionally good through; given a simple formula of discounted cash flow (DCF), $\textrm{P.V.} = \textrm{F.V.} / (1 - r)^t$, I was able to learn the fundamental principle of time-value of money and realize what "Cash is King" & "Time is Money" really mean. Plus, we frequently use/hear the term "ROI" (Return On Investment) in industry, and the course gives us a deeper understanding of its definition and insights the formula brings.

I still don't see any visible impacts on my work, but I can confidently say I become able to more easily understand what context is, when I meet with my colleagues lately. Unsure if it's truly because of the courses though.

In summary, learning the fundamentals of unfamiliar fields is an easy way to broaden our viewpoint and make us open-minded. The activity hopefully enables you to see things from different angles and work effectively in a cross-functional team.

¹. If you're looking for "Introduction to Product Management" resources, I strongly recommend this book. I read the book when I was an engineer, and there were so many findings I couldn't list here. Note that there is a big difference between the first and second editions, so make sure you get the latest one. ↩

This article is part of the series: Ethical Product Developer

Author: Takuya Kitazawa

Takuya Kitazawa is a freelance software developer based in British Columbia, Canada. As a technologist specializing in AI and data-driven solutions, he has worked globally at Big Tech and start-up companies for a decade. At the intersection of tech and society, he is passionate about promoting the ethical use of information technologies through his mentoring, business consultation, and public engagement activities. See CV for more information, or contact at [email protected].

Now Gift a cup of coffee

Disclaimer

Opinions are my own and do not represent the views of organizations I am/was belonging to.
I am doing my best to ensure the accuracy and fair use of the information. However, there might be some errors, outdated information, or biased subjective statements because the main purpose of this blog is to jot down my personal thoughts as soon as possible before conducting an extensive investigation. Visitors understand the limitations and rely on any information at their own risk.
That said, if there is any issue with the content, please contact me so I can take the necessary action.