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.