Bootstrapping Lessons from Brooklyn

Before attending an October NSF I-Corps entrepreneurial workshop in Brooklyn, I finished the required reading:

In this post I’ll share a few things I took away from the workshop as an observer, and what I learned from the books.

As a launching point, a startup was defined as:

“A temporary organisation designed to search for a repeatable and scalable business model”

I was struck by the phrase temporary organization, but I suppose the idea is that once you become a revenue generating venture, you’re no longer in the startup phase, rather you toggle the switches into an operational business where success is measured by how well you execute.

National Science Foundation I-Corps

The I in I-Corps stands for Innovation.

There is a shift afoot in the NSF away from funding stand-alone scientific research toward “broadening the impact” of basic research.

One way to broaden the impact of scientific research is to fast-track the science into products and businesses. Ergo we have I-Corps. From the I-Corps website:

The NSF Innovation Corps (I-Corps) is a set of activities and programs that prepare scientists and engineers to extend their focus beyond the laboratory and broadens the impact of select, NSF-funded, basic-research projects.

I-Corps, and the Brooklyn workshop I attended, are rooted in the soil of the Lean Startup movement.


Context: Customer Discovery & Lean Startup

Steve Blank is the de facto graybeard of Lean Startup. Lean Startup was proposed in 2011 by Blank’s former student and entrepreneurial mentee, Eric Ries. While Ries popularized the movement beyond the software community, Blank contributed the essential first step:

Customer Discovery

With the exception of Customer Discovery, Minimum Viable Product, and the novel idea of iteratively testing a hypothesis about perceived customer value, much of Lean Startup is derived from the Agile / XP movement which has been used for over a decade in the software community.

Historical Context: Waterfall → Agile → Lean Startup

Software developers progressed from Waterfall to Agile and, more recently, into Lean Startup.

Waterfall is a sequential design process that was the canonical approach to software development for over 40 years. The stages of a waterfall are an unfortunate but apt metaphor for process rigidity (i.e., a new stage may not start until its immediate predecessor is completed).

Out of the process rigidity of Waterfall came the Agile Manifesto (Snowbird, Utah 2001).

Software developers have lived through the gains and pains of Agile implementations for over a decade (see Bottom-Up Change: The Agile Manifesto at 10). The lighter weight Agile taught us to embrace change, to adapt quickly to an evolving product vision, and to produce working software for the customer. Agile also taught us to iterate over bite-sized chucks of work and to reflect upon what we’d accomplished. We learned the value of incremental development. In short, we learned to

Plan, produce, and reflect.

Much of the Agile mindset is well-suited for starting a business.

The Business Model Canvas

Much of the workshop was centered about teaching graduate science and engineering students how to effectively use a Business Model Canvas. A Business Model Canvas is a template for developing new business models. The primary directive of a startup is to search for a viable business model.

“Startups search. Companies execute.”
Frank Rimalovski, NYU Entrepreneurial Institute.

In the journey to find out if your model has legs, the Business Model Canvas is used to organize your hunches about what will sell and who your customers will be.

Business Model Canvas

Over the course of the 3-day workshop, the Business Model Canvas became both narrative and scorecard. It was used for measuring progress in discovering the essential aspects of the model. Participants were charged with finding and interviewing potential customers so they could test their hunches. They were admonished to

“Get out of the building!”

And participants were urged to,

“Start thinking about the ecosystem…how the money flows.”

Participants were instructed to frame, trim, and hone their product concepts (and the written descriptions of their products) so that the gist of the product was easily and instantly communicated to a less sophisticated audience.

“Frame the description of your product for your mother.”
― Lyndsey Marshall Gray, NYU Entrepreneurial Institute

I observed graduate students, called Entrepreneurial Leads or ELs, struggling to coherently and concisely express concepts like Value Proposition or Customer Segments to a panel of business experts and instructors who grilled them. Several times a panel member blurted out, “Who cares?”

“This is delivery. We learn by doing.”
Jerry Engel, Berkeley-Haas School of Business

A Value Proposition is a promise of value. The Business Model Canvas has a box for Value Proposition, labeled VP. Participants were encouraged to write their value propositions as testable assertions.

A value proposition applies directly to one customer segment or another. The Business Model Canvas also has a box for Customer Segment, labeled CS. The workshop instructors stressed the importance of being able to map a value proposition to a specific customer.

When participants struggled with identifying their customer segments, they were encouraged to be concise and to think about the pointy tip of the arrow.

“Who are the people who will open their wallets first?”
―Lyndsey Marshall Gray, NYU Entrepreneurial Institute

Parting Wisdom

Many scientists, and would-be entrepreneurs, are hyper-focused on technologies or alleged features rather than benefits because that’s what they find most compelling, but the process of determining value, and who might buy a product, has more to do with the Pains and Gains experienced by a potential customer.

Like the Business Model Canvas, The Startup Owner’s Manual and Business Model Generation are dry and formulaic. But who am I to argue with success?

By all accounts, searching for a business model is a step-by-step journey of conquering one of the aspects of business development that might be most uncomfortable to those of us who are socially-inept or analytically minded:

Engaging people to validate your hunches about your product.

Software startups must be able to distinguish between users and paying customers because they’re not always one in the same.

Stripped bare, Steve Blank’s insight is that customer discovery is essential. One personal epiphany worth repeating over and over again for would-be software entrepreneurs:

Don’t bother coding anything until you discover & understand who’s going to buy it.

If you’re attempting to bootstrap a software product or company, The Startup Owner’s Manual is essential reading because I’m betting the formulaic practices will save you months, if not years, of misguided effort.

REFERENCES

SUPPLEMENTAL READING

Agile Adaptations

I’ve been following the Lean-Startup movement since I wrote about it in Framing Product Development. In the Spring of 2010 I was jazzed up about Lean-Startup following a gathering at DevJam with a small group of friends where we viewed a simulcast of the Startup Lessons Learned Conference –the brain child of Eric Ries.

Yesterday I tweeted:

Several RT’d. Others commented about this distillation of ideas.


My Admission

 My Tweet was cribbed from Abby Fichtner’s (a.k.a., Hacker Chick) screencast Pushing Agile to the Next Level. The side by side comparison of Agile and Lean Startup (below) is a concise and helpful representation of an evolution of thinking in the Agile software development realm.

Of Hacker Chicks’s excellent slide and presentation, I pass on Alan Cooper‘s tweet – ostensibly directed at her vision of the evolution of the Agile movement…

Most accurate, succinct, and wise demarcation of the two disciplines.Alan Cooper

Agile 2.0

I share Hacker Chick’s vision. For me Lean-Startup has become Agile 2.0. True to the spirit of Agile, movements must adapt and adopt, or die. I recognize that Hacker Chick has shown the Agile community a bridge to the future. The challenge for any ponderous old-paradigm organization producing custom software products is

How to behave like a startup?

Lean-Startup teaches us to create the infrastructure necessary to test our business models (our products). That means getting it into the hands of the users, testing hypotheses (fail early / fail often), and pivoting toward viability — like a heat-seeking missile follows heat.


Previous Posts About Lean-Startup For those new to Lean-Startup, I’ve written several posts on my understanding the constituent principles:

The UX of Desire

The Botany of Desire by Michael Pollan gives a compelling perspective on how desirability determines viability and how plant species have thrived by co-evolving with humans. Michael Pollan’s insights are wildly applicable to software User Experience (UX).

Pollan begins with the premise

Design in nature is but a concatenation of accidents, culled by natural selection until the result is so beautiful or effective as to seem a miracle of purpose.

He demonstrates how four plants have survived through adaptation, and have ultimately thrived by capitalizing on human desires and needs:

  • The Apple – exemplifies our desire for sweetness & intoxication (apple jack),
  • The Tulip – exemplifies our desire for beauty,
  • Marijuana – exemplifies our desire for pleasure, and
  • The Potato – exemplifies our need for sustenance.

Human Desire & Software

Facebook grew from an idea in a Harvard dorm room to over 500 million active users in a hand-full of years (cf. Facebook Timeline). My hunch is that Facebook’s popularity is based on its appeal to human behavior and its fulfillment of human desires. That is, by tugging at our narcissism, our curiosity and our instinct to connect with others, Facebook enables us:

  • to know what our friends, and would-be friends, are saying & doing, 
  • to surreptitiously learn more about particular love interests, 
  • to be flirtatious within a socially removed virtual cocoon, or simply 
  • to be noticed.

The Botany of Desire reversed my bias about humans domesticating plants like corn or apples or cotton. Perhaps it was the other way around – could it be that the plants domesticated us? Plants have, at the very least, used humans to co-evolve and thrive.

I now think of my killer app as a “species” co-evolving with humans. Future startup software might well have to be every bit as cunning as a Venus Flytrap. Our software must provide the sensory lures, then deliver on needs. Future apps might well be like successful plants — spawned by and grown by adaptively fulfilling specific human needs in a survival-of-the-fittest environment.

The Lean-Startup approach seems a fitting platform for the evolutionary experimenting that future killer apps might require. Lean-Startup is rooted in the principle of iteratively adapting and refining a business model (i.e., an evolutionary concept), based on proving the viability of features (meeting needs that customers desire).

INot only will killer apps have to provide features and fulfill needs, they will also have to present desire fulfillment in an alluringly positive experience not unlike a flower’s nectar lures and intoxicates a honey bee to better serve the flower’s ongoing reproductive purpose.

The UX of Desire means attracting and delivering (…so beautiful and so effective) as if the life of your app depended on it!

Startup Pivoting & Software

What is Startup Pivoting?

As Alan Cooper says in To Pivot, Or Not To Pivot,

When a startup company discards Plan A and moves on to Plan B, it is called a “pivot.”

The Lean Startup approach suggests that entrepreneurs use the Lessons Learned from the inevitable failure of Plan A to adjust their business model. An iterative approach that rapidly continues until the business model proves the viability of the idea.

In the context startups, pivoting is a term coined by Eric Ries. Pivoting is when, through a series of small-scale trials (hypothesis testing), a startup moves incrementally toward a better business model.

Each failed trial causes a pivot point where some element of the business plan is tweaked (e.g., customer segment, feature set, positioning).

Does Pivoting Apply to Iterative Software Development?

I propose that we – the iterative software development community – think of each release of new features as a business proposition and an opportunity to Pivot, much like a lean startup. Then, ask

  • What is our feedback loop with our customers?
  • Would our team modify a feature based on negative feedback?
  • Would our team roll back a feature based on negative feedback?

Further, I challenge the iterative development community to think of meaningful measures of the value of a new feature, whether value is measured by revenue generated or by the coolness buzz created.

Beware of Shadow Beliefs

One term I learned from Eric Ries is Shadow Belief. Shadow beliefs are the closely held, somewhat notional beliefs and assumptions that frequently sink good-intentioned entrepreneurs. All of us fall somewhere in the continuum of delusion, particularly those under the spell of a great startup idea or cool software feature.

One shadow belief is We know what the customer wants. Another shadow belief is Advancing the plan is progress.

Hypothesis Testing & Software

What is Hypothesis Testing?


Hypothesis testing is used by Eric Ries in the context of the Lean Startup. Hypothesis testing encompasses:

  1. Proposition – for example: How many users will pre-order our product?
  2. Test – e.g., a website with a picture of the product and an accompanying pre-order button.
  3. Results – Evaluate the number of pre-orders.
  4. Action – Refine the test (e.g., A/B testing or different market segment) or tweak business model (see pivoting).

Does Hypothesis Testing Apply to Iterative Software Development?

A shortcoming I repeatedly see in Agile software development is what I derisively call bogus prioritization. That is, the business or product owner sets the direction of the development team based on seat-of-the-pants guesses of what’s valuable, rather than on something more verifiable.

I propose that we – the iterative software development community – think of each release of new features as a business proposition, much like a startup company. Part of the Lean Startup philosophy is continuous testing and refinement as you converge to a better business model. Can we do the same with each software release?

We might ask,

  • What is a hypothesis and how best to test it with real customers?
  • That is, how do we make a bold hypotheses like “mCommerce will double eStore revenue” testable?
  • What hypotheses are we hoping to get answers to in this release?
  • How might prototyping of features be used to test hypotheses?
  • Will test-marketing feature sets be off-putting to our loyal customers? To new customers?

Believe those who seek the truth. Doubt those who find it.
~ Derek Sivers

 

The Building Blocks of Software Pleasure

I found Aarron Walter’s software pleasure pyramid in Esther Derby’s post Are We Aiming Too Low? Aarron’s sketch is compelling for its simplicity, and for what it says about past and future agile software development.

Software Pleasure Pyramid

David Hussman pointed out that ancient Egyptians practiced evolutionary design with improvements with each iteration.

“The first pyramids were merely burial mounds. The next version was the step pyramid (Djoser’s tomb) and the next version the “bent” pyramid (a design in rock that they had to refactor during construction. These were all the forerunners to the Giza structures. It was a progression of small, simple structures which evolved based on the learning (and failures) from the last iteration.”
~David Hussman

Most of the developers I program with day-to-day concentrate on functional & reliable. And, on balance, we’re proficient, if not rock stars. Many of us have benefited from wisdom from the Agile & XP communities. Most of us use, in one way or another, some or all of the following:

  • granular tasking, 
  • emergent design,
  • programmer’s idioms like One method, One purpose
  • test-driven development, and 
  • continuous integration.

The better craftsmen I have worked with, young coders like Eric Brandes, consider usability as part of the craft and it shows in their work.

I yearn for the pleasurable in software; software that’s a pleasure to use.

Listening to Alan Cooper, the progress to the pleasure plateau is going to require a new level of professional craftsmanship that runs the gamut from simply functional and reliable to sublime user experience.

We are the experts, we are the grownups, and the users are the 5-year old kids. No you don’t give them ice cream & candy but…realize they’re hungry…so you get the broccoli and liver.
~Alan Cooper

We’ve learned from evolutionary science that successful organisms often take advantage of the desires of other species. Apples, in the European-centric frontier of North America, appealed to the human desire for sweetness (and for intoxication in the form of hard cider), so humans cultivated the apple for the properties they desired. Or was it the apple cultivating humans?

Part of achieving the level of pleasurable in our software is to understand human behavior and desires.

How do we get to the pleasure plateau in software?

Like the emergent design that unfolded with the incremental construction of ancient pyramids, the Agile software community continues to learn and grow. Future viability of the community rests on integrating interaction design and adopting some important principles of the Lean Startup community like

Integrating product hypothesis testing into iterative development to create a tighter feedback loop between paying customers and a money-generating (pleasure) applications.

The pyramid is an instructive metaphor because software pleasure rests on the stability of the underlying building blocks of functionality, reliability, and usability.

Lean Startup for Established Businesses?

The Lean Startup concept – as championed by Eric Ries, Steve Blank, Andrew Chen, and others – is to move incrementally toward a viable business model using a tight feedback loop with potential customers.

Lean Startup is an ongoing sequence of posing hypotheses, testing those hypotheses, and then pivoting (adjusting) your business model based on the test results.

Integral to the Lean Startup concept is Steve Blank’s idea of Customer Development (i.e., a hyper-focus on customers and the market at hand).

Lean Startup should not be limited to cagey entrepreneurs and Silicon Valley hipsters. 

Lean Startup could be readily applied to most product development projects that occur in companies of all shapes & sizes.

For software development projects in established companies, Lean Startup would be much like an incrementally improved version of Agile software development.

A significant upgrade to the time-tested Agile approach might be realized simply by having the development team pivot based on a tight customer-testing & analytics loop, rather than reacting to deer-in-the-headlights guesses hastily offered up by bewildered product owners. Engineers at Google have been doing this for years (see the Google News example in my post Launch Early & Learn).

Have the development team pivot each iteration based on a tight customer-testing & analytics loop, rather than the whims of the product owner.

Established companies are afflicted with an overwhelming inertia to make seat-of-the-pants decisions based on whims and half-baked notions. This occurs because employees and contractors are not stakeholders. This also occurs because of dead wood (the lazy & uninspired). To be fair, it’s not their bacon. It’s much easier to make decisions based on a whim than it is to design tests, and do the grunt work, that answers essential and existential questions.

One challenge to established businesses is to set up an iterative framework of hypothesize, test, and pivot. Another challenge is to inspire employees to care enough about the product to doggedly pursue customer experience & customer desires through balls-out hypothesis testing and a feedback conduit to customers. 

The flip-side challenge is walking the tight-rope of customer development. That is, walking the fine line between engaging potential customers to help you converge to a business model and repelling potential customers by asking too much of them.

Resources