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 2011, 2010 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.
Posted by at

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.





Posted by at

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


Posted by at

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.
Posted by at
Labels:

Saturday, July 30, 2011

Business Model Analysis, Part 9: Outsourcing


This post is part of a series on business model analysis for entrepreneurs. The first post in the series presents a comprehensive list of issues (available as a downloadable PDF) entrepreneurs should consider when designing a business model. Others delve into specific issues; this one looks at factors that determine whether a startup should keep key activities in-house, versus outsourcing them.

The key word in the last sentence is "key." Serial entrepreneur Furqan Nazeeri has argued that startups, because they are resource constrained, should outsource all activities that do not contribute to long term, sustainable competitive advantage. VC Fred Wilson generally agrees, and notes that startups often make the mistake of outsourcing product development due to a lack of in-house skill, but in doing so they sacrifice the crucial ability to iterate the product designs (a point echoed by Vivek Wadhwa). Wilson also says that startups often outsource customer service due to perceived cost savings, but in doing so they forfeit valuable customer feedback.
Another consideration in deciding whether to outsource key activities is the prospect of asymmetry in bargaining between a startup and powerful partners. HubSpot's Dharmesh Shah has warned about the many risks that a startup confronts when negotiating with big companies. Serial entrepreneur and VC Marc Andreesen has likened dealing with big companies to the long, frustrating, and harrowing pursuit of Moby Dick.
I won't try to expand on those insights here. Rather, I'll focus on the microeconomics of in-house vs. outsource decisions, which, in economists' parlance, are choices about vertical integration. According to Yale Professor Oliver Williamson, there are economic advantages to completing transactions between two units within a vertically integrated company—rather than between two independent firms—when the transactions entail high levels of uncertainty, small numbers bargaining, and asset specificity.  With transactions between independent firms, uncertainty makes it difficult to draft a contract that specifies each party’s obligations under any contingency that might arise.  Absent a complete contract, the parties periodically will need to renegotiate transaction terms. If either party is subject to “small numbers bargaining,” that is, if it has few potential transaction partners, then that party may be vulnerable to hold-up when it renegotiates. Finally, if either party’s assets are tailored for a specific transaction type and cannot be redeployed into other uses, then failing to complete a crucial transaction—for example, securing an input required for production—may lead to bankruptcy with little liquidation value.

Startups frequently face the conditions that encourage vertical integration. By definition, they confront high levels of uncertainty. Also, when they target new markets with radical innovations, startups may require access to idiosyncratic assets controlled by only a few potential partners.

However, vertical integration poses challenges for resource-constrained startups, because it often requires major investments. Cake Financial, a service that gave investment advice to consumers based on analysis of their online stock trades, illustrates this dilemma. Cake’s founder had a choice between building software that could extract a customer’s trading data (with their permission) from their online brokerage accounts, or licensing access to the data from a firm that had already developed similar software. Concerned about that firm’s fees and whether it would be responsive to a small startup’s needs, Cake’s founder chose to build the software. This consumed most of the $9 million in venture capital that Cake had raised, and put the startup in a precarious position when demand for its service was slow to emerge and then capital markets slammed shut during the 2008 global economic crisis.
Posted by at
Labels: ,

Friday, July 29, 2011

Business Model Analysis, Part 8: Crossing the Chasm


This post is part of a series on business model analysis for entrepreneurs. The first post in the series presents a comprehensive list of issues (available as a downloadable PDF) entrepreneurs should consider when designing a business model. Others delve into specific issues; this one provides an overview of Geoffrey Moore's concept of crossing the chasm.

In his classic book on hi-tech marketing, Moore observed that customer adoption of revolutionary new technology products follows a predictable life cycle. Early adopters, according to Moore, are visionaries seeking breakthroughs; they can imagine the new product’s benefits before they have been proven. Because they are tech-savvy, early adopters can self-assemble complementary hardware, software, and services needed to use the new product, and can cope with its inevitable initial bugs. In the next stage of the product life cycle, the early majority—a much larger group—are pragmatists who will only buy a standardized product that has clearly proven benefits. They demand a “whole product solution”—an easy-to-use, reliable bundle of all necessary hardware, software, and services—supported by a reputable firm.



Moore observed that peer-to-peer references are crucial in driving technology purchase decisions. However, early adopters are not considered to be credible references by the early majority: there is a chasm separating the two groups because they rely upon such different purchasing criteria. As a result, new products that are successful with early adopters often stall when startups try to sell them to the early majority.

Moore’s prescription for crossing the chasm is to target a single segment within the early majority; to engineer a whole product solution with clear benefits for this segment; and to overwhelm the segment with an integrated, intensive marketing campaign. From this beachhead, the firm can then leverage referrals to capture other early majority market segments. Moore likens this strategy to World War II’s D-Day, when the Allies landed a massive force at Normandy as the first step in their invasion of Europe.

Most startups targeting fundamentally new markets will not encounter the chasm until they are a few years old; in the meantime, they will be busy cultivating early adopters. Consequently, seed-stage ventures can probably ignore the chasm risk as Steve Blank points out in Four Steps to the Epiphany. However, a “D-Day” strategy requires plenty of planning, so entrepreneurs should begin to watch for the chasm as their startup matures.
Posted by at
Labels: ,
Subscribe to: Posts (Atom)