Goodbye Testgram, Hello PlayerZero

March 19, 2022

We’re changing our name! 

We started out over a year ago with a mission to change how organizations monitor the quality of their code. Our hypothesis for how to achieve this: give engineers a cleaner, more user-centric approach to testing their code (without creating bloat in their workflow). We have learned a TON since that has steered us to look at quality more broadly. So today we are stretching our legs out of the “testing” space into something bigger. 

Why we’re changing our name: More than testing

We chose the name “Testgram” to express how we hoped teams would see the product in their monitoring workflow, a unit (“gram”) of testing. But we realized that testing wasn’t the most exciting part of what we’re building. Testing is seen as additional work; even if you can do it better, it isn’t the real bottleneck in development, and everyone has been conditioned to loathe tests.

So we dug deeper. As they say in great product design, you always start by defining the user and the need. For our users (developers), the problem is that engineering hours are being wasted trying to solve issues. The real need is to minimize the time teams spend dealing with user issues.

Our first company direction was to address this with a vitamin; we wanted to get to it before it was a problem. But in reality, this was in direct conflict with how we view quality monitoring ideally. 

We came to the conclusion that a bug only becomes real when a user’s experience is derailed by its existence.

With that insight in mind, we dove back into research mode, speaking with hundreds of users and non-users alike to explore workflows, day-to-day responsibilities and pain points. 

We found something extremely interesting. The communication gap between users and engineers has never been greater. Layers of time, processes, and personalities separate them and lead to time-wasting games of telephone whenever a user experiences an issue. For example, support teams often lack the knowledge and tools necessary to tell developers what they need to know to fix the problems that users encounter, so developers waste their time trying to find and fix bugs based on inadequate or inaccurate descriptions. This is the real bottleneck we’re trying to break open.

Testing might be part of this, but it’s just the proactive “vitamins”; frequent testing might be good practice, but it’s easy to skip or minimize. Focusing on helping teams fix existing issues lets us meet the immediate need our users have – fix bugs faster – without assigning them testing work they may not already be doing.

So, Why “PlayerZero”? - Put users first & fix bugs faster

Every bit of data we (safely) collect contributes to understanding a single user experience as expressively and empathetically as possible. Every day we ask ourselves, “How can we create the best platform to understand the intent and pain point of a real user in an application, without the luxury of sitting next to them and seeing it in person?” This sentiment constantly inspires us to build the best product possible.

The user is the starting point, the “index 0”.

A key difference between the value of our product and what exists on the market is that, with our product, you can bring a user to life in any browser, through a simulation. This isn’t replay, it’s a simulation. And what do we call a mission-driven participant in a simulated world?

A player.

The user is the starting point, the “PlayerZero” in our universe. They’re whose problems you need to fix, who you need to make happy, and who you need to learn from. When using PlayerZero, the developer acts as “Player 1”. They take control of the perspective of the user session. Others they share the session with might be players 2, 3, 4, et cetera, but the original user, whose experiences we are able to simulate, is Player 0. PlayerZero lets you take the perspective of this user to see your product how your users see it.

Building a voice

Many of our early users have told us they had a moment of realization that we aren’t improving existing quality monitoring models – we’re rethinking quality monitoring from the ground up. 

We’re leaning into being different in an industry of monotony. 

Stepping into a video game can be an immersive experience. You take control of a character and can see and experience a world from their perspective. We want to give developers the ability to step into the perspective of their product’s users.

Other products replay user sessions, we create a far more malleable and flexible experience. We bring the user to life in the developer’s own environment so they can step into the shoes of someone who experienced an issue with their product. This isn’t like watching a movie of what happened; it’s like taking control of a character in a video game. We needed a name that signified the depth of what we’re doing. And we’re confident that PlayerZero delivers.

If you haven't already, sign up and give it a try now!

Written by:
Tim Schmitz
Additional Articles

Goodbye Testgram, Hello PlayerZero

March 19, 2022

We’re changing our name! 

We started out over a year ago with a mission to change how organizations monitor the quality of their code. Our hypothesis for how to achieve this: give engineers a cleaner, more user-centric approach to testing their code (without creating bloat in their workflow). We have learned a TON since that has steered us to look at quality more broadly. So today we are stretching our legs out of the “testing” space into something bigger. 

Why we’re changing our name: More than testing

We chose the name “Testgram” to express how we hoped teams would see the product in their monitoring workflow, a unit (“gram”) of testing. But we realized that testing wasn’t the most exciting part of what we’re building. Testing is seen as additional work; even if you can do it better, it isn’t the real bottleneck in development, and everyone has been conditioned to loathe tests.

So we dug deeper. As they say in great product design, you always start by defining the user and the need. For our users (developers), the problem is that engineering hours are being wasted trying to solve issues. The real need is to minimize the time teams spend dealing with user issues.

Our first company direction was to address this with a vitamin; we wanted to get to it before it was a problem. But in reality, this was in direct conflict with how we view quality monitoring ideally. 

We came to the conclusion that a bug only becomes real when a user’s experience is derailed by its existence.

With that insight in mind, we dove back into research mode, speaking with hundreds of users and non-users alike to explore workflows, day-to-day responsibilities and pain points. 

We found something extremely interesting. The communication gap between users and engineers has never been greater. Layers of time, processes, and personalities separate them and lead to time-wasting games of telephone whenever a user experiences an issue. For example, support teams often lack the knowledge and tools necessary to tell developers what they need to know to fix the problems that users encounter, so developers waste their time trying to find and fix bugs based on inadequate or inaccurate descriptions. This is the real bottleneck we’re trying to break open.

Testing might be part of this, but it’s just the proactive “vitamins”; frequent testing might be good practice, but it’s easy to skip or minimize. Focusing on helping teams fix existing issues lets us meet the immediate need our users have – fix bugs faster – without assigning them testing work they may not already be doing.

So, Why “PlayerZero”? - Put users first & fix bugs faster

Every bit of data we (safely) collect contributes to understanding a single user experience as expressively and empathetically as possible. Every day we ask ourselves, “How can we create the best platform to understand the intent and pain point of a real user in an application, without the luxury of sitting next to them and seeing it in person?” This sentiment constantly inspires us to build the best product possible.

The user is the starting point, the “index 0”.

A key difference between the value of our product and what exists on the market is that, with our product, you can bring a user to life in any browser, through a simulation. This isn’t replay, it’s a simulation. And what do we call a mission-driven participant in a simulated world?

A player.

The user is the starting point, the “PlayerZero” in our universe. They’re whose problems you need to fix, who you need to make happy, and who you need to learn from. When using PlayerZero, the developer acts as “Player 1”. They take control of the perspective of the user session. Others they share the session with might be players 2, 3, 4, et cetera, but the original user, whose experiences we are able to simulate, is Player 0. PlayerZero lets you take the perspective of this user to see your product how your users see it.

Building a voice

Many of our early users have told us they had a moment of realization that we aren’t improving existing quality monitoring models – we’re rethinking quality monitoring from the ground up. 

We’re leaning into being different in an industry of monotony. 

Stepping into a video game can be an immersive experience. You take control of a character and can see and experience a world from their perspective. We want to give developers the ability to step into the perspective of their product’s users.

Other products replay user sessions, we create a far more malleable and flexible experience. We bring the user to life in the developer’s own environment so they can step into the shoes of someone who experienced an issue with their product. This isn’t like watching a movie of what happened; it’s like taking control of a character in a video game. We needed a name that signified the depth of what we’re doing. And we’re confident that PlayerZero delivers.

If you haven't already, sign up and give it a try now!

Follow us on Twitter
Sign up for our newsletter.
Get the latest articles delivered straight to your inbox.
Share
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
Additional Articles