Why I Stopped Using Aardvark and Became a Quora Addict

Written by Ariel Seidman on June 9th, 2010

I stopped using Aardvark for three reasons:

  • It felt very transactional — it lacked soul and depth.
  • It invaded my private space (my instant messenger sessions).
  • It performed well at questions that classic search engines and/or discovery site like Yelp usually handle well e.g. what bike stores are in Palo Alto or where can I find a free SVN MacOS client. You can get answers to these questions without nagging somebody.

On the other hand, I have become a Quora addict for three reasons:

  • Performs well at questions not well suited for a search engine: opinion, multiple constraints scenarios, hypothetical scenarios, etc.  For example startup founders and investors commonly ask “How did company X get traction.”  When somebody with knowledge of that company answers it provides insight that a search engine cannot find because that content previously did not exist.
  • Provides depth and insight — by keeping questions alive, providing answer summaries, etc. the content can become richer.
  • Feels like a natural conversation.  Quora is like a party where you can jump in and out of conversations of interest.  Whereas Aardvark which feels like a party where everybody is separated by a wall.

This blog post is adapted from my answer on Quora.  You should follow me on Quora here.

My Reading List for Product Managers

Written by Ariel Seidman on June 9th, 2010

I finally got around to putting together my recommended reading list for consumer web product managers.  You don’t need to carry the title of product manager — this is for anybody (engineer, designer, etc.) who is the CEO of a user facing feature(s).

Have more recommendations to add to my reading, add them to the comments below.

But..But..I Built What The Customer Said They Wanted

Written by Ariel Seidman on June 1st, 2010

At most enterprise software companies sales and its largest customers dictate product requirements.   Product managers and engineers usually just execute against these “requirements.”  These enterprise systems are rarely successful because the people setting the requirements – sales and its largest customers – are mostly confused (or don’t care) about what the users of these systems actually need to get their job done effectively.

eBay is one of the very best Internet stories.  They built a global marketplace that created economic opportunity and work-life balance for millions of people.  Very few Internet services come close to that kind of economic impact.  Ultimately though eBay got “enterprised.”  While I never worked at eBay I know many who have and they basically tell the same story Ben Foster a former product management leader at eBay explains well here:

The fear of ruining Ebay’s “secret sauce”.  Products could be vetoed by the heads of various functional units if it threatened “the community”.  But no one really knew what made the business so successful, and so there was major resistance to non-organic change.  Our most vocal and successful community members were the very same people who benefited from the inefficiency of the Ebay platform.  So we had major disincentives to innovate.
Seller focus.  Sellers paid Ebay the money, so the company focused innovation on them.  We listened to sellers that said that they wanted feature X, Y, or Z.  But we missed what sellers really wanted.  What sellers really want is for buyers to think of Ebay FIRST when they want to buy something.

This reminds me of one of the best quotes on product innovation: “Your customers won’t tell you everything, so you need to invent on their behalf” – Jeff Bezos CEO and Founder of Amazon.com.  If you are a product manager and sales comes rushing to you with a list of requirements don’t cut and paste those into a product requirements document.   Big mistake.  Listen to customers and listen to sales, but then go and do the hard work of innovating on their behalf.

Mobile Design & Development Resources

Written by Ariel Seidman on May 26th, 2010

I have accumulated lots of links that serve as resources for understanding, building, and launching mobile apps and services.   Every so often I will share a data point or an insight I gleaned from these resources and somebody will ask me for the link – I then go digging.   To reduce the amount of digging I do and provide a better way to share these mobile resources I will start to organize them by topic here.  If you would like to add something to this small directory please add them in the comments.

Mobile Design

Mobile Development

Mobile Technologies

New Forms of Mobile Search & Discovery

App Store and App Marketing

Mobile Monetization

Web Businesses Adapting to the Mobile Era

Mobile Strategy

65,000 New Android Devices Ship Each Day. How Much Are They Worth To Google?

Written by Ariel Seidman on May 14th, 2010

Google recently announced that partners are shipping 65,000 new units of Android each day. How much is that worth to Google – in revenues, not brand equity, rather real hard cash?  Some simple math will provide us the answer.

First, What % of Android Devices are Shipping with Google as Default?

Most users are default users.  They use the email service, search engine, browser, etc. put in front of them.   Of these 65,000 Android devices, how many have Google as the default search engine? Almost all.  Lets assume 95% because there are just a few Android devices shipping with Yahoo! Search as the default.  So, 61,750 Android devices ship each day with the home screen search box or built-in search button hardwired to Google.

How many searches per month does an Android user perform?

Last year Google and Stanford published an excellent report on mobile search query behavior comparing the search usage patterns across PC, iPhone, and feature phones.   The report discloses two important numbers: the average number of search sessions (8.06) the average number of queries per session (1.86) users perform on their iPhone over a 35 day period.

Multiplying those two numbers (search sessions by queries per session) produces the average number of queries (14.7) an iPhone user does per 35 days.  Lets adjust this number upwards by 50% for two reasons:

  1. The data-set is from the summer of 2008. Since that time as the underlying devices and networks get faster the number of queries users perform increases.
  2. Android devices ship with a search box sitting on the home screen or a built-in search button. Whereas, the iPhone the web search box is out of sight integrated into the Safari app.

After adjusting the number upwards by 50% an Android user is performing 22 queries per 35 days, or 19 per 30 days to keep our units similar.

65,000 New Android Devices are  Worth: $7,011/month

$7,000 a month — thats it.  Lets see how we get to this number.  The 61,750 Android devices with Google as the default are generating 1.2M queries per month (# of shipped Android devices times monthly searches per Android device).  At an RPM (revenue per thousand) of $20 that is $23,370 a month or $0.36 per device/month.   Now, hold on. Google does not keep all of this revenue.  Google is paying carriers a traffic acquisition cost (commonly referred to as TAC) anywhere between 60% to 80%.  Using a 70% TAC we get our answer:

Google earns $7,011 a month in search revenues from the 65,000 Android devices that ship each day.

Google earns $0.11 a month in search revenue per shipped Android device.

Looking Ahead: What is the Search Lifetime Value of an Android User?

Android users are worth more then just $0.11/month because they usually keep their phones for longer – twenty-four months or the average contract length.  Assuming twenty-four months the lifetime value of an Android user is $8.63 (monthly search revenues per device x 24 months).  Put simply, each Android device shipping is worth $8.63 in search revenues over the lifetime of their Android device.  As Google improves monetization of mobile search queries this number will go up.  Using a TAC of 70%  Google earns $2.6 in search revenues per user over the life of an Android device after paying the carriers.

So, why was Google trying to bypass carriers and sell Android phones directly to consumers?  Simple economics.  By selling directly they earn 3x more on each Android device, it’s the difference between $2.6 and $8.6.

Notes:

  1. If you have better data you can change the assumptions, the spreadsheet is here
  2. I did not calculate the search monetization opportunity from the Maps application.  I believe a significant percentage of local search queries are moving from web search to the Maps application, I am not aware of sufficient data to estimate this revenue.
  3. Search monetization differs by market — I do not account for this.  I assume $20 RPM across all markets.

Five Clues for Sniffing out Software Projects Bound for Failure

Written by Ariel Seidman on May 13th, 2010

Spending eighteen months on a software project doomed to fail (either gets shut down or market irrelevance) is a waste of the important asset – your time. If you find yourself stuck on one of these you will pick up bad software development habits and find the innovation sucked out of you. Here are five clues to help you sniff out software project that should be avoided.

1.) Projects with Lots of Mass

My general rule of thumb is to avoid any project with significant amounts of mass in its early stages. By mass I mean lots of user research, lots of PowerPoint slides flying around, lots of executive attention, lots of developers. This chaos will generate even more chaos and usually failure. Some of the most successful projects at Yahoo! began as very small side projects: Yahoo! Answers and Yahoo! Sketch-a-Search. Find small projects with people (two three developers, a product manager, and designer) you respect with a track record of building good stuff.

2.) The Project with Three Names

If a project is not going well there is a trick to help it regain stature – rename it. It used to be called “Phoenix” now its “Marin” – problem solved! Before joining a project be sure to ask about the naming lineage.

3.) The Replacement Project

These are easy to detect. Somebody decides to follow a technical trend and in the name of flexibility, scalability, blah-blahbility decides to replace outdated an outdated technology platform with a new shiny platform (i.e the latest technology trend).

4.) The Project that Declares War

These are not hard to detect but hard to ignore, as their pitch inspires high emotional excitment. Declaring war on your archenemy naturally excites us humans. We like conflict. These projects are prone to failure because there is usually no clear angle of attack (see my post here). Rather, its lets build or sell a slightly better or cheaper version of the competitive offering. For example, if you are Monster.com trying to fend off Craigslist offering job listings for $50 is not going to do much other then erode your margins. The reason Monster is failing is because of poor applicant quality. Address that issue rather than chasing Craigslist.

5.) The Sacrificial Lamb Project

Projects that SVPs keep in their portfolio just in case somebody decides its time to start whacking some projects in the name of cost cutting. Because these are relatively rare they are also hard to detect.