Topic Reading Lists

▼

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.
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.





at