Do you want your new product or big feature to look, feel, and work great when it hits your customers’ hands? A good bug bash can help.

A bug-what??

A bug bash. It’s an intensive and fun exercise where you put a thing you’ve built through its paces. It involves getting coworkers to take your new product or feature for a spin, try to break it in all the possible ways, and share their feedback along the way.

You’ll laugh; you’ll cry; you’ll feel the exhilaration of seeing someone break your product in ways you never expected.

But most importantly, you’ll end up with a higher-quality, more polished, and delightful experience for your customers.

And so, here is a complete guide to bug-bashing: why do it, what pitfalls to avoid, and how to organize it at your company. You’ll find a step-by-step process and even templates you can use to jump-start your bash.

Let’s dive in!

Why host a bug bash?

As teams work on projects, they get close to the things they’re building. By the time their work is finished and ready to ship, they have seen it, thought about it, and reviewed it a thousand times.

Inevitably, they’ve lost the ‘beginner’s eye’ when evaluating the fruits of their labour. They can’t tell if a workflow is actually easy or if an interaction is predictable, or if there’s a typo in a bit of copy they’ve seen over and over and over again.

To your team, the workflow is easy because they came up with it. The interaction is predictable because they know what to expect. The typo is invisible because they don’t even read the words anymore; they see the text as a single element.

A bug bash gets you fresh eyes on your product in a low-stakes environment.

Furthermore, bug-bashing sends a message to your team and stakeholders that you care about product quality and reinforces the standards you’ve set.

What bug-bashing is not.

Let’s set the record straight…

Bug-bashing is not QA.

QA is performed by the team that’s building the product. Ideally, it happens throughout the build cycle and not at the end. Most often, QA happens in a Test environment with regression tests in Staging.

In contrast, bug-bashing is done by people outside of the project team, usually a few teammates from Product, Design, and Engineering, plus a couple of people from Product Marketing, Customer Success, or Sales.

The number of people and the composition of the group depends, of course, on the size and structure of your company.

Moreover, bug bashing happens at the end of the build cycle and in a Production environment, once the team has deemed their new product or feature ready for release.

Bug-bashing is not dogfooding.

Dogfooding — which stems from “eat your own dogfood” — is another popular technique for improving product quality. It involves having your team or company use your product for real.

Unlike dogfooding, bug-bashing is still a test. It’s a thorough simulation of what real users might do, but that’s all it is.

This brings me to the last point…

Bug-bashing is not real validation.

It’s not a substitute for customer development, user testing, or a Beta program. While immensely helpful at ironing out small issues and polishing details, bug-bashing doesn’t remotely resemble real-world usage.

Organizing a bug bash.

Here are some practical tips for organizing a bug bash. They’ve been informed by a few years of trial and error and closely resemble how our R&D department does it at Rise People circa early 2021.

The Product Manager is often the right person to organize a bug bash. They have the right skillset to corral a diverse group of people, come up with meaningful tasks to do, and sort through the feedback after the fact.

However, in your organization, the responsibility might fall on the Engineering Manager or even a QA Manager (if you have those). Still, the Product Manager, Designer, and Tech Lead should be heavily involved.

Step 0: Decide to do it.

Frankly, you must first decide if a bug bash is the best tool for you. Here are some heuristics:

• Bug-bashing is quite expensive, as it involves several skilled people taking time out of their day to mess about with your release candidate. Because of this, it’s best reserved for large chunks of work, like a new product or an extra-large feature.
• Bug-bashing is best used when you’ve exhausted your team’s ability to assure quality. It doesn’t mean that the project is in perfect shape, but in your gut, you should feel like you could release it to customers tomorrow. In other words, bug-bashing is best for “final drafts” and not “first drafts.”

Step 1: Find volunteers.

You’ll need a group of 10–12 people to bug-bash the thing you’ve built. Fewer can work, but more is likely unnecessary.

You want people who are familiar with your objectives, principles, and overall product standards but unfamiliar with the work at hand.

Most people should come from Product, Design, and Engineering because a) they have a knack for Product, b) they know what to expect from the exercise, c) their feedback is easier to process, and d) they’re more likely to volunteer.

A couple of people should come from other teams. Product Marketing (PMM) is often a good fit, or someone from Customer Success (CS) who’s knowledgeable about the product or domain.

As you form your group, make sure you have a good mix of browsers and, if applicable, phones.

Pro tip: Invite the new person, someone who’s recently joined your org. It’s a great way to engage them, entrench your values, and help them connect with more coworkers.

Here’s an example of an invite you can send to a Slack channel (credit goes to Reagan White, Sr. PM at Rise):

📣 Call for volunteers 👇

What: Bug bash (testing) of the new [thing]

The opportunity: The [product] team seeks fresh eyes and brains on the beta software we are preparing. What issues might you spot that we should consider fixing before opening our beta later in the week to a select number of keen customers?

When: [date], from [time], for up to an hour or more, depending on your appetite and availability.

This date and time might change, but hopefully not. We are likely to have addressed all known show-stopping quality issues by this time.

Please react with a 🚀 emoji if you want to be invited to join us to review the software on a test org in Production. We’ll bring scripts for you to follow, roles for you to play. React with some other emoji if you don’t want to be invited but want to express yourself anyway.

Step 2: Set up a space.

• You’ll need time to bug-bash. 90 minutes is a safe bet. Make sure to block off this time in people’s calendars.
• You’ll need a real-time way to talk. In the olden days, we called that “a meeting in a conference room.” These days, a Zoom / Google Meet call will do the trick.
• You’ll need a way for people to share feedback. For example, a channel in Slack or a shared Google Doc. Whatever you choose, it needs to accept images, videos, links, and otherwise make it super-easy to post feedback as you go.
• You’ll need user accounts. You can either create fresh testing accounts in Production (configured just for your thing) or use an existing set, whatever makes the most sense.

Step 3: Write a script.

Set up a doc and outline the general instructions for your bug bash. Then, add the tasks you’ll want your users to complete. If you have multiple user personas (e.g. admin vs end-user), you’ll need to assign those roles to your volunteers and design your script in a way that allows a thorough test.

Here are example instructions we use at Rise:

Hello,
We want our product to offer an excellent, defect-free experience to all users. To make sure that is happening, we want to run an extensive bug-bashing of [thing]. Thank you for your help!

How?
(asynchronously)

1. [Organizer] will invite you to [a slack channel] and send you this document.

2. You will set up screen capture on your computer using Loom. [You will set up a screen recording on your iPhone or Android.]

3. [Organizer] will invite you to sign up for a testing account.

4. You’ll activate your account as usual.

5. You will sign in using your new account credentials and set out to accomplish a set of tasks outlined below.

6. Along the way, you will do your absolute best to break the app. You are expected to take unexpected actions, navigate in unpredictable directions, make bizarre choices, and otherwise surprise the team with your ingenious edge cases.

7. Any time you encounter anything that seems broken, weird, janky, unsettling, or otherwise not good, you will take a screenshot and post it along with the observed and expected behaviour notes [in Slack].

Bug Bash Tasks
[fill in]

Pro tip: One task we’re particularly fond of throwing in at the end is “Click on everything that seems clickable!”

Step 4: Do it!

When your bug bash commences, the organizer should explain the objectives and facilitate the session.

If appropriate, they should pace the progress through the tasks. For example, the ‘admins’ go first, then the ‘end-users’ follow.

The attendees should try and share their feedback as they go. This way, they won’t forget or filter out the small things upon reflection. Here’s what that looks like in practice in Slack:

Step 5: Review and prioritize the feedback.

Once the dust of the session settles, you and your team will want to review all the feedback and decide what to do with it. Here, good bug triage principles and processes can help.

It’s good practice to acknowledge the feedback (👀 ), dig in deeper if needed, and post a link to the relevant project management (e.g. Jira) ticket next to it.

Ultimately, the key outcome of a bug bash is a decision: Either the thing is ready to ship to customers or it’s not.

I recommend that the team takes on collective responsibility for making this decision based on their risk assessment. This way, they can all feel accountable for the outcome.

BONUS Step 6: Reward participants

A prize giveaway after a successful bug bash could go a long way in getting repeat volunteers. Consider recognizing and rewarding the person who contributed the most bugs, or the one who broke your app in the most creative way.

Have fun! 🐛

If you liked this article, check out:

• Helping users “get it:” The churn-stopping power of Product Education
• Building internal tools: A mindset shift for product people

Of you can follow me on Twitter for short bursts of SaaS Product Management and startup advice.