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.
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:
Often times I'm asked what it is I do. I usually answer with a short response like "I sit behind a computer most of the day and send emails" or "I help build Web sites and apps". You see, describing what a product manager does to someone not in technology isn't easy. You want to tell them in intricate detail what it is you do but you don't want to bore them or tell them something that will just go right over their heads, like "I write product specifications for RESTful APIs".
Recently, a VP of Engineering where I work reached out to me to help understand what I did, so that they could better identify a candidate for an API/SOA product role that they were looking to fill. The questions were:
Here is my response, which describes in intricate details what an API product manager is responsible for.
Today, much to my dismay, I decided to stop using the Google Voice service for my mobile voicemail and start using the default AT&T service.
I decided to use Google Voice when I got my new smart phone, the Samsung Galaxy S. There are a lot of great features in the Google Voice product. My favorite features are the ability to “see” my voicemail and listen to messages directly from a toolbar widget in the browser. The option I chose was to forward my phone calls to Google so that they can provide the voicemail service when I missed a call. If you decide to use a Google Voice number, the features and options you have are even greater.
But like all Beta products, you cannot expect everything to be perfect. Unfortunately, when it comes to receiving phones calls, the quality and performance standards that I hold a product to are extremely high. And specifically, with the Google Voice service, it seems that sometimes, phone calls that were made just wouldn’t connect. I didn't believe this was happening until more than one person told me that my phone wasn't working. If you were the caller, you wouldn’t even get my voicemail box. Instead, it would appear as if the number wasn’t connected or a wrong number was dialed. This is unacceptable.
The other issue I had was with the quality of the audio file that was used for playback. Often, the volume was entirely too low to comprehend the entire voice message. Lastly, the transcription of the audio to text was hit and miss. If the caller spoke like a robot and the line was totally clear on their end, the transcription was great. If, however, the caller was not the clearest speaker or their connection (like from another mobile phone) was not clear, the transcription was either not useful or missing entirely.
Overall, I would rate the Google Voice product a C+. Again, I place significant weight on their ability to connect callers. The thought that I may have missed a critical call from someone was too much risk for me to live with and certainly was not off-set by the cool Google Voice features.
So it’s back to the regular AT&T voicemail for me. I’m hoping someday they’ll bring visual voicemail to my phone service. Until then, please leave a message!
The VW-Prüfgelände Ehra testing track in Germany is where Volkswagen does all significant road testing of automobiles they develop, including the Bugatti Veyron. This track is supposed to be super secret but very little is suppresed in Google Maps. The track includes a straightaway that is over 7 miles long! The Bugatti Veyron is the world's fastest production car, with 1001 horse power, costing $1.7 million and capable of an "electronically governed" top speed of 253 MPH.
View Larger Map