Extremely agile thinking
Learning from our experiences as a startup
We started building PlayerZero (called "Testgram" at the time) in 2018 to be a proactive testing tool for developers to stop issues from reaching production. In just 2 years, we have gone through 5 major product shifts. Even though this could feel tumultuous at times, each shift brought us closer and closer to a final vision we are proud of. Each shift has increased our excitement, alleviated concerns our users had, and helped more people see how we can help their workflow. Our core values haven’t drastically changed, but how we understand the problem/solution space – and more importantly, how we work within it – has.
These mind-shifts remind me of a quote from Francis of Assisi, where he sums up how to eat an elephant: “Start by doing what’s necessary; then do what’s possible; and suddenly you are doing the impossible.” Let’s fix the issues teams have today on our way to building a future where these issues no longer exist.
Now, the fun part. How did we get here?
Software design with an open mind
“Human-centered design is a philosophy, not a precise set of methods, but one that assumes that innovation should start by getting close to users and observing their activities.” — Donald A. Norman, Co — founder of Nielsen Norman Group
We knew we had to create a simple product. It was a simple problem after all – we need to deliver all the details of a session to a developer.
In the design world, there’s a lot of talk about design thinking as king to a successful product. It works hand in hand with a lean team mentality and an agile development process. The goal is to test your work early and often, find all of the holes and ensure confidence in all aspects of what you deliver. And, document, document, document. These theories are rooted in a generally agile mindset focused on scalability, ability to grow, and adaptivity. Think fast, but not so fast that you lose track of each step in the process.
While there is absolutely nothing wrong with these processes, they don’t necessarily work when building for a startup. We have to show value, and we have to show it fast. So instead of completely breaking all rules we typically follow, we found ways to adapt them. They had to bend enough to let us get a valuable product out soon.
New rules needed to be set.
The skateboard mentality: Design. Fall. Design. Fall.
There are always many ways to solve a problem, especially when there is no pressing deadline and endless resources. But what do you do when you have to provide value in a week?
Think about transportation. Two people have one week to build a method of transportation. Person 1 chose to build a car. After a week, they weren’t able to use their car; they only built 4 wheels and a frame. On the other hand Person 2 chose to build a skateboard. While a skateboard certainly isn’t the fastest way to get around, it’s simple and fast to build - they completed the task. Now, while Person 1 is still building their car, Person 2 can get around and think of ingenuitive ways to enhance what they’ve already built. The skateboard has value because it does what you asked for – no more, no less.
So we needed to find our skateboard. A “minimum viable product”, the smallest thing we can build to provide value quickly. The. Most. Simple. Solution. How do we deliver session data quickly?
The most challenging aspect of this mindset is constantly trimming the fat. Asking why we should add a feature and what value it adds. Can we validate this assumption? Is this a must have technically or a nice to have little sparkle to get people excited? As tempting as a little sparkle is, an extra week of development is another week you aren’t getting real user feedback and you aren’t learning from your users. Over time, we often saw that the ideas that never made it in the skateboard most likely would never need to come to life. Keep it simple.
Today, PlayerZero has a “skateboard” that provides clear and concise session data. It’s a bug report that can be created by anybody but is useful for everybody. Our biggest focus after was ensuring it works from every angle. Fall off the skateboard a few times and create a foundation the team is confident in.
Be like Ironman: Adapt your product
After seeing a demo of PlayerZero, one developer said, “I didn’t know I needed this until you showed it to me.” There were no products on the market with the same idea or value as what we’re building at PlayerZero. The sky is the limit and there are so many directions we could push towards. How do we grow from here?
Let’s talk Iron Man, because he’s a good example of someone adapting to needs. He builds things as they are needed for specific situations. Iron Man 2008 edition wasn’t the most badass suit he could have had, but we were amazed at its ingenuity. Over the years, he added little features here and there. Enhancements.
We’ve been really excited about this stage at PlayerZero. We’ve built our first iteration – our 2008 Iron Man suit. We continue to dream big but push on small enhancements to deliver the BEST value with our “skateboard” as we steadily evolve it into a scooter, a bike, and beyond over time.
The best part about this step is that, since we’ve proven our skateboard works and solves a problem, users or potential users have been quick to tell us how we can enhance PlayerZero to provide them with more value. We do not want to assume what our next steps should be or what issues might arise. In our first year, we learned this the hard way. We spent valuable time developing features that never made it to prod, didn’t add immediate value, or weren’t as useful as we assumed. We needed to focus on small enhancements and setting up calls with as many people as possible. Even if they don’t become users, they will be blunt and honest about what they expect with your base product, how your tool can become a part of their workflow, and what you can do to get them excited to use it. We focus on their team, structure, and processes, and over time trends have appeared for me and the team to bring into the product
Understanding what the next MVP is is just as important as knowing what the first one is. Jumping to build a Tesla from a skateboard is almost as impossible as starting off with nothing. Startups need to take baby steps and have user feedback drive EVERY step of our future development.
Be more agile by being less Agile
“There is a way to do it better — find it!”
Thomas A. Edison
Working with less structure doesn’t mean everything will fall apart. Just hold on to the parts of the structure that makes sense for you and your team like we did at PlayerZero. We anonymously test when we can, and when time doesn’t allow, we push extra hard on outreach for feedback in prod. We wireframe when we can, and when pressed, try to pair design with developers to bring ideas to life early.
It’s all hands on deck. We are hyper focused on creating an environment where we are getting feedback from users as often as possible to stay moving. Even if they do not convert to users, feedback is the only way to know if you make the right decisions. Be ready to act on their feedback. And, there’s no such thing as negative feedback when you’re iterating. If something is wrong, pivot – don’t move the moment one user brings it up, but if it’s recurring, trust the process. The earlier you implement a better experience, the more buy-in from new and existing users.
Lastly, use your team! The benefit of building a technical product is that our own team is a potential user. Including all areas of the company has been a huge win when it comes to brainstorming and troubleshooting. Continuously exhibiting empathy and always listening – to both my coworkers and our users – are the only ways for us at PlayerZero to succeed long term.
What we’ve learned about building a startup
Most of these changes to our workflows will have to change in the long term, and that’s ok. We’re trying to fail fast to learn even faster. As we continue to push right now we have 3 major goals: communicate better, find balance in growth and slowww down.
Communicate better
We are all moving faster than a speeding bullet. We learned quickly that there is no such thing as overcommunicating. As a small team, it’s easy to assume that everyone is in the loop. Don’t assume. Don’t let things fall through the cracks - every moment is valuable to keep everyone moving together. And, since we’ve surrounded ourselves with some of the smartest people, letting them in on ideas early only helps communication strengthen and ideas flow more easily.
Find Balance in Growth
There’s a delicate balance between too much process and no process. Even from the beginning each team had basic processes they followed. Startups will always be moving fast, so the challenge is to integrate more refined processes as we grow. Establishing process on a tool that has a solid foundation allows us to take the time to find what works and what doesn’t for the team. In the end, the more process, the more polished your product is able to be when it is released - this means happier end users early on.
Slow down to Speed Up
There’s beauty in slowing down. Moving quickly forces you to learn quickly, but it causes team members to be scrambled and disjointed. You miss valuable feedback. You can’t get enough feedback or confidence in what you’ve built. So, we’re trying to slow down, think through the flows fully, and enjoy every moment of finding our best product market fit to provide value to the tech world.