Episode #58: Building Products Through User Contact and Clear Communication with Rohan Katyal

Great product work is not only about choosing features. It is also about earning trust, keeping teams aligned, learning directly from users, and knowing when to change direction. In Episode #58, Rohan Katyal shares a practical view shaped by engineering, growth, and zero-to-one product work.

What you'll learn

• How an engineering background can improve empathy, trust, and trade-off decisions

• Why direct conversations with users reveal what reports can miss

• How a consistent communication cadence helps different stakeholders find what matters

• Why growth teams should test broadly before concentrating on the strongest levers

• What influence without authority actually requires from a product manager

Use technical understanding to make better trade-offs

Katyal studied computer science in undergraduate and graduate school and describes himself as an engineer by training. He says that engineering gave him a problem-solving mindset and a tactical understanding of how products are built. A product manager does not need to write every line of code, but knowing what happens under the hood can improve the quality of planning and collaboration.

That understanding also builds empathy. When a PM recognizes why one change may take three weeks while another takes four, conversations with engineers become more realistic. Technical context helps the team discuss what could go wrong if a seven-week investment is shortened, what value might be lost, and where a compromise is acceptable. The point is not to overrule engineering. It is to make trade-offs with a clearer picture of their consequences.

Stay close to users and communicate with discipline

One of Katyal's strongest lessons is simple: teams should talk directly with users. Research reports and dashboards are useful, but they cannot capture every detail of how someone experiences a product. While working on Super, a product for creators that was later sunset, some creators had his phone number and would text when an event ran into trouble. Those direct exchanges exposed real usage patterns and problems that might never have appeared in a formal report.

He pairs user contact with deliberate overcommunication inside the organization. The tool matters less than the system. Teams may use Slack, Notion, or another stack, but updates work better when they arrive on a predictable cadence and in a consistent format. Readers rarely need every detail. Consistency lets each person quickly find the section, metric, or decision relevant to them.

Data and frameworks also help move discussions away from ego and past-company anecdotes toward the current situation. However, one update does not fit every audience. A team, a manager, a cross-functional partner, and a senior executive may need different levels of detail. Discipline creates the structure; empathy determines what each audience needs.

Test broadly, then concentrate on evidence

Katyal describes growth work on click-to-WhatsApp ads as a case where a strong underlying product made expansion possible. The team included people with relevant growth experience, which brought many hypotheses into the room. Rather than betting everything on one idea, they explored a broad set of possible levers, including acquisition, activation, awareness, product changes, and increased value for advertisers.

Over roughly two and a half to three months, the team tested multiple hypotheses. Once two or three areas showed promise, they went deeper. Awareness and education emerged as important because businesses already using the product found value, while some non-users either did not know about it or did not understand how to use it. When education increased their intent to adopt, the team concentrated on that opportunity.

The broader lesson is a useful operating pattern: assemble people who understand the problem, generate several informed hypotheses, test across the opportunity space, and then focus resources where evidence is strongest.

Lead through influence, not a CEO title

Katyal pushes back on the familiar claim that a product manager is the CEO of the product. CEOs typically own responsibilities such as profit and loss, hiring, and formal organizational authority. Most PMs do not. The limited overlap is that both roles can be ambiguous and require stepping into whatever problem is blocking progress.

For product managers, influence comes from making a sound case, not from having the final say. That reality can be especially surprising for people entering associate PM programs. A PM may support a large cross-functional group while being the only person in that role, without peers on the immediate team or authority over the people doing the work. Clear reasoning, context, relationships, and storytelling therefore matter.

Katyal learned this firsthand when his presentations at Meta were too detailed or failed to focus on what executives needed. He improved by studying strong presenters, practicing in team and cross-functional settings, asking listeners for their three takeaways, joining Toastmasters, and seeking mentorship from a respected communicator. The feedback revealed gaps between the message he intended and the one people received.

Build the habits behind better product decisions

This conversation connects product craft to a set of repeatable habits: understand enough technology to discuss consequences, maintain direct contact with users, communicate predictably, test before narrowing, and tailor the story to the audience. None depends on a grand title. Each helps a team make clearer decisions together.

Listen to Episode #58 with Rohan Katyal for the full discussion on zero-to-one work, growth, communication, and practical product leadership: play the episode.