How to create meetings that don't suck

Often throughout the week, I look ahead at my calendar and wonder how and why I have so many meetings. Is it because so many of us are remote? I don't think that's the case as visits to the office are packed with meetings too. Is it because in my role as a product leader, I'm often bringing cross-functional teams together to discuss strategy and define + align on a path forward? It would be oddly comforting if that was the case, but looking through my calendar it doesn't feel like that's the reason. There must be ways I can be more efficient. 

I've shared previously that I set aside "focus" time in my calendar for deep thought. I'd say about 60 to 70% of that time remains meeting free. Could I be doing more to increase the percentage? 

In my People-First Product Leadership course, I recommend individuals do a meeting retrospective. 

1. Identify the meetings you have during the week where your entire product team gets together. If a meeting occurs every other week or once a month, include the recurring meeting as well.  

2. Put a * by the meetings where learning or reflection occur.  

3. Strikethrough those meetings where the format is more broadcast and the content could be shared effectively asynchronously, for example via Slack.

4. Now, just as you would use a retrospective to evaluate a sprint or release upon completion, go through the steps above and determine which meetings should “continue” vs “stop” or potentially be revised or introduced

Fortunately I've listened to myself and have done this exercise already. Yet, I keep returning to — what else could I be doing?  Are there tricks or tips you have found work for you?  I'd love to learn from your experiences. 

Included below are articles which build on the ‘being more effective’ theme. 

--

Meetings That Don’t Suck

Of course the title drew me in, so I borrowed it for this newsletter. What can I say... I didn't come up with a better heading after playing with ChatGPT. 

The article is from a Product Manager which made it easier to visualize the impact the suggestions could have on my calendar.  Even though a number of the recommendations were familiar, I enjoyed the slightly sarcastic tone and was reintroduced to suggestions I could immediately apply. Here is the entire list. 

1. Kill the status meeting

2. Hold one-on-one meetings sacred

3. Every meeting must have a single owner

4. Share the purpose of the meeting and agenda ahead of time

5. Your calendar doesn’t make you important

6. Calendars shouldn’t postpone decisions

7. Keep meetings small

8. Consider the opportunity cost of every meeting

9. Treat other people’s calendars as a scarce resource

10. Escalate, don’t undermine

11. If the meeting is over, end the meeting

12. Declare calendar bankruptcy

I have been working with my team to take more ownership of meetings (#3, #4 and #7). Keeping meetings small (#7) is a nice one to unpack as meeting size often provides an interesting lens into company culture as does the path to escalation (#10). 

Based on reflection and reading a related article on making async decisions, I tested out the following approach on a project I'm leading.  

• Began the project Slack channel title with "temp" thereby visually conveying to all that the meeting series would be finite. 

• Titled each meeting in the calendar with its number in the meeting series as a "count down" to completion.

• Identified who should be "informed" (thank you RACI / DACI) and added those folks to the Slack channel but not to the meeting series. 

• Shared the decisions and numbered actions with owners and due dates in the Slack channel as a visual reminder and reference

• Sent a reminder in Slack of the meeting number and actions + owners ahead of each session.  

The approach worked. There was focus, ownership, and delivery. We shared out our work at a company All Hands, and the output was well received. Now our technical project manager is trying out the approach on a new project. It will be interesting to observe his results and any adjustments made along the way.

Learnings from Shreyas Doshi's Time Management Seminar

Shreyas Doshi has held product management roles at Stripe, Twitter, and Google. He’s now a coach and advisor who also finds time to teach a product management course on Maven. Given how effectively he appears to juggle his busy schedule, I was excited to read this article. It also reinforced a number of points from his appearance last year on Lenny’s podcast.

Shreyas learned you cannot do everything. Nor can you do everything to perfection. Yet as a product manager there are constantly more and more asks - and more and more meetings - coming your way. You also need to guide others to move fast, experiment, and apply learning — all of which require putting "Don't let perfect be the enemy of good" into practice.

Here are the steps recommended in Shreyas’ seminar.

1. Leverage-Neutral-Overhead (LNO) task categorization framework for perfectionists

Leverage (L) tasks are the ones to identify and focus on as they 10x your impact. Neutral (N) tasks are those where you get the expected impact given the time commitment. Overhead (O) tasks have very little impact given the time required.

Yes, the hard part is identifying which are L tasks in your world. Often scale or reach (e.g. number impacted) are good indicators. Think about your work and assign L, N, and O to your tasks. Then afterwards, do a retrospective to see what items were classified correctly or not. Then once validated, double down on L tasks. In return, be ok simply doing a good job on N tasks and only do O tasks when absolutely necessary as they are not worth the time or effort.

2. Proactive time blocking in your calendar

As I do with this newsletter, I set aside specific time to find articles, structure them into the newsletter and make edits. Shreyas recommends a similar approach for calendar management.

• Evaluate your tasks using the LNO framework

• Block out time in your calendar for L (and to some extent O) tasks and be specific about what you want to achieve.

• Stay within the time box and apply the learning next time when you find more time is required.

3. You don’t always have to eat the frog first thing in the morning

Accomplishing a task feels good. And, who doesn’t want to start off their day with something positive. While L tasks tend to be harder (aka eating a frog) they require a lot of time whereas N and O tasks are less time intensive. Complete N and O tasks first thing, then celebrate crossing them off your list. Doing so means you will have fewer distractions when you go into focus time to tackle the L tasks.

The Trap of the Extraordinary

Deciding when to meet and equally importantly, when not to, means prioritizing what is important and requires people coming together. Often we use our employer’s definition of importance and hope it’s aligned to our own. Even in the ideal situation when it is, living your life by metrics or “strategic direction” could result in missing out on the amazing yet simple moments of wonder, curiosity, and learning.

Sahil Bloom writes:

A step to take is introduce a channel on Slack or your messaging app of choice to celebrate the wins. Don’t forget to call out ordinary accomplishments as most likely the activity felt extraordinarily special to the people who drove the work.

Another approach is setting aside a few minutes at the start of your team call to have people share ‘thank you’s’ - thank people who helped them, individuals who went out of their way, someone who presented for the first time… all those moments which mean a lot to the people in your team and bring them closer together through the acknowledgement.

These simple acts encourage collaboration, which can led to more effectiveness across your team as individuals are working more closely together. They also help people to feel acknowledged and recognized, which provides the fuel to encourage people to grow and advance their career - even when it means getting comfortable with being uncomfortable as Barry O’Reilly says.

Leading Product Development With an Intrapreneurial Mindset

On the podcast, Valdemar Østergaard shares the story of a team he worked with at a startup accelerator. The team had created an iPad app which encourages elementary school students to wash their hands more. They thought it was a slam dunk given the increase in awareness of washing your hands due to COVID. Even though the team had been meeting and were aligned, Valdemar asked if they had observed their target audience and how they interacted with water. They hadn’t. While spending one day at a school, they saw students playing with plastic ducks in the water. They immediately pivoted and in one day built a plastic duck which dispenses soap and was a hit with the students and their teachers.

The original approach the startup team took reminded me of the phrase “product sense”. It’s popular at the moment and implies the ability to understand a product's needs, e.g. having the sense of what makes a product great based on calling upon skill and experience. I’ll disagree and commit. Product sense often is interpreted to mean you can trust your gut and suss out a path forward to success. As with the team Valdemar coached, this approach can lead individuals to go down a path that does not resonate with their customers simply by following what they believe to be “product sense”.

Instead by designing your product development process with a “Discover” phase at the start helps to remind individuals to take time to find the true customer pain points by observing and/or speaking with customers. The subsequent phases are more effective, because they build on the direct customer input captured right at the start. You have a better sense of the true customer problem or opportunity. Plus the team now has a precedent of connecting with customers, which makes it more natural to do so during subsequent stages - which ensures you catch gotchas and can pivot before development has begun.

The same approach applies to internal company events too. For example a hackathon idea can address pain points of customers and employees which have been observed firsthand. As a product lead, it’s likely you also oversee tools and processes your team applies. By listening to their feedback and observing where a stumble occurs, you can identify ways to increase the efficiency of your team and likely bring them some joy to celebrate as well.

I was in NYC for the month of April and took a newsletter break to explore the city. I’m excited to be back in San Francisco. Lancaster joined us on the trip and got a bit adventurous.

I hope everyone had a great April as well! I look forward to sharing more updates with you all soon.