ReadWriteTalk » Blog Archive » Tom Stocky - Product Manager, Google Development Products

Tom Stocky - Product Manager, Google Development Products

Introduction

Tom Stocky

This is an interesting episode of ReadWriteTalk. On Friday April 4th, I interviewed Tom Stocky a Product Manager with Google Development Products. After the interview, we sent the audio over to be transcribed. At the time, I had no idea that on Monday April 7th, Google Development Products would announce arguably their most ambitious project yet - the Google App Engine. At that point, we considered releasing the interview immediately. But decided that while it would have been interesting context before the announcement at that point we should go through our normal process waiting for the transcribing to be complete. We did cover the announcement thoroughly on ReadWriteWeb, for listeners I link to all our coverage on the show notes.

Anyway,we still think this its very interesting context and hope you agree. The first half of the interview covers a number of different projects, other than the AppEngine (because that was still in stealth mode). The second part gets into how Google evaluates the success of the different Development Products. It is interesting to apply the same metrics and goals Tom discusses to the App Engine and consider what other projects may be coming soon from Google.

One thing we’re considering moving forward is releasing the audio immediately after the interviews are adding the transcript later. Please let me know what you think about that idea!

Standard Podcast [22:18m]: Play Now | Play in Popup | Download

Transcript

	Sean Ammirati: So today on ReadWrite Talk I have Tom Stocky, a Product Manager with the Google Development Products. So Tom if you could start out just giving an overview of your role at Google and what your responsibilities are.Tom Stocky: Sure. So I lead the team of Product Managers who work on our developer products. So it’s basically the products that are covered are on code.google.com. I think in the context of the upcoming event we have, we lay down our products in neat categories which are AJAX and JavaScript, API’s and tools and then Social, Mobile and Maps and Geo. And I think that those kind of layouts, the different categories of API’s and tools that we offer. Sean Ammirati: Ok and since you’ve mention that, let’s get to this right away. So you have an upcoming conference on the 28th and 29th. Can you talk to us a little bit about that? Tom Stocky: Sure, it’s our biggest developer event of the year. It’s called Google I/O and it’s May 28 to 29. It’s a two day event in San Francisco. And basically we had a similar event last year. That was one day and we got a lot of great feedback. And part of that feedback was that people really wanted the opportunity to go deeper on some of these technical issues and discussions that we were having.
02:44	So we’ve set-up the conference this year to have, there are a lot of talks and there is still a fair number of intros and tutorials for people who are less familiar with the different APIs Google has. But there’s also hackathons and these side rooms that we’ll have where you can interact directly with the engineering team. And there will be some FireSide chat type forum where you can ask any questions you want of the engineering teams that are working on these products.Sean Ammirati: Ok cool! And as you look over the last six months, can you tell us some of the things that you’ve recently launched? Like I know the Contacts API is one of them. Can you talk about a couple of the things that maybe recently emerged under these different five categories? Tom Stocky: Sure. I mean you mentioned one. In the area of the social, you know the way we see this as still this fundamental problem on the web which is for developers as all these new social sites that are cropping up, developers have to write the different application for each one of these sites. And then on the user’s side, it’s like each time a user goes through a new or one of these sites, I have to re-enter all my friends and re-enter all these contacts. And so we’re trying to make some initial stuff that help solve those problems.
04:00	While on the developer’s side, OpenSocial is kind of a framework where you can write a single application or at least use a single programming model to put your application on MySpace and Yahoo! and Orkut and other networking sites. And then on the other side, the user’s side, we have the Social Graph API which is this public friend information on XFN and FOAF and make that more programmatically accessible.And then for our own contact data, like you mentioned the Google Contacts Data API which is an effort to make the address book information you have in Gmail. Of course with the proper authentication and authorization. But make that more portable so that developers can have access to that. So that’s in the social state.
04:48	I think in mobile, one of the recent things we announced was Google Gears for mobile. If you’re not familiar with Google Gears, it’s basically is a way to bring offline access to web applications. And gears for mobile is interesting because it brings that same functionality to mobile phones. I think Maps and Geo, the most popular API there for sure is the Maps API itself. And we continue to have incremental features that come up that are basically exposing all the functionality in Google Maps itself to expose that into the Maps API as well.And then just in terms of AJAX and tools, I think the biggest effort we have there is probably the Google Web Toolkit which is basically instead of writing your web app in JavaScript directly, you can write it in Java. And then as the compiler, that then compiles that into JavaScript. And the way the team like to think of it is it’s faster JavaScript that you could write by hand. And that’s really the idea, to basically produce JavaScript that is more optimized than any same person could do by hand.
06:00	Sean Ammirati: Right. Yes. I think let’s just kind of go through those a little bit. Then starting with the social stuff. Obviously Open Social is something that’s been I think very well covered but I think the other two I think are maybe a little less well known. So talk about this Social Graph API first. It’s interesting. I was at south by southwest and the guys from, I think both Plaxo and SixApart talked about “Oh you know we knew this was a need.”Once we found that Google was working on it it was like, “Let them do it because they have a nice cache of the web”, for lack of a better term. So can you talk a little bit about how you came up with the Social Graph API idea and then just a little bit about kind of how it came to deployment. Because I would imagine that although I’m sure part of it was the talented team that you had, there’s also just certain advantages you have being Google and trying to tackle these problems. And maybe the Social Graph API would be an interesting example of that.
07:04	Tom Stocky: Well I think, I mean what we found was, there’s all of this public information out there in the form of things like XFN and FOAF which are really I mean they’re just special tags within web pages. And so Google was already as part of the search infrastructure, crawling all these pages. And it was aware of this information but it wasn’t really accessible to developers in any programmatic or interesting way. I mean that’s not entirely true. There are services out there that access these information as well.
07:37	But the idea was because this is all public data and it’s out there, why not make it a little more useful and help support those standards like XFN and FOAF. And so the idea is you basically you can make a call for the API and give it an identity and it will return back. Would it find through the pages that Google has crawled? Would it find in terms of connections to other people and in terms of the multiple identities the people might share across these sites in a public way.Sean Ammirati: Great. And XFN I know is on microformat. Is FOAF on microformat as well? Tom Stocky: To be honest I’m not exactly sure. Sean Ammirati: Ok. The reason I ask is Yahoo! had a lot of publicity recently about how their search engine was leveraging microformats. It seems like you guys may be doing the same thing although I know they were doing in the search results. You know it’s interesting that these standards are sort of seems to be adopted across a lot of the Google tools and I was just curious. Talk with the Google Contact API as well if you wouldn’t mind.
08:42	Tom Stocky: Sure. So there it’s making use of the Google Data API specs if you will. And they’re basically to give developers programmatic access to a user’s contact that they have in Gmail or Google Talk or any of the other places that you can populate that information.And so a user can go to a third party site and then with the proper authentication and authorization, you just redirect to Google and back. And then it gives the developer access to that information so they that can look up to user’s friend and then do something useful with that. Like for example port it over to another social application. Sean Ammirati: Right. You know obviously there’s lots of these tools that are out there asking you for like your Gmail address to find out who your friends are. This is I guess the legitimate way to do that, is that the idea?
09:34	Tom Stocky: We mean for it to be a safe way so that the user has control over the way they’re sharing this information. And doesn’t have to give out their user name and password. Data portability is a big topic but we’re trying to make one small step at least for exposing the contacts needed and making it more portable. And it will be great if this became a trend on the web where basically everyone, friend and contact data was portable between all these sites.Sean Ammirati: Right and as you say there’s ways to do that with good authentication like FOAF and things like that. The Data Portability Movement, it will be interesting to get your take on that. Tom Stocky: It would make for a long discussion but I think the short answer is I think we believe information wants to be free and so the more that we can prevent. Like within Google we certainly have have the idea that we don’t want to whack people’s data and we want to give users the ability to control that data and decide if they want to take it somewhere else or if they want to share it with another service. They can do that. And so at the same time we were hoping that the web and a number of other sites can bring similar philosophy which I think they are already starting to do.
10:49	Sean Ammirati: Yes. That was a great overview of the social ones. I think some of the other new things are probably more familiar. But it will be interesting to just get a sense in terms of all these initiatives. Are there kind of big themes that are driving the initiatives that end up being kind of part of code.google.com projects for lack of a better term? Is there other things that you’re trying to sort of use when you’re selecting what products to focus your team on?Tom Stocky: Sure. I think, I mean in general what we’re trying to do is help move the web forward as a platform. Google was born on the web. We believe in the web. We see that that’s where most of the activity is right now in terms of developers. And we just want to help improve it. And so a common question we get is, why do we care and why is this important to Google?
11:45	And I think the answer there is the way we think about it is there’s really this developers-apps-users cycle, if you will. And so as the web platform improves, it attracts more developers. We have more developers, that means more and better applications. And that attracts more users and increase usage of the internet as a whole. And that’s something that’s beneficial to Google as well as every other site on the web.So that’s kind of the philosophy. And so what we’re doing is we’re trying to look for, well what are the hard problems that developers face on the web today? You know when they’re writing JavaScript apps or if they’re writing complex web apps. And how can we systematically, you know go down that list and help improve things along those lines.
12:30	Sean Ammirati: Two interesting questions come out of that. One is, how do you identify those problems? And then two, how do you measure the success of the projects you’re doing?Tom Stocky: Sure. So the first one, how do we identify the problems? Well we have a fortunate thing of this that most of the engineers within Google are writing web applications. Feedback internally about tools and APIs that we could build that would help them. And similarly, I mean we try to stay as engaged as possible with the developer community and we look for feedback. We’re starving for feedback and we’re always looking for it anyway we can. And so we could get that from like the discussion groups and we read a number of blogs out there. We look for the pain points that are kind of consistent across the number of different sites. In terms of measuring the success, there I think is when we see innovative and exciting applications that previously might not have been possible, that’s what we see as success. And it’s really it’s not a success for Google necessarily, it’s really success for the web and for the success of the web in the platform.
13:38	Sean Ammirati: Which is really interesting and definitely feels very noble. I’m curious like, maybe this is just because for a day job I’d have some practice like when you go for your annual review, how do you make the case of what you’re doing is valuable? I mean do you highlight those applications?Tom Stocky: It totally depends on you know the product itself. I mean there are cases where… so fundamentally if I’m a product manager for particular product, our success metrics are probably going to be active usage by developers. So the number of active developers who are writing against my API. And then if I can get some sense of the breadth and the scale that they’re accessing. So if I get some sense for the number of end users, total end users that are using something that is based on one of these APIs. I mean if you want to get into the low-level I think those are two and pretty important metrics. Depending on the products, there’s number of other ones you can think of but I mean end users and active developers are the two big ones.
14:41	Sean Ammirati: Now it’s just helpful to think about how you’re picking these projects, right? And going back to sort of whether there’s opportunity to make development on the web easier. Just looking forward, are there things that you’re starting to look at as, “Boy these are some challenges that the web has right now and maybe Google can help solve these problems.” But you haven’t yet created any API’s or solutions around them?Tom Stocky: Well I think one of the challenges, I mean we have the beginnings of a solution but they’re certainly a long way to go is getting web apps in a way that as regular as you can and kind of in a native or client apps. And by that I mean either JavaScript as a language makes some things very much easier and make other things harder. Things like debugging and adding break points or even just modularizing your code in a way that can be shared easily across the big group. Or even just writing JavaScripts in a way that is really high performance and low latency. It doesn’t have too many HTTP request back and forth.
15:47	>And so we have something called Google web Toolkit which is a unique approach to this. Where you write it in Java, you compile it to JavaScript. And then as I said before we think of that as the best possible JavaScript that you could write. And better than when you could write it by hand. And there’s a long way to go.And that’s an open source project. So it’s an example of our approach to this which is that we put something out there and we try to get as much feedback as possible and we work collaboratively with the developer community to design the product going forward. And make sure it’s hitting all the important main points. Sean Ammirati: Interesting. Are all of your projects open source? I mean I was aware Google Web Toolkit was open source but how did you make that decision?
16:33	Tom Stocky: I think generally we want to do things in an open way. So, yes Google as toolkit is open source, open social. It’s like these are the reference implementation called Shindig. That is open source in the Apache license and generally this spec is posted with the ability to be shared. Opensocial.org was created around there.Google Gears is also open source. I mean as much as we can we want to create these services and tools and APIs in a way that we can get additional contribution from the developer community. And also in way so that they can take it in direction that we didn’t anticipate. Sean Ammirati: I mean that’s a really interesting sort of view. We like to call ReadWriteTalk the people behind the web. This is a really interesting view in your role at Google and serve maybe a part of Google people don’t naturally think of first because you have that search product as well.[Laughter]
17:33	But just when stepping back for a moment and just thinking about the web in general, one of the questions I like to ask people as well as, just what are the things that are exciting you about the web right now? And that what are the things that are concerning you about the web right now? Anything that jumps to mind on either of these?Tom Stocky: In terms of excitement, I mean to me the most exciting thing is just being the application that are created and the fact that I would have never imagined you could do these things inside of the browser. You know if you ask me three, five years ago. It’s been nice because being in Google because we’ve been involved with some of those milestones. With things like Gmail and Google Map, I think those represent milestones in kind of the evolution of web application development. In terms of the things that concern me, that’s a tough question. I mean I think there’s a lot of big problems that still need to be solved but I will just come back to what I said earlier which was that the performance of web applications and the end user’s experience, I think it’s still the most important thing.
18:45	I get into the trap. You know sometimes when I’m writing some scripts and stuff that I do things because it’s kind of it’s cool and it produces some kind of whizzy feature in an apps that I’m creating. But at the end of the day, there is sometime’s the trade off between that and it’s just making sure that the users can accomplish what they need to. I don’t mean to keep bringing up the Google web toolkit but I think that’s really what it’s focus is. Is to make sure that web applications are creating far high performance and are able to work effectively on the web.Sean Ammirati: That’s very good. Talking about the applications that you never would have expected to be created in the browser? Any non-Google web properties that jumped to mind? Tom Stocky: Well I think Zoho was a great one. And that also highlights our approach to APIs and tools in general. Google Gears came out and Zoho actually implemented an offline version of their documents application before we did it ourselves within Google. You might have seen recently, we did announced Google Docs’ offline capability. But that was a couple of months after Zoho did. I think that they have a lot of great features in their apps. And yes I think that just highlights our approach. Sean Ammirati: Cool! Which is great. So just going back to the conference here as we wrap up. Just for the developers maybe who are using some of these tools and are trying to get a sense of whether it makes sense when they go at it. If you could just once again go over there. There the hackathon and the in depth sessions, how would you explain kind of why they should be there for those two days? Maybe it’s a good question to end on.
20:31	Tom Stocky: Sure. I think I mean you mentioned some of the formats. We have split the sessions into a bunch of different types. We have what we call “101 Sessions” which are kind of intros for people who don’t have much previous knowledge of a certain API. We have “201s” which are like a deeper dive.And then we have “Code Laps” which are a way to interact with engineers directly and as they walk through, kind of a way to build a sample app or something with a particular API. And then there’s FireSide chats which are direct Q&A with the engineering team. And Tech Talks which are kind of more traditional presentations. And that kind of map to what we do within Google as well. And I think in general, the reason to come is we’re doing our best to bring everyone that we have in Google that works in developer products to one place at one time. As well as the various members of community who are working on these efforts too. And I think the level of interaction and the accessibility of all these people in place is probably hard to match anywhere else. And that’s really the goal for the conference.
	Sean Ammirati: Cool! Tom, I appreciate you chatting with us quickly today. And hopefully this gave people a taste for what is going on in the Google Development Tools and maybe they’ll get a chance to meet you in San Francisco in May. So thanks a lot.Tom Stocky: For sure, great! Thank you.

This entry was posted on Thursday, April 10th, 2008 at 6:49 pm and is filed under Intraprenuer. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.