Update: I was joined by some great panelists yesterday. Very nice and interesting to also experience the growth of the Internet of Things!
Thanks @ielshareef, @kshah24, @victorosimitz, @mlaguren, @octopi, @AngelHack and @dberlind for yesterday’s #API track. Nice seeing everyone!
— Adam Colson (@adamc) May 14, 2015
Spotted! @kshah24 speaking at @Apps_World about #API management. Are you attending? #AppsWorldNA pic.twitter.com/v5wVpuEOWh
— Whitepages Pro (@WhitepagesPro) May 13, 2015
I’ve been invited back to speak at the Apps World North America conference, happening May 12-13 at Moscone West in San Francisco, CA. This is a great conference, with a focus on mobile apps. I’m looking forward to networking and sharing my own expertise and experiences integrating, building, launching and managing APIs the last 6 years.
The developer conference & exhibition provides two days of high level insight and discussion around a massive and ever-growing industry - mobile apps. Expected to attend are some 10,000 developers, mobile marketers, mobile operators, device manufacturers, platform owners and industry professionals.
The conference features 11 different targeted workshop tracks, speed networking, one to one meetings, parties and includes 6 free to attend developer workshop tracks and a free exhibition with over 350 exhibitors. I’ll be speaking as part of the paid track on API Strategies.
Here are some of the API topics that I and the other panelist have been asked to cover:
And here is a teaser and my brief take on some of these topics.
It should come to no surprise for those that know me, but I'm a bit of an "Internet of Things" fan. Years ago I caught the IoT bug and I don't see it going away anytime soon. I'm constantly thinking of ways to automate my daily life, both at home and at work. I've been using Tasker for my Android phone since 2010, for everything from saving my battery to automating geo and event-based notifications (my wife appreciates it when my device texts her that I left work).
Then something called IFTTT (If This Then That) came along and openend up another world of possibilities - letting the layman (ie - non-developer or non-techie) create cloud connections between services and apps that would nornally never be integrated. Yahoo! experimented with this when they launched a product called Yahoo! Pipes but it fell flat because it wasn't something the average consumer could understand how to use - API? What's an API?.
Now, automation is reaching the masses and store shelves. WiFi is popping up in everthing now: light bulbs, switches, security cameras, thermostats, coffee-makers. This enables connectivity to the cloud, which means connectivity to Web hooks, APIs and cloud-based ETL services like IFTTT and Zapier. Simply put: your favorite apps - example: Instagram and Google Drive - can now talk to each other, which means a whole plethera of integration opportunities (commonly called recipes or connections) to help make your life easier by automating the routine stuff you do everyday.
But enough of the background. Let's walk through how to use some of these tools together to help you with something you do on a daily or nightly basis: charge your smartphone.
The story
As a smartphone user, I want to limit how long my phone charges for so that I don't overcharge my battery. Lithium-ion batteries will perform better and have an overall longer life if they're not always left on the charger (at 100%) or fully discharged (0%).
The solution
In short: an app on my phone (Tasker) will send an SMS "trigger" to the cloud ETL service (IFTTT), which will then take the "action" of turning off the charger by cutting the power to the outlet (WeMo Switch device).
Today marks the 70th anniversary of the Battle of Iwo Jima, or Operation Detachment. On Feb 19, 1945, the United States Armed Forces landed on the black sand beaches of the small island in the Pacific, Iwo Jima. For the United States, the goal was to capture the entire island and its three airfields, which were to be used as launching points for aircraft used to attack the Japanese mainland. For my great uncle Frank Mirabella (also my Godfather who I affectionately referred to as simply "Uncle Frank"), the day represented a truly unanticipated effort of survival.
As my role as the API Product Manager and Owner for Ticketmaster has grown - a direct result of the increase in API adoption, growing user base and product feature expansion - it is finally time to bring in some help.
We're hiring both an API Sales Engineer (or Integration Engineer or API Analyst) as well as an Affiliate API Product Manager. Someone I work with recently asked me what the difference was between the two roles - Product Manager and Sales Engineer. Because I play both roles today for the Ticketmaster API, maybe the differences aren't so clear.
It often isn't clear to others (especially non-techies) what a Product Manager does (let alone an API Product Manager) and what their value to a business this. It especially isn't easy to understand what a Sales Engineer does, until it is explained to you.
It's been far too long since my last blog post here. Twitter is all too convenient and I seldom have time to post something as informational as I'd like. That said, I'm taking the time now to mention that I'll be speaking at the Apps World 2014 North America conference in San Francisco on Feb 5-6, 2014.
Excited to welcome @LiveNation Senior Product Manager @adamc to the #API workshops at #AppsWorld http://t.co/qDTQSZUkVL
— Apps World (@Apps_World) December 2, 2013
I've been invited to be a panelist for their API Strategies Workshop on Feb 5. Some of the questions that I'll help try to answer:
I have an immense amount of experience developing APIs, most recently for Live Nation Entertainment, where I manage the event discovery and ticketing commerce APIs that are used to power all of our mobile products. I'm also evangelizing opening up (to some degree) our APIs at Ticketmaster as well as leading product strategy for a new enterprise API that will be built upon our shiny new ticketing back-end.
I have many examples and professional case studies for the benefits to developing an API, for opening up access and for making sure what you decide to build and launch will actually get used ("if you build it, they will come" does not always apply).
I've seen the value to providing alternative Web interfaces to data for a while, dating all the way back to the early-to-mid 2000's, when I decided to leverage trendy standards like RSS, feed readers and widgets, to deliver personalized, timely results to Realtor.com users. Now, I'm helping to build complex Rest interfaces that asynchronously manage the e-commerce flow for thousands of mobile app users every day.
I've launched multiple developer portals, managed developer networks, blog about how to use API and write API documentation for my products. I also help manage the set up and configuration of the Ticketmaster API.
Looking forward to sharing my experiences and knowledge with others. It's not too late to register for the event. Hope to see you there!
This post is the first in a series of posts (hopefully) aimed at helping those in an Internet product-related position - product manager, project manager, marketing manager, usability designer, interaction designer, qa tester, etc - do their daily jobs better. I'll be adding templates, advice, strategies and other gems on information that I've absorbed over my 12 years creating and managing online products to this blog.
The first challenge I'm hoping to help people address is this: what is an alternative way to easily and effectively communicate my requirements or needs around a certain idea I have? How can I more effectively convey to an engineer what the feature should do? My answer is the Use Case.
Use cases provide an excellent method of describing what a product, system, feature, etc is supposed to do. It is an effective alternative to the more traditional methods of documenting functional requirements and business rules and helps to provide software engineers with a clearer picture as to what the desired objective of a feature is.
Every good use case should try to convey the following: