👋 Hello and welcome to this week’s edition of ✨Community Wisdom ✨ — a weekly email highlighting the most helpful advice from our subscriber [[Slack]] community. As always, a big thank you to [Kiyani](https://www.linkedin.com/in/kiyanibamba?originalSubdomain=ca) for pulling this email together.
#### 💥 Top threads this week
1. Ideal sprint lengths 2. Where a PM’s job ends and the product designer’s begins 3. Running a PM team meeting 4. Running a leadership team meetings 5. Running a post-mortem 6. Great product/executive coaches
#### 🤓 Top reads and listens
1. Setting up a sales team 2. Lessons for early-stage founders 3. Stripe: Platform of Platforms 4. On product discovery 5. Takeaways from Are Your Lights On?
Let’s dive in!
💥 Top threads this week
1. Ideal sprint lengths
Q: Hi all. I'm curious, what cadence do you use for sprints in a startup of 2-3 people? Does 2 weeks make sense or do you go for a shorter cycle?
>
– Soumya Santhanakrishnan
[Wayne Vernon](https://twitter.com/wplusv): It depends! I’ve worked with 1 and 2-week iterations, though never at a 2-3 person scale, so take this with a grain of salt.
The big question is: What does a sprint mean to you?
Is this just for planning? Agile ceremonies? Are you releasing based on sprints?
My gut says that this ultimately won’t matter at your scale, since with a smaller team the overhead introduced by running shorter iterations is more or less negligible.
But ignoring your specific situation, I hear “one-week sprints” and think “more meetings to stay aligned”, and more meetings are usually bandaids rather than a proper solution.
My short answer is: I’d stick to two weeks because there are better ways to stay on track that doesn’t introduce more overhead.
[Aadil Maan](https://twitter.com/aadilmaan): @Wayne Vernon literally read my mind. Love this stance. Moneyball.
I would go further and suggest that at this scale, perhaps you shouldn't worry about sprints at all. Just focus on continuously shipping features out when you feel like you have something. It sounds wrong but Teams don't realize that 2wk sprints aren't just 2wks of coding, there is a lot of planning and administrative work that needs to happen to get those sprints to sing.
At Google, I saw teams ship/sprints daily, 2wks, 6wk, quarter. Android is sometimes multiple quarters to a year.
Soumya Santhanakrishnan: That's super helpful, thank you! I'm leaning towards not even thinking in terms of sprints. At www.souffle.club we’re building a fun Q&A space for the most insightful takes on tech topics. So we end up launching questions every 3 days. Given that timeline, my co-founder and I have been talking about how we should just have a priority for a day and ship ASAP. and if it takes >=3 days then flag and talk about it.
[Tyler Wince](https://productsolving.com): FWIW, we ditched Scrum in our 20 person engineering team (3-4 engineers per product team) and just do Kanban now. Everyone is more aligned, attends fewer meetings, and we have more flexibility than we ever did doing Scrum.
[Josh](https://twitter.com/herzigma): We're also in the process of ditching formal 2-week sprints and moving to Kanban. Also about 20 engineers so keeping up regular rituals of prioritizing, grooming, standups and retros. Also very interested in trying 6-week sprints, mainly as a tool for more clearly involving engineering in discovery and design.
I rarely find 2-week sprints the right cadence.
[Aadil Maan](https://twitter.com/aadilmaan): This thread is magical because engineering teams often equate being agile to 2wk sprints and hearing many of you are ditching it.
So, I actively participated in switching the Google Dart team from quarter shipping to 6wk shipping. There is something goldilocks about 6wks. The first 2wks can give engineers a green field to really dig deep and get dirty with the details, draw plans and then mad dash 4wks to the finish line. I advocate a modified sprint of 8wks. 6wks of engineering with 2wks of testing and converging the work done in the 6wks.
My experience has taught me that Any feature work more than 4wks in estimate needs more grooming.
[Josh](https://twitter.com/herzigma): @Aadil Maan I'd love to hear more about 6-week sprints - fell in love with that unicorn after reading Shape Up: Stop Running in Circles and Ship Work that Matters and am still hoping to experience it in the wild.
[Aadil Maan](https://twitter.com/aadilmaan): I have lived with 6wks and it’s the magical number. iOS and macOS are developed over 4 back to back sprints 8wks in size. 6wks of development with 2wks of convergence during which no feature work happens, it’s all testing and fixing the work we did in the 6wks. Dart moved away from quarter because it’s easy to drift while 6wks is enough to stay focused and do complex work.
I would love to chat more if you want and I really want to hear about your experience with 6wks. Basecamp, although it gets crap sometimes for their work stances, have some really awesome nuggets. I have read every book they have shipped and each is a fascinating read.
Scott Stenback: For those of you using Kanban, I was inspired by Lean from the Trenches a few years ago and created the version below for one of my teams.
The On Deck column was populated with cards from the four columns directly to the left. From there it was the standard left to right flow until Done.
We bent Jira to get it usable for remote but in reality, it was always meant to be on a wall with post-it notes and painter’s tape.
[Wayne Vernon](https://twitter.com/wplusv): Amazing conversation! I’m really happy to see more people moving away from what’s “normal” and to what works best for their situation.
Agile is a collection of tools in your toolbox, not a single hammer. Pick and choose the pieces you need to maximize the likelihood of success for your org, product, and team.
Zachary Cohn: At 2-3 people, I’d ditch more formal agile and use either an agile ban or a full-on kanban approach. This tends to work well for maximum throughput, which as a 2-3 person team should be your goal. (throughput being defined loosely - engineering, product validation, user research, etc).
Things move too fast at that stage to wait until the end of the sprint to change direction.
2. Where a PM’s job ends and the product designer’s begins
Q: On your teams, where does a product manager’s job ‘end’ and where does the product designer ‘begin’?
>
– [Tal Raviv](https://www.linkedin.com/in/talsraviv/)
[Josh](https://twitter.com/herzigma): I'm no longer allowed to use Figma.
More seriously, we work side by side, we're both heavily focused on discovering and designing just different focus areas. My observation is that if Product isn't butting heads with Product Design (and product marketing and even engineering) then something's not right. And in this case, the butting heads when you're in a group and see a piece of litter on the ground, and you all bend down to pick it up and bump heads...the leaning in kind.
[Jeff](https://twitter.com/jfedor): I like to think of it as co-design. Product brings the context of the problem we're solving and why it matters. Together with Design and Eng, a range of solutions are explored. Eng provides options that are feasible (based on whatever constraints), Design owns the experience of that solution.
For me, Product owns customer discovery and I think it's powerful for Design to own product discovery. But wherever we can, we (Design, Eng, & Product) all ride shotgun on those sessions. Conversations and iterations get us to the solution.
But like @Josh I'm not in Figma to do anything other than comment.
[Wayne Vernon](https://twitter.com/wplusv): Varies quite a bit with the experience, skillset, and interests of the product designer. As well as with the product and the type of design work it demands. And with the scale of your org.
On bigger products or products that are more technical (e.g. less hands-on design to be done), I’ve found senior product designers are often happy to spill over into user and market research, which is fine by me.
But like everybody else – I never touch design!
[Archisman Das](https://twitter.com/archismandas): Jeff has articulated it really well. I think the job doesn't end, but the roles that PM and Design/Engineering play reverses depending upon the stage you are in. During the Customer Discovery, Design and Engineering play the role of the checker and it is the PM's responsibility to prove that it is the most important problem/opportunity that the team should pursue now. Once that's done, in Product Discovery stage Design and Engineering comes up with the solution and the PM evaluates if it is the best way to deliver value to their customers.
Now, this is an ideal scenario and the reality varies based upon the maturity and strength of the team members.
Zachary Cohn: I'm actively hiring a product designer right now with the express goal of kicking me out of Adobe XD. I think at one point in an informational interview I said “Please stop me.”
3. Running a PM team meeting
Q: I'd love to learn more about how other teams run PM meetings. We run a weekly PM meeting to increase transparency of efforts and information.
>
Currently our format is this:
>
- General announcements - General updates: Company direction, new company-level decisions, etc. - Follow ups from last MTG - Recent / Upcoming launches - Celebrate launches + raise awareness for implications to other parts of product - New efforts / Updates to existing efforts - New efforts or direction for visibility to other PMs. No need to list every single project - just ones beneficial for other PMs. - Helpful reads / info - Slack threads that provide context and info, or good reads for PMs - Other random things - Todos
>
I'd love to hear about other agenda items that have been beneficial in increasing the output of PMs ;- ) Thanks!
>
– [Tank](https://www.linkedin.com/in/takehiro-tank-mori-a3083487/)
[Alex Dou](https://www.linkedin.com/in/alexdou/): I have a manager friend who has instituted “BB Time” (BB in honor of Brené Brown). The purpose of this time is to be vulnerable and let down the mien/mask of “everything is going smoothly”.
Our PM team has a section carved out for “what feels hard [harder than it should be]?” The purpose of this section is to discuss sticking points up and down the stack: troubleshooting comms with Team X; doing a teardown of a PRD that has raised unexpected questions and gotten “stuck”; trying on versions of a Vision/Strategy.
I think the correct cadence is ~1/week, and even though these might come up in 1:1s (which hopefully you are doing weekly!) I think it’s worth having this crosstalk with other PMs.
[Tank](https://www.linkedin.com/in/takehiro-tank-mori-a3083487/): Nice, thanks @Alex! How long are the meetings btw? I'm also curious to hear what the outcomes of those discussions are -- does it result in senior PMs mentoring more junior PMs or has it been more of a flat discussion?
[Josh](https://twitter.com/herzigma): @Alex that's a great model. One (similar) thing I did was start by opening it up for anyone to speak. It gave me a chance to model open listening and we could all practice responding without judgment. It built great trust. @Michael Kellar - keep me honest - what worked well and what should we have done better.
[Amit](https://www.linkedin.com/in/amitjklein/): Are you talking about a cross-functional PM meeting (many PMs?) or a weekly product team meeting led by PM (with eng/design/etc...)?
[Tank](https://www.linkedin.com/in/takehiro-tank-mori-a3083487/): A cross-functional PM meeting with many PMs.
[Amit](https://www.linkedin.com/in/amitjklein/): For business as usual meetings (no major changes upcoming). One way we've done this in the past is a monthly meeting where we:
- Review of top-level company goals and how we are doing against them
- Each PM goes around and shows their key KPI(s), experiments run/lessons learned/upcoming launches (5 min each)
- One PM is the guest speaker and presents a challenge they are facing or a key decision they need to make for feedback and we deep dive.
We had separate product review meetings (each PM had one weekly) with product leadership that was approval focused (and any PM could attend most usually did to listen in).
[Michael Kellar](https://linkedin.com/in/michael-kellar): I think these are awesome opportunities both for cross-functional sharing, as you referenced, but also team building/trust. As @Josh said, one of the best things he accomplished for us, was building a team that really trusted one another, we had that mystical psychological safety and it was huge.
The biggest thing I took away was that making sure you take the time to encourage everyone in the room to participate (or sometimes just wait/let them come to the team), meant we all had a voice, and knew we had each other’s best interests in mind.
[Tank](https://www.linkedin.com/in/takehiro-tank-mori-a3083487/): Nice, that's a great point actually. Our team hasn't really talked too much about establishing psychological safety, but I definitely feel that that is important for a product team.
(I think it's often a challenge since a lot of times product managers are siloed in their own domain).
[Jonah](https://app.slack.com/team/U01GA3RA69F): PMing requires strong writing. We've allocated part of our weekly meeting to review a team member's product brief and provide immediate feedback. It has very quickly elevated everyone's clarity in their writing. A secondary benefit has been streamlining our team communications.
[Alex Dou](https://www.linkedin.com/in/alexdou/): @Tank meetings were short. This “what’s hard” line item was budgeted with maybe ~5-10 minutes, with an option (as always) to spin off into a separate thread to avoid ballooning this meeting
I can also speak to some of the outcomes I perceived:
- Blockers are identified early and loudly - this was during our PM staff meetings, so it was a kind of Chatham House Rules space where we could share hardships without worrying about negative reactions. As you might imagine, this helped us decrease wasted cycles, come up with better answers/approaches earlier, etc
- Stronger team self-worth/self-esteem - I oftentimes feel pressure to “know everything” (as an aside, one of the things I think is hard about PM is an implicit pressure/assumption to always “be the guy/gal” nb. this is a specific manifestation of the Spotlight Effect). However, when you only see yourself struggling against something—as we all do in our lives—and everybody else dutifully “knowing everything”, you start to think that you’re the problem. This really helps fight against that
- Increased espirit de corps - this is closest to what you were talking about. It was a good opportunity for spontaneous brainstorming and mentorship (not just Srs mentoring Jrs, but also folks with differently spikey radar charts mentoring others).
And @Josh, I love that. I think this is one of those tricky things where it has to be modeled by the team lead, otherwise, it’s just on this side of “too weird”. But it really helps Team Leads/Heads of/VPs by fostering that psychological safety that other folks have mentioned already. In the Rands manifesto, this is also an underutilized source of Critically Fresh information
@Michael Kellar, something you mentioned really piqued my side hobby interest in group psychology and its overlap with meeting facilitation. Do you remember the first time Josh brought this practice to the table? Do you remember your reaction?
[Tank](https://www.linkedin.com/in/takehiro-tank-mori-a3083487/): These are all great resources, thanks @Alex Dou!
Do you remember the first time Josh brought this practice to the table? Do you remember your reaction?
[Michael Kellar](https://linkedin.com/in/michael-kellar): I do not recall the first time, but I’d also say it was a practice that changed as the team grew. In the beginning we were very small, just a few people, so I think it was almost an entirely informal meeting, and then as we got bigger, it became a more intentional practice that we appreciated and made sure to maintain.
4. Running a leadership team meeting
Q: We are looking to run better Leadership Team meetings. Right now it feels more like a read-out/progress report rather than a strategic touchpoint. I am looking to get inspiration/advice:
>
- What do you believe the purpose of a Leadership meeting is? - How often do you have them? And how long are they? - What is the agenda? How much is communicating plans vs. discussion on bigger problems? Is the meeting used to keep people accountable or do you have other avenues for that? - How do you set the agenda? - Who is represented? - Do you communicate minutes/decisions with the rest of the organization?
>
– [Ben Kaye](https://www.linkedin.com/in/benkaye/)
[Aishwarya](https://www.linkedin.com/in/aishwaryab): We went through a bit of this in late 2019. As a leadership team, you want to typically have 2 “types” of meetings:
- Tactical: Mainly for quick decisions/progress on key events that have been decided, icebergs that may have been spotted. These are typically weekly.
- Strategic: These are again broken into 2 types based on how you run the business. In our case, we have a Monthly Strategic which focuses on pillars that are 1-2 quarter focussed. The other kind is more for Yearly planning activities - what does success look like for next year, what are priorities, headcount management, budget planning etc.
Once this was established, some of the questions you ask above - e.g. communicating plans vs discussions/debates fall into their own cadence. E.g. is it a pricing/packaging decision that will affect GTM motions - that’s more suited for a monthly, is it an a/b test on onboarding that. just launched - thats a quick tactical update.
Brian Clare: We follow the entrepreneurial operating system from the book Traction by Gino Wickman. Works well. Keeps tasks aligned and people accountable. Aligns to quarterly and annual goals (or rocks as they call it)
Soumya Santhanakrishnan: We did a thing where we took all the progress report stuff out. It's sent on slack every week in a document format and people can ask questions/comment in the doc. The time with leaders in a room is precious, so there'd be one person who's running the meeting who'd decide on 1-2 topics for us to discuss and unblock. Found it to be much more powerful.
Rohit Gupta: Flows.co helps you run well-managed meetings and stick to agendas and is currently on LTD -Flows - Reinvent Your Meetings details
[Zainab Ghadiyali](https://zainabghadiyali.substack.com/): The number one goal for a leadership meeting is alignment. Everyone in that group needs to be in lockstep - it is very easy to get misaligned very quickly.
- Have them as often as needed to make decisions and align on strategy
- Always keep an agenda of the top 1-3 things you need to make decisions. Have more than 3? Schedule another meeting
- Everyone in the team gets to bring in a topic for decision
- Every function
- Yes! But filtered version. The company doesn’t have all the context so just sharing notes without context can be confusing for your employees
5. Running a post-mortem
Q: Can anyone recommend any articles or just advice in general on how to run a really great post-launch post-mortem for a product?
>
– [Adam](https://www.linkedin.com/in/aorshan/)
[Tal Raviv](https://www.linkedin.com/in/talsraviv/): Great question!
The best sessions I’ve seen have given people ample time to think - that means either ask them a few days before to fill things out in a spreadsheet or silent time during the retro to do just that - I’ve seen both, probably depends on the magnitude of what you’re looking back on (a sprint vs. a major launch)
The other principles I’ve seen important have been psychological safety and withholding blame, and creating an atmosphere where talking about a mistake or failure is not seen as political or personal (a good measure is how defensive people get or open they are to talk about something).
This is hard. Would love to see what others have to say!
[Wayne Vernon](https://twitter.com/wplusv): As @Tal Raviv suggested, I’d try to offload some of the thinking and brainstorming as homework.
I’ve had luck with doing a pre-meeting survey, distilling the responses down to 3 key themes, and then focusing the discussion on only those themes.
Trying to cover everything gets out of hand fast and you’ll end up talking about so much that it will be impossible to make any meaningful change.
[Walter Budzian](https://linkedin.com/in/walterbudzian): I’ll piggyback on what Tal is saying about creating a blameless culture. A great piece to read on this is “The Blame Bias” chapter from a book called Primed to Perform.
To have a high-performing culture where people can do their best work it’s important to examine the root cause of failure in a system not failures in people. It’s not easy - we have a bias to hate the players instead of the game.
The authors illustrate this in a variety of social experiments. A big piece of the puzzle is that a leader's preconceived notions are going to impact outcomes. If, as a leader, you come to the table assuming you have a team that is making mistakes, the team actually performs worse. Conversely, when you have expectations that you have a high performing team with positive intent and you look to the systemic cause of issues, teams perform better.
So, in running those post-mortems, come to the table with high expectations of a team trying to do their best work and collaborate to look at what systems/processes can be improved.
Much more detail in that book, which is my number one recommended read for anyone in management or leadership positions.
Rachel Horowitz: Agree on all of the above! The other thing that I've found helpful is to circulate a doc with the key dates and events and milestones beforehand so everyone is on the same page about the who and what and can focus on the how and why without getting derailed where different people had different recollections of the facts
[Nishi Patel](https://www.linkedin.com/in/nishipatel/): Agree as well on all of the above. We’ve created retro playbooks in the past to help drive the concept of it being blameless and to help foster a psychologically safe environment. I don’t have the playbook on hand, but here’s one that we based it off of: How to Run an Agile Retrospective Meeting with Examples. We also used stickies.io for remote retros and it worked great.
[Adam](https://www.linkedin.com/in/aorshan/): Thanks so much, everyone! A few of you mentioned circulating materials beforehand. Are there any particular questions or jump-off points you’ve found to be particularly effective when included in the pre-meeting email?
[Tal Raviv](https://www.linkedin.com/in/talsraviv/): One tiny tactical thing that helps me is to say the quote “A bad system will beat a good person every time” (attributed to Edward Deming) and emphasize we’re here to fix the system.
6. Great product/executive coaches
Q: Has anyone here worked with a great product/executive coach that they’d recommend to work with a VP of Product at a startup?
>
– Anonymous
[Adam Waxman](https://twitter.com/ajwaxman): I’ve had a great experience with Donna Lichaw: Donna Lichaw — Leadership and Executive Coaching
Jacob Sussman: I have a call with Leah Feuer next week - she previously worked as a head of product / product advisor before focusing on coaching.
Julia Lipton: As promised, here's the list. Feedback welcome! For context, this list is shared with VCs, founders, and friends. Feel free to share it publicly! Also "feature requests" welcome!
You can also nominate a coach. It should take less than 1 min. The fields are optional, the only info I really need are their skills, your vouch, and your email. The rest I can pull.
🤓 Top reads and listens
1. Setting up a sales team
[Josh](https://twitter.com/herzigma): Another great one from David Sacks: [Simple Math to Set Up a Sales Team](https://sacks.substack.com/p/simple-math-to-set-up-a-sales-team).
2. Lessons for early-stage founders
[Tal Raviv](https://www.linkedin.com/in/talsraviv/): Founder of Segment on simple lessons - I feel these apply to product teams just as much as a startup Lessons for early stage founders
3. Stripe: Platform of Platforms
[Yaakov Cohney](https://twitter.com/YaakovCohney): Every Stripe product announcement is incredible on its own, but today's Stripe Capital launch is one that I am sure will lead to many more 'How Can I Invest in Stripe" requests. Anyway, the associated Stratechery is like the perfect wine pairing and one of the best ones I have ever read: Stripe: Platform of Platforms – Stratechery by Ben Thompson.
4. On product discovery
[Jeff](https://twitter.com/jfedor): Simple approach to how and why product discovery is a critical Product Org skillset A 4-step guide for day-to-day product discovery
5. Takeaways from Are Your Lights On?
[Wayne Vernon](https://twitter.com/wplusv): Wrote a Twitter thread with my takeaways from Are Your Lights On?, inspired by @Shreyas Doshi. Until I saw @Lenny Rachitsky’s and @Shreyas Doshi’s threads, I had never appreciated the potential of Twitter as a publishing platform.
I’m mostly sharing so I can say: Wow, this is harder than it looks!
If you haven’t tried writing a Twitter thread, I highly recommend you give it a shot. It might seem silly at first but the inherent constraints of the medium force you to edit, optimize, and proofread every word (or character!). It’s a great way to not only challenge your writing skills, but to organize your thoughts.
Tiago Forte’s progressive summarization technique is a great tool for capturing, filtering, and writing about what you read.
That’s it for this week 👋
If there’s anyone in your life who would benefit from this newsletter or community, consider giving them a gift subscription💞
Sincerely,
Kiyani and Lenny 👋