How to be a Product Manager in Space
I’ve wanted to be a Product Manager since I was a kid. Well…no, when I was a kid I wanted to be a herpetologist (lizard scientist), but I wanted to be a Product Manager (PM) since I attended my first hackathon back in Miami. I remember realizing, a couple hours in, how much more efficient the hack would be if the tasks were split up correctly, thus increasing productivity enough to build a fully functional app by the end of the 24 hours of the hackathon.
Since then, I’ve had pleasure of finding other jobs that gave me the thrill of discovering the different challenges in producing amazing projects. I learned to participate in the creative process on the marketing team at MailChimp. I sharpened my time management skills as a project manager at CloudScaling. More importantly, I learned the importance of fostering a strong team while I created HackFSU. All of these things led me to Tinybop, an independent children’s game company in Brooklyn. As a Junior Product Manager I’ve had the pleasure of joining a team committed to creating elegant, educational iOS apps where kids can freely explore, learn, build, think, and grow through play.
Last week the first project I was assigned to, the app Space by Tinybop, did just that. Space is an open-ended exploratory game that allows children to travel through the cosmos, hurl meteorites at planets, discover the phases of the moon, zoom onto the sun, and jump into a whirling space storm.
This month, Space by Tinybop was released on the App Store. The previous six months of development were full of ups and downs but now, I feel like for the first time, I finally understand what a product manager is. As I’ve been growing into this role, I’ve been meeting with a lot of PMs and it seems like there is still an enormous amount of ambiguity around what exactly a product manager is. It seems that even if we all agree on the core features of what a product manager is, there are still vast differences in their application, based on the type of technology one works with as a PM. So in an attempt at knowledge share, I wanted to recap what exactly being a PM meant for me. Here are a few ideas of what I think it means to be a Product Manager.
Being a product manager means
Drawing shitty drawings
I learned a lot about problems with my features by drawing them before even doing a feature write-up. I can’t tell you how many hours I’ve spent swiping and tapping a piece of paper to see if a certain feature would actually work and make sense. In the end, you have a lot of not-so-great drawings but this is often the first step to getting feature ideas out of your head and into the real world.
Being rejected
Coming up with numerous feature ideas means having 80% of your ideas flat out rejected when presenting them to your team. While it often feels like a nice gentle tumble down a flight of stairs, getting rejected widened the scope of what I consider when writing features. Some of those considerations include company brand guidelines, ease of usability, gesture conflicts, time management, and maintaining UI consistency throughout app. Every rejection adds another filter you can give to your ideas to make them better.
Being kinda rejected (aka getting your idea stretched until you don’t remember why you ever thought it was a good idea)
When presenting features, good feedback takes the form of good questions that make you consider use cases you may not have thought of before. At the beginning of Space, I would spend all day wire-framing different scenes attempting to approach it with a creative edge. After coming up with a few sketches, I would call in the product leads to bounce back ideas and I would get hit with the questions….
How does this interaction begin and end? How does this interaction refresh? What is the default state of this interaction? Is there any on-boarding to make the expected interaction more clear? Why would you want to engage in this interaction more than once? What is the take away? Is this interaction worth the effort?
I was always astounded by how quickly my ideas would crumble at the beginning of the process. Was I just bad at this? After picking up the pieces of my broken concept, I realized that part of what I was learning was to internalize a lot of the questions I would hear and ask more of them to myself and incorporate the answers in the design.
Trying to explain a complex problem in a single sentence
My super brilliant managers are often very busy solving many problems which means I can only get guidance in quick moments. In these quick moments, I have to summarize numerous product problems in one sentence. This exercise has helped me work harder at finding the true core of any given problem.
In a team setting as well, you often only have a short amount of time to catch up in person, so summarizing problems in team meetings is important too. Again and again, we would have an hour to flesh out four small features. This means 15 minutes per feature to both describe the problem and get group input on potential solutions. This is challenging but I have found that the “how might we” method is an interesting approach for asking questions in a way that promotes ideation.
Feeling like a detective when you do market research
Conducting market research (which in my case means playing a lot of video games) is essential to understanding what you’re up against. Overall, it’s important to learn from others in all situations. With that in mind, it’s important to see who has tried to make products similar to the one you’re making. Where have they decided to place things? What is their on-boarding like? What does this product make you feel? Trying to understand other companies product decisions may shed light on how you might want to make similar decisions.
Crying in the bathroom
It is overwhelming to have a million working parts all requiring attention. Sometimes you just have to cry and make an Excel sheet to relax.
Writing feature descriptions
Stories on stories on stories. Every time I thought I was being specific enough I wasn’t. Working with the same product day in and day out, you get so oriented with the product that it’s easy to forget that other people don’t share your perspective. There were times I would use short hand for certain terms or refer to different scenes (lovingly) by names I had made up but never defined to the team. One fix for this was having someone outside of the company or team read over my stories and point out unclear words and then compile them and send “new app terms” emails where I broke down acronyms and detailed internal scene names.
In general, stories would start with the sentence:
“As a user I would like to (what a user should do) and see (what a user sees) in order to (purpose of the feature).”
Other things typically in a feature description include:
- Steps user has to take in order to get this feature to happen
- Steps a user takes to find this feature
- Default state of scene/feature
- Detail progression of feature
- End of interaction
- Linked assets associated with feature
Writing bugs
Pushing visually and technically strong commits inevitably means accidentally making some mistakes. After going through a concept sprint to lay out features, you have a clear view of how you expect the app to look. When there are certain features that are not meeting expectations, it’s time to write bugs carefully aimed at specifying where the feature went wrong.
Clarity is very important when writing bugs because vague bugs can cause a lot of back and forth between you and the dev, wasting precious development time. The most clear format I’ve used for writing bugs includes:
- Expected behavior
- Current behavior
- Recreation steps
- Device type
- Build version
Overtime, being more clear will become easier and you will get a better understanding of the balance between too little and too much information when writing bugs.
Being excited about everything
I can’t tell you how many times I was blown away by the designers and engineers on my team. Initially, I kept my excitement inside to avoid sounding inexperienced by getting giddy about every prototype. At a certain point though, I realized that positivity is always timely and there was no need to stifle that. Enjoying the process is important in all aspects in life.
Growing pains and all, I am truly excited and honored to be doing a job I love alongside some of the most brilliant people that are all playing a unique role in helping me grow, as not only a product manager, but also as a person. Together we produced a beautiful app that provides an immersive and scientifically accurate model of the solar system to engage kids to learn through exploration. Space by Tinybop is available on the App Store worldwide.
Download Space by Tinybop here.
Check out my website to learn more about my past projects here.
Connect with me on LinkedIn here.
Email me with any feedback/questions at diva@tinybop.com or leave comments below!
