If you look at my phone right now you’ll find six note-taking apps, 11 apps to track my finances, seven different fitness apps, and nine ways to message people. Do I use them all? Sometimes, occasionally, not really, and yes, respectively. Do I need to have them all? I prefer not to answer. But we’re not here to talk about my potential addiction to trying software products. I’m here to convince you that testing out new software has helped me grow as a product manager.
The truth is that I love discovering new apps. When people scroll through my phone, they’re astonished at the number of apps I have installed. Sometimes it feels like I’m the expression “There’s an app for that” personified.
The normal lifecycle for my relationship with a particular app is: 1) See something about it somewhere on the internet (generally Product Hunt, a tech blog, or even Twitter). 2) If it strikes me as potentially interesting, download and play around with it for a few minutes to a few days. 3) Rarely use it again. Sometimes, I’ll delete an app and never look back. But if it feels promising, I keep it on my phone to track its updates to see how it evolves. (Because, yes, I’m also a compulsive “updater” and frequent release-notes reader. And, no, I don’t want to talk about it.)
Trying out apps has become a hobby of mine, but over time my hobby has proven to be extremely valuable in my job as a product manager. At Postlight we spend a lot of time thinking about software and helping our clients design and build solutions to their business problems and opportunities using a variety of different tools and techniques. Sometimes it’s a design sprint, a Relay, or a far-reaching, greenfield whiteboarding session. For me, my vantage point comes from knowing how other products have tackled similar problems (and sometimes even unrelated ones), and using that as inspiration for a solution.
Exposing myself to many different apps across a variety of use cases helps me stay relevant. Software is continuously evolving, and one great way to stay informed is by exploring a lot of it. Trying new apps helps me monitor trends regardless of industry and pick up on patterns that become commonplace. This ensures that the software I’m helping design always feels up to date.
I’ve built an intuition for what distinguishes a good piece of software from a less successful one. Every new technique or UI behavior I expose myself to becomes a new tool I can leverage when brainstorming for a client. Recently a designer and I were stumped about how to show related objects in a search UI and enable operations between them. I was able to point to how Airtable and Coda were solving this problem, and we incorporated the same ideas in our design. The client loved it.
The value of an app-etite
There’s a lot of value in comparing different apps from a single space. It’s a good idea to check out the competition and see how they’re approaching similar problems. It can help identify areas that some of them are not covering and therefore present a clear opportunity. More broadly, an abundance of apps in a given space (financial trackers and to-do apps, I’m looking at you) serves as a great reminder that there are many solutions to the same or similar problem.
Great software is often a result of deeply understanding a problem and building a solution that tackles it. But it’s also a byproduct of its creator’s experiences, inspiration, and creativity. When starting from the same place, some product teams take a left turn while others take a right. We all understand problems differently. It’s humbling and refreshing to see how somebody else has thought about a solution.
The variety of comparable apps can also lead to fun team exercises. Our product team explores competing apps from a given space and tries to understand the motivation behind certain decisions, and why the teams might have arrived at a given solution. It’s interesting to think about the different starting points and premises they might have had when building their apps. Of course, we can never be sure about why the teams made the choices they did, but we have come up with what we think are some good guesses.
Doing these thought exercises flexes our product muscles and opens new perspectives we might not have considered. Here’s an interesting challenge: next time you use one of your go-to apps, try and think about why the creators emphasized or included certain features over others. Why is that the first thing you see and what are the default actions? Was making it accessible a priority for them? Is there tension between the product and the business? Were they prioritizing accessibility?
I’ll leave you with a thought. Software is now part of our culture much in the same way music, film or literature might be. Many of the best and most exciting musicians, screenwriters, directors, and authors learn and stay relevant by exposing themselves to as many albums, films or books as they can, and learning from others. They build from the references of others and strive to push each of their disciplines further. Shouldn’t those of us working to develop new products do the same?