Product Management

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.

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.

Pinterest & LinkedIn: Identity of Taste vs. Expertise

/ Adam Nash / 4 Comments

It’s hard to go three feet in Silicon Valley these days without someone commenting on the phenomenal engagement and growth being seen from Pinterest and other curation-based social platforms.  What’s a bit surprising to me, however, is how many people refer to this demand as a growing interest and search for “expertise”.

As I have a passion for finding a more human understanding for what drives engagement in real life and then mapping it to online behavior, I think the use of the term “expertise” here is misleading.  Instead, I believe what we are seeing is an explosion of activity around an incredibly powerful form of identity and reputation: the identity of taste.

Expertise is Empirical

If you go to LinkedIn, you see a site that is rich with the identity of expertise.  LinkedIn has rich structured data around sources of expertise: degrees, schools, companies, titles, patents, published content, skills.  They also have rich sources of unstructured content about job responsibilities, specialties, questions & answers, group participation, status updates and comments.  There are even implicit indications of expertise related to other online identities (like Twitter) and relationships to other people with expertise (connections).

This expertise can be tapped by using LinkedIn’s incredibly powerful search engine, either on site or via API, or by browsing the talent graph displayed in catalog form on LinkedIn Skills.  Github has created a powerful identity for developers based on their actual interests and contributions in code.  Blogs, Tumblr, Quora and Twitter have helped people create identities based on the content they create and share.

The power of identity based on expertise is that it is concretely demonstrated.  Education, experience, content and relationships are all very structured and concrete methods for measuring and assessing expertise.  However, in some ways, expertise is limited by it’s literal nature.  Factual. Demonstrable. Empirical.

Taste is Inspiring

Pinterest, however, has unlocked an incredibly powerful form of reputation and identity that exists in the offline world – an identity of taste.  People don’t care about the expertise of people who are assembling pinboards.  They care about how those combinations make them feel – the concept, the aggregation, the flow of additions.  The Pinboard graph begins for most people with their friends, but people quickly learn to hop based on sources to people they don’t know, finding beautiful, interesting, intriguing or inspiring collections of images.

This isn’t an identity based on expertise, really.  It’s not even clear how closely related it is to a graph of interests. Curation-based social platforms evoke a different phenomenon, and with it, some very powerful emotions and social behaviors.

Taste is different than expertise.  Taste does not imply that you are a good person or a deep well of expertise on the domain.  Taste is not universal, although there are certainly those with a predilection for influencing and/or predicting the changes in taste for many.  But when we as human beings find people whose taste inspires us, it’s a powerful relationship.  We map positive attributes to them, ranging from kindness to intelligence to even authority.  Fame & taste are often intertwined.

You Are What You Curate

Curation-based social platforms are based on the interaction of three key factors:

  1. A rich, visual identity and reputation based on curated content
  2. An asymmetric graph based on not only following people, but specific feeds of curated content
  3. A rich, visual activity stream of curation activity

It’s the first item that I seem to see most under-appreciated.  Vanity, as one of the most common deadly sins in social software, drives an incredible amount of engagement and activity.  As people are inspired by those who create beautiful identities of curated content, they also become keenly aware of how their curated identity looks.  When people signal an appreciation for their taste, it triggers power social impulses, likely built up at an early age.

This, more than anything else, reflects the major step function in engagement of this generation of curation over previous attempts (anyone remember Amazon Lists?)

How Does Taste Factor into Your Experience?

I always like to translate these insights into actionable questions for product designers.  In this case, these are some good starting points:

  • How does taste factor into your experience?
  • Is the identity in your product better served by reputation based on taste or expertise?
  • Are the relationships in your product between users based on taste or expertise?
  • Are you creating an identity visually and emotionally powerful enough to trigger curation activity?
  • Are you flowing curation activity through your experience in a way that stimulates discovery and the creation of an identity of taste?

Don’t underestimate the power of good taste.

Be a Great Product Leader

/ Adam Nash / 28 Comments

People who know me professionally know that I’m passionate about Product Management.  I truly believe that, done properly, a strong product leader acts as a force multiplier that can help a cross-functional team of great technologies and designers do their best work.

Unfortunately, the job description of a product manager tends to either be overly vague (you are responsible for the product) or overly specific (you write product specifications).  Neither, as it turns out, is it effective in helping people become great product managers.

I’ve spent a lot of time trying to figure out a way to communicate the value of a product manager in a way that both transparently tells cross-functional partners what they should expect (or demand) from their product leaders, and also communicates to new product managers what the actual expectations of their job are.  Over the years, I reduced that communication to just three sets of responsibilities: Strategy, Prioritization & Execution.

Responsibility #1: Product Strategy

They teach entire courses on strategy at top tier business schools.  I doubt, however, that you’ll hear Product Strategy discussed in this way in any of them.

Quite simply, it’s the product manager’s job to articulate two simple things:

  • What game are we playing?
  • How do we keep score?

Do these two things right, and all of a sudden a collection of brilliant individual contributors with talents in engineering, operations, quality, design and marketing will start running in the same direction.  Without it, no amount of prioritization or execution management will save you.  Building great software requires a variety of talents, and key innovative ideas can come from anywhere.  Clearly describing the game your playing and the metrics you use to judge success allows the team, independent of the product manager, to sort through different ideas and decide which ones are worth acting on.

Clearly defining what game you are playing includes your vision for the product, the value you provide your customer, and your differentiated advantage over competitors.  More importantly, however, is that it clearly articulates the way that your team is going to win in the market.  Assuming you pick your metrics appropriately, everyone on the team should have a clear idea of what winning means.

You should be able to ask any product manager who has been on the job for two weeks these questions, and get not just a crisp, but a compelling answer to these two questions.

The result: aligned effort, better motivation, innovative ideas, and products that move the needle.

Responsibility #2: Prioritization

Once the team knows what game they are playing and how to keep score, it tends to make prioritization much easier.  This is the second set of responsibilities for a product manager – ensuring that their initial work on their strategy and metrics is carried through to the phasing of projects / features to work on.

At any company with great talent, there will be a surplus of good ideas.  This actually doesn’t get better with scale, because as you add more people to a company they tend to bring even more ideas about what is and isn’t possible.  As a result, brutal prioritization is a fact of life.

The question isn’t what is the best list of ideas you can come up with for the business – the question is what are the next three things the team is going to execute on and nail.

Phasing is a crucial part of any entrepreneurial endeavor – most products and companies fail not for lack of great ideas, but based on mistaking which ones are critical to execute on first, and which can wait until later.

Personally, I don’t believe linear prioritization is effective in the long term.  I’ve written a separate post on product prioritization called The Three Buckets that explains the process that I advocate.

You should be able to ask any product manager who has been on the job for two weeks for a prioritized list of the projects their team is working on, with a clear rationale for prioritization that the entire team understands and supports.

Responsibility #3: Execution

Product managers, in practice, actually do hundreds of different things.

In the end, product managers ship, and that means that product managers cover whatever gaps in the process that need to be covered.  Sometimes they author content.  Sometimes they cover holes in design.  Sometimes they are QA.  Sometimes they do PR.  Anything that needs to be done to make the product successful they do, within the limits of human capability.

However, there are parts of execution that are massively important to the team, and without them, execution becomes extremely inefficient:

  • Product specification – the necessary level of detail to ensure clarity about what the team is building.
  • Edge case decisions – very often, unexpected and complicated edge cases come up.  Typically, the product manager is on the line to quickly triage those decisions for potentially ramifications to other parts of the product.
  • Project management – there are always expectations for time / benefit trade-offs with any feature.  A lot of these calls end up being forced during a production cycle, and the product manager has to be a couple steps ahead of potential issues to ensure that the final product strikes the right balance of time to market and success in the market.
  • Analytics – in the end, the team largely depends on the product manager to have run the numbers, and have the detail on what pieces of the feature are critical to hitting the goals for the feature.  They also expect the product manager to have a deep understanding of the performance of existing features (and competitor features), if any.

Make Things Happen

In the end, great product managers make things happen.  Reliably, and without fail, you can always tell when you’ve added a great product manager to a team versus a mediocre one, because very quickly things start happening.  Bug fixes and feature fixes start shipping.  Crisp analysis of the data appears.  Projects are re-prioritized.  And within short order, the key numbers start moving up and to the right.

Be a great product leader.

This work is licensed under a Creative Commons Attribution 3.0 Unported License.

Steve Jobs, BMW & eBay

/ Adam Nash / 33 Comments

There have been so many articles posted on Steve Jobs in the past week, I really thought I wasn’t going to add one here on my blog.

However, yesterday, John Lilly wrote a great piece on Steve Jobs yesterday, and I realized I might have a story worth telling after all.  I find myself fortunate, in retrospect, to have joined Apple in 1996 as an intern, and then full time in 1997 just weeks before Steve Jobs took the helm as interim CEO.

A Tale of Two Meetings

As an outgoing intern of the Advanced Technology Group, I actually did attend the meeting that John describes in his blog post.  However, as a full time engineer on WebObjects, I also had the opportunity to attend a different all hands that Steve Jobs called for the entire Rhapsody team (the codename of the project that became Mac OS X).

If you haven’t read John’s post, it’s definitely worth reading in tandem with this one.  He does a great job capturing the insights from the ATG meeting.  Instead, let me add to the story with my recollection of the Rhapsody meeting that happened the same week.

(Note: It has been over fourteen years since the meeting, so don’t take this as a literal play-by-play.  I have no notes, so all quotes are from memory.  But this is how I remember it.)

The “Michael Dell” Meeting

The mood of the Rhapsody team meeting was energetic, but mixed.  More than any other group at Apple, the Rhapsody team required a combination of talent from both long time Apple engineers and newly merged NeXT engineers.  There was a palpable sense of excitement in the room, as particularly the NeXT team had a huge amount of respect for the “incoming administration”.  At the same time, there was an element of discontent around suddenly finding themselves part of a large company, and even some skepticism that Apple was salvageable.

Steve got on stage at the front of the room in Infinite Loop 4, and put a huge, larger than life picture of Michael Dell on the wall.  He repeated the news fodder that Michael Dell had been asked recently what he would do if he was running Apple Computer.  (At the time, Dell was the ultimate success story in the PC industry.)  Dell said that he would liquidate the company and return the cash to shareholders.

A few gasps, a few jeers and some general murmuring in the audience.  But I don’t think they expected what he said next.

And you know what? He’s right.

The world doesn’t need another Dell or HP.  It doesn’t need another manufacturer of plain, beige, boring PCs.  If that’s all we’re going to do, then we should really pack up now.

But we’re lucky, because Apple has a purpose.  Unlike anyone in the industry, people want us to make products that they love.  In fact, more than love.  Our job is to make products that people lust for.  That’s what Apple is meant to be.

What’s BMW’s market share of the auto market?  Does anyone know?  Well, it’s less than 2%, but no one cares.  Why?  Because either you drive a BMW or you stare at the new one driving by.  If we do our job, we’ll make products that people lust after, and no one will care about our market share.

Apple is a start-up.  Granted, it’s a startup with $6B in revenue, but that can and will go in an instant.  If you are here for a cushy 9-to-5 job, then that’s OK, but you should go.  We’re going to make sure everyone has stock options, and that they are oriented towards the long term.  If you need a big salary and bonus, then that’s OK, but you should go.  This isn’t going to be that place.  There are plenty of companies like that in the Valley.  This is going to be hard work, possibly the hardest you’ve ever done.  But if we do it right, it’s going to be worth it.

He then clicked through to a giant bullseye overlayed on Michael Dell’s face.

I don’t care what Michael Dell thinks.  If we do our job, he’ll be wrong.  Let’s prove him wrong.

All I can remember is thinking: “Wow. Now that’s how you regroup, refocus and set a company in motion.”  I had seen speeches by Gil Amelio in 1996, and there was nothing comparable.  Please remember, at this point in time it wasn’t at all obvious that Steve or Apple would actually succeed. But I felt like I’d witnessed a little piece of history.

Fast Forward: eBay 2006

That meeting left a huge impression on me that extended well beyond Apple.  Steve’s actions and words at Apple in 1997 represented the absolute best in leadership for a turnaround situation.

It wasn’t until 2006, however, that I found myself at another large technology company looking to rediscover itself.  In the summer of 2006, I was one of a relatively small number of product leaders to tour a draft of a new initiative at eBay called “eBay 3.0”.  Led by the marketing team, a small, strong team had done a lot of research on what made eBay different, and what people wanted from the eBay brand.  The answer was that eBay was fun, full of serendipity, emotion, thrill.  The competition of auctions, the surprise at discovering something you didn’t know existed.  This reduced into a strong pitch for eBay as “colorful commerce”.

I was excited about the research and the work, because it echoed some of the things I remembered about Steve & Apple, and the simple vision he had for a company that made products that people lusted for.  But I also remember voicing a strong concern to several members of the team.  I told them about Steve’s speech to the Rhapsody team, and asked: “Does eBay want BMW market share, or Toyota market share?”  At the time, eBay was more than 20% of all e-commerce, and all plans oriented towards growing that market share.

Unfortunately, eBay tried to do both with the same product.

It’s not typical for a large, successful public company to basically say market share doesn’t matter, and to drive a company purely around a simple focus and vision.  When things are the toughest, unfortunately, that’s when leadership and vision matter the most.

Final Thoughts

Who would have imagined that Apple would have the largest market capitalization in the world?  Who would have thought that in the year 2011 that Apple – not Microsoft, not Dell, not Sony – would be defining the market for so many digital devices and services?

Most importantly, who would have thought that a leadership mandate that eschewed market share would achieve such dramatic gains?

Apple so easily could have gone the way of SGI, the way of Sun.  Instead, it literally shapes the future of the industry.  All because in 1997 Steve was able to offer a simple and compelling reason for Apple to exist.  A purpose.  And it’s a purpose that managed to aggregate some of the most talented people in the world to do some of their best work.  Again and again.

So I will add here a simple thank you to Steve Jobs for that meeting, and for changing the way that I think about every company’s purpose – their reason to exist.  Rest in Peace, Steve.

Joining Greylock

/ Adam Nash / 5 Comments

Today, John Lilly put up a really nice note on the Greylock Partners blog officially welcoming me to the firm.  Needless to say, I’m both honored and excited to be joining such a great team.

We’re fortunate to be witnessing the explosive growth of not one but two incredible new platforms for consumer products and services: social and mobile.  Both are literally changing the fundamental ways that consumers interact with devices, and are rapidly changing the dynamics for building successful new products and services.  After spending the past four years helping to build out social and mobile platforms, I can’t wait to partner with entrepreneurs to help them build out the next generation of products and companies over them.

Over the past few years, I’ve shared a number of insights here on this blog about building great products and companies.  Here are a few that are worth reading if you are curious about how I think:

And of course, the most appropriate for this announcement:

For now, I just want to say thank you to Reid, David, John and the entire Greylock team.  I can’t wait to get started.

Designers: Getting the Most Out of Your Product Manager

/ Adam Nash / 4 Comments

I gave a lighthearted talk yesterday at the LinkedIn User Experience team’s all hands meeting. I called it “Getting the Most Out of Your Product Manager”, and it was intended to talk from the perspective of someone who has lived in both of the HCI (Human Computer Interaction) & PM (Product Management) worlds.  The goal of the deck was simple – by explaining to designers and user experience professionals what makes a great product manager and how they are held accountable, it more obvious why occassionally PMs & Designers can clash.

There are some inside jokes so it might not be as funny to everyone, but it was popular enough that I thought I’d share it here.

As a side note, it was truly amazing to see such a large and amazingly talented group of designers and web developers arranged together.  Incredible validation of a simple truth – that if you want great user experience, you need to foster a culture and process that not only attracts the best talent, but also lets them do their best work.

It’s hard to believe that it was only in 2007 that we started down the path of having a formal UED team at LinkedIn.  When you see products like the recent LinkedIn mobile products, it’s worth remembering that great designs come from great teams.

 

LinkedIn as a Platform

/ Adam Nash / 2 Comments

From the first conversations that I had with Reid Hoffman about LinkedIn, what was striking was the amazing clarity about how value is created by social web properties.  Those conversations turned into one of my favorite talks, where I walk through the basic understanding of LinkedIn as a Platform business for students and new hires.

Since it’s a such a popular framework, I thought I’d capture an outline of it here so that others can benefit from it.  There is nothing here that won’t be familiar to industry insiders and folks who focus on social software.  However, I’ve found that most people, especially technologists who have not had first hand experience with social platforms, seem to find this useful & interesting.

LinkedIn as a Platform

I started my career as a software engineer, and as a result, I’ve always had a very technical view of what defines a platform.  Across multiple decades, platforms tended to be defined by technical constructs: entities and services that are exposed to software developers.

What’s most interesting about the social web is that, for the first time, technology is necessary but insufficient to deliver a successful platform.  So while LinkedIn is a technology company and great technology is a prerequisite for a great platform, it’s important to understand that in this generation great technology alone won’t ensure success.

Why the Social Web is Different

The reason why technology alone isn’t sufficient is due to the simple fact that on the social web, the true value of the platform extends from the users themselves.

First and foremost, users interact with each other.  At LinkedIn, the very first type of interaction was the simple act of connecting.  If you look at Web 1.0 companies, they spend an inordinate amount of money on user acquisition.  On social properties, user acquisition is effectively free because users generate activity, and that activity brings in other users.  This activity can be an invitation, a message, a comment, a like – any way that one person can reach out and contact another user.  More importantly, as a metrics-oriented product manager I can tell you, the likelihood that a person will respond to another person is easily an order of magnitude (10x+) higher than the response rates of a person to a company.  (Just think about your inbox and you’ll see it’s obviously true.)

What’s interesting about all of this user activity is that, in fact, activity itself is a form of content.  When someone responds in a group, comments on a status update, votes on a poll, or answers a question, they don’t just interact with other users – they also create content.  That content, as it turns out, becomes a catalyst for other people to engage and interact.

In fact, one of the primary aspects of a social platform is that users generate content.  Once again, looking back at the Web 1.0 generation of websites, content creation was one of the most challenging things to economically scale.  On social websites, users generate the bulk of the content.  What’s more, that content itself drives additional users to the site.  For example, the very first type of content that users created at LinkedIn was their professional profile.  Users discover this content via search engines, applications, and social distribution, and they join LinkedIn to engage with that content.

When developers want to connect with the LinkedIn platform, whether they are giant companies like Microsoft and SAP or tiny startups, the technology is just the means.  What they really want to connect to is this incredible engine of professionals, content, and activity.  It’s this vibrant, circulating, and growing engine of content that developers want to connect to.  This entire engine is really the LinkedIn platform.

Businesses Built Over the Platform

LinkedIn has had an open developer platform since late 2009, but it was in very early days that the company realized that it was fundamentally a platform business.

Despite it’s popular reputation as a site that has always made money, for the first few years LinkedIn did not focus on monetization at all.  There was always a high degree of confidence that if you could aggregate the world’s professionals and understand their reputations and relationships, it would be a new and incredibly valuable ecosystem.  However, around 2005 and into 2006, LinkedIn began experimenting with a few different theories on what the best way to build a sustainable business over this platform.

One theory was that, when you pull together a huge number of professionals, there would be an opportunity for hiring managers and companies to find great talent.  This was the precursor to the “Hiring Solutions” family of products.

Another theory was that, when you pull together a huge number of professionals, there would be an opportunity for companies to reach professionals with their products and services.  This was the precursor to the “Marketing Solutions” family of products.

Yet another theory was that there would be a small percentage of power users who would be willing to pay money for additional search and communications capabilities.  This was the precursor to the “Subscriptions” family of products.

Now, all of this pre-dates my joining the company, but what is truly amazing about this story is that, very quickly, all of these businesses worked.  And by worked, I mean they started immediately generating interesting and growing revenue.  This is also why LinkedIn slammed to positive cash flow so early in its history, and why the first party I got to attend when I joined the company was the “In the Black” party where the company celebrated that milestone.  (It was a good party.)

I can’t tell you how unique it is to have a technology startup that finds not one, but three potentially huge revenue streams early in its history.  In fact, most venture capitalists tend to prefer that companies find a single business model to execute against.

But the truth is, this was the catalyst for realizing an important fundamental truth: the LinkedIn platform is an incredibly powerful and valuable ecosystem, and that multiple great businesses can (and will continue) be built over it.

Where LinkedIn Spends Most of Its Time

One of the great things about LinkedIn as a company is that there is incredible alignment across the company about how our ecosystem creates value.  The value comes from the vibrancy of the professional network itself.

This is why, across the company, you’ll see that the vast majority of energy is spent on figuring out how to leverage this platform of professional identity and insights to make LinkedIn more useful, more often to professionals globally.  It turns out that the more professionals, the more activity, the more content created, the more value is created for all of LinkedIn’s businesses.

This is why LinkedIn puts their members first.  Our job is to connect the world’s professionals, and make them more productive and successful.  The rest follows.

Extending LinkedIn Across the Web

As LinkedIn extends itself as a true professional operating system for the web, the incredible volume and velocity of professional identity and insights will provide value to a whole new generate of web, desktop, mobile and enterprise applications.

How to Make a Great T-Shirt: Metrics

/ Adam Nash / 6 Comments

This is the third post in my series on “How to Make a Great Tech T-Shirt“.

Define Success to Achieve Success

On the consumer web, product managers succeed and fail based on their ability to define, measure and understand their product metrics.  When new Product Managers start at LinkedIn, one of the first tasks that I give them is to thoroughly reassess the metrics in the area they are taking over, and prepare a new set of metrics that they will use to measure success with their area on an ongoing basis.

As a result, it’s not completely surprising that I believe that if you want to make great t-shirts for a technology organization, you have to first define a clean, objective measure of success.  You then have to experiment, measure, learn and iterate to produce truly great t-shirts.

Key Metrics: T-Shirt Success

The key to a good metric is simple.  Objectivity.  The problem with t-shirts is that *everyone* has an opinion about what they want in a t-shirt.  Unfortunately, almost no one has ever tested out their pet theories in an objective way.  Thus, T-Shirt choices get made based on the personal opinions of the people making them, rather than what will be most successful for the organization.

Over my years of making t-shirts at LinkedIn, I’ve narrowed my success metrics to a simple measure:

  • What percent of people who received a t-shirt wear it after a 1 month, 3 month, 6 month, and 12 month time periods

That’s a lot to absorb, but it’s really quite simple.  Let’s say you made 100 t-shirts in October 2009:

  • How many people wore your t-shirt to work in November 2009?
  • How many people wore your t-shirt to work in January/April/October 2010?

Clearly, if the more people wearing your shirt on an ongoing basis, the more successful your shirt was at achieving its objectives.

If You Make A T-Shirt and No One Wears It…

  • Q: If a tree falls in the woods and no one is there to hear it, did it make a sound?  (A: yes)
  • Q: If you make a t-shirt and no one wears it, was it worthwhile to make a shirt? (A: no)

In my blog post, Why T-Shirts Matter, I outlined over half a dozen reasons why t-shirts are important to technology organizations.  None of those justifications come true, however, if no one wears the t-shirt.  That’s why success is defined by how often people wear the t-shirt, and for how long.

If you’ve made t-shirts before, then you probably recognize the pattern of failure.  In the failure case, everyone takes a t-shirt, but somehow, you never see people wear them around the office.  Sure, maybe a couple people wore them the day after you handed them out.  But a few weeks later, it’s like they never existed.  When you ask about them, people tell you “Oh, I wear it on the weekend” or “I use it for the gym”.  Listen, let’s be honest.  A lot more people in technology talk about going to the gym than actually doing it.  These are the white lies people tell you to avoid telling you the truth: “I took a t-shirt because, for some uncontrollable reason, I have to take any t-shirt that is offered.  But I’m never going to wear it.”

Experiment With Your Shirts

You should be making at least one new t-shirt per quarter for your technology organization, so you have time to learn and experiment.  As we go through the upcoming blog posts on t-shirt quality and design, you’ll see that there are a variety of choices.  There is no one universal answer, but if you are attentive to what t-shirts “work” in your organization, you’re more likely to make new t-shirts that work.

For example:

  • Should you make women’s sizes?  The answer is simple – if it increases the number of people who will wear the shirts to the office and for longer, then yes, you should.  (At LinkedIn, this is absolutely true.)
  • Are certain colors more successful than others?  Absolutely.  (At LinkedIn, the best colors are black, navy, charcoal grey, and heather grey).
  • Should you spend more on higher quality t-shirt manufacturers and materials?  Absolutely.  T-Shirts that go bad quickly or shrink end up never getting worn.  Better to spend $12 for shirts you’ll see for the next two years than $5 on shirts you won’t see again.

I think the more you think about the simplicity of this metric, the more you’ll see that it will help you quickly spot at your workplace what are the shirts people love, and thus which shirts were worth the time & money.

 

Proposed Solution: Quicken 2007 & Mac OS X Lion

/ Adam Nash / 53 Comments

Right away, you should know something about me.  I am a die-hard Quicken user.  I’ve been using Quicken on the Mac since 1994, which happens to be the point in time where I decided that controlling my personal finances was fundamentally important.  In fact, one of my most popular blog posts is about how to hack in and fix a rather arcane (but common) issue with Quicken 2007.

So it pains me to write this blog post, because the situation with Quicken for the Mac has become extremely dire.  Intuit has really backed themselves into a corner, and not surprisingly, Apple has no interest in bailing them out.  However, since I love the Mac, and I love Quicken, I’m desperately looking for a way out of this problem.

Problem: Mac OS X Lion (10.7) is imminent

Yesterday, I got this email from Intuit:

It links to this blog post on the Intuit site.  The options are not pretty:

  1. You can switch to Quicken Essentials for Mac.  It’s a great new application written from the ground up.  In their words, “this option is ideal if you do not track investment transactions and history, use online bill pay or rely on specific reports that might not be present in Quicken Essentials for Mac.” Um, sorry, who in their right mind doesn’t want to track “investment transactions”?  Turns out, at tax time, knowing the details of what you bought, at what price, and when are kind of important.  At least, the IRS thinks so.  And they can put you in jail and take everything you own.  So I’m going with them on this one.  No dice.
  2. You can switch to Mint.  I love Mint, and I’ve been using it for years.  But once again, “This option is ideal if maintaining your transaction history is not important to you.”  Yeesh.  For me, Mint is something I use in addition to Quicken.  Unfortunately, Mint is basically blind to anything it can’t integrate with online.  Which includes my 401k, for example.
  3. You can switch to Quicken for Windows.  Seriously? 1999 called and they want their advice back.  Switch to Windows?  Intuit would get a better response here if they just sent Mac users a picture of a huge middle finger.  By the way, to add insult to injury:  “You can easily convert your Quicken Mac data with the exception of Investment transaction history. You will need to either re-download your investment transactions or manually enter them.”

This is an epic disaster.  I’m not sure how many people are actually affected.  But the Trojan War involved tens of thousands of troops, so I’m going with Homer’s definition of “Epic”.

What’s the Problem?

There are really three issues at play here:

  1. Strike 1. Around 2000, Intuit made the mistake of abandoning the Mac.  Hey, they thought it was the prudent thing to do then.  After all, Apple was dying.  (The bar talk between Adobe & Intuit on this mistake must be really fun a few drinks into the evening.)  Whoops.  This led Intuit to massively under-invest in their Mac codebase, yielding a monstrosity that apparently no one in their right mind wants to touch.  From everything I hear, Quicken 2007 for the Mac might as well be written in Fortran and require punch cards to compile.  Untouchable.  Untouchable, unfortunately, means unfixable.
  2. Strike 2. Sometime in the past few years, someone decided that Quicken Essentials for the Mac didn’t need to track investment transactions properly.  I’ve spent more than a decade in software product management, so I have compassion for how hard that decision must have been.  But in the end, it was a very expensive decision, and even if it was necessary, it should have mandated a fast follow with that capability.  It’s a bizarre miss given that tracking investment transactions is a basic tax requirement.  (See note on the IRS above)
  3. Strike 3.  Apple announces the move from PowerPC chips to Intel chips in June 2005.  Yes, that’s *six* years ago.  Fast forward to June 2011, and Apple announces that their latest operating system, Mac OS X Lion, will not support the backwards compatibility software to allow PowerPC applications to run on Intel Macs.

Uh oh.

This is Intuit’s Fault.

With all due respect to my good friends at Intuit, this problem is really Intuit’s fault.  Intuit had six years to make this migration, and to be honest, Apple is rarely the type of company to support long transitions like this.  You are talking about the company that killed floppy drives almost immediately in favor of USB in 2000, with no warning.  They dropped support for Mac OS Classic in just a few years.  It’s not like Apple was going back to PowerPC.

If you examine the three strikes, you see that Intuit made a couple of tactical & strategic mistakes here.  But in the end, they called several plays wrong, and now they are vulnerable.

Intuit would argue that Apple could still ship Rosetta on Mac OS X Lion.  Or maybe they could license Rosetta to Intuit to bundle with Quicken 2007.

Apple’s not going to do it.  They want to simplify the operating system (brutally).  They want to push software developers to new code, new user experience, and best-in-class applications.  They do not want to create zombie applications that necessitate bug-for-bug fixes over the long term.  Microsoft did too much of this with Windows over the past two decades, and it definitely held them back at an operating system level.

A Proposed Solution: VMware to the rescue

I believe there is a possible solution.  Apple has announced that Mac OS X Lion will include a change to the terms of service to allow for virtualization.  If this is true, this reflects a fundamental shift in Apple’s attitude toward this technology.

The answer:

  • Custom “headless” install of Mac OS X 10.6.8, stripped to just support the launch of Quicken 2007.
  • Quicken 2007 R4 installed / configured to run at launch
  • Distribution as VMware image

OK, this solution isn’t perfect, but it is plausible.  Many system utilities are distributed with stripped, headless versions of Mac OS X.  In fact, Apple’s install disks for Mac OS X have been built this way.  A VMware image allows Intuit to configure & test a standard release package, and ensure it works.  They can distribute new images as necessary.

The cost of VMware Fusion for the Mac is non trivial, but actually roughly the same price as a new version of Quicken.  I’m guessing that Intuit & VMware might be able to work out a deal here, especially since Intuit would be promoting VMware to a large number of Mac users, and even subsidizing it’s adoption.

Will Apple Allow It?

This is always the $64,000 question, but theoretically, this feels like really not much of a give on Apple’s part.  They are changing the virtualization terms for Mac OS X Lion, so why not change them for Snow Leopard to0.

Can We Fix It? 

I’m a daily VMware Fusion user, which is how I use both Windows & Mac operating systems on my MacBook Pro.  If Intuit can’t work this out, I just might try to hack this solution myself.

In the end, I’m a loyal Intuit customer.  I buy TurboTax every year, and I use Quicken every week.  So I’m hoping we can all find a path here.

Feel free to comment if you have ideas.