The Cost of a Bug

Who this book is for

Người làm sản phẩm ở doanh nghiệp Việt Nam: product manager, product owner, trưởng nhóm sản phẩm ở công ty phần mềm, ứng dụng di động, sàn thương mại điện tử, fintech và bộ phận số của doanh nghiệp truyền thống; làm việc hằng ngày với kỹ sư, thiết kế, đội bán hàng và chăm sóc khách, thường không có đội nghiên cứu người dùng hay phân tích dữ liệu riêng.

Sound familiar?

• When an incident hits, everyone messages at once and nobody knows who's handling it.
• Customers learn of bugs before the company does, through social posts.
• The bug list has hundreds of items with no clear order.
• Post-incident meetings become blame hunts, so nobody dares report early next time.

Each chapter answers one question

1. Chapter 1: When the product breaks, what does the PM do?

   In the last incident, who spoke to customers, who fixed it, and who decided?

   In an incident, product people handle customers and communication so engineers can handle the fix.

2. Chapter 2: If every bug is urgent, which one really is?

   What severity is this bug, and what response does that severity require?

   A shared severity scale helps the whole company respond at the right size.

3. Chapter 3: Does a longer bug list mean a better product?

   Of the current bug list, which ten should be fixed first?

   A bug list without an order is a list nobody reads.

4. Chapter 4: Does finding someone to blame mean fewer mistakes?

   Does my team's retrospective ask who got it wrong, or what allowed it to go wrong?

   Hunting for the guilty makes people hide mistakes next time; looking for gaps in the system gets mistakes reported early.

5. Chapter 5: Who decides what's good enough to ship?

   Has my team agreed what level of quality is enough to release?

   The quality bar is a product person's choice, whether or not they say it out loud.