No Batteries Included - Shreyas Doshi's blog

IIW2008a reception - Internet Identity Workshop

IMG_0276
Originally uploaded by santhoshreyas

We sponsored the reception at the Internet Identity Workshop.

Prove ownership of your MyBlogLog profile. Now!

A neat feature of the OpenID technology is that it allows you, the developer, to verify that the user indeed has ownership of a URL endpoint. I had stated earlier that lifestreaming services are going to find this feature very useful. Services like FriendFeed, Plaxo Pulse (and of course, MyBlogLog) can enable users to verify ownership of their various online identities/profiles, thereby promoting more authentic activity feeds and eliminating the impersonation scenarios that will inevitably come up.

More generally, once a user has proved to your service that he owns a particular URL endpoint using OpenID, interesting things can follow. Your service could retrieve (you should do this under user consent and control, of course) user attributes that lie at the verified URL endpoint. The retrieval is significantly easier if the attributes are marked up with the appropriate microformats. I am sure people will come up with many interesting features by combining this simple, yet powerful, capability with technologies like YADIS, FOAF/XFN, MicroID.

Now, for the big news of the day. Today, we rolled out support for MyBlogLog profile URLs as OpenID identifiers (Ian Kennedy's post on the MyBlogLog blog). With this change, we have also eliminated the only-one-custom-OpenID-identifier per-account restriction. This means that you can select both your Flickr photostream AND your MyBlogLog profile URL as your OpenID identifiers, in addition to creating a pretty me.yahoo.com identifier. Simon, we heard you loud and clear. :-) This change is especially exciting because the folks at MyBlogLog have been awesome about implementing support for hcard, XFN, FOAF, in addition to hosting a pretty rich profile complete with the New With Me activity streams feature. We hope that you will find this change useful and that it can act as an enabler for more fun applications of the OpenID technology in the future.

To set your MyBlogLog profile URL as your OpenID identifier, start here (requires logged-in state).

T-shirt Front view

IMG_0244
Originally uploaded by santhoshreyas

(btw, this was posted using the new Share This button on Flickr - good job, Kellan and the Flickr team)

The Yahoo! OpenID t-shirts are here

IMG_0243
Originally uploaded by santhoshreyas

Yahoo! announces plans to adopt OAuth as part of the Yahoo! Open Strategy

If you've been following some of the posts on this blog, you've hopefully drank the kool-aid on the view of identity standards like OpenID and OAuth as the fundamental building blocks for more interesting and interoperable apps on the web. At Yahoo!, we've been thinking hard about the value of adopting open standards instead of pushing proprietary products that have been in existence prior to these standards. We have also been talking to and working with the OAuth and OpenID communities on technical, business, and legal fronts. To put our money where our mouth is, in January 2008, we launched the public beta of the Yahoo! OpenID Provider, with an emphasis on significantly improving the OpenID user experience and allowing users to have the convenience of a single identity without the burden of understanding the technical underpinnings of OpenID.

Today, Ari Balogh (new Yahoo! CTO - see video below) publicly announced the broader Yahoo! Open Strategy at the Web 2.0 Expo keynote session (see Cody Simms' post on the Yahoo! Developer Network blog for the juicy details). A key element of this announcement is that, in the not-too-distant future, we will be supporting OAuth as THE STANDARD for authenticated API access for 3rd party developers that want to innovate on top of Yahoo!'s incredible assets and diverse array of services. This auth mechanism will work with web applications, thick-client (installed) applications, and embedded applications! For those who are not familiar with OAuth, it is a community-driven standard that allows 3rd party developers to securely access APIs that expose user data residing on services like Yahoo!. This is done in a way that:

• the user doesn't have reveal his Yahoo! password to the 3rd party application - A good general practice
  
• the 3rd party application only has access to the stuff that is necessary for its use, and nothing else (eg. only access my Address Book, and not my Mail or my billing information) - Scoped access is better than global, unfettered access to all my data
• the user can easily revoke access if he no longer trusts or uses the 3rd party application - User is always in control

If you are familiar with Yahoo! BBAuth, you can think of OAuth as a standard way of doing what BBAuth enables. As a developer who's building interesting things on top of Yahoo! APIs and APIs of other companies that support OAuth, you will not need to write a whole lot of custom code to integrate with 'N' different authentication APIs which all essentially do the same thing. Besides, you can take advantage of open source client libraries for OAuth to reduce the time to implement the auth component of your service or mashup - instead, you can focus that time on building features that really delight your users.

Our announcement today represents a big win for the OAuth community's efforts and is a harbinger of even more interesting things in the near future. As always, stay tuned for more...

Updates:

Heres a video of Ari's Y!OS announcement:

Techcrunch coverage of The New Yahoo!

See Neal Sample's post on Yodel Anecdotal

Heres Neal's talk at Web 2.0 Expo:

See Charlene Li's write-up of Yahoo!'s Open Strategy announcement

Test Test Test

Posting to my blog from Facebook using Blog It - created by the folks at Six Apart.

What is your daytime email address? How about your evening-time email address?

Found in the community clubhouse reservation form for our neighborhood. I left the evening-time email address field blank. I check my email during the day.

Product Marketing Manager != Product Manager

A cursory glance through "Responsibilities" section of the job postings for "Product Manager" and "Product Marketing Manager" reveals that there is a great deal of confusion between these titles. Many postings that advertise a product marketing manager position are really looking for a product manager, and vice versa.

The role of a product manager, as I have recently described here, is fundamentally different from that of a product marketing manager. There is always some overlap, but, in general, they demand a different set of skills for success.

I can best describe my view of the difference in the responsibilities of a product manager and those of a product marketing manager by using the well-known 4 P's model of marketing activities. In the scope of activities defined by the 4 P's, the product manager is responsible for "Product" and the product marketing manager is responsible for "Price", "Place", and "Promotion". Its a simple distinction and it almost always works.

What does a product manager do?

I regularly meet people that find it hard to understand and/or describe what a (software) product manager does. I don't blame them. Very early in my own career as a product manager, I would embark on a monologue for 2 minutes when asked what a product manager did, probably leaving the listener more confused at the end than when I started off.

With experience, I am now able to describe the essence of what a product manager does in one line.

Statement 1: The product manager defines what product the engineering organization should build

"what" is the operative word here. The engineering lead/architect defines the "how", the project manager defines the "when", the product manager defines the "what".

Product managers seem to do a lot of other things, so am I oversimplifying or even inaccurately depicting the role of a product manager? The answer to that is that it depends and I will explain it in two parts.

I. A *lot* of what a product manager does really just supports the essence that I have described above. Activities such as:

a. competitive analysis
b. creating the business case (the "why" of the product)
c. talking to customers, users, executive management, other functional groups within the company (legal, marketing, biz dev, PR, ...)
d. writing PRDs
e. prototyping
f. working with user experience design

Each of these activities helps the product manager understand what product needs to be built and then describe it in a way that engineering can build it. Hence, these activities all support the essence I have stated above.

II. Some other activities of a product manager don't fall so cleanly into the essence. Examples include:

a. Supporting the sales team in deal pursuit
b. Clearing obstacles in product development (funding, resources, ...)
c. Educating people about the product (data sheets, presentations, ...)
d. Working on partnerships

These and other such activities may be a necessary part of a product manager's job, but they are not sufficient without the essence. These activities can be bundled under the following description

Statement 2: A product manager also supports other parts of the organization in order to ensure product success

The role of a product manager is probably one of the most misunderstood roles in the industry today. I have seen people with a product manager title performing the role of a marketing manager, project manager, business analyst, solutions engineer, account manager, business development professional. Conversely, I have seen people in the role of a tech lead, business analyst, marketing manager, program manager, engineering manager perform the role of a product manager. Whether or not your title says it, and whether or not you know it, if you are doing what I have described in statements 1 and 2, you are a product manager.

On anecdotal evidence and product input: how not to build crappy products

Every once in a while, one finds oneself in a discussion over an important topic, having an opposite view as that of a colleague, friend, or family member. This is almost never a bad thing in my view. In the business world, for instance, I would not enjoy being in an organization where no one challenges my views or where I cannot challenge others'. Theres one aspect of such discussions, however, that I try to avoid as much as possible. It is best illustrated with an example.

Lets say I am having a discussion with Joe (a colleague) about the features of our new consumer electronics device. Now, lets say that I maintain that including a certain feature is not justified as it is an advanced feature that we've found is unlikely to be used by most of our users. Joe retorts with "Thats not true! My mother-in-law, who is not at all tech-savvy, regularly uses (and loves) this exact feature in our competitor's product". Hence, I must be wrong and Joe must be right.

While the flaw in the above reasoning should be obvious, its astounding how many times, as a product manager, you will find yourself in a discussion like this. Furthermore, this problem is often exacerbated by the HiPPO (Highest Paid Person's Opinion) effect during product reviews.

Its critical for you to identify whenever you are in a discussion of this nature and take steps towards ensuring that it doesn't lead you to the creation of a crappy product. To counter the threat of anecdotal evidence (often disguised as "input" or "feedback"), follow this recipe of questions:

Does this increase product appeal and/or value?

If yes, does this increase the complexity of the product?

If yes, do the current metrics (quantitative, qualitative, or both) justify this complexity?

If yes, can this be built such that it doesn't adversely affect other, more critical metrics?

If yes, build it. If not, wait until the next version of the product and ask these questions all over again.

Note that I am not suggesting that you ignore input or anecdotal evidence. However, I find far too often that product managers (especially those new to the field) don't say No at the right time. By following a consistent evaluation process - with the underlying strategy of keeping things simple - you can avoid building a crappy product.