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.


  1. Sir,

    Does this course also benefit people who want to launch actual physical products?

    Sheshlok Samal

  2. Sheshlock: The students are all working on software applications, but the skills they are building (e.g., how to assess demand for a product; how to track team progress) should apply to physical products, too.

  3. Really cool to hear about this course. First thought is that it begins to address a gap in the MBA curriculum otherwise being approached by Skillshare and General Assembly.

    Also, you hit the nail on the head about "agile". Product management today is very iterative, so somehow accounting for this is essential. But I understand why it's hard to simulate that in the course. What if the course teamed up with engineers from the College and SEAS, so that development was "in-house" on each of these teams? I know that if I were a CS student at the College again, I would have loved to either cross-register or somehow be involved with this course.

  4. Jason: I've been thinking along exactly these lines, thanks. CS50, the intro course at Harvard College, has over 800 students enrolled, all of whom have to build a simple app. It'd be intriguing to merge the efforts in ways that allowed an agile team of a PM 101 student + a CS 50 student to specify and build an app. I'll give this more thought...

  5. Tom,

    Really great to hear that you guys are offering this course at HBS! I'm a Wharton undergrad, and I really wish we had a course like this. As Wharton professor Kartik Hosanagar observes, one of the greatest weaknesses of typical MBA entrepreneurs who just came from banking / consulting is their lack of product experience:

    I'm currently working on an ed tech startup (, and I'm thinking about towards more of a platform business model (I was directed to this post from your July 2011 post - Business Model Analysis, Part 2: Platforms and Network Effects, which I found through Google search). I hope to take the upcoming General Assembly 10-week course on Product Management to help me gain a better understanding of best practices in launching and scaling a platform.

    Anyway, thanks a lot for the great posts, and I look forward to following your future posts!


  6. By the way, it's great to see that you're also promoting the Lean Startup strategy. I did my first Lean Startup Machine workshop in in September, and I absolutely fell in love with it. I'm now a Lean Startup Machine workshop coordinator in Philly - currently organizing something for students at Wharton in January, and later for students Philly-wide in February.

  7. Clarke: Thanks for the encouraging words, and good luck with your startup. If you have a chance, please email me to let me know how you liked the GA course on product management. It looks terrific, and we're always on the lookout for fresh ways to teach this stuff.

  8. Tom you may consider including "Agile" or rapid prototyping management strategies for software and SaaS offering development efforts. Agile stakeholder management, communication and effective risk management are also critical exposure areas to consider for your students.

  9. Thanks, Kyle: I agree fully about the importance of learning agile. Our outside speakers talk about it, and students can read about it. The challenge is giving them hands-on experience with agile within the constraints of our course design. During the first semester, they don't work in a team, and during the second semester, after they recruit devs, they are not co-located with the devs, who are outside contractors. Not sure how to fix this, but some on Twitter have suggested integrating with a CS course where other students are building apps.

  10. Hi Tom,

    A: HNY to you and all the students.
    B: I so want to jump into PM101 class but nevertheless.
    C: I read couple of PRD's(Sample?)Couple of my inputs would be:
    1: Introduction (Would rather prefer to design a product where industry is rather moving. Ex(Mobile): Device Mgmt | Application Mgmt | Push Notification)
    2: It's assumptions and constraints
    3: Overview
    - Business Need
    - Customer Demand
    - Feature Description
    - 3 Customer use-cases
    4: Detailed Product Overview
    - Key Concepts
    - Key Structure
    - Distribution
    - Installation
    - Updates
    5: Detailed Product Anatomy
    - Top Level Keys
    - Product Types
    - Colors | Bar codes |Sections | Fields
    6: Product Eco System (With Phases)
    7: Product Workflow (With Phases)
    8: Product Framework
    9: Product Visual References

    PS: What i felt is,the more prod mgmt learning is done via/for industry oriented opportunistic...the better. Just a sample(arbit) prd/mrd(case studies) are of zero use when grads will be ready for job market.

    Best Wishes,

  11. Thanks, Mayank. I agree that the closer to industry, the better. Of course, few companies will let part-time, untrained students play a meaningful role in an important product development process. That's why we felt that giving the students hands-on practice with real apps that would get used by their peers was a step in the right direction -- as you say, much better than case studies.

  12. Tom - have you thought about partnering students with non-profits or state/local government (especially focused on leveraging open data - see to provide projects broader than just ones focused on the HBS community? That would give the students some real customers to interact with to gather requirements data, and maybe even solve some hard problems for those communities. I also agree that having the experts spending more time reacting to students' work-in-progress is critical. I took part in a start-up weekend at the University of Hawaii in November (, and found that the most valuable part of the program was getting that kind of feedback.

  13. Jon: We've thought about non-profits, but your suggestion about leveraging app development opportunities of state/local government is a new idea. Thanks!