Akesh Shah embarks on a new blog series helping “non-technical” PMs get up to speed with a number of development topics
06 August 2017
A couple years ago, if you had asked me to explain what an API was I would definitely have done one or all, of the following:
- Asked you to disable caps lock and ask again, nicely
- Refuted that you spelled “app” wrong
- Yelled, “look at that puppy,” pointed behind you, and ran away when you investigated
That example might be a bit hyperbolical, but the fears held by “non-technical” Product Managers are very real…and who can blame them? A quick Google search for “non-technical product manager” will bombard you with results that would make many question their own professional competency. The term “technical” in a PM title has a bevy of meanings that often depend on the industry, company, department, and level of the role. What most organizations are seeking from their PMs, technical or not, is someone that can effectively communicate with the development team to ensure requirements are well-defined and understood, while leading the team to deliver a thoughtful product to users in a timely manner. I am aware of the over-simplification of the Product role I presented, but if a company is looking for an engineer, they would file a requisition for one!
One of my most memorable moments during my first few weeks at Mobileforming came at the end of my first 1:1. My boss addressed the importance of understanding APIs in my role:
“You don’t have to understand APIs and how they impact the app to be successful here, but by doing so you’re setting yourself up to be a great PM, and I only want great PMs working for me. By learning the ins and outs of the API you’ll gain a much deeper understanding of how the app actually works, not just understanding the front-end.”
An API is similar to a walkie-talkie system in many ways; however unlike a walkie-talkie, every API requires a specific format for requesting information. This formatting is in place to offer organization and consistency to the service, making things easier for anyone engaging with it. For example, if you were using a weather API the information required by the Weather service might just be the location and it would return you current weather. However, if you also indicate you’re interested in a forecast that could be determined by a flag, or it could be that you must provide the weather API the date range in the request. This variance between APIs is why nearly every one is accompanied by documentation, some stellar, others not so much. The documentation ensures that those consuming the service are aware of best practices and how the service was setup. Today’s most versatile specification for documenting an API is through the use of Swagger.
In this series, I will share some proven strategies to help you break into the APIs for your own apps, but what we’re focusing on today is :
- Learn how to identify quick wins and how to implement them
- How to use your Proxy tool
- How to better understand the APIs used by your app
- Advance your troubleshooting skills
- Help you communicate with your development team more effectively
- Who knows what else we’ll decide to share, subscribe to stay in the loop!
All I ask for in return is that you push to break out of your comfort zone and employ some of these techniques in your own products. The only prerequisite for getting started is setting up a proxy tool on your computer. We use Charles Proxy here, but there are several tools out there, both free and paid. Once you’re set up, you’ll be able to see the “conversation” between the front-end and API that brings your app to life. I’ve included an example of the Charles UI below, are you excited yet?
A nearly universal API transaction that mobile apps conduct is Login. In addition to serving as the gatekeeper to one’s account, most login calls will also include pertinent account details of the user. In the fictitious example below, we are looking at the login call for a game that can also be played on the web: Seed Sower. The goal of the game is to accumulate points by planting seeds and growing veggies…sounds fun, huh?
First, I recognized that a couple elements returned in the API transaction were not being used by the app: RewardPreference and JoinDate. Let’s focus on RewardPreference, since I think we can all deduce what JoinDate means for each user…
Whether you’re leveraging a preexisting API, or it was developed concurrent with the mobile project; these unused values are extremely useful, as they’re deemed important by those building the service, and can even offer insight into the way your business operates.
As for RewardPreference, I logged into several accounts and was unable to conclude what this element was used for. Therefore, I reached out to the API development team to understand what this parameter meant.
What are the findings?
I learned that the RewardPreference element was used to determine the user’s selection for how they would like to be rewarded for time spent playing the game. This element is returned for all users, with 1 of 3 values: DP, DP, and NP.
- DP meant the user would like to earn Double Points for their gaming activity: 2x points for each hour of play.
- BS meant the user would like to receive Bonus Seeds: additional seeds would be deposited into the guest’s account for each hour of play.
- Lastly, NP meant the user had yet to identify their preference, or Not Populated, so they would receive no additional seeds or points.
With this information already being returned from the API, we added a custom alert to prompt all users with a value of RewardPreference = NP to set their Reward Preference after a successful login. Now users of this game are maximizing their potential to succeed by receiving more points or seeds for what they were already doing by playing the game. This enhancement should be well received by players, as we’re now offering them two options towards attaining more playtime, as a result increasing their engagement with the app.
No matter what product you are working on, users will appreciate personalized recognition for their app activity. Thanking you with a push notification for every login is too much, but celebrating a milestone or anniversary adds to the overall experience you deliver users.
“THE MORE WE CAN TEACH AND SHARE WITH EACH OTHER, THE MORE WE WILL GROW..”AKASH SHAH, SENIOR PRODUCT MANAGER
Let’s look back at our example with Seed Sower, specifically the JoinDate element in the login call. Since we know this element indicates when a user created their account, hopefully some light bulbs go off for you. Here are some options that I came up with:
- Greet them with a congratulatory message on their first visit to the app after their anniversary…or send them a push on that date
- Create a promotion where users can earn Triple Points on every monthly anniversary date, or you could run this promotion throughout the entire anniversary month
- You could even identify a subset of very active users who signed up to play in the early days and display a custom modal to them with an invitation to the super exclusive Seed Sower New Year’s Eve Party, Rumor has it, this year’s special guests include Elon Musk, Mark Zuckerberg, and Reid Hoffman
Up next in the series we will dive into using the Charles Proxy, which will include setting breakpoints to better understand how an API behaves, learning how to troubleshoot issues and identifying the point of failure for the issue, and better understanding your app by viewing the sequence of calls made for specific interactions.
We would love to hear about what ideas came to mind and any quick-wins that you uncovered by diving into the API at your own organization.