Menu

Posts tagged “product management”

The Trap of Tying Your Identity to Your Job Title

Elena Verna makes some really great points in her post on The Trap of Tying Your Identity to Your Job Title. If you are struggling with questions around title and importance and what it all means, this one is for you. This point on external expectations particularly stood out for me:

Perhaps most concerning is the inclination to make career decisions based on perceived market expectations rather than personal happiness and well-being. This mindset propels individuals down a path not of their choosing, driven by the desire to conform to societal benchmarks of success rather than pursuing what genuinely brings joy and satisfaction.

On kindness and decisiveness

Mike Fisher reminds us how important it is for leaders to be excellent listeners in Listen or Speak. This part particularly resonated because it’s a misconception about me that I’ve had to deal with my entire career:

Just because we speak softly doesn’t mean we act with hesitancy or indecisiveness. We can be a strong leader, setting the example, and making the tough decisions all the while communicating in a manner that keeps the conversation going and open to other people’s inputs.

I believe strongly in acting people-first as a leader, and I’ve found that when I’ve gone through interviews and/or job changes in the past there is a very common worldview that equates kindness with indecisiveness. It always takes a little while for people to realize that just because I believe we make better and more successful products when we treat each other well and truly listen to everyone’s input, it doesn’t mean I don’t know how to make decisions.

I haven’t quite been able to put my finger on why this misconception exists in the corporate world, but my current hypothesis is that collaboration gets confused with consensus, and there is a fear that “speaking softly” will result in a consensus culture where decisions take forever to be made. With that part—the dangers of consensus cultures—I do agree with. Consensus cultures often produce watered down, unexciting products. Products where endless rounds of give-and-take have worn down the original idea to a shadow of what it once was. Consensus cultures also wear down the teams working on the product, because no one really gets what they want, they just get some of it.

So I always try to make the point that I prefer collaboration over consensus. In collaboration cultures people understand that even though everyone gets a voice, not everyone gets to decide. People are able to voice their opinions and argue (kindly!) for how they believe things should be done. But it certainly doesn’t mean that everyone has to agree with every decision. That seems to help—so if you find yourself in a similar situation, give that framing a try!

Since this is something I have felt in my own career, it’s also something I try to be cognizant of in my dealings with those around me. Just because someone doesn’t dominate the conversation (see the “babble hypothesis”, which states that those who talk the most tend to emerge as group leaders), or refuses to engage in combative conversations, it doesn’t mean that their viewpoints and opinions are weak or invalid. In fact, the opposite is likely true.

No, but phrased in the form of a question

In No, but phrased in the form of a question the Raw Signal team gives some great advice about how to handle those seemingly out-of-nowhere senior exec requests as a leader:

The problem is that as you get more senior maintaining productivity and de-risking execution is no longer good enough. Your job is not stability for its own sake. Your job is to make your team an instrumental piece of the organization’s success. And yes, one piece of that is making sure they can focus on their work. […]

The more senior you get, the more your approach to change needs to evolve from concern and critique, to curiosity. Whether that’s the CEO and their team bringing forward a new strategy, or a colleague pulling you aside after a meeting with an idea. Just for a minute, park the questions about implementation, and look at the idea on its merits.

On empowered teams vs. feature factories at sales-led organizations

I think this is a really insightful comment (LinkedIn) by Ben Erez about the realities of being a PM in a sales-led organization. It’s worth reading his whole argument because it’s definitely a spicy take. But the crux of it is that sales-led organizations cannot function with empowered product teams (I think everyone who reads this blog knows what I mean by that, but just in case, here’s a refresher).

Here’s a key part of Ben’s argument, and the really spicy part:

I think sales-led companies should embrace the feature factory culture fully; stop evaluating PMs by their strategic contribution (a weight off the PMs shoulders given they never get time for strategic work anyway) and start rewarding PMs based on how many features they ship that the sales leaders care about. This will align the PMs in your org to think and work the way the sales team (and CEO) wants them to work. It’ll kill many unhealthy tensions in the org and get people rowing in the same direction.

Would I want to work in that environment? Probably not.

But most b2b SaaS companies are already sales-led. And there are thousands of PMs in those environments who feel the tension I’ve described. So I think most b2b SaaS PMs would celebrate their company embracing their feature factory and just calling it what it is.

Could this be seen as defeatist? Maybe. But I also think that the “just calling it what it is” part of the argument is really key here. It doesn’t serve anyone—not the product, not the company, and certainly not its customers—to pretend you have an empowered product culture when you do not. So remove the pretense, and just be honest about who you are.

If you want to become an empowered organization, that’s great! But that’s a transformation that has to come from the executive level, and it’s not a short or easy process. So go on that journey, yes! But until then, be honest about what the organization is, make expectations clear to PMs, and reward them accordingly.

How Asana and Slack’s meeting purges have paid off

The importance of async work and cutting down on meetings to allow for more Deep Work time won’t be new to regular readers of the blog. And yet I can’t resist sharing another article about it… How Asana and Slack’s meeting purges have paid off has the usual methods and recommendations in it (although “Meeting Rest” is a new one to me—read the article for details).

Instead what I want to focus on here is a few pull quotes about the results companies report once they were able to successful reduce their meetings. Here’s Asana:

A few months later meeting lengths had shrunk. Most 30-minute meetings were converted to 15 minutes, some weekly meetings were moved to every other week or month, and others were deleted entirely. That meant each person was saving an average of 11 hours per month, totaling about 3.5 workweeks per year.

And:

The 60 participants saved 265 hours per month in total when reducing unproductive recurring meetings. In the aftermath of our meeting reset, employees are much more strategic and thoughtful about removing items from meeting agendas that can be effectively handled asynchronously.

From Remote:

By cutting down on meetings, we’re not just saving time. We’re also empowering our teams to work on their own schedules. This gives our employees a sense of autonomy and keeps them motivated, fostering a culture of productivity and efficiency.

And finally, Typeform:

We sent another engagement form to the team to see how they were feeling after we made these changes. The ‘ways of working’ score went up more than 10 points. Trimming our meeting time has helped our employees and our customers, which is really satisfying.

It’s worth the effort, friends. Re-evaluate the need for all those meetings. Embrace async. It leads to happier employees and more effective communication in permanent places that can be referenced in the future. And, importantly, it leads to higher quality products because no one has to rush through “actual work” after all their meetings are finally done for the day.

Evolving our organization: introducing Engineering Managers and Engineering Leads

I’ve been digging into different ways to structure engineering teams a bit, and I like this take on the different roles of Engineering Managers and Engineering Leads:

It became obvious that in most cases it’s too much for one person to manage people (growth, performance and motivation), along with driving technical execution. At the same time, in most teams, we had one or more senior developers on whom Tech Lead could rely and delegate architecture decisions, quality, mentorship, etc… We decided to give these engineers roles to make them recognized in the company for their impact, also to improve communication channels, and to help team and product leads. We introduced the role of Engineering Lead to have a major influence on how we build products. Additionally, we replaced the Tech Lead role with the Engineering Manager role, which gave more focus on people and team management (“who”).

It also reminded me of Lara Hogan’s excellent post on how Engineering Managers and Engineering Leads work with Product:

Fit

Molly Graham has a fantastic essay on how to figure out if a job is the right fit for you. The post focuses on senior roles, but there are some great tips for everyone here:

What I look for, truly, is the intersection in the two sides of the equation: does what we NEED match what this person WANTS to do? As I said, most companies and most interviews focus more on the question: can this person do what we need? But if you’re trying to recruit the best talent in the world, it needs to start with them. Who are they? What do they love doing? What are their ambitions? How does their past shape what they want for their future? What are they insecure about? What do they want to prove? My interview style is really about mapping that.

Quality vs Quantity

Mike Fisher preaches the good stuff in Quality vs Quantity. He talks about the importance of shipping small, incremental releases to customers:

By prioritizing the quantity of opportunities to learn, teams encourage a culture of continuous learning and flexibility. Each iteration becomes a learning opportunity. This method aligns more closely with real-world conditions where customer preferences and market dynamics are constantly evolving. Furthermore, this approach reduces the risks associated with big launches like Windows Vista, where a significant investment is made in a single, large-scale product release. Instead, smaller, more frequent releases allow for adjustments and refinements based on actual user feedback and engagement.

5 Different Types of Debt That Can Hinder Your Product Organization

I like Jason Knight’s take on 5 Different Types of Debt That Can Hinder Your Product Organization. There’s the usual “tech debt” advice, of course, but also some good insight on other types of debt to look out for, such as…

Revenue debt builds up as companies scale up through unstructured sales-led growth, selling to anyone they can, meaning that they start to build dependencies on a disparate set of customers who have sometimes substantially different needs. This makes focusing, or even saying no, too difficult because there’s too much revenue tied up in each segment.

Say the quiet part out loud: simplifying communication in high context environments

The Culture Map by Erin Meyer is a great book about how to improve communication between different cultures when you work at a company with a global workforce. Recently I’ve been thinking about how these concepts apply not just at a (geographical) global level, but within the systems of a single organization. What are the norms of how people communicate with each other in meetings, in email, over Slack? What type of confusion/misalignment might happen because of those norms, and how can it be improved?

There’s one dimension the book covers that I think applies particularly well to modern organizations, and that is the difference between high context and low context communication.

High context settings are those where communication relies heavily on implicit understanding. The assumption is that everyone has the same frame of reference, which means a lot is left unsaid, with the belief that everyone “just gets it.”

Low context environments, on the other hand, are those where things are spelled out more clearly. There’s less assumption that everyone has the same background information or knowledge, leading to more explicit communication.

For instance, if you often don’t know what people are talking about in meetings and it makes you feel like you missed something obvious, you might be in a high context environment. Perhaps things move so fast that there’s an assumption that everyone already has all the context of the previous 10 meetings that happened about a topic. It’s natural for this to happen—but it reduces the effectiveness of our work and the health of our relationships.

I’ve been trying to be more deliberate about addressing this issue—at least for myself and the people I work with most closely—by actively going more “low context” in my communication. When something is implied through context, but not explicitly stated, I aim to go out of my way to make it explicit.

The goal is to ensure that no one has to feel like they can’t contribute (or be scared of making the “wrong” contribution) because they weren’t part of every conversation. By making the implicit explicit, we level the playing field. It’s not just about adding clarity to our communications, it’s about fostering an environment where everyone, regardless of their starting point or level in the organization, has the same opportunity to understand and contribute.

By breaking down our messages into clearer, more accessible information, we’re not dumbing down—we’re opening up. We’re building a foundation where everyone can work confidently, equipped with the knowledge they need to contribute meaningfully.

Keep an eye out for opportunities to say the quiet part out loud. To clarify a statement, or state the thing that appears to be said between the lines. It takes work and concentration, but it’s a shift that can make a big difference in how we work and relate to each other.