Why Standups Are Useless And How To Run Great Product Team Meetings
- Andy John tl;dr: In the bulk of a product development process, standups aren't useful. Instead, hold 1-2 meetings a week with the following agenda - (1) action items: who is handling what key action item and by what date? (2) what decisions need to be made?featured in #160
Performance Metrics For Blazingly Fast Web Apps
- Conrad Irwin tl;dr: Conrad discusses Superhuman's approach to performance metrics (1) Use event.timeStamp for start of events (2) end of events, use use performance.now() in a requestAnimationFrame() 3) ignore when the tab is not focused 4) aggregate data using “% of events that are under target” 5) visualize multiple thresholds. 📈 Click on the link in this tweet to bypass the paywall.featured in #155
How Product Managers Lose Trust
- John Cutler tl;dr: Trust is essential between team members and is a result of previous decisions made between team members. Second, language used by PMs is essential - John uses various scenarios to illustrate this.featured in #154
Guide to Product Planning: Three Feature Buckets
- Adam Nash tl;dr: Features can be bucketed into one of three. Metric movers, designed to make business goals happen. Customer requests and customer delight, making sure customer needs are focussed on.featured in #152
Do, Try, Consider - How We Give Product Feedback At Asana
- Jackie Bavaro tl;dr: Framework for giving feedback on product related matters. "Do" is rarely used and mandatory, asking the team to perform a next step. "Try" asks the team to explore a next step. "Consider" shares an optional idea.featured in #151
Creating Flow and Value in Product Development
- John Cutler tl;dr: The time developers spend coding in a 40 hour work week is relatively small. Hence, limiting work in progress, the scope of work, and handoffs between teams can increase flow and value in product development. The key is to focus on cadence and flow.featured in #137
featured in #135
Engineering Guide To Writing Correct User Stories
- Nikita Sobolev tl;dr: This article runs through how to get better with the default user story format, rewrite stories so they become verifiable and how to link user stories with tests, source code, and documentation.featured in #134
Why Everyone Should Read Support Emails
- Simon Schultz tl;dr: Everyone in a company, irrespective of title, should spend 30 mins per week reading support emails. Why? Support emails... Reflect current state of product & company Kick start internal & customer conversations Are nuanced (vs statistics) and you learn more about your customer Create an increased sense of responsibility and urgencyfeatured in #132