The Combinatorics of Family Chaos

/ Adam Nash / 9 Comments

For those of you who read this blog regularly, you’ve likely noticed a lull in my posting.  That’s because, about two weeks ago, my wife & I welcomed a new addition to the family.  Given that the most common response to our decision to add a fourth child to the family has largely been “borderline insanity”, I felt it was appropriate to share some of my thinking on the complexity that comes with every new addition.

The Wrong Model: Linear

When a couple decides to have a second child, you are quickly inundated with advice on how to manage the complexity.  The most common refrain you hear is: “Don’t worry, you can still field man-on-man coverage.”  Another popular version of this advice is: “At least you’re not outnumbered.”

The implication here is that managing the family is fundamentally a relationship between parents & kids, like this:

Parental Ratio = # of Parents / # of Kids

With the implication that somehow, as long as the parental ratio is greater than or equal to one, you’ll be able to manage.

Unfortunately, I’ve found that this description of complexity dramatically understates the drama of real family life.

The Right Model: Combinatorics

Instead 0f focusing specifically on the number and types of nodes in the family graph, I think it’s more useful to think about the nature of emotional entanglements (aka “drama”) and understand that they tend to require at least two people, but can easily involve more.  As a result, the complexity of family life can be more accurately modeled as the number of two-party relationships in a family that can engage in drama.

Initially, a couple has exactly one potential pair:

  • Adult 1 <-> Adult 2

However, once you add a single child to the mix, you immediately add two more vectors of potential drama:

  • Adult 1 <-> Child 1
  • Adult 2 <-> Child 1

It’s worth noting that it’s sometimes unclear whether a three-party argument is truly a single argument or actually a combination of two or three two-party arguments, but let’s just roll with the simplified assumption for now that all drama can be decomposed to pair-based drama.

Pascal’s Triangle actually makes calculating this number for any size family trivial.  This means that:

  • Two family members (0 kids): 1 drama pair
  • Three family members (1 kids): 3 drama pairs
  • Four family members (2 kids): 6 drama pairs
  • Five family members (3 kids): 10 drama pairs
  • Six family members (4 kids): 15 drama pairs

It’s combinatoric, specifically in the form of:

family complexity  = # of family members  choose 2

Which is a fancy way of saying each new child adds a new relationship to the mix for every existing family member.  This sequence is also known as the triangular numbers.

For those of you who have or come from large families, let me know if this lightweight graph theory matches your experience.

Julia Elizabeth Nash

Julia Elizabeth Nash
Born 10.0 lbs, 21 inches
Single handedly increased Nash family complexity by 50%

How to Fix the “Green Screen” on a Nintendo Wii

/ Adam Nash / 1 Comment

This blog post falls under the category of “tormenting technology problems that can ruin your evening.”

Our Nintendo Wii gave up the ghost a couple of weeks ago.  After ordering a replacement on eBay, and then returning it due to this issue, I was shocked to get a second Wii with the same problem.  Realizing it must be a configuration issue, I was able to diagnose and correct for it.  I’m posting the solution here to help any other unfortunate souls with the same problem.

Symptoms

Your Nintendo Wii displays a blank, solid green screen.  Sound works fine, but nothing but green on the TV.

Likely Cause

You have a new Nintendo Wii and have used a component cable (Green-Blue – Red + Red-White) to connect it to an HD television.

By default, the Nintendo Wii comes configured to display 480i signals.  The problem is, newer high definition TVs don’t handle a 4:3 480i signal properly from component cables, and the Nintendo Wii doesn’t self-configure for 480p when you plug in component cables.

What makes this devilishly complicated is that if you try to configure the Wii using the standard RCA cable (Yellow-Red-White), the option to change the display to 480p is greyed out.  Catch-22.

Solution

Here are the steps to properly configure your Nintendo Wii for component display:

  • Hook up your Nintendo Wii using the component cable.
  • Instead of plugging the Green-Blue-Red cables into your display using the component ports, instead plug the green cable into the “Yellow” port of the RCA ports on your display.
  • You will now get a greyscale rendering of your Nintendo Wii interface, but totally usable.
  • Navigate through the configuration screens.  When complete, go to settings, and then select “Display”.  You’ll find that the 480p option is now selectable.  Choose it.  Also make sure to set the display to 16:9 if you have an HD display.
  • Shut off the Wii, and hook up your component cables to the component jacks on your display.

That’s it.  Fairly simple, but I had to dig through a number of bad google results to figure it out.

Hope this helps someone out there, and saves you from returning a perfectly good Nintendo Wii. Tune in next week, I will be reviewing a few of the best gaming headsets, I find games play much better with headsets, solo immersion goes a long way.

User Acquisition, Virality & Mobile Distribution: Notes

/ Adam Nash

On Friday, Brendan Baker put up his notes from my Greylock Discovery Fund talk on user acquisition, virality & mobile distribution.  It’s a great resource to see a combination of third party notes about the talk, as well as some of the Q&A from that session.

Greylock Blog: User Acquisition, Virality & Mobile – Notes from Our Session with Adam Nash

Last week, I also had the opportunity to give a similar talk at 500 Startups.  As promised for those who couldn’t attend, here is a short list of relevant blog posts from the past two years that provide more depth to the topic:

Product Leadership

Design Led Product

User Acquisition & Virality

Product Prioritization

Goodbye, Newton

/ Adam Nash / 5 Comments

Today, we had to say goodbye to a very special member of our family, Newton Nash.

On December 2, 2002, I came home to find my wife waiting for me in the parking lot of our apartment complex.  I was immediately whisked away to pick up a surprise gift, a new beagle puppy.  There were a few puppies left in the litter, but I chose the one who peed when he saw us.  He was about eight weeks old at the time.

We picked a beagle because we lived in a small apartment at the time, but didn’t want to get a “toy” dog.  At the time, Star Trek Enterprise was still on TV, and I had asked Carolyn what type of dog Captain Archer had.  After meeting a few beagles at the local Starbucks, we were sold.

Newton was named based on an arcane naming convention matching three criteria: had to be a scientist, had to be an apple product or codename, had to end in “N” to go with Nash.

Newton was the first addition to our little family, which eventually added a second beagle (“Darwin”), and three children.  He was a 13″ beagle who grew up to be nearly 17″ at the shoulder.  He didn’t have a huge tolerance for party tricks, but could sit, stay, lie down, roll over and on a good day, do a military crawl.  Despite a somewhat extreme fondness for licking ears, he was incredibly gentle and playful with friends and strangers alike.

We knew our time with him was short, but didn’t realize it would be this short.  He will be missed.  I’ve posted a selection of photos from the last nine years below.  Many thanks to Eric Cheng, who took a few of the best shots over the years on his regular visits to suburban madness.

This slideshow requires JavaScript.

User Acquisition: Mobile Applications and the Mobile Web

/ Adam Nash / 8 Comments

This is the third post in a three post series on user acquisition.

In the first two posts in this series, we covered the basics of the five sources of traffic to a web-based product and the fundamentals of viral factors.  This final post covers applying these insights to the current edge of product innovation: mobile applications and the mobile web.

Bar Fight: Native Apps vs. Mobile Web

For the last few years, the debate between building native applications vs. mobile web sites has raged.  (In Silicon Valley, bar fights break out over things like this.) Developers love the web as a platform.  As a community, we have spent the last fifteen years on standards, technologies, environments and processes to produce great web-based software.  A vast majority of developers don’t want to go back to the days of desktop application development.

Makes you wonder why we have more than a million native applications out there across platforms.

Native Apps Work

If you are religious about the web as a platform, the most upsetting thing about native applications is that they work.  The fact is, in almost every case, the product manager who pushes to launch a native application is rewarded with metrics that go up and to the right.  As long as that fact is true, we’re going to continue to see a growing number of native applications.

But why do they work?

There are actually quite a few aspects to the native application ecoystem that make it explosively more effective than the desktop application ecosystem of the 1990s.  Covering them all would be a blog post in itself.  But in the context of user acquisition, I’ll posit a dominant, simple insight:

Native applications generate organic traffic, at scale.

Yes, I know this sounds like a contradiction.  In my first blog post on the five sources of traffic, I wrote:

The problem with organic traffic is that no one really knows how to generate more of it.  Put a product manager in charge of “moving organic traffic up” and you’ll see the fear in their eyes.

That was true… until recently.  On the web, no one knows how to grow organic traffic in an effective, measurable way.  However, launch a native application, and suddenly you start seeing a large number of organic visits.  Organic traffic is often the most engaged traffic.  Organic traffic has strong intent.  On the web, they typed in your domain for a reason.  They want you to give them something to do.  They are open to suggestions.  They care about your service enough to engage voluntarily.  It’s not completely apples-to-apples, but from a metrics standpoint, the usage you get when someone taps your application icon behaves like organic traffic.

Giving a great product designer organic traffic on tap is like giving a hamster a little pedal that delivers pure bliss.  And the metrics don’t lie.

Revenge of the Web: Viral Distribution

OK. So despite fifteen years of innovation, we as a greater web community failed to deliver a mechanism that reliably generates the most engaged and valuable source of traffic to an application.  No need to despair and pack up quite yet, because the web community has delivered on something equally (if not more) valuable.

Viral distribution favors the web.

Web pages can be optimized across all screens – desktop, tablet, phone.  When there are viral loops that include the television, you can bet the web will work there too.

We describe content using URLs, and universally, when you open a URL they go to the web.  We know how to carry metadata in links, allowing experiences to be optimized based on the content, the mechanism that it was shared, who shared it, and who received it.  We can multivariate test it in ways that border on the supernatural.

To be honest, after years of conversations with different mobile platform providers, I’m still somewhat shocked that in 2012 the user experience for designing a seamless way for URLs to appropriately resolve to either the web or a native application are as poor as they are.  (Ironically, Apple solved this issue in 2007 for Youtube and Google Maps, and yet for some reason has failed to open up that registry of domains to the developer community.)  Facebook is taking the best crack at solving this problem today, but it’s limited to their channel.

The simple truth is that the people out there that you need to grow do not have your application.  They have the web.  That’s how you’re going to reach them at scale.

Focus on Experience, Not Technology

In the last blog post on viral factors, I pointed out that growth is based on features that let a user of your product reach out and connect with a non-user.

In the mobile world of 2012, that may largely look like highly engaged organic users (app) pushing content out that leads to a mobile web experience (links).

As a product designer, you need to think carefully about the end-to-end experience across your native application and the mobile web.  Most likely, a potential user’s first experience with your product or service will be a transactional web page, delivered through a viral channel.  They may open that URL on a desktop computer, a tablet, or a phone.  That will be your opportunity not only to convert them over to an engaged user, in many cases by encouraging them to download your native application.

You need to design a delightful and optimized experience across that entire flow if you want to see maximized self-distribution of your product and service.

Think carefully about how Instagram exploded in such a short time period, and you can see the power of even just one optimized experience that cuts across a native application and a web-based vector.

Now go build a billion dollar company.

User Acquisition: Viral Factor Basics

/ Adam Nash / 18 Comments

This is the second post in a three post series on user acquisition.

In the first post in this series, we covered the basics of the five sources of traffic to a web-based product.  This next post covers one of the most important, albeit trendy, aspects of user acquisition: virality.

Lot-of-Rabbits

It’s About Users Touching Non-Users

Look at your product and ask yourself a simple question: which features actually let a user of your product reach out and connect with a non-user?   The answer might surprise you.

At LinkedIn, we did this simple evaluation and discovered that out of thousands of features on the site, only about a half-dozen would actually let a user create content that would reach a non-user. (In fact, only a couple of these were used in high volume.)

I continue to be surprised at how many sites and applications are launched without having given careful thought to this exactproblem.  Virality cannot easily be grafted onto a service – outsized results tend to be reserved for products that design it into the core of the experience.

Useful questions to ask, from a product & design perspective:

  • How can a user create content that reaches another user?
  • How does a users experience get better the more people they are connected to on it?
  • How does a user benefit from reaching out to a non-user?

Understanding Viral Factors

One of the most useful types of metrics to come out of the last five years of social software is the viral factor.  Popularized by the boom of development on the Facebook platform in 2007, a viral factor is a number, typically between 0.0 and 1.0.  It describes a basic business problem that affects literally every business in the world:

“Given that I get a new customer today, how many new customers will they bring in over the next N days?”

“N” is a placeholder for a cycle time that makes sense for your business.  Some companies literally track this in hours, others 3 days, or even 30.  Let’s assume for now that 7 is a good number, since it tells you given a new customer today, how many new customers will they bring in over the next week.

Basic Viral Math

The good news is, once you identify the specific product flows that allow users to reach non-users, it’s fairly easy to instrument and calculate a viral factor for a feature or even a site.  But what does the number really mean?

Let’s assume a viral factor of 0.5, and an N of 7.  If I get a new user today, then my user acquisition will look like this over the next few weeks:

1 + 0.5 + 0.25 + 0.125 ….

It’s an infinite series that adds up to 2.  By getting a new user, the virality of this feature will generate a second user over time.

Two obvious epiphanies here:

  • A viral factor is a multiplier for existing sources of user acquisition.  0.5 is a 2x, 0.66 is a 3x, etc.
  • Anything below 0.5 looks like a percentage multiplier at best.

What about a viral factor of 1.1?

One of the memes that started to circulate broadly in 2008 was getting your viral factor to “1.1”.  This was just a proxy for saying that your product or service would explode.  If you do the math, you can easily see that any viral factor or 1.0 or higher will lead to exponential growth resulting in quickly having every human on the planet on your service.

I don’t want to get into a Warp 10 debate, but products can in fact have viral factors above 1.0 for short periods of time, particularly when coming off a small base.

Learning from Rabbits

The key to understanding viral math is to remember a basic truth about rabbits.  Rabbits don’t have a lot of rabbits  because they have big litters.  Rabbits have a lot of rabbits because they breed frequently.

When trying to “spread” to other users, most developers just focus on branching factor – how many people they can get invited into their new system.  However, cycle time can be much more important than branching factor.

Think of a basic exponential equation: X to the Y power.

  • X is the branching factor, in each cycle how many new people do you spread to.
  • Y is the number of cycles you can execute in a given time period.

If you have a cycle that spreads to 10 people, but takes 7 days to replicate, in 4 weeks you’ll have something that looks like 10^3.  However, if you have a cycle that takes a day to replicate, even with a branching factor of 3 you’ll have 3^27.  Which would you rather have?

In real life, there is decay of different viral messages.  Branching factors can drop below 1.  The path to success is typically the combination of a high branching factor combined with a fast cycle time.

As per the last blog post, different platforms and traffic channels have different engagement patterns and implicit cycle times.  The fact that people check email and social feeds multiple times per day makes them excellent vectors for viral messages.  Unfortunately, the channels with the fastest cycle times also tend to have the fastest decay rates.  Fast cycle times plus temporary viral factors above 1 are how sites and features explode out of no where.

Executing on Product Virality

To design virality into your product, there really is a three step process:

  1. Clearly articulate and design out the features where members can touch non-members.  Wireframes and flows are sufficient.  Personally, I also recommend producing a simple mathematical model with some assumptions at each conversion point to sanity check that your product will produce a strong viral factor, layered over other traffic sources (the multiplier).
  2. Instrument those flows with the detailed metrics necessary for each step of the viral cycle to match your model.
  3. Develop, release, measure, iterate.  You may hit success your first time, but it’s not unusual to have to iterate 6-8 times to really get a strong viral factor under the best of conditions.  This is the place where the length of your product cycles matter.  Release an iteration every 2 days, and you might have success in 2 weeks.  Take 3-4 weeks per iteration, and it could be half a year before you nail your cycle.  Speed matters.

You don’t need hundreds of viral features to succeed.  In fact, most great social products only have a few that matter.

What about mobile?

Now that we’ve covered the five scalable sources of web traffic and the basics of viral factors, we’ll conclude next week with an analysis of what this framework implies for driving distribution for mobile web sites vs. native applications.

User Acquisition: The Five Sources of Traffic

/ Adam Nash / 12 Comments

This is the first post in a three post series on user acquisition.

The topic of this blog post may seem simplistic to those of you who have been in the trenches, working hard to grow visits and visitors to your site or application.  As basic as it sounds, however, it’s always surprising to me how valuable it is to think critically about exactly how people will discover your product.

In fact, it’s really quite simple.  There are only really five ways that people will visit your site on the web.

The Five Sources of Traffic

With all due apologies to Michael Porter, knowing the five sources of traffic to your site will likely be more important to your survival than the traditional five forces.  They are:

  1. Organic
  2. Email
  3. Search (SEO)
  4. Ads / Partnerships (SEM)
  5. Social (Feeds)

That’s  it.  If someone found your site, you can bet it happened in those five ways.

The fact that there are so few ways for traffic to reach your site at scale is both terrifying and exhilarating.  It’s terrifying because it makes you realize how few bullets there really are in your gun.  It’s exhilarating, however, because it can focus a small team on exactly which battles they need to win the war.

Organic Traffic

Organic traffic is generally the most valuable type of traffic you can acquire.  It is defined as visits that come straight to your site, with full intent.  Literally, people have bookmarked you or type your domain into their browser.  That full intent comes through in almost every produto metric.  They do more, click more, buy more, visit more, etc.  This traffic has the fewest dependencies on other sites or services?

The problem with organic traffic is that no one really knows how to generate more of it.  Put a product manager in charge of “moving organic traffic up” and you’ll see the fear in their eyes.  The truth is, organic traffic is a mix of brand, exposure, repetition, and precious space in the very limited space called “top of mind”.  I love word of mouth, and it’s amazing when it happens, but Don Draper has been convincing people that he knows how to generate it for half a century.

(I will note that native mobile applications have changed this dynamic, but will leave the detail for the third post in this series.)

Email Traffic

Everyone complains about the flood of email, but unfortunately, it seems unlikely to get better anytime soon.  Why?  Because it works.

One of the most scalable ways for traffic to find your site is through email.  Please note, I’m not talking about direct marketing emails.  I’m referring to product emails, email built into the interaction of a site.  A great example is the original “You’ve been outbid!” email that brought (and still brings) millions back to the eBay site every day.

Email scales, and it’s inherently personal in its best form.  It’s asynchronous, it can support rich content, and it can be rapidly A/B tested and optimized across an amazing number of dimensions.  The best product emails get excellent conversion rates, in fact, the social web has led to the discovery that person to person communication gets conversion person over 10x higher than traditional product emails.  The Year In Review email at LinkedIn actually received clickthroughs so high, it was better described as clicks-per-email!

The problem with email traffic generally is that it’s highly transactional, so converting that visit to something more than a one-action stop is significant. However, because you control the user experience of the origination the visit, you have a lot of opportunity to make it great.

Search Traffic

The realization that natural search can drive traffic to a website dates back to the 90s.  However, it really has been in the past decade in the shadow of Google that search engine optimization scaled to its massive current footprint.

Search clearly scales.  The problem really is that everyone figured this out a long time ago.  First, that means that you are competing with trillions of web pages across billions of queries.  You need to have unique, valuable content measured in the millions of pages to reach scale.  SEO has become a product and technical discipline all it’s own. Second, the platform you are optimizing for (Google, Microsoft) is unstable, as they constantly are in an arms race with the thousands of businesses trying to hijack that traffic. (I’m not even going to get into their own conflicts of interest.)

Search is big, and when you hit it, it will put an inflection point in your curve.  But there is rarely anysuch thing as “low hanging fruit” in this domain.

Advertising (SEM)

The fourth source of traffic is paid traffic, most commonly now ads purchased on Google or Facebook.  Companies spend billions every year on these ads, and those dollars drive billions of visits.  When I left eBay, they were spending nearly $250M a year on search advertising, so you can’t say it doesn’t scale.

The problem with advertising is really around two key economic negatives.  The first is cash flow.  In most cases, you’ll be forced to pay for your ads long before you realize the economic gains on your site.  Take something cash flow negative and scale it, and you will have problems.  Second, you have solid economics.  Most sites conjure a “lifetime value of a user” long before they have definitive proof of that value, let alone evidence that users acquired through advertising will behave the same way. It’s a hyper-competitive market, armed with weapons of mass destruction.  A dangerous cocktail, indeed.

While ads are generally the wrong way to source traffic for a modern social service, there are exceptions when the economics are solid and a certain volume of traffic is needed in a short time span to catalyze a network effect.  Zynga exemplified this thinking best when it used Facebook ads to turbocharge adoption and virality of their earlier games like FarmVille.

Social Traffic

The newest source of scalable traffic, social platforms like Facebook, LinkedIn and Twitter can be great way to reach users.  Each platform is different in content expectations, clickthrough and intent, but there is no question that social platforms are massively valuable as potential sources of traffic.

Social feeds have a number of elements in common with email, when done properly.  However, there are two key differences that make social still very difficult for most product teams to effectively use at scale.  The first is permission.  On social platforms, your application is always speaking through a user.  As a result, their intent, their voice, and their identity on the platform is incredibly important.  Unlike email, scaling social feed interactions means hitting a mixture of emotion and timing.  The second issue is one of conversion.  With email, you control an incredible number of variables: content, timing, frequency.  You also have a relatively high metrics around open rates, conversion, etc.  With social feeds, the dynamics around timing and graph density really matter, and in general it always feels harder to control.

The Power of Five

Eventually, at scale, your site will likely need to leverage all of the above traffic sources to hit its potential.  However, in the beginning, it’s often a thoughtful, deep success with just one of these that will represent your first inflection point.

The key to exponential, scalable distribution across these sources of traffic is often linked to virality, which is why that will be the topic of my next post.

Product Leaders: User Acquisition Series

/ Adam Nash / 8 Comments

I can be pedantic about user acquisition.  The truth is that consumer web and mobile applications are under increasing pressure to demonstrate explosive exponential traction.  Building a great product is no longer sufficient, lest you be left with the best product in the world that no one has discovered.

As an engineer and designer by training, I didn’t always put this level of focus on traffic acquisition.  It wasn’t until we tried to build an entirely new site under the eBay brand (eBay Express) that I was forced to focus our team’s efforts on one large fundamental challenge: traffic acquisition.

Those struggles, some successful (and some not) led me to appreciate how profoundly the social web changed the metrics of distribution.  When we founded the growth team at LinkedIn in 2008, we were able to structure our thinking around user acquisition, measure it, and bend the curve significantly for the site. 

A special thanks to both Reid Hoffman and Elliot Shmukler, who both contributed significantly to my thinking on the subject.

History is Written by the Victors

History is written by the victors, and on the consumer web, victory is often defined by market distribution.  Growth does not just happen, it has to be designed into your product and service.

The following posts attempt to capture some of the fundamentals that I’ve personally found useful to structure thinking around social user acquisition, and extend those concepts from the web to mobile applications:

Remember, Product Leaders win games.  Now let’s get started.

How to Make Great Green Beer for St. Patrick’s Day

/ Adam Nash / 2 Comments

You learn a lot of things at a hypergrowth startup, mostly by doing.  For some reason, I love St. Patrick’s Day. St. Patrick’s Day wasnt always a big event at LinkedIn, at least until we figured out how to make green beer.

It may sound trivial, but making a great green beer is surprisingly delightful.  Throw in a leprechaun hat, some Irish whiskey, and a warm afternoon, and you’ve got yourself a party.

Step 1: The Beer

We tried quite a few varieties, but what you are really looking for is a bright, vibrant yellow color to start with.   Most people were happiest with Corona, although Beck’s was also popular.  Wheat beers tend to be too cloudy, and anything darker tends to look swampy.

(Listen, I know Corona doesn’t scream Irish, but we’re going for effect here.)

Step 2: Supplies

Before you can have your event, you need to assemble the following:

  • Case(s) of beer.  Theoretically could get a keg, but our parties were never that big.
  • Bottle openers.
  • Clear, 16 ounce plastic cups.
  • Green food coloring, liquid.

Step 3: The Process

The workflow is simple, but this detail is important.

  1. Put two (not one, not three) drops of food coloring in the bottom of a cup
  2. Open the beer
  3. Pour liberally, to get good mixing and a bit of a head

That’s it.  The magic is that you get almost perfect color distribution pouring the beyou over the food coloring.  Adding the food coloring afterward, even with stirring, is a giant fail. You won’t get what you want.

The Results

Happy St. Patrick’s Day! 🍀

Review: Quicken 2007 for Mac OS X Lion

/ Adam Nash / 6 Comments

This is going to be a short post, but given the attention and page views that my posts on Quicken 2007 received, I thought this update worthwhile.

Previous Posts

Quicken 2007 for Mac OS X Lion Arrives

Last week, Intuit announced the availability of an anachronism: Quicken 2007 for Mac OS X Lion.  It sounds odd at first, given that we should really be talking about Quicken 2013 right about now, but it’s not a misprint.  This is Quicken 2007, magically enabled to actually load and run on Mac OS X Lion.  It’s like Intuit cloned a Wooly Mammoth, and put it in the New York Zoo.

The good news is that the software works as advertised.  I have a huge file, with data going back to 1994.  However, not only did it operate on the file seamlessly, the speed improvement over running it on a Mac Mini running Mac OS X Snow Leopard is significant.  Granted, my 8-core iMac likely explains that difference (and more), but the end result is the same.  Quicken.  Fast.  Functional.  Finally.

There are small bugs.  For example, some dialogs seems to have lost the ability to resize, or columns cannot be modified.  But very small issues.

Where is it, anyway?

If you go to the Intuit website, you’ll have a very hard time finding this product:

  • It’s not listed on the homepage
  • It’s not listed on the products page
  • It’s not listed on the page for Quicken for Mac
  • It’s not listed in the customer support documents (to my knowledge)
  • It doesn’t come up in site search

However, if you want to pay $14.95 for this little piece of magic (and given the comments on my previous posts, quite a few people will), then you can find it here:

Goodbye, Mac Mini

I have it on good authority that Intuit is working on adding the relevant & required investment functionality to Quicken Essentials for Mac to make it a true personal finance solution.  There is a lot of energy on the Intuit consumer team these days thanks to the infusion of the Mint.com team, and I’m optimistic that we’ll see a true fully features personal finance client based on the Cocoa-native Quicken Essentials eventually.

Top 10 Product Leadership Lessons

/ Adam Nash / 5 Comments

On Sunday, I was fortunate enough to give a talk at the 9th annual Harvard Business School Entrepreneurship Conference.  I’m trying to be better about posting the slides from these talks as they happen.

Context & Caveats

This talk is based substantially on a lecture I gave at LinkedIn on August 31, 2011.  It’s heavily based on the unique product, strategy and organizational issues that you see currently in fast moving, hyper growth, consumer-focused software companies.

At the same time, many of the higher level business and management issues discussed are fairly universal, so hopefully there is something useful here for anyone who is passionate about building organizations that build great products.

So take a look, and I look forward to the comments.  FWIW The Optimus Prime quotes are from this excellent list of Optimus Prime quotes for the workplace.

Be A Great Product Leader

Great Product Leaders Win Games

/ Adam Nash / 11 Comments

Being a great product leader is hard. Every organization and process is different, and in many cases you are responsible for the outcome without having the authority to enforce decisions. My recent blog post on Being a Great Product Leader was an attempt to capture the specifics of how to lead a great, cross-functional software team.

To scale a great team, however, you need more than just a list of roles and responsibilities. How you onboard new talent is as important for the long term health of your team as how you identify and hire them in the first place.

The Trials of Being a New Coach

When a sports team gets a new coach, there is some authority that comes with the role. You can immediately set standards for behavior & strategy – how the team is going to practice, what plays the team is going to run. That authority, however, tends to be short -lived. Before you know it, the team begins to focus on one thing: are we winning games?

Joining a new team as a product manager has the same dynamic. At most of the companies I’ve been a part of, there is this false sense of security that comes from process and organization. Sure, if you are technically fulfilling the role and responsibilities of a product manager, there is a certain amount of respect and authority initially. However, in the long term, teams want to win games, and in software that means products that people are proud of and products that move the needle.

So is there a pattern of behavior for new product managers that ensures long term success? I’ll argue yes, and for my new hires I boil it down to three phases:
2 weeks, 2 months, and 2 quarters.

Two Weeks

The first two weeks of a product manager are critical, because this is the window where a new leader can establish the most important aspect of the role: what game are we playing, and how do we keep score.

As a result, the first thing I lay out for new product manager is:

  • The company culture and organizational philosophy of the team. Why the company matters. Product/engineering partnership. Results oriented performance.
  • The current strategic frame for how their product fits into the overall strategy of the company.
  • The current metrics and milestones for the product they are taking over.
  • A set of frameworks for the roles & responsibilities of product managers. These include posts on being a great product leader, product prioritization, finding heat in design, etc.

In the first two weeks, a new product manager is expected to:

  • Thoroughly challenge and finalize the strategic frame for the area. Does the existing frame make sense, or is there a better game to be playing?
  • Thoroughly understand the existing product metrics, and identify new or different metrics needed to properly assess the success of the area (max: 3)
  • Reprioritize all existing and future ideas & concepts based on the above, a.k.a. the product roadmap.

In addition, the first two weeks is the time when a new product manager can physically sit down and meet all the other key product and engineering leaders in overlapping areas, to help them both have context for their product and more importantly establish communication channels across the company with other key leaders. Great product managers very often serve as efficient people routers, and knowing who to talk to is often as important as knowing what to do.

Two Months

Like medicine, theoretical knowledge will only get you so far as a product manager. At some point, you learn by doing. A team will tolerate theoretical discussion for a short while, but in the end, a new product manager needs to get their hands dirty.

Two months is too short a time to significantly move the needle, but it is enough time to run through a few release cycles. In the first two months, it’s crucial for a product manager to actually be responsible for something released to users. In addition, the first two months is the typical time frame for a new product manager to flesh out the “best idea” from the team on how to win.

Two months is enough time to:

  • Have identified key outstanding bugs or minor feature fixes that matter.
  • Led the design / specification of solutions to those issues, and see them go live.
  • Write their first product specification for a larger, more significant milestone for their area. This should be their highest priority project to “move the needle” as they’ve defined it for the team.

The first two months are crucial, because not only does it help the new team execute together and coalesce, but also put their stake in the ground on what their next big evolution will be. By leading the effort to place that bet, a product manager sets the team up for the type of success that hopefully will provide long term momentum for that product team.

Two Quarters

Six months is the window to get a cross-functional team into the positive, reinforcing cycle of ongoing success. At this point, the team has released both small and large features, and has meaningfully “moved the needle.”

This doesn’t mean, by the way, that the product manager led the launch of a single, monolithic all-or-nothing feature. In fact, what it most likely means is that the team launched a combination of iterative efforts to test out their theories and push through changes that in the aggregate validated the strategy and prioritization that had been put in place.

Great Product Leaders Win Games

Once teams have victories under their belt, in hyper-growth companies they gain both the desire to win again, and the confidence to execute on that desire. Creating that momentum is one of the hardest, and yet most valuable elements of cross-functional leadership.

This pattern has proven reliably consistent for my own product leadership efforts, as well as in differentiating the long term success of product managers I’ve hired and mentored.

In some ways, it’s really simple: great teams like winning, and great leaders reliably lead teams to great victories.

Now go out and win games.

How to Fix the Apple TV 2 “Blinking White Light of Death”

/ Adam Nash / 36 Comments

This is one of those public service announcement blog posts that I write whenever I run into a non-trivial technical problem.  My hope is always that the time I take to write this up will save someone time & money in the future.

The AppleTV 2 Blinking White Light of Death

Problem is simple: Your AppleTV 2 has a blinking white LED that never stops, and all it displays on the TV is an image instructing you to connect the device to iTunes.

Cause: Most likely, you interfered with a firmware update. In my case,  I had selected an option on my AppleTV 2 to update its firmware.  However, before it was complete, the power to the device was cut.

Mission: Find a Micro USB Cable

I didn’t realize it was possible to physically connect your AppleTV 2 to your computer.  This blog post was my first clue on what had caused my issue, and how to solve it.  Unfortunately, it sounded like he never was able to solve the problem directly.

It’s a bit strange that Apple decided to put a Micro USB port on the AppleTV 2.  However, after reading this support article on the Apple website, I was determined to try to fix it myself.

Finding a Micro USB cable turned out to be non-trivial.  To the casual observer, the Micro USB and the Mini USB look very similar.  The Mini USB is used by Blackerries, hard drives, and countless devices.  The Micro USB port is a bit smaller, flatter, and more oval.

Apple actually does not carry the cable in store, although you can get one online.  The trick was finding a device that uses the Micro USB.  In my case, I found them stocked next to the Sony eReader.

iTunes Saves the Day

I plugged the new Micro USB cable into a powered USB 2.0 hub.  Given some of the issues reported by others, I suspect that it’s possible that the power draw of the AppleTV might be a bit more than typical USB ports can handle.  In any case, the Apple TV showed up in iTunes 10.5.x.  I clicked the “Restore” button, and a couple of minutes later it was done.

No issues at all with the device – it was literally reset to a factory clean state.

Since an overwhelming number of support articles and comments I found online suggested that this didn’t or wouldn’t work, I thought I’d put this blog post out there.  Hopefully it will help someone in their hour of need.

 

 

Apple, Cisco, and Dow 15000

/ Adam Nash / 49 Comments

I was driving home on Sunday, listening to the radio, and it occurred to me how different the financial news would be if Apple ($AAPL) was in the Dow Jones Industrial Average (^DJI).

Of course, being who I am, I went home and built a spreadsheet to recalculate what would have happened if Dow Jones had decided to add Apple to the index instead of Cisco back in 2009.  Imagine my surprise to see that the Dow be over 2000 points higher.

In real life, the Dow closed at 12,874.04 on Feb 13, 2012.  However, if they had added Apple instead of Cisco, the Dow Jones would be at 14,926.95.  That’s over 800 points higher than the all-time high of 14,164 previously set on 4/7/2008.

Can you imagine what the daily financial news of this country would be if every day the Dow Jones was hitting an all-time high?  How would it change the tone of our politics? Would we all be counting the moments to Dow 15,000?

Why Cisco vs. Apple?

This isn’t a foolhardy exercise.  The Dow Jones Industrial Average is changed very rarely, in order to promote stability and comparability in the index.  However, on June 8, 2009, they made two changes to the index:

  • They replaced Citigroup with Travelers
  • They replaced General Motors with Cisco

The question I explored was simple – what would have happened if they had replaced General Motors with Apple on June 8, 2009.  After all, Apple was up over 80% off its lows post-crash.  The company had a large, but not overwhelming market capitalization.  The index is already filled with “big iron” tech stocks, like Intel, HP & IBM.  Why add Cisco?  Why not add a consumer tech name instead?

In fact, there is no readily obvious justification for adding Cisco to the index in 2009 instead of Apple.

The Basics of the Dow Jones Industrial Average

Look, I’m just going to say it. The Dow Jones Industrial Average is ridiculous.

You may not realize this, but the Dow Jones Industrial Average, the “Dow” that everyone quotes as representative of the US stock market, and sometimes even a barometer of the US economy, is a mathematical farce.

Just thirty stocks, hand picked by committee by Dow Jones, with no rigorous requirements.  Worse, it’s a “price-weighted” index, which is mathematically nonsensical.  When calculating the Dow Jones Industrial Average, they take the actual stock prices of each stock, add them together, and divide them by a “Dow Divisor“.  They don’t take into account how many shares outstanding; they don’t assess the market capitalization of each company.  When a stock splits, they actually change the divisor for the whole index.  It’s completely unclear what this index is designed to measure, other than financial illiteracy.

In fact, there is only one justification for the Dow Jones Industrial Average being calculated this way.  Dow Jones explains it in this post on why Apple & Google are not included in the index.  To save you some time, I’ll summarize: they have always done it this way, and if they change it, then they won’t be able to compare today’s nonsensical index to the nonsensical index from the last 100+ years.

So what? Does it really matter?

It’s a fair critique.  Look, with 20/20 hindsight, there are limitless number of changes we could make to the index to change its value.  Imagine adding Microsoft and Intel to the index in 1991 instead of 1999?

I don’t think this exercise is that trivial in this case.  The Dow already decided to make a change in 2009.  They decided to replace a manufacturing company (GM) with a large hardware technology company (CSCO).  They could have easily picked Apple instead.

The end result?  People talk about the stock market still being “significantly off its highs” of 2008.  In truth, no one should be reporting the value of the Dow Jones Industrial Average.  But they do, and therefore it matters.  As a result, the choices of the Dow Jones committee matter, and unfortunately, there seems to be no accountability for those choices.

Appendix: The Numbers

I’ve provided below the actual tables used for my calculations.  Please note that all security prices are calculated as of market close on Monday, Feb 13, 2012.  The new Dow Divisor for the alternate reality with AAPL in the index was calculated by recalculating the appropriate Dow Divisor for the 6/8/2009 switch of AAPL for CSCO, and a recalculated adjustment for the VZ spinoff on 7/2/2010.

Real DJIA DJIA w/ AAPL on 6/8/09
Company 2/13/2012 Company 2/13/2012
MMM 88.03 MMM 88.03
AA 10.33 AA 10.33
AXP 52.07 AXP 52.07
T 30.04 T 30.04
BAC 8.25 BAC 8.25
BA 74.85 BA 74.85
CAT 113.70 CAT 113.70
CVX 106.38 CVX 106.38
CSCO 20.03 AAPL 502.60
KO 68.44 KO 68.44
DD 50.60 DD 50.60
XOM 84.42 XOM 84.42
GE 19.07 GE 19.07
HPQ 28.75 HPQ 28.75
HD 45.93 HD 45.93
INTC 26.70 INTC 26.70
IBM 192.62 IBM 192.62
JNJ 64.68 JNJ 64.68
JPM 38.30 JPM 38.30
KFT 38.40 KFT 38.40
MCD 99.65 MCD 99.65
MRK 38.11 MRK 38.11
MSFT 30.58 MSFT 30.58
PFE 21.30 PFE 21.30
PG 64.23 PG 64.23
TRV 58.99 TRV 58.99
UTX 84.88 UTX 84.88
VZ 38.13 VZ 38.13
WMT 61.79 WMT 61.79
DIS 41.79 DIS 41.79
Total 1701.04 Total 2183.61
Divisor 0.13212949 Divisor 0.146286415
Index 12874.04 Index 14926.95

Calculating the “alternate divisor” requires getting the daily stock quotes for the days where the index changed, and recalculating to make sure that the new divisor with the new stocks gives the same price for the day. It’s a bit messy, and depends on public quote data, so please feel free to check my math if I made a mistake.