Leadership And Execution Excellence: Assessment for Product Managers

Leaders inspire and motivate without exercising authority, while managers have specific responsibilities like coaching and staffing.

Feedback

To be effective as a Product Manager, you must act as a leader. Good leaders influence others, inspire, and motivate them without excercising authority.

Why

Feedback

As Simon Sinek explains in Start with WHY, the most important question a leader must answer is “WHY.”

Why are we doing this? What’s our purpose? Why does it matter?

People can only become truly engaged and motivated when they see the “big picture” and feel they are contributing to something meaningful.

Uncover the significance of purpose in leadership and execution in “The Product Leadership Playbook“

Act as a leader

Feedback

As a Product Manager, you’re not a manager to the designers or engineers, hence you might not have the specific expertise to coach or staff these roles.

To be effective as a Product Manager, you must act as a leader.

Importantly, not every conflict is bad. It’s essential to have good, constructive conflicts so that we can challenge our ideas, solve problems, and innovate as a team.

Adjusting the level of freedom to the team’s maturity.

Feedback

It’s essential to adjust the level of freedom to the team’s maturity:

– Too much freedom can confuse and overwhelm a team and create a mess because they don’t know what to do. This can lead to frustration and demotivation.

– Too little freedom can make them feel trapped, like they can only follow orders and can’t think for themselves. This can also result in frustration and demotivation.

Both situations can make the team unhappy and less effective. So, it’s important to strike the right balance.

Remember, empowerment doesn’t mean “delegate and forget.” It’s about being present and ready to support your team when they need it.

Purpose, autonomy, psychological safety, mastery

Feedback

Purpose: As Simon Sinek explains in Start with WHY, the most important question leader must answer is “WHY.”

Autonomy: In No Rules Rules, Reed Hastings and Erin Meyer highlight the most critical aspect of Netflix’s culture – leading with context, not control.

Psychological safety: The importance of psychological safety can’t be stressed enough. In Amy Edmondson’s book The Fearless Organization, she defines it in as “a shared belief held by members of a team that the team is safe for interpersonal risk-taking.”

Mastery: Daniel Pink nailed this feeling in his book Drive when he defined mastery as “the desire to get better and better at something that matters.”

Money is not a motivating factor in the long-term: https://hbr.org/2013/04/does-money-really-affect-motiv

Exposing vulnerabilities and admitting mistakes

Feedback

Being authentic is an essential part of developing meaningful relationships. People can connect with and feel close to others when they expose their vulnerabilities.

I remember one of my directors saying, “I forgot. I’m old.” That was an amazing feeling. Those words were impossible to fake.

“In order for connection to happen, we have to allow ourselves to be seen, really seen.”- Brené Brown

It’s important to avoid a common mistake: while staying authentic, remember to adapt your communication style to the audience. This is not about pretending but rather about professional communication.

Team regularly achieving its goals

Feedback

The effectiveness of leadership is often measured by the team’s ability to achieve its goals. It reflects the leader’s ability to guide, motivate, and support the team effectively.

Reduce the cognitive load
Minimize bottlenecks and handoffs

Feedback

According to the Conway’s Law:

“Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.” – Melvin Conway

In the same way, it’s logical to model an organization’s communication structure to mirror the desired software architecture. This approach is known as “The Inverse Conway Maneuver.”

Create and maintain the shared infrastructure and tools other teams rely on

Feedback

Stream-aligned teams are the heart of the Team Topologies approach. Most product teams fall into this category.

They are small, self-contained teams that fully own a specific stream of work, such as a product, user journey, or customer segment.

Stream-aligned teams are cross-functional, empowered to make decisions, and responsible for the entire lifecycle of their work, from discovery to delivery and beyond.

In Empowered, Marty Cagan calls those teams “experience teams” and differentiates between:

– Customer-enabling experience teams, when the users are internal employees.

– Customer-facing experience teams, when the users are company’s customers.

By feature(s) set

Feedback

When scaling by feature(s) set, each team is responsible for developing and delivering a feature or a set of features.

Pros:

– Clear definition of the team’s boundaries.
– Can lead to less technical dependencies between teams.

Cons:

– Can lead to teams working in silos.
– More challenging to focus on the outcomes.
– More difficult to keep a cohesive UX.

To set and communicate goals

Feedback

To set and communicate clear goals.

Leading tech companies are successful not because of OKRs, but because they use OKRs as a tool to enhance their empowered teams.

As quantitative metrics

Feedback

Quantitative metrics that measure progress towards the Objective

Focusing on goals, not features

Feedback

According to Marty Cagan, “(…) most of your ideas are simply not going to work” – Inspired

Besides, nobody cares about the features. It’s about the problems they solve and an impact solving those problems has on the customers, and the business.

There are cases when your business needs a specific date, for example, marketing might need to prepare a GTM strategy.

The most important rule is not to make those commitments too soon.

Ask for additional time to address 5 risks:

– Value. Will it create value for the customers?
– Usability. Will users figure out how to use it?
– Viability. Can our business support it?
– Feasibility. Can it be done (technology)?
– Ethics. Should we do it?

More: https://www.productcompass.pm/p/what-exactly-is-product-discovery

Communicate those “high-integrity commitments” as estimates, not dates.

Sequential task execution

Feedback

A traditional Gantt chart is a time-based, feature-based roadmap. It might work in project management, but is a fatal choice for product managers.

Embrace what you don’t know.

Product Owner is just accountability, and Product Manager is a job title. It’s the same person.

Feedback

Product Owner is just accountability, and Product Manager is a job title.

The Product Owner’s accountability, described in the Scrum Guide 2020, is best fulfilled by an experienced Product Manager.

Product Managers vs Product Owner: Who’s Who?

Sprint Review

Feedback

Scrum says nothing about product strategy, product discovery, releasing a product to learn from customers using it for real, and leveraging product analytics.

You can learn more from this video: https://youtu.be/GR9-8lOUhwA

Cycle time, work in progress, and throughput

Feedback

Kanban is about optimizing the flow of value.

3 key practices :
– defining and visualising a workflow
– actively managing work items in a workflow
– improving a workflow

1. Cycle Time

A Kanban metric that is a component of Lead Time. It measures the time it takes from when the implementation of an idea begins until it’s done.

2. Work In Progress (WIP)

WIP is a Kanban metric that represents the number of ideas that your team is currently working on.

The goal is to limit WIP to reduce context-switching and minimize the Cycle Time. This ultimately minimizes the Time To Market (TTM).

3. Throughput

The rate at which ideas pass through your team’s workflow over a given period.

It’s essential to know Little’s Law, which can be expressed as:
Avg. Cycle Time = Avg. WIP / Avg. Throughput

A great set of resources: https://kanbanize.com/kanban-resources/getting-started/what-is-kanban

Card, Conversation, Confirmation

Feedback

The 3 C’s of User Stories are Card, Conversation, and Confirmation.

They are essential for writing a good User Story:

1. Card

Those are the cards I previously presented, explaining WHO, WHAT, and WHY. Although they once were physical cards, you’re more likely to create User Stories in tools like Jira today.

2. Conversation

Rather than creating a detailed specification, discuss the reasoning behind the User Story with the whole product team and stakeholders.

It’s also essential for everyone to understand not just how the User Story will benefit the users but also how it will contribute to the Product Outcome (or Product Goal in Scrum) and how it aligns with your product strategy.

This empowers others to make informed, autonomous decisions without micro-management.

3. Confirmation

Confirmation refers to the Acceptance Criteria that should be fulfilled to ensure the requirements have been met and delivered correctly. It’s typically a concise checklist, not a list of detailed test cases.

A larger User Story, which need to be splitted into smaller User Stories

Feedback

Some User Stories are too big to be selected for the implementation. In that case, you must break them into smaller, more manageable pieces to deliver value faster and, ideally, start learning from customers using your product for real.

– Epic: A larger element, typically combining 5-15 smaller User Stories (please do not attach to those numbers; that’s highly context-specific).

– User Stories: Small, manageable items.

– Tasks: Used to plan and monitor the exact work performed by Engineers. Product Managers have nothing to say here.

When evaluating a product, I want to read reviews of a product, so that I can reduce the uncertainty

Feedback

What I like about Job Stories is the focus on the context in which the action is performed. The format of a Job Story:

SITUATION: When [the context]
WHAT: I want [action to perform]
WHY: So that [the desired outcome]

But as you might notice, it misses the information about the user.

So, if you want to write Job Stories, I encourage you to include the information about the user:

WHO AND SITUATION: When [the context] as a [user type]
WHAT: I want [action to perform]
WHY: So that [the desired outcome]