How You Communicate Signals Your Seniority

Three sentences in, I will likely have judged whether you are a good leader. 3 common pitfalls to avoid sounding more junior than you are.

Client: I know I have the skills to do product management at the senior or leadership level. However, whenever I talk with a hiring manager, I get down-leveled after the conversation. They don’t view me as a leader. What did I do wrong?

Consider the following two responses to the popular interview question: “Tell me about yourself.”

Example 1: I am an expert in product road mapping throughout the product development lifecycle. I have extensive experience growing product teams, clarifying product vision, converting opportunities into strategy, and building cohesive plans. I have experience in documenting and evaluating decisions and running daily standups and agile release meetings.

Example 2: I am a product leader with 10+ years of experience at consumer and Saas companies. I launched and grew a new product from 100 to 10,000 users, managing a team of PMs and 80+ xfn partners. I opened a new office for the company in New York, grew it to 40 PMs, Designers, and Engineers, and then opened another new office in Dubai. I partnered with our CPO to draft our team values, iterate on the recruiting funnel, and standardize operational forums like product and design reviews.

Based purely on the responses, who would you hire? Who would you consider for a manager role? Do you even believe this is the same person?

The altitude of your communication signals your seniority and experience. Over and over, I see candidates focus on the wrong parts of an experience to highlight in their resume or initial phone screen when they have great relevant experiences for the role.

Talk about the outcome and why, not the input.

Leaders focus on the outcome and impact delivered of the work they do, not how it is done. Hiring managers want to know what business impact you delivered for the company, not that you know how to do sprint planning and make presentations. So focus your precious time or space on describing the outcome. It sounds something like the following:

I was at Thumbtack for 5 years leading the supply side of the marketplace. In my time where, we grew the supply 20X from 5,000 to 100,000 small businesses — the largest platform of SMBs for services in the US.

When I was at Meta, we shipped a set of updates to how small businesses set budgets and targeting for their ads. This increased campaign start conversion by 15%, leading to $20M increase in revenue globally.

When I was Instagram, we redesigned the Profile tab to better accommodate new features like IGTV, Shopping, and Reels. This led to 50% more engagement on IGTV and 100% more engagement in Shopping, key initiatives for the company at the time.

I led a project to refactor the core code base and make performance improvements which accelerated development speed by 30% and decreased app size by 50%, leading to 10% in app installs.

(please note all numbers are illustrative)

Particularly for product leaders, your role is directly tied to the outcome of the business. If you launched product features but cannot describe the impact it had on the business, then why did we spend precious engineering and design resources on it?

Some projects may be more straightforward to measure impact than others. In general, if you want to progress in your career, it’s important to be staffed to projects that tie closely to business metrics (see. previous post “When in doubt, chase a number”. While it may be “useful” to do that refactor or redesign, or work on an annoying bug, if it doesn’t have high impact, it is not going to get you further in your career. As you can see above, even redesigns and performance improvements can and should tie to a business case.

The more you describe the “How”, the more Junior I think you are.

Many early career product managers default to the “how” of product management when describing their work. They prioritized roadmaps, ran sprints and standups, and communicated across functions. They know how to use JIRA, Figma, and Loom. They have certifications in agile or program management. They may be good to get past the initial resume filter. However, as a hiring manager, particularly for product leaders, I honestly don’t care about any of those things. I start with the assumption that you know how to run a product team.

Instead, I want to hear what happened as a result of that work (above), and how you evolve what you do based on the situation and needs of the team. Only junior managers take a generic one-size-fits-all approach. The more you describe a generic “how”, the more I question whether you are a leader who’s led through a variety of challenges, or an entry-level PM who is still learning by applying generic frameworks. Do you know that sometimes it’s better to adopt a kanban system versus do sprints? Can you evolve your communication channels and style based on the urgency and complexity of the project? Can you organize your team differently based on the strengths of each person? Each team and project is unique, and the “how” needs to differ.

Therefore, never lead with a “how” to answer a “what did you do” or “why should we hire you” question. And when your hiring manager does ask a question like “What’s your working style? or “How do you like to run your product teams?”, get specific with your answer.

“I recently led a high priority project with a ton of urgency, so we did daily 5 min standups over Slack and set weekly review holds with key decision-makers that we cancelled if not used.”

“When my team was small, we had an informal sprint process but we mostly checked in weekly on progress. I gave my engineers and designers a lot of autonomy to work directly together towards launching incrementally. My role was to help breakdown and prioritize. As the team grew, we adopted a kanban system due to the different skillsets on the team (e.g. iOS, Android, Web), and I focused on clearly identifying dependencies so that we didn’t get bottlenecked.”

“I prefer to delegate wherenever possible. I like to have my engineers or designers lead parts of or entire projects, and often look for opportunities to let me research or data counterparts lead brainstorming conversations based on their work.”

I know you can learn JIRA. What is harder to teach is working style with peers across a variety of functions and experience handling conflict. Focus on describing your values and how you adapt to challenges and conflict, particularly ones you foresee the particular job or company facing where possible.

Speak to the context of your audience, not of yourself

One of the clearest differences between a product leader and a junior PM is how easy it is to understand the point they are communicating. A junior person can make explaining a simple concept long-winded and complicated. They try and cover every detail, but without structure and with many acronyms. A senior leader will make a complex point simple to grasp for anyone whether they are close to the work or not.

Let’s imagine a scenario where a service was down, and the product leader is making an update announcement to the rest of the company:

Example 1: The service shut down for 2 minutes today due to a bug that was pushed to production. We recently refactored the services_info service in our web code base and did not consider correctly handle the multi-user scenario. We have not been able to prioritize this refactor for a few months due to the push to get ship onboarding features. We’re fixing it now.

Example 2: At 10am today, our service was down for 2 minutes, resulting in $1000 of lost revenue and increased customer support volume. The service is now back up and support volumes are now back to normal. The engineering team is working on a long term fix that is expected to be complete by end of today. We will also perform a review on our processes for launching new features to catch issues like these in the future. If you have further questions or concerns, please reach out to Joe.

Which communication feels more senior? The difference comes down to the following:

1. Specificity as relevant to the audience: Both messages have some specificity (e.g. 2 min outage). However, the second example has specificity that is important to the audience (e.g. revenue lost, support volume, who to contact for questions). Whereas the first example has a specificity that is important to the team but the audience (e.g. refactor causing the bug, why it was not prioritized). The communication prioritizes what the audience likely wants to know and is at the level of understanding of the listeners, not the speaker.

2. Focus: A senior leader tries only to make one point at a time. The most important one. They don’t try to cover all their basis and explain everything at the same time. They also don’t “run-on” into unnecessary detail for the situation (e.g. we didn’t prioritize it because…”)

3. Sets expectations: The second example sets expectations for what happens next (e.g. support volume stable, the fix is out by the end of the day, process review will happen). The first does not. Setting expectations gives people who are concerned about the outage a clear path forward and a sense that the situation is being handled with seriousness and worked on urgently.

4. Avoid Acryonms: The first example contains a large amount of technical or functional language (e.g. pushing a bug to production, or refactoring a service). The second example avoids this entirely as it is irrelevant to the majority of the audience.

Communication is a skill, and it takes practice. If you’re in the day-to-day work, it can be hard to pull yourself out of it and up-level your communication. Practice with a friend or colleague. If you’re interviewing, practice with a coach. It can be more powerful to do one practice with a mentor or coach who knows what good looks like than it is to do 10 practice sessions with someone who is at your level.