UX is hip.  And rightly so.  I thought I’d share a theory why this is so and what impact it might have on your startup.  This despite the fact that I’m relatively new to UX concepts.

The 90s

Painting with a super broad brush, the 90s technology revolution which saw the introduction of PCs and networks into businesses was driven primarily by increases in productivity measured at the business level.  Reduction in support staff, increased internal and inter-business communication had a measurable impact on the business.  While the technology was expensive and the immediate net benefit small, it grew enough in the late 90s to, at the very least, portend benefits to come.

It was far from smooth-sailing.  The effective lifecycle of a PCs was only 2-3 years.  If you had a network of 100 nodes, you were easily paying 100K/year to hardware and software to keep things running at a pretty basic level.  Some medium sized businesses were seriously thinking of packing it in until costs would come down or larger benefits could be realized.

If there’s one thing that seems to be true in technology, it’s that future benefits are easy to imagine and don’t come quickly enough. In other words, the industry pretty consistently over-promises and under delivers.  Technology in the 90s was mired with buggy (Microsoft) software that bogged down trailing hardware and arguably was maliciously incompatible with (buggy) legacy network software (Netware).

An emphasis on UX was nowhere to be seen.  Of course, that’s not exactly true, Apple had it in spades.  But the extra dollars required for an improved user experience had little impact for the average business user on business productivity. A reasonable argument could be made that this was a short-sighted view, but the view was rational. If you triple the price tag, you must triple the productivity. The Macintosh made headway in businesses at the departmental level, where the impact on productivity was significant; in other words, where specialized graphic-intensive applications were put to use.

The UX experience on the PC was crap and no one wanted to pay to improve it, since you could still reduce the administrative support to principal ratio even with crappy systems.  That it took a IT guy several weeks to implement buggy MS Mail to SMTP gateways and the end-user process to send such an email sucked didn’t matter relative to the time and money savings of sending proposals at the last minute vs sending hard copies via Fed Ex.

The 2000s

As the Internet emerged as a business productivity tool, the primary beneficiary was the department.  The browser as a standardized UI for internal applications reduced IT supports costs and offered some freedom for departments and business units from their dependency on IT.  As SaaS emerged, this independence accelerated.

The early user experience on the browser was horrible and often worse than that of desktop or client/server applications.  But the benefits from a lightweight interface and reduced dependency on IT outweighed the superior UX experience.  Further, technical limitations on the browser thwarted efforts to improve the experience.

Today

While I’m sure there will be a whole new revolution in business and departmental productivity, likely brought on by human-computer interaction technology (think Kinnect), today’s story is about personal productivity.  Applications built for the desktop stand-alone, mobile, browser-based SaaS are all about improving user productivity.  The two primary ways to achieve this are 1) work within existing flows; 2) mimic the offline world.

I chuckle when I see marketing slogans “We’re going to change the way you work!”  Really?  See ya!  Why do dating sites fail? They don’t replicate how human beings meet.

The tricky thing is that you need to improve productivity enough to justify the costs without changing behavior so much as to make the product undesirable.  How do we do this?  With superior UX, of course.  How do you nail such a thing?  It should come as not surprise that my recommendation is deploying Lean UX design principles.  You must understand the it is a delicate, learning process.

“But people are so different!” you rightfully lament. Yep, the one size fits all is dead. While investors and industry pundits hand-wringing about copycats, features-not-products, thinking-too-small, etc., the entrepreneurship world is producing 1000s of startups to figure out how to solve common problems across a wide-diversity of people.

I don’t know what the landscape ends up looking like.  If big businesses swoop up  lean startups who have successfully unlocked one or more beachhead market segments, they can’t kill the innovation or roll it up into bloatware without creating a new startup opportunity.  Similarly, is it possible for one SaaS or mobile product to solve similar productivity problems for a mass of varied segments?

I welcome your thoughts in comments!

In fact, some early adopters of Lean Startups — those who have already bought into the framework to the extent that they’ve applied its practices into their high tech startup — might be a tad disappointed.  They might have to look a little deeper; there’s no vanity steps to success herein.

Why? In the end, this book is not written for them. But rather, like any good entrepreneur, Eric is aiming at the Mainstream market.  According to Geoffrey Moore in Crossing the Chasm, you can’t address the Mainstream market the same way you learned to do in the early adopter market.  (Hence the chasm.)

In my opinion, for example, early smartphone adopters diss’ the iphone, because Apple targeted the Mainstream, not them.

Eric’s intentions are easily discerned from his definition of Startup:

“A human institution designed to create new products and services under conditions of extreme uncertainty.”

This is clearly not intended to speak (only) to high technology startups, but rather to anywhere uncertainty exists. In my opinion, this is the strength of Ries’ book: it is a call to action to anyone inclined to take action to make things better despite facing severe uncertainty.  There is no boundaries to where you can exercise your entrepreneurship.  And though Eric doesn’t state so explicitly, true entrepreneurs are those willing to admit to the uncertainly within the institutions they inhabit AND to develop solutions that solve problems in the face of that uncertainty.

This definition applies to social entrepreneurship, non-profits, education, government, large successful businesses, and any business with technology risk or market risk, including yes, high tech startups.

Think about this for a second.  If true, the problem with the failure to innovate facing many hugely successful businesses is not that they don’t “act like a startup,” but rather that they don’t understand their own uncertainty.  Most people recognize that many governmental institutions face extreme inefficiencies and could benefit from new products and services designed and implemented in new ways.  The roadblock is, perhaps, that in a society overly dependent upon the advice of “experts,” we are unable to admit to the uncertainties we confront and therefore fail to unleash the creativity necessary to build new systems to solve big problems.

Conversely, those who claim to know everything, in other words face no uncertainty, are either not part of a “startup” or simply not truly entrepreneurial.  The arrogance of certainty leads to doing things the way they’ve always been done.

Make no mistake:  there is much here for high tech startups. Entrepreneurs who are still figuring out how to apply the principles to their businesses have much to learn here, but Eric describes less how to do it and more how to think about doing it. (Teach a man to fish and all that.) Personally, I have found that there are multiple layers of understanding to be had in the Lean Startup world and most of us are just scratching the surface. While some will look for more specific action items, Ries’ approach is honest, since there is no such thing as a startup blueprint.  While “Build, Measure, Learn” is easy to grok, the actual practices one has to put into place to create a learning environment that induces change, that produces products that people care about is hard.  No, It’s really hard.  And it’s one thing to do it in a high-tech startup of a couple of people and it’s another thing entirely do to it in a startup environment of 10 people and it’s another universe to do it in static, change-averse cultures that are in the most dire need of disruption.

Eric’s “stuffing the envelope” analogy, for example, is illuminating and one I hadn’t encountered before.  It turns out that stuffing envelopes one at a time is faster than differentiating the tasks and doing them in batch mode.

“What if it turns out that the customer doesn’t want the product we’re building? Working in small batches ensures that a startup can minimize the expenditure of time, money, and effort that ultimately turns out to be wasted.”

When in execution mode — i.e., when uncertainty has been eliminated — you can optimize processes for speed or cost.  When in learning mode, however, crippling inefficiencies can occur if you’ve optimized execution on the wrong parameters and then learn your assumptions were wrong.

Eric offers stories that run against the grain, which lead you to think differently about how to solve problems, such as increasing efficiency through less specialization and the fastidious elimination of metrics that enforce false certainty (vanity metrics).

There’s more to come. Eric briefly tackles the quest to bring disruptive innovation to the enterprise. At this point, I’m not sold on the methods prescribed.  Ries says he aims to “protect the parent organization from the startup” thereby turning the conventional model “on its head.” The premise seems to be that senior management “springs innovation” onto existing managers.

I’m not sure this is the case.  I think it more likely that senior managers are more distrustful of low margin, small market experiments run by kooky internal entrepreneurs then they are of managers who continue to execute on current products.  Futhermore, there is no real head flipping here since these are really two sides of the same coin. Maybe big company departments need protection from fast moving startup people, but startups need “protection” from the problem of being measured by the same criteria (e.g. profit margin) as existing product.  Big company R&D centers are rife with products that never see the light of day.

My take is that big companies are going to look more to startups to solve the problem of disruptive and even sustaining innovation.  An economy bustling with 1000s of Lean Startups is conducive to enterprises waiting for small entrepreneurs to prove the market before the big guys move in.  It will be interesting to see how this plays out.

The Dark Side The book is perhaps a bit heavy on the development side of the house, but for anyone envisioning innovation, this is the right place to start.  Eric’s discussion of applying the “5 Why’s” is instrumental to understanding the implementation of fail-safe processes.  It would be interesting to see  these principles applied to the dark art of sales and marketing.  Instead of traditional loss reports, what would a no-blame-game 5 Why’s look like to dissect a failed sale?  Poor Customer Support?

But this only means that new ideas of how to apply Lean Startup principles need to be tested, validated and shared.  When discussing my book, the Enterpreneur’s Guide to Customer Development, with Steve Blank, he remarked how the school of thought he pioneered “is what it preaches.” Eric’s book demonstrates that.  Not only because Customer Development is an important aspect of Lean Startups, but because Eric’s own vision and elucidation of Lean Startups has evolved tremendously from when I first heard him present his ideas in June of 2009 in China.

The Lean Startup movement is a framework entrepreneurs of all stripes can use to innovate in their industries. All those who adapt and practice it – who make it their own – will continue to advance the Lean Startup framework.

For some reason, it didn’t get chosen.  : )  Actually, it’s a just slide from my You are (not) a Visionary deck I presented at last week’s Wisconsin’s Forward Technology Conference.

As technologists working on new products and new markets, we tend to forget where we are on the technology adoption lifecycle curve.  That’s a mistake.  Here’s why:

1. Nobody cares

See all that white space under the middle of the curve?  Those are people using products that aren’t yours. They are inundated with new offers every day. They exist in a world of information overload. It doesn’t matter how great your technology is, nobody knows about you, nobody cares about your product.  See that white space under the line marked by the blue dot?  Yeah, me neither.  If, for example, you are building a new web app that demands people spend time on your site, whether you’re the new deal site du jour or a “disruptive” new Q&A site, you’re competing against limited attention, ie., limited time carved out for spending time online.  Never mind your actual competition. You have to either increase the amount of time people spend online, or steal time from Facebook, Twitter, Google, Microsoft, CNN et. al.

2. You have a long way to go

Inside our early adopter bubble, we think a TechCrunch mention is the end all, be all.  What % of the US population has never heard of TC, 97%?  See where the curve starts accelerating up?  That’s about where the chasm lives, waiting to swallow you up.  Of course As Steve Blank likes to point out, you’re lucky if you even get to the chasm. We are easily distracted by minor (albeit clever) improvements to infrequent activity on technology platforms that from a global perspective, are obscure.  Say, like posting photos that look like Polaroids to Twitter. Not only are we enamored with such minutiae, but are ready to declare such features “the winner.” Of what, who knows?  You can try Leapfrogging early adopters, but that requires millions and millions of dollars (see iPhone/iPad).

3. Your entire ecosystem is early

Have you noticed the resurgence of email newsletters? It’s as if technologists finally got the DMA memo that email is (still) the online communication tool of choice among consumers.  In other words, if you want to reach customers, email is better than Twitter, Facebook, SMS, etc.  Not that these aren’t effective, too, for some segments, but like it or not, email is king.  The point is that the distribution of users on the platforms your product depends on, determines your market potential.

If your strategy depends on early majority platforms, you will need patient investors and money to burn. If you aim to leverage established platforms, remember that users generally like them the way they are (that’s why they were successful).  It’s hard to alter user behavior within a platform, too.

Of course, your objective might be to overthrow entrenched players, or perhaps to re-segment their market.  But remember that the momentum achieved by established companies successfully converting the “early majority” crushes your “better” product.

Use your fellow “early adopter” denizens to help vet your product, determine what works to solve pain, reward passion, instigate sharing, but don’t assume your success here and infatuation with your wiz bang technology represents a real market.

Solution-centralism starts in Customer Discovery.

More often than not I encounter surveys that pay scant homage to the problem, usually has a means of filtering respondents. For example, a typical survey asks “do you have this problem” and if so, how appealing do these solutions sound?  Tweaks to the problem description involve messaging more than understanding.  In other words, the startup team focuses on understanding what words resonate with respect to the problem, as if  the problem itself is fully understood.  Interestingly, the problem continues all the way through to asking pricing questions that evoke dubious responses like “would you be willing to pay?” or “how much would you be willing to pay?”  There is no direct connection to value in these questions.

You hear this in elevator pitches all the time, too.  Egocentric pitches assume the features (and even the benefits) make the problem compelling.

In fact, the opposite is true. The willingness to pay depends on the depth of pain (or passion).

One of my favorite Eric Ries quotes:

If you can’t sell magic, you can’t sell your solution.

Nobody cares about your solution.  They care about solving their problems.

Solution-centralism continues in Customer Validation.

Your product is out the door and you have some market signal, but are still searching for Product-Market Shanggri La.  And you have the feature list and engineering spec that is going to get you there.  Everyone does.  You’re one feature away.  Always.  Your iteration loop has an invisible exit gate.

This is the chasm before The Chasm.  This is where you become the anti-Dropbox, a shattered “tip of the spear.” This is where you become unable to answer who you are:

• too many features;
• features people don’t use;
• features across too many market segments;
• features to keep up w/ Jones’ Widget Co.

Stop.  Please.

Problem-centralism Wins

Be a problem expert. In this age of fast development and no IP protection, whoever “owns” the customer, wins.  You own the customer by understanding and solving their problem better than anyone else.  This is why Customer Development, when properly done, is critical to your success.

• When surveying users early on, focus on problem statements before solution.  (FYI, I am working on an application to help with that.)
• Interviews are critical toward establishing empathy.  Emotion indicates resonance and cues you when to dive deeper, rather than going shallow and broad (like surveys).
• Product demonstrations are not for “show and tell,” but rather is this solving the problem (exercising the passion).
• Messaging/positioning around problem lures the unsuspecting and suspicious alike.
• While iterating product toward what resonates, kill features.

Ultimately your addressable market size depends on amount of pain (passion) in the market, i.e., the size of and number of market segments that share a “big enough” pain (or passion).

Steve Blank speaks to San Diego Tech Founders from Brant Cooper on Vimeo.

Contents:
00:00 My Intro
03:17 Why Accountants Don’t Run Startups
- Old constraints on startups
- Entrepreneurial explosion
- Startups vs Small Businesses vs Large Businesses
- IBM example of big company disruptive innovation
- What did my income statement say in month 1?
- “You’ve just washed ashore on an a deserted island with a knife in your mouth and a loincloth.”
- Searching for a business model, not a business plan
- Customer Development
58:26 Atoms or Bits (New Material)
- Physical vs Online products
- History of Lean
1:03:26 Sloan vs Durant
1:08:41 Q&A
1:29:50 My Conclusion

Be sure to come check out entrepreneur turned investor Mark Suster talk to San Diego Tech Founders March 31.

=> Startups RSVP here.

=> Investors, Service Providers, Professionals RSVP here.

Blank’s Customer Development is critical, otherwise speculating what comprises your startup’s business model is just another academic exercise.  Arguably, one could easily waste as much time documenting assumptions on your business model canvas as documenting them inside a 40 page business plan.  The canvas exposes your hypotthesis and customer development tests them.  It’s a laudable ambition to document and test all of your business model canvas components.

But how much is necessary to get going?

All building blocks are not created equal.  I believe there’s a natural progression towards figuring out your business model and many blocks are directly dependent on prior blocks.  Is it worth the time to document 2nd or 3rd tier blocks before establishing the reality of 1st tier?  The answer, of course, depends on you and your business.  It doesn’t hurt to go as far as you can at the start, unless the activity inhibits you from getting started, i.e., “getting out of the building.”

To use a rather simplistic example, you might presume that your customer is an enterprise-sized business that requires a field sales force and partnerships with highly technical systems integrators.  What if your customer ends up being a medium-sized business that requires SaaS product distribution?  Early customer development might very well point you down the correct path from the outset.  Some business model components flow naturally from validated core hypotheses.

The real dilemma in my mind is, what do you test first? The key to getting started is to nail the validate of the core hypotheses: Customer, Problem, Solution.

Go to the #CustDev White Board

In our book, The Entrepreneur’s Guide to Customer Development, Patrick Vlaskovits and I developed a white board exercise to help think through business model risk in order to determine what to test first.  The key components are:

=> draw the ecosystem around your business as you imagine it, including partners, distributors, customers.

=> determine which are mission critical — in other words, can you get going without any?  Which are absolutely necessary?

=> state the value proposition for each mission critical participant — what determines whether or not they join the ecosystem?

=> list the minimum product functionality necessary to get entities to participate.

=> prioritize the risks (technical and market) based on the above.

Ultimately, what you trying to prioritize is: what’s the quickest way to fail your business model. The “value path” of testing your business model runs through testing the the core value proposition of each of your mission critical ecosystem entities.  Easiest to test means:  what you can test in the shortest time frame.

If building a landing page and driving traffic to it has the potential of killing your present business model hypotheses, then it’s a legitimate “intermediate MVP” and worth testing.  But be careful.  Are you sure you’re not testing your ability to drive some amount of traffic or your positioning?  If a 3rd party API doesn’t provide the hooks you need to develop a critical piece of technology and therefore your business model fails, maybe that’s what you test first.

Documenting the building blocks of your business model = good.  Using the #CustDev White Board exercise in conjunction helps you determine what to document and test first.

How do you determine what to test first?

Here’s a handy graphic illustrating source and bias:

If one looks closely, one can perhaps discern my bias. ; )

Let’s go through these.

1. Those with marketing backgrounds are comfortable speaking with customers in a manner determined by their specific role.  Product Managers talk about road map, collect feature requests and bounce ideas off customers, often in group settings (focus groups, advisory boards, etc.).  Product Marketers communicate features and benefits and elicit feedback, often through surveys.  Corporate marketers practice “branding” and spin.  Feedback goes to info@ email boxes, twitter tweets, and Facebook ‘Likes’ (or not).

2. UX Designers are quick to tell you they invented Customer Development only called it something different.  And frankly, they’re right to a degree.  When it comes to product design.  Or parts of product design.  Anyway, UX Designers are good at observing user behavior and interacting with them in a particular (not peculiar) way to determine if the product is “working.”  This is instrumental to today’s products.  (Not always the case, as I’ll argue in another post.)

3. Engineers, in their lifetime quest to never have to actually speak to a live animal of the “Customer” species, utilizes analytics tools and product instrumentation to produce reams of data on user behavior, i.e., actual user interaction with the product.  Instrumentation is instrumental, too.

4. Penultimately and leastly, are the investors, branders, Madison-Ave marketers, turn-key salespeople, high-tech gadflies and backseat pundits who declare that Vision is the only thing that matters.  All you have to do is be like Apple and Ikea, get it?  Do I have to spell it out for you?  All you have to do is be just like A-P-P-L-E.  There now, go to it.

5. Finally, what is the Customer Development bias?  Customer Development needs all the practices above, but none of them help you understand the problem, the pain, the passion. That’s the final leg or better yet, the first leg of Customer Development.  Empathy.  Whatever walk for mankind you need to do to walk a mile in your customers’ shoes; whatever interview technique, lunch buying, drink toting, teatotaling, karaoke yodeling you must participate in to gain an understanding such that you feel empathy.

Now, then, can’t we all just get along?

Please excuse the hyperbole and generalities and the tongue-in-cheek.  Recuse yourself as you see fit.  Feel free to post vitriol in comments. : )

btw, note that AARRR isn’t exactly sequential… in fact, i’d emphasize Activation & Retention *first*, then go after Acquisition & Referral, then optimize for Revenue

Recently, I have caught a couple of my Customer Development clients optimizing the metrics in the “wrong” order, so Dave’s comment bears repeating and perhaps some expounding upon.

The Pirate Says “AARRR”

The anagram is ordered by user experience:

A – Acquisition – User is directed to your site;

A – Activation – User signs up or is otherwise engaged;

R – Retention – User keeps coming back, i.e., is engaged over time;

R – Referral – User invites others;

R – Revenue – User pays or is otherwise monetized;

This is not, however, the order in which you should optimize your product while building your business.  The order (and truly, the metrics themselves) are dependent upon your business model.

For B2C Free, Say RRAAR

Retention – Nail engagement so that users want to or must come back;

Referral – Your business model requires massive user growth, so your product must require referrals to work or must be so cool it just happens;

Activation – Once your users are here to stay and inviting others, optimize their conversion funnel.

Acquisition – Now you’re ready to blow up acquisition.  (Good time to get investment funding.)

Revenue – Millions of users?  Time to monetize.

For B2C or B2B Freemium, Cheer RRRAA!

Retention – Nail engagement so that users want to or must come back;

Revenue – If your business model requires users or businesses to pay, you need to figure out what they’ll pay for before you blow-up anything;

Referral – Since you’re likely not a true network-effects business, you optimize referral after revenue.  Optimizing referral is actually part retention, part funnel optimization.  Users are so happy they will refer others to your site or provide you testimonials or speak to the press, etc.  Not much sense in blowing up your acquisition, however, until you have that level of passion.

Activation – This refers to Blank’s “Sales and Marketing roadmap.”  Here you understand and optimize your sales funnel.

Acquisition – OK, now you can hire that PR firm.

For Enterprise B2B, Cheer an alternative RRRAA!

R – Revenue – If you’re selling to businesses the number one thing you need to prove is that someone cares enough about what you’re providing to give you money for it.

R – Referral – As above, referral in this context means that your customers are willing to sing your praises publicly.

A – Activation – In this context, activation is understanding your sales and marketing roadmap.

A – Acquisition – After you nail your sales and marketing roadmap, you’re ready to feed the top of the funnel.

R – Retention – In enterprise B2B, you often don’t have a subscription model, but may be charging annually for maintenance and support.

Note that you will always need to do some level of “acquisition” in order to figure out and optimize the other stuff.  But the point is that you’re not concentrating on or optimizing acquisition at the start.  Exact order of AARRR is debatable from one business to another, so use above as guidelines only.

Customer Development does not equal User Acquisition

Customer development is a method for discovering, testing and validating user acquisition and conversion methods.  So that a marketplace suffers from the “Chicken and Egg” problem, i.e., there’s only a true market when they’re both there doesn’t affect Customer Discovery and some amount of Customer Validation.  In other words, you can interview both sides of the market place, show them solution ideas, validate MVP features all without the other side of the marketplace being involved at all.

The pre-development signal you are trying to hone in on is “What will it take minimally for each side of the equation to come to the market?”  In most marketplaces, what you will discover is that one side of the market is actually the product, and the other side is the consumer of the product.

Product vs Consumer

In truth, the “Chicken and Egg” problem doesn’t exist.  I hate to burst your object impermanence bubble, but your local weekend farmer’s market exists even when you don’t go.  ; )  Marketplaces can exist with products, but no customers — just not for long.  One side creates the marketplace, i.e., is the “product”; the other side creates the market, i.e., is the consumer of the product.

To put it another way, the business doesn’t exist without product, but doesn’t succeed without customers.  (Exists, but fails.)   In the groupon example, clearly coupons are the product.  (Groupon doesn’t exist without coupons, Groupon doesn’t succeed without consumers.)  A client of mine had photographers on one side of a marketplace business model and people who need custom photos on the other.  The business doesn’t exist without photographers; doesn’t succeed without people buying photos.

Marketplace User Acquisition

The “Chicken and Egg” dilemma does (potentially) exist, when it comes to converting prospects into customers or users.  ”Network Effect” businesses have a great potential to grow virally  if they nail their value prop, but need the effect to get the effect!  Some marketplaces suffer from the same dilemma: there’s no value to either side until both sides are there and engaged.

BTW, Customer Development doesn’t have a specific process that will instruct you how to get both sides to your product and get them engaged.  Customer Discovery will not tell you how to solve the acquisition and retention chicken/egg problem.  Is this the much-ballyhooed Customer Development “Fallacy?”  (I don’t get what the fallacy is supposed to be.) Like most aspects of building a business, you won’t find an answer in a book.  You actually have to try methods others have used or think up some new ones and SEE WHAT WORKS.

• Namesake has done a good job using a velvet-rope strategy to test, validate and grow its network effect.  They carefully invite early-adopter types to ensure that site activity is consistent and of decent quality so that there is something for new users to engage with;
• Use a tight geographic approach to control environment;
• You have to get product to market, so make it dead simple for the product side of your marketplace to engage.  Not just cheap (or free, initially), but simple. Do the work for them if you must.

I hope you find this helpful!