Bug Reports: Describing Issues Accurately

When something breaks, "It's not working" is the least helpful thing you can say. To be a high-value team member, you need to describe how it is broken.

The Vocabulary of Failure

• Bug: A mistake in the code that causes an incorrect result.
• Glitch: A small, temporary problem (often visual).
• Crash: The application stops working entirely and closes.
• Lag: A delay between a user action and the response.
• Regression: A bug in a feature that used to work perfectly but broke after a new update.

The Bug Report Framework

A professional bug report (in Jira or Slack) usually follows this structure:

1. Summary: A one-sentence description. ("Checkout button is unresponsive on mobile.")
2. Steps to Reproduce: A numbered list of actions.
   1. Open the app.
   2. Add an item to the cart.
   3. Click 'Checkout'.
3. Actual Behavior: What happened. ("The button turns grey but nothing happens.")
4. Expected Behavior: What should have happened. ("The user should be redirected to the payment page.")

Useful Verbs for Bugs

• To trigger: To cause the bug to happen. ("Clicking 'Save' triggers the error.")
• To reproduce: To make the bug happen again. ("I can't reproduce this on my machine.")
• To break: To cause a failure. ("The new update broke the login flow.")
• To fix/resolve: To solve the problem. ("We've resolved the issue in the latest build.")

Alex's Tip: If you find a bug, check if it's a Regression. Engineers hate regressions because it means they broke something that was already "done." Mentioning "This worked yesterday" is a very important signal.

Marc Andreessen, who coined the term, described it simply: you know you have product-market fit when the market pulls the product out of your hands. Before fit, you push the product on people. After fit, they pull it from you.

A team without product-market fit might say we are still searching for fit. A team with it might say we have fit; now we scale.

The build-measure-learn loop

These terms connect in a cycle that startups repeat:

1. Build an MVP or feature.
2. Measure how users respond (signups, retention, feedback).
3. Learn whether your assumption was right.
4. Iterate: change the product based on what you learned.

Common mistakes

1. Calling a customer a client every time. Client is common in consulting and agencies; customer is standard in SaaS and product companies. Use customer for subscription software.
2. Saying we did an MVP for instead of we built an MVP. The verb is build or create: we built an MVP to test onboarding.
3. Confusing traction with product-market fit. Traction means measurable progress (signups, revenue). It is a sign of fit, but not the same thing.

Practice

Rewrite these sentences with precise product vocabulary:

1. We will make a new product for notifications. (it is one part of the app)
2. We have 1000 customers using the free version. (they do not pay)
3. We launched, so we have product-market fit. (launching is not fit)

Possible answers:

1. We will build a new feature for notifications.
2. We have 1000 users on the free plan. (or: 1000 free users)
3. Launching is not the same as product-market fit; we still need to measure retention.

You now have the core product vocabulary. In the next lesson, you will learn the money vocabulary that surrounds all of this: runway, burn rate, and funding rounds.