Sharing Knowledge

Sharing knowledge has many benefits, as outlined in this Northwestern article “Knowledge Sharing: Leveraging Trust and Leadership to Increase Team Performance”. But beyond performance it also helps team members connect and become stronger as professionals.

However, communication within a team or from one team to another is often difficult, and so it is always good to practice those skills. One way to do that is help folks identify what types of information would be useful to others. Types of information could be isolated into categories around - info/training on tools and processes, updates to project work or product enhancements, new capabilities discovered, or pain points / risks that have been found or escalated. When we come across this type of information, who should it be communicated to - internal team members, other teams (dependent or not), leadership, external vendors, users, etc.

Learning good communication skills can start small. Stand-ups can help stretch those knowledge sharing skills.

---

STAND-UP EXERCISE

Go round-robin with the questions:
What is one thing that someone else on the team could benefit from knowing you are working on? Said another way - what is one interesting thing you've learned/done in your work recently?

Measuring Burnout

I suggest everyone on my team keep an eye on Product Hunt at some level. It is a great place to see a wide variety of new apps and platforms across a variety of verticals, and can reveal useful products for both our business and personal lives, or just be a source of inspiration. On their site one of my UX designers pointed me towards Care, a burnout prevention tool for remote teams.

The Care app/site is both an assessment tool and a recommendation engine. After a quiz, it scores your stress, focus, and recovery level, and then provides potential fixes in the categories of personal well-being and team health. They offer a Slack plug-in or an online assessment. The assessments are free, or you can sign up your teams for a subscription and see even more metrics, comparisons, and recommendations.

Understanding your team’s burnout levels is always important, but perhaps even more so in this age of labor-market upheavals, evolving work-from-home norms, and macroeconomic uncertainties. With remote teams that can be even more difficult, as creating a maintaining personal connections is more difficult, as well as understanding someone’s true input / work hours. While burnout is often a result of exacerbated workplace stressors, it is not just a couple companies experiencing burnout culture; it is everywhere, as this American Psychological Association article details.

The first steps are understanding where your team members see themselves in terms of stress and burnout. Then you can look to the solutions, for themselves and their teams.

Note: burnout can/does affect all participants in a workplace. As a product leader, be sure you are also checking in on your managers / yourself.

---

STAND-UP EXERCISE

Have your team take the free self-assessment from Care prior to stand-up. You as a leader will be able to see the team’s overall results. Discuss with them if they were surprised by any part of the assessment. Were there any questions they wished were asked that weren’t? Is the action plan that was provided feasible or unrealistic? Are there items missing? What are ways in which we can combat burnout culture as a team? (Perhaps have those interested read this Entrepreneur article “5 Ways Leaders Can Fight Burnout Culture”.)

Encourage your product managers to perform this exercise with their own teams, and discuss how product teams can support each other.

Frameworks and Mental Models

One way product managers can be most effective is by having a process to get to the answers they need quickly and consistently. To find organization in the chaos of a new project or initiative, product managers can use framework thinking.

Framework thinkers are able to find clarity in complex situations. Further, good frameworks can bring focus to everyone's thinking, allowing the team to prioritize the questions that really matter. Framework thinkers make more progress because they remove the clutter and roadblocks for their teams.

Frameworks and mental models are abundant. There are some that are too specific in other areas to apply directly to product management, but almost all of them have something useful to take away. You can find much written about them, as companies and institutions who develop them have a strong incentive to promote them. The specific model becomes part of their brand, their unique selling proposition, and eventually recruitment tools. Some become whole books or treatise, which may or may not actually be the point of a framework. It should be easy to remember and simple to employ.

PMs can start researching specific frameworks for product management to provide structure. You want to build a personal catalog of these that you can lean on when faced with a problem or complex initiative. But looking widely at general business or thinking frameworks can also make you a better product manager (and more well-rounded person). Any of these require a bit more research into the methodology, as well as some trial and error in the application of it.

---

STAND-UP EXERCISE

Ask the team to read (or listen to) Product Management Mental Models for Everyone, which highlights frameworks in the categories of Investment, Design/Scope, and Shipping/Iterating. I asked my team specifically to reference models 5-12 in the designing and scoping section.

For stand-up discuss if anyone sees where these frameworks might have been useful to have in past projects. Ask if anyone has additional frameworks they use regularly, or have seen used at other employers. Do any of these contradict each other? Are there some that seem better suited for the culture or content of your team than others? Which can you immediately begin using, or using elements of?

Envy

The journey to be a better product manager or product designer, like most professional careers, is full of comparison. Comparison against others on the same career track, against other product teams and their resourcing or maturity, comparison against other products at other companies (which can be great research!), comparison against other areas of the business and their ability to drive or accomplish work, and the list goes on.

Comparison can often trap us in envy. You do the comparison, find your own lacking, and wish you had the other. This is how some features get put into roadmaps, after all. But looked at slightly larger, the comparisons that make us envious might also have something to teach us - especially if we think about it in terms of personal or professional growth. The twinge of envy is a trigger that we are unhappy or desire to change something. Can we spin that into an action?

A bite-size podcast I often listen to is the Before Breakfast podcast by Laura Vanderkam (episodes are around 5-10 minutes). She had a specific episode called “Understand your Jealousy”, which speaks to this idea of finding meaning in what makes you envious, albeit in a more personal setting. Finding your “pain point” of what makes you envious allows you to do something about it.

---

STAND-UP EXERCISE

Do whiteboard exercises with your team to kick off a conversation. My team did this exercise over two different stand-ups, but you could combine to one, time-permitting.

The first whiteboard is asking folks what makes them envious. I put it on a scale of personal to professional, so we could spark conversation easily but still dig into the workplace-focused topics. The second whiteboard flips the idea, asking why might others be envious of you? This is meant to open up the understanding of jealousy (that sometimes what you perceive isn’t reality) and that it can also be a real driver for behavior.

What forward steps can we create from where we see our envy? And where can we help others by noticing their envy of us? How do we turn what can be seen as a negative emotion into a call for action?

Asynchronous Ways of Working

The most effective product teams know how and when to communicate with each other, which is why all teams should have agreed upon “ways of working”. This could be referred to as ground rules, or working agreements, or baselines, but they should define how the team wants to work together, what they want in the working environment, and what they want from each other. There are many templates out there, and perhaps we’ll revisit this broader theme in a future stand-up topic.

But I’ve recently asked my team to reconsider their ways of working in terms of the working environment. Much has changed in the last two years regarding virtual work, and our organization (which was previously quite location-specific) has hired folks from across the globe in that time. This means product teams span countries, timezones, cultures. Since some folks have begun returning to an office at least a couple days a week, and some folks won’t ever go into an office, it is an ideal time to revisit the topic.

One of the original principles of Agile was regarding physical co-location. That has obviously eased and been replaced by virtual co-location. But I asked the team to consider asynchronous communication for areas where they might never have previously thought of it. Geekbot published an article explaining how to run asynchronous stand-ups, that formerly sacred synchronous touchpoint of each product team member’s day. (Geekbot has incentive for this, as their product is a Slack plug-in to help automate/optimize this process.) Finding tools and processes that optimize for all folks on the team is necessary for an effective product team.

---

STAND-UP EXERCISE

Have your team review the Geekbot article “Daily Remote Standups: Video Call Downsides & How to Run Better Remote Standups in Slack”, and then discuss if they have found any of the same challenges as the article outlines. Are folks getting burned out on all the video meetings? Is the daily standup timed appropriately for all team members?

And then look to them to push it forward - how can they incorporate solutions to some of these problems? How would you test async stand-ups within your own team? Can you begin running asyc stand-ups for Summer Fridays? Or on days that are already ceremony-heavy like the end of sprints? How can you pair with your Agile coach / scrum master to experiment with this?

What are other asynchronous tools that can be employed within your product team? Are these documented in your ways of working?