Saturday, January 12, 2013

What Is Entrepreneurship?


This post was originally published at HBR.org.

What is entrepreneurship? You probably think that the answer is obvious, and that only an academic would bother to ask this question. As a professor, I suppose I am guilty of mincing words. But like the terms “strategy” and “business model,” the word “entrepreneurship” is elastic. For some, it refers to venture capital-backed startups and their kin; for others, to any small business. For some, “corporate entrepreneurship” is a rallying cry; for others, an oxymoron.

The history of the word “entrepreneurship” is fascinating and scholars have indeed parsed its meaning. I’ll spare you the results, and focus instead on the definition we use at Harvard Business School. It was formulated by Professor Howard Stevenson, the godfather of entrepreneurship studies at HBS. According to Stevenson, entrepreneurship is the pursuit of opportunity beyond resources controlled.

“Pursuit” implies a singular, relentless focus. Entrepreneurs often perceive a short window of opportunity. They need to show tangible progress to attract resources, and the mere passage of time consumes limited cash balances. Consequently, entrepreneurs have a sense of urgency that is seldom seen in established companies, where any opportunity is part of a portfolio and resources are more readily available.

“Opportunity” implies an offering that is novel in one or more of four ways. The opportunity may entail: 1) pioneering a truly innovative product; 2) devising a new business model; 3) creating a better or cheaper version of an existing product; or 4) targeting an existing product to new sets of customers. These opportunity types are not mutually exclusive. For example, a new venture might employ a new business model for an innovative product. Likewise, the list above is not the collectively exhaustive set of opportunities available to organizations. Many profit improvement opportunities are not novel—and thus are not entrepreneurial—for example, raising a product’s price or, once a firm has a scalable sales strategy, hiring more reps.

“Beyond resources controlled” implies resource constraints. At a new venture’s outset, its founders control only their own human, social, and financial capital. Many entrepreneurs bootstrap: they keep expenditures to a bare minimum while investing only their own time and, as necessary, their personal funds. In some cases, this is adequate to bring a new venture to the point where it becomes self-sustaining from internally generated cash flow. With most high-potential ventures, however, founders must mobilize more resources than they control personally: the venture eventually will require production facilities, distribution channels, working capital, and so forth.

Because they are pursuing a novel opportunity while lacking access to required resources, entrepreneurs face considerable risk, which comes in four main types. Demand risk relates to prospective customers’ willingness to adopt the solution envisioned by the entrepreneur. Technology risk is high when engineering or scientific breakthroughs are required to bring a solution to fruition. Execution risk relates to the entrepreneur’s ability to attract employees and partners who can implement the venture’s plans. Financing risk relates to whether external capital will be available on reasonable terms. The entrepreneur’s task is to manage this uncertainty, while recognizing that certain risks cannot be influenced by their actions.

Entrepreneurs face a Catch-22. On the one hand, it can be difficult to reduce risk without resources. For example, outside capital may be required to develop and market a product and thereby demonstrate that technical and market risks are limited. On the other hand, it can be difficult to persuade resource owners to commit to a venture when risk is still high. Entrepreneurs employ four tactics in coping with this Catch-22:
  • Lean experimentation allows them to resolve risks quickly and with limited resource expenditure, by relying on a “minimum viable product,” that is, the smallest possible set of activities required to rigorously test a business model hypothesis.
  • Staged investing allows entrepreneurs to address risks sequentially, expending only the resources required to meet a given milestone—before committing the resources needed to achieve the next milestone.
  • Partnering allows entrepreneurs to leverage another organization’s resources and thereby shifts risks to parties better able/more willing to bear them. In a variation of this tactic, entrepreneurs rent resources to keep costs variable and to avoid the big fixed outlays associated with resource ownership.
  • “Storytelling” by entrepreneurs—conjuring a vision of a better world that could be brought about by their venture—can encourage resource owners to downplay risks and in the process commit more resources than they would if they had not been inspired. Steve Jobs, for example, was famous for his mesmerizing “reality distortion field,” through which he impelled employees, partners, and investors to go to extraordinary lengths to help fulfill his dreams.

So, does Stevenson’s definition of entrepreneurship matter, in practical terms? I’d argue that it does, for two reasons. First, it sees entrepreneurship as a distinctive approach to managing rather than a specific stage in an organization’s life cycle (i.e., startup), a specific role for an individual (i.e., founder), or a constellation of personality attributes (e.g., predisposition for risk taking; preference for independence). In this view, entrepreneurs can be found in many different types of organizations, including large corporations. That should be encouraging if you believe that entrepreneurship is an engine of global economic development and a force for positive change in society.

Second, the definition provides a guidepost for entrepreneurial action; it points to tactics entrepreneurs can take to manage risk and mobilize resources. One of my former students put it well when asked to give advice to aspiring entrepreneurs: “For me, ‘pursuing opportunity beyond resources controlled’ sums up perfectly what I do day-to-day. You need to be inventive, creative, opportunistic, and persuasive, because you rarely have enough resources. Embracing this definition helps me in my role.”

Sunday, December 30, 2012

Managing Startups: Best Posts of 2012


Here's my compilation of 2012's best posts about managing startups. I assembled similar lists at the end of 20112010 and 2009. Many thanks to all of the authors. The generosity of the startup community is amazing, and these insights are invaluable to those of us who teach and coach aspiring entrepreneurs.

Apologies to authors whose work I've omitted. Please use comments below to suggest additional posts. Happy New Year!

Lean Startup
Business Models
Customer Discovery and Validation
Marketing: Demand Generation and Optimization

Sales and Sales Management
Viral Marketing
PR Strategy
Branding/Naming a Startup
Product Management/Product Design

Business Development
  • John O'Farrell of a16z describes how quality trumps quantity and clarity regarding mutual objectives is crucial in doing business development deals, using Opsware's transformative distribution agreement with Cisco as a case study.
Scaling

Funding Strategy
Founding Process
  • My colleague Noam Wasserman published his book, The Founder's Dilemmas, that describes tradeoffs that founders confront when deciding when/with whom to found, how to split equity, how to divide roles, etc.
  • Blake Masters' summary of Peter Thiel's Stanford CS183 lecture on the importance on early founding decisions.
  • Charlie O'Donnell of Brooklyn Bridge Ventures on questions that co-founders must address ASAP and the concept of the "minimum viable team," i.e., the smallest set of skills needed to get traction in an early-stage startup.
Company Culture, Organizational Structure, Recruiting and Other HR Issues
Board Management
Startup Failure
Exiting By Selling Your Company
The Startup Mindset and Coping with Startup Pressures
  • Paul DeJoe of Ecquire on managing the pressure that comes with being a startup CEO.
  • Steve Blank on why it matters how co-founders fight.
  • Blake Masters' summaries of Peter Thiel's Stanford CS183 lectures on the role of luck in startup success and on "founder as victim, founder as god." Fascinating stuff! 
  • Steve Blank on the challenge of distinguishing between vision and hallucination in charting a startup's course.
  • Andrew Chen on dealing with the "trough of sorrow" following a big bump in traffic after a TechCrunch story.
  • Paul Graham of Y Combinator on "black swan farming," i.e., coping with the facts that: 1) the vast majority of returns are concentrated in a few startups, and 2) the most successful startups often don't look very good at the outset/
  • Graham on how to get startup ideas and on generating/coping with frighteningly ambitious startup ideas.
  • 50 startup lessons learned by James Maskell, founder of Vinetrade; startup lessons learned by Vin Vacanti.
  • Andreas Klinger of LOOKK on how/why founders lie to keep doing things in their comfort zones
  • Serial entrepreneur/angel investor Jason Calacanis on the two biggest questions founders need to ask: Will customers recommend my product, and will they remember it?
  • Investor James Altucher on how to survive your 1st year as founder/CEO.
  • Chris Dixon: once you take outside money, the clock starts ticking.
  • Jason Calacanis with advice for seed-stage entrepreneurs facing the "Series A Crunch" [Jason wrote this on Jan. 2, 2013, so it doesn't officially qualify for this "Best of 2012" -- but the advice is just too good and too important to wait a full year before including it next year's compilation!]
Management Advice, Not Elsewhere Classified
Career Advice (Especially for MBAs)
Startup Hubs
  • Brad Feld of Foundry Group and TechStars has published the book Startup Communities, a guide to building an entrepreneurial ecosystem.
Tools for Entrepreneurs
  • Beyond Steve Blank's Startup Owner's Manual, a book he co-authored with Bob Dorf, here is a list of the fantastic resources Steve has made available to the startup community -- mostly for free.

Saturday, December 29, 2012

Product Management 101


This fall at Harvard Business School, we launched Product Management 101, a course for academic credit that uses a "learning-by-doing" approach to build basic PM skills, rather than the classic HBS case method approach. I describe our course design below with the hope that colleagues at other universities will adapt and improve it.

First, a nod to the two MBA candidates who proposed, designed and oversaw PM 101: Prem Ramaswami and Rana Kashyap. The course has many moving parts, and Rana and Prem kept them in smooth motion.

Motivation. As I've written in a course note co-authored with Jeff Bussgang and Rob Go, product manager is a fantastic entry-level general management position for MBAs. Every year, dozens of HBS graduates seek PM jobs. They face a Catch-22, though, because these jobs typically require prior PM experience. Many students have such experience, acquired either before or -- via summer internships or working on their own startups -- during business school. The Catch-22 is most acute for career switchers who decide to pursue a PM position midway through their MBA -- too late to gain experience through a summer job. PM 101 was designed for these students.

Fall Semester. Our goal was to give students hands-on practice specifying and managing the development of a real application. We identified concepts for websites and smartphone apps that might benefit the HBS community, but were unlikely to ever be developed by student entrepreneurs (not enough profit potential) or by the school's own IT unit (too far down their priority list). Examples included a better online campus map; a mobile app for sharing taxis; and a site for scheduling professors' office hours.

Each of fourteen students was assigned an app and a faculty adviser who provided periodic coaching. After a spending a couple of weeks assessing customer requirements, students delivered a Market Requirements Document and, based on their assessment of demand, a recommendation on whether to proceed. After discussing the MRDs, we killed a few apps; students who were working on them were teamed with a classmate on a surviving application.

Students spent the next several weeks specifying their application's functionality and preparing a Product Requirements Document. At the end of the semester, students presented their PRDs to each other and to a panel of faculty advisers, HBS IT managers, and Student Association officers. We voted on which apps should proceed into development. Six of the original fourteen applications were still live after this process. Students whose products were not advanced could join another team.

Winter Semester. For each app moving forward, HBS has allocated $5-8K to be spent on development. Next semester, student teams will select and supervise an outsourced engineering team. Following launch, we expect students to: 1) stress test the application and fix bugs; and 2) collect and interpret data needed to enhance features. Software launched as a result of PM 101 will be owned by HBS, but the school may transfer the IP to our Student Association and/or release it as open source software.

Workshops. In addition to the MRD and PRD checkpoint sessions mentioned above, every two weeks we met as a group with outside experts -- seasoned product leaders and designers -- who gave presentations on key product management skills and tools. At these workshops, students got feedback on their work-in-process from each other and from the experts. Pre-class readings and session assignments are listed on our course site. Session topics included:

  • What does a PM do and who do they work with at different stages of the product life cycle? What are the attributes of successful and unsuccessful PMs?
  • What is a Market Requirements Document and why might a PM be asked to complete one? What techniques do PMs use to understand customer needs and validate demand for a product?
  • What is a Product Requirements Document? Why do some tech companies use them while others do not?
  • What approaches (e.g., project planning software, face-to-face meetings, etc.) do PMs use to track progress and coordinate their team's efforts?
  • How should a PM approach wireframing? What do they need to know about UX design? 
  • What does a PM need to know about cloud technology? Database architectures?

We'll continue these workshops next term, for example, devoting sessions to how PMs work with engineers and to post-launch analytics.

Lessons Learned. At the end of the semester, we asked the students to blog on lessons they learned about the PM role. One wrote about how difficult it was to find definitive metrics to evaluate a product idea at its very early stages, and how killing her idea led her to reconsider her personal standards for success and adding value in an organization. Another wrote about learning that being a PM entails not being a "nice guy" -- rejecting colleagues' feature suggestions because the PM has to make some tough calls. A third wrote about the challenges of becoming a PM as an MBA without strong coding skills.

Improvement Ideas. As with any first iteration, we see lots of ways to improve PM 101. With our workshops, for example, we spent too much time having experts present and not enough time having them react to students' work-in-process. We also should have spent more time having students critique each others' work, as design school students do.

A shortcoming of the course, in the words of one of the few students who had prior PM experience, is that "Unfortunately, it's difficult for PM101 to give students a clear understanding of the often-hurried timeframe, constant pivots, and complexities of people management." Working just a few hours per week, and not as part of a bigger team, doesn't capture the essence of the role.

Another big question is what to do about agile. We recognize that MRDs and PRDs are seen as "old school" by product professionals who favor agile processes. Our readings and many of our speakers discussed agile development, so students gained some understanding of its methods and precepts. But our course design, with its reliance on upfront specification followed by outsourced development, would make it difficult to actually employ agile processes -- as would the fact that our student PMs, who take four other courses, are expected to spend only 5-10 hours per week on PM 101. Ultimately, we concluded that students would gain a deeper appreciation of agile's advantages if they understood how and why to create a PRD.

A final question is how to scale the course. So far, our fourteen students have learned a lot, but next year, we'd like to at least double enrollment, given strong demand for the course and the big fixed cost of organizing it. An obvious problem with scaling is the subsidy required to fund outsourced software development. Prem has floated the idea of shifting the course focus away from apps that benefit our school's community to software developed for not-for-profits. In that scenario, we might find a foundation willing to underwrite development expenses.

I hope that readers who see solutions to the scaling question and other ways to improve the course will share their ideas here.









Thursday, December 29, 2011

Managing Startups: Best Posts of 2011


Here's my compilation of 2011's best posts about managing startups. I assembled similar lists at the end of
2010 and 2009. Please use comments to suggest additional posts. Happy New Year!


Lean Startup
  • Eric Ries's book, The Lean Startup, is a must-read for entrepreneurs.
  • Elad Gil outlines the pros and cons of staying in stealth mode.
  • Andrew Chen unpacks the concept of product-market fit.
  • The Startup Genome Project presents research on thousands of startups in a pair of reports. Be sure to read their report on premature scaling, the leading cause of startup failure.
Business Models
Naming a Startup
Customer Discovery and Validation
Metrics
Demand Generation and Optimization
PR Strategy
Viral Marketing
Sales Management
Business Development
  • Chris Dixon on the Goldilocks Principle of business development, that is, how a big company may view partnership opportunities with a startup that is "too hot" vs. "too cold" vs. "just right."
  • Fred Wilson on how an orientation toward users versus brands should drive business development and other priorities at a startup.
  • Curtis Smolar on the legality of content scraping.
Funding Strategy
Pitching
Are We in a Bubble?
Founder Issues
Recruiting and HR Policy Issues
Board Management
Management Advice, Not Elsewhere Classified
Startup Failure
The Startup Mindset and Coping with Emotional Pressures
Career Planning Issues
Tools for Entrepreneurs


Monday, August 1, 2011

Business Model Analysis, Part 10: Getting Started


This post is part of a series on business model analysis for entrepreneurs. The first post in the series presents a comprehensive list (available as a downloadable PDF) of issues entrepreneurs should consider when designing a business model. Others posts in the series delve into specific issues; this one aims to provide some practical advice for entrepreneurs as they get started with business model analysis.
Why Bother?

Since the list in Part 1 of this series includes four dozen questions, entrepreneurs may see business model analysis as a daunting task and an unwelcome distraction at their venture’s outset. They may prefer to conduct a few interviews with prospective customers, then start building, in order to learn by doing in an improvised manner.

Eric Ries explains the dangers of this “Just Do It!” approach in his book, The Lean Startup, and I won’t repeat his arguments here. However, if the sheer length of the list of questions above is a deterrent, entrepreneurs should keep this in mind: due to serial interdependence between the questions—some cannot be considered until others are addressed first—it is not possible, necessary, or even desirable to answer all of the questions immediately and simultaneously. In the spirit of the lean startup, business model analysis is an iterative and ongoing process.

Most entrepreneurs begin the process with an insight about an unmet need and a potential solution for that problem. They explore the opportunity through customer discovery interviews, and use early feedback to refine their concept. Until their idea settles down, it makes no sense to push for deep understanding of pricing options, customer acquisition costs, working capital requirements, etc.

While entrepreneurs should avoid over-investing in detailed analysis of downstream topics, at some point early in the process of evaluating an opportunity, they should make a quick pass through all of the questions. Their goal should be to articulate hypotheses for as many questions as possible, and to gauge their team’s confidence that these hypotheses are on target. Back-of-the-envelope economics are adequate at this stage.

This quick but comprehensive scan is intended to ensure that the entrepreneur has not ignored any important business model elements. Likewise, the scan should surface potential “deal-breaker” issues early—in particular, any lack of internal consistency between business model elements—and to stimulate a search for ways to address them. For example, based on the initial scan a team might conclude: “We envision a complex new product that would probably best be sold through a face-to-face demonstration, but our ballpark unit economics suggest we cannot afford a direct sales force.”


Write It Down!



When conducting this first pass through the business model questions, entrepreneurs should write down their hypotheses, along with the key assumptions behind them. As their model evolves, entrepreneurs should adhere to this “write it down!” discipline. They should consider displaying a summary of their model as an information radiator—a prominent visual display that can be readily referenced and amended by team members—like the wall displays that many teams use to track the status of programming projects or progress with their product roadmap. For example, a wall-mounted white board could depict a business model “canvas,” following the approach suggested in Alex Osterwalder’s book, Business Model Generation. For some terrific examples of Osterwalder’s canvas in action, see the presentations done by Steve Blank’s students in his Lean LaunchPad course at Stanford.

Using the information radiator approach, members can affix different-colored Post-It notes in the cells of the canvas, showing the status of hypotheses for each business model question, for example: 1) green = the hypothesis has been validated through a decisive test; 2) yellow = a test that could validate the hypothesis has been identified, but not yet executed; 3) blue = a hypothesis has been advanced, but not a way to test it; and 4) pink = the question is important, it is too early to offer a hypothesis. As the team makes progress, pink notes will be replaced with blue ones, blue will be replaced with yellow, clusters of notes representing competing hypotheses about a single question will be pruned, etc. And, when the team makes a pivot—that is, when it changes its business model in significant ways due to a failure to validate a key hypothesis—large swaths of the board may revert from green notes back to yellow, blue, or pink ones.