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!
The use of belly putters by regular PGA Tour professionals has been a hot topic this year. Certainly, belly putters have helped to resurrect the careers of some - like Adam Scott, Ernie Els and Matt Kuchar - as well as kick-start the careers for others, namely Keegan Bradley and Webb Simpson.
For Bradley and Simpson, the belly putter has not only helped them win majors (last year's PGA Championship for Bradley and this year's US Open for Simpson) but also earn a spot on the 2012 US Ryder Cup team, of which Kuchar was also a member.
On Friday and Saturday of the 2012 Ryder Cup, US belly putter players went 7-1 in their matches while the European belly putting team (Sergio Garcia) went 1-2 on Friday and Saturday.
On Sunday, when it counted the most, the US players - Bradley, Simpson and Kuchar - went 0-3, including a slew of crucial missed putts for birdie and par by Simpson. Meanwhile, Sergio's shining moment in his comeback win on Sunday's singles wasn't even due to his putting but rather Furyk's inability to close him out (Furyk bogeyed the 17th and 18th holes).
Winner of 2012 Putting Cup - traditional putters.
There's been little research done to support the case that they should be banned because they result in an unfair advantage over the traditional style of putting. This article shows evidence that players don't actually show improvement or gain an advantage over traditional length putters. There's no doubt that certain players, namely Adam Scott, have become better putters when using the belly putter. However, they've not ascended to the heights of "putting God" as a result.
For the PGA Tour and the USGA, the decision to change the rules of golf and ban these types of long putters comes down to one
decision: should a player be permitted to anchor the putter against any part of their body, other than their hands (ie - their chest, forearm or belly)?
The questions that I like to ask are: if anchoring a putter was such a competitive advantage, why aren't all the players doing it? If it helps players lengthen their career, why should we ban a key component to their livelihood? Why haven't more players adopted
Bernard Langer's forearm-anchored putting style, when it clearly helped him cure the yips?
I went to a belly putter back in 2007, when I was having trouble making short putts. It worked great, except on long putts. I put the putter away after 4-putting a hole in a USGA qualifying match.
It's late on a Wed night before the NCAA tournament is to start, you want to get your bracket picks in, you sign in and go to the bracket page... and what? You see two med recs stacked on top of one another, thereby making it impossible to fill out your bracket.
Then, you start this blog post, go back to the site to see if they've fixed it and...
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.
I just received an email from Songkick that outlines their intentions to take users' private profiles on their service and make them public. This seems like a logical next step for them, given that they already have a great hold on event and artist content. Folding in user-generated fan content and their favorites into the public mix opens up all kinds of money-making opportunities for the site - think targeted advertising, increased organic search engine traffic.
I couldn't find a blog post from them on this topic or any other news, so I'm posting the contents of the email here.
We're reaching out to let you know that as of 1st December, we will no longer be supporting private profiles on Songkick - which means that your user page will automatically become public.
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!