pm@olin: Specs (Class 3)

Goals:

1. Explain what a “spec” is.
2. Provide more context for how to communicate with teams.
3. Provide one basic spec framework to adapt as needed for projects.
4. Get accustomed to writing specs and receiving feedback on them.

Optional Readings:

Want to be a PM? Do a project (Ellen Chisa)
Painless Functional Specifications (Joel Spolsky)
Why Even Lean Startups Need Functional Specs (Rian van der Merwe)
There’s Nothing Functional About A Functional Spec (37 Signals)
Making Things Happen - Chapter 7 (Scott Berkun)

Materials:

1. Make sure students bring laptops to be able to work on the spec.
2. Example specification documents if you have ones you can share.

Exercises:

This class is a bit more controversial than the other ones I’ve posted. It may be because I started my career at Microsoft, but I’m a firm believer in having some sort of spec. I don’t think the spec needs to be what people traditionally think of – a 50 page waterfall document type. Instead, I think it’s important to have everyone on one page about what you’ve agreed you want to build.

Having talked to many people who are in very agile environments, and having worked on many small projects, I’ve found the page one spec to be a good balance of defining what we’re doing, without overly constraining too early. Some projects many need more or less.

What type of Spec – 30 minutes

Given the caveat above, I started by discussing a 2×2 Framework of ways to consider a spec.

Quick <-> Long – How long will you be working on the project? I think the longer you’re going to be working on the project, likely, the more of a plan you’ll need up front. Even if you’re starting with experiments and building, it can be nice to have a further out vision.

Casual <-> Formal – This is more along the lines of “how risky is this?” If you screw up your hackathon project, no big deal. If you screw up your contract with the DOD, big deal.

To give an example in each area:

Quick/Formal – Product Owner, backlog, etc. You might just be doing an incremental feature at a time, so you can define it quickly. I also think that the Microsoft Design Change Request features fall into this bucket – they have a very small scope, which makes them quick, but it’s important to get them right, which is formal.

Quick/Casual – Hackathons. Something you might not be working on for very long, and is pretty casual. I gave an example from when I was at Olin – a few of us built a “virtual gum ball machine” as an excuse to try out Git and Heroku for the first time (!)

monster_gumball

Long/Formal – Projects with more stakeholders. DOD projects, Waterfall Microsoft projects (i.e. Office 2010), projects that you hand off to another company.

Long/Casual – I think this is probably the most rare type of project. Internal, Lots of mockups, drawings, permanent design space (UOCD studio).

IMG_6174

Page One Specs – 2 hours

The reason I opted to teach “Page One” Specs is I think they cover the most area. They can be most of what you need for a Quick/Formal project or a Long/Casual project, the first stage of a longer spec for a Long/Formal project, and it helps me organize my thoughts for side projects. They also have the benefit of being short – ideally, one page. Another tool that fits in here is wireframes. We’d already done that in Class 2, so I wanted to focus on the writing side.

To cover this we worked as a group. I explained a section of the page one spec, the students tried to write it for their projects, and then we went around the room and shared a few. I critiqued the statements live. While doing this it’s important to move around the room – everyone improved after hearing a few critiques, so you don’t want to critique the same person repeatedly.

While live critique can be painful, I also felt it was important in this context. Often a new PM will share their spec and be defensive the first time someone challenges it. (I remember getting ripped apart!) I was hoping to provide that experience in a safer place, so it would be less scary during a job.

To be honest, the students summed up most of my feedback as “don’t have any extra words.” I try to be concise in spec writing, but that might be a style issue.

Sections we covered:

  • Vision – Broad, motivational, short sentence.
  • Goals – What do you want to achieve by making this? This is less broad than the vision, but substantially more aspirational than the features.
  • Background – Why are you doing this? What’s going on in the space? Data to support the investment. I also say this is the section where you put “anything an executive insists on having in the doc, but isn’t useful.”
  • Scenarios – Stories about people using the Product that aren’t feature specific.
  • Features (prioritized) – We spent a significant amount of time here, and I think this is one of the most important sections to get right.
  • Success Metrics – We didn’t end up covering this because we ran out of time and have an entire class on metrics/analytics later.

During the conversation we also talked about:

  • How to scope specs and how many specs each project should have.
  • How to get other people involved in writing the spec, and how to circulate the spec after it’s written.
  • The concept of a “cutline” – when to delay launch to get the features in, and when to ship even if it isn’t perfect (shipping is a feature!)

Suggested Notes / Changes

1. I didn’t come prepared with specs I had written. It’s hard for students to grasp the concept in a vacuum, so I’d recommend bringing printouts of a few that they can reference.
2. This takes longer than the time we had available. In retrospect, I wish I’d covered the “what types of specs” on another day, and used this day completely for writing page one specs. I probably also could have been more efficient and not let every student share quite as often.
3. I am not in love the with long/formal 2×2 framework. I’d love to hear a note for another axis that you can think about a spec on, because long and formal seem pretty aligned.
4. This lesson is not great for non-software Products. I have one student who is exploring hardware ideas, and I had a hard time translating this. If anyone reading this is a hardware PM, I’d love some input/advice for the rest of my course.
This was me trying to write features for a blender:

IMG_6177

Personal:

One of the things I realized during this lesson was how much my class has gravitated around projects that I’ve done. I use them frequently as examples (it’s my context) – but now when I’m introducing something new, I get questions about old projects. “So would you say the Broadcast project was X or Y?” etc.

I’m not sure if this is a good or a bad thing. In some ways, I wish I’d had the benefit of talking to someone who honestly told me about a range of projects. On the other hand, I don’t want them to anchor too much off of only my personal experiences.

 

pm@olin: Business & Design (Class 2)

This week was special for me! I had the chance to bring my parents to class to watch me teach. Thanks to my students for allowing that to happen :)

Goals:

1. Understand the difference between a project and a business.
2. Give students business frameworks to understand the business aspects of their idea, the factors influencing adoption, and the factor’s influencing an industry.
3. Explain the PM’s role in the business process, and figuring out “what” to make.
4. Demonstrate the differences between the PM and Design responsibilities by playing both roles.
5. Discuss different design tools and when they are appropriate.

Optional Readings:

The Lean Startup (Eric Ries)
Crossing the Chasm (Geoffrey Moore)
Porter’s Five Forces (Wikipedia)
How to Work with Designers and How to Work with PMs (Julie Zhou)
PM-Designer Tension (Ellen Chisa)

Materials:

1. Business Model Canvas Printouts (one per student)
2. Whiteboard & Markers (set up board before class)
3. Blank paper and pens for sketching
4. Hat full of business ideas

Exercises:

As I’ve mentioned before, my students are familiar with basic Engineering/Design concepts. One of the things I didn’t realize early in my career was the importance of all of the aspects of a business. I gravitated more towards neat projects and less towards businesses.

Business Model Canvas (group) – 20 min

The Business Model Canvas is a tool from the book “Business Model Generation.” I haven’t written the book, but have been exposed to the Canvas in a few different contexts. I thought it was a lightweight way to get going.

The model covers a few key areas. It starts in the beginning with “Value Proposition” – or what I think of as being closest to Product. It expands out to cover partners, activities, resources, customer relationships, channels, and segments. The bottom if for cost structure and revenue.

I drew the Canvas on the board before class and we went through it together. I let the students pick the company we discussed, and they chose Airbnb. We filled it in for some of the challenges we brainstormed.

FullSizeRender_1

(Disclaimer: I’ve never worked at airbnb, so this isn’t necessarily correct. It was our best attempt at working through the tool so they could get experience).

Porter’s Five Forces and Roger’s Five Factors – 15 min

Next, I gave the students two of the classic business frameworks to consider. I wanted them to think about what would help their Product be adopted, and what other industry challenges they should consider. I’m not going to recap these here because there’s lots of good documentation on them if you aren’t already familiar.

FullSizeRender_4

 

FullSizeRender_3

 

Business Model Canvas (solo) – 35 min

After covering the three business frameworks, students spent time figuring out a business model canvas for their idea. If students did not come prepared with an idea, I had them pull one out of a hat.

They were technically working alone (i.e. not a group project), but the students sat at tables together and were free to discuss and ask each other for input. Some tables chose to do both ideas together.

After, we talked about some of the ideas and what they found useful/surprising as they thought through them from a business angle.

PM/ Designer Division Exercise – 1+ hour (rotate halfway)

The highlight of the class, in my mind, was the Design / PM Exercise.

The students broke into pairs. One student was the “PM” and responsible for communicating what they wanted to build based off their idea and their business model canvas. One student was the designer and responsible for creating wireframes based on the idea.

The intent was to give the students practice with specifying “what” instead of specifying how – and to help teach them how to convey ideas clearly while speaking. The PM wasn’t allowed to specify “I want these views” – instead, they just communicated what they wanted the user to be able to do overall. They also weren’t allowed to give real time feedback – instead the designer worked, and then explained their concept. Finally, the PM was allowed to practice giving feedback and revising the concepts.

After about half an hour most teams had managed to create some wireframes. There was definitely frustration during the process, which was the goal. In most roles, there isn’t such a strict division. I wanted the students to see what a strict division would be.

After half an hour, we discussed how it went, and then students flipped and tried the opposite role for about half an hour. I think it was a bit easier for the second set.

FullSizeRender_2

Design Tools – 20 min

We concluded by briefly covering a bunch of tools designers might use, and what’s good at what point in time. I wanted to give students an idea of the breadth of what’s available rather than just teaching them one tool in depth.

Again, I’m not going to list all the tools available here.

FullSizeRender (3)

Suggested Notes/Changes:

1. I introduced the Five Forces first and Five Factors second. I’d flip it around – start with adoption and then talk about industry context. I also didn’t introduce the “chasm” concept because I thought they’d know it already. They didn’t, so I should have included that in my original lesson plan – I already added it above.
2. Students didn’t have as much experience as I was hoping in terms of being able to act as designers and PMs. If I did it again, I’d take one group in the hallway and give some specific instructions to create more conflict (i.e. tell the designers to try to make a business call/pricing decision).
3. The idea hat didn’t work quite as well as I’d hoped. Students weren’t always entirely clear on some of the concepts.
4. It would have been nice to have more time to discuss the design tools, but we ran out of time.
5. This class covered A LOT of content. The students kept pace well, but it’s something to keep in mind.

pm@olin: Introduction (Class 1)

Goals:

  1. Let each student determine their own sense of “who am I as a Product Manager?”
  2. Generate a list of Learning Goals
  3. Co-create the remainder of the Syllabus
  4. Introduction to teacher & students

Optional Readings:

Materials:

  • Post it notes, notecards
  • Sharpies
  • Whiteboards & markers

Exercises (in order):

Defining Product Management (20 minutes): 

I had an advantage in this regard as Olin students are mostly familiar with the discipline. I didn’t need to do as much of the “PMs work with Engineers” – so we were able to be a bit more philosophical.

  • Individual Generation: I asked each student to take post it notes and write down what they associate with Product Management. As they went I gave more prompts such as [as a Product Manager] “What do you do first thing in the morning?” “What keeps you up at night?” “Who’s your ally within the company? Who don’t you like to work with?” Towards the end, I asked them to take their ideas and turn them into once sentence.
  • Pairing: I had students get in pairs and share their sentences, brainstorms, and discuss differences.
  • Group: Since we’re small (10) we were able to have each student share their sentence out loud and hear variation.

Frameworks (20 minutes):

I shared two frameworks to think about Product Management.

1. Business / Design / Technology: this one is pretty standard and is also used in a lot of design consulting. I just wanted to point out that PMs fall in very different places on this spectrum.

FullSizeRender

2. Five PM Dimensions: This one I made up. I think it still could use some work, but these are some attributes I’ve noticed while working, and I think it adds more practical “work” dynamics in addition to skills. How much these matter can vary based on the job, but I think it’s helpful to know where you are on these spectrums.

One student mentioned that she didn’t like the “tradeoff” aspect of this. It isn’t meant to say you can’t both start and finish – that would put you in the middle. I’ve noticed most people do have preferences towards one side or the other.

I used slightly different words to start with, but if I had to name them now, my best shot is:

  • Starter / Finisher – I think this is key. At Olin, many students start lots of projects and abandon them. At Microsoft, finishing strong is one of the most valued traits. An experienced PM once told me “a PM gets the job because they’re good at one, but to be really good you need to learn how to do both.”
  • Big Picture / Details – Are you good at picking a direction for the team? Or are you good at taking that direction and making sure every little piece works?
  • Owner / Executor – Does it matter to you if you have the final say? Do you want to create the vision and push it up, or are you okay with having a vision pushed down?
  • Technical / Nontechnical – As much as it pains me to admit it, this seems to be a big issue in the industry. It will matter more in some jobs than others.
  • Political / Autonomous – I wasn’t expecting how much political work would go into being a PM. In my mind this is “how much do you mind needing to network / socialize ideas / work with partner teams /etc ?”

FullSizeRender (1)

After sharing, I had the students think about where they fall on each of the frameworks, and where they might like to be.

Learning Goals (20 minutes):

After we talked about each of these areas and some of the work they entail, I had the students (as a starting point) write down what skills they wanted to learn. I gave them 10 minutes to do that, then asked them to take a couple minutes and pick out their top one.

We went around the circle and I wrote down each student’s top thing. My commitment is that through the class, everyone will improve at their first choice. Obviously, I’d like them to learn more. As it’s a one-credit class I’m looking to measure my/their effectiveness off of this metric.

I wasn’t sure what to expect, but I was pleasantly surprised by the outcome of this. There’s a wide spectrum of goals ranging from “proper task management skills” to “how to be friends with your team while maintaining authority.”

Syllabus (30 minutes):

The goals exercise translated nicely into discussing what I was going to cover during the semester. I put a list of topics up (by date) and asked students to add post it notes for anything specific they wanted to learn in that lesson. This might look a bit sparse because I talked while I was writing, but hopefully it helps get the idea across.

FullSizeRender (2)

I was also able to combine/move a few lessons to add topics that I hadn’t expected interest in. One topic we added was the Career Workshop – students were very interested in adjacent roles. The final pm@olin syllabus is here, and I’ll be adding a post like this for each class that we have.

Introductions (30 minutes):

The last topic we covered was introductions. I introduced myself – I added a fair amount of personal (why I went to Olin) and professional (what projects I did at Microsoft/Kickstarter). I let students ask anything they wanted to.

As we have the luxury of the small group, each student also did an introduction. I have a wide range of ages (including one freshman!) and a bunch of different interests. Some students are going to large companies, some want to start their own company, some want to be PMs full time, and some don’t. It’s a diverse group and I’m excited that it’s small enough that we can really get to know each other.

Suggested Changes/Notes:

  • I didn’t introduce myself at the beginning, as is customary at HBS. I wanted to jump straight into work. In hindsight, a brief introduction “Hi, I’m Ellen, and we’re going to jump right in but I’ll tell you more about myself later” would have helped.
  • The five dimensions could be different. Feel free to experiment and find ones that you think are most helpful (let me know!)
  • At Olin, co-creation is encouraged, so I felt very comfortable bringing a skeleton syllabus and asking the students to help me fill it in with their interests. This exercise might not work as effectively in a school that isn’t so focused on pedagogy.
  • There were more questions about what makes a “good” Product Manager than I would have expected – I added some readings to reflect that, and I’d suggest working it into your comments while teaching this lesson.

pm@olin: Syllabus

I mentioned earlier this year that I have the opportunity to teach a Product Management seminar at Olin (henceforth referred to as pm@olin). This course is aimed at students who have some knowledge of Engineering, Design, and Business, but have not been professional PMs.

This my first attempt at creating a PM curriculum from scratch – previously, I’ve created one-off lessons or worked from an established curriculum. I received suggestions and input from a many friends and colleagues. Based on that feedback this class is a mix of lessons that deal with PM’s primary obligations (what to build) and softer skills like negotiation and feedback.

I’ll be posting my lesson plan for each lesson individually and linking from this post. If you’re teaching a PM class, I’d be honored if you wanted to use some of these exercises (let me know how it goes!)  If you decide to replicate the entire class, attribution would be nice.

Each lesson will include:

  • Learning goals.
  • Suggested (non-required) readings on the topic.
  • Classroom exercises & required materials.
  • Classroom lecture notes.
  • Commentary on what worked well & what didn’t, suggestions for improvements.

Here’s our schedule:
February 4th – Introduction: What is PM? What type of PM are you? What do you still need to learn?
February 11th – Business & Design: What industries/markets/products are worth pursuing? How do I think about competition? How do I work with designers to scope the Product?
February 18th – Specs: when do I need a spec? How much spec? What does it include?
February 25th – Negotiation Workshop: Practicing Negotiation skills.
March 4th – Building: Who does what when we’re building software? What’s project management? How does that change in Agile vs. Waterfall? What tools can I use? What’s bug triage and how do I do it? What will I mess up the first time?
March 11th – Career Workshop: Is PM for me? How do I find a good fit? How do other people see PM vs. other disciplines?
March 18th is Spring Break.
March 25th – Launching: How do you launch a product or an update?
April 1st- Feedback Workshop: Giving and Receiving Feedback, project postmortems.
April 8th – Analytics: What do I track? How do I track it? How does this vary for B2B vs. B2C?
April 15th – Presentation Workshop: Presence, Leadership, and speaking on the fly.
April 22nd – Lingering questions and topics that come up throughout the other classes –possibly Diversity in Tech.
April 29th – Capstone: TBD (I have an exciting idea for this, but still hammering out some details).

One question that came up early on from my students was “will you tell us what other people think?” I definitely want to give multiple perspectives. I’ve built the lessons based on that. As I share lessons, if you think I missed something critical, please let me know! I’d be happy to update in the next class with another perspective.

I’m also looking for some Boston-area guests on March 11th. I’d love a mix of perspectives, and particularly some people who have held PM and another role (content, engineer, designer). If you’re interested in joining us, please let me know!

Newsweek, Allies, and Critique

Earlier today an article came out on Newsweek about the state of women in Silicon Valley. As disclosure, I spoke with Nina before her article, and she mentions this Manifesto that I co-signed. I enjoyed our conversation, and I know the article doesn’t cover the depth of the conversations she had.

It does include comments from Vivek Wadhwa, a Silicon Valley investor, diversity coach and author of Innovating Women (as given in the article).

The comment is “Wadhwa says shaky self-confidence is one of the chief things holding women back. It’s not just about the money, though. Wadhwa says women not only are reluctant to overstate their accomplishments and goals; they habitually understate them. “Often I have to say to them, Why are you underselling?” he says. “When I coach women, I tell them how wonderful they are. Women won’t make the ridiculous projections about their companies that the guys will. They won’t say the really stupid thing the nerds do. They are a lot more realistic and practical and humble.”

I was only loosely familiar with Wadhwa’s work before today. He’s oft-cited in the technology press for working on issues of gender & technology, but I hadn’t dug into the details. I’ve also noticed many women that I respect (particularly Cate Huston) criticizing his involvement.

This comment caught me off guard.

It sounds like a positive. “They (women) won’t say the really stupid things that nerds do.” It’s not positive.

I have an Engineering degree. I say really stupid nerd things all the time. The most excited I’ve ever gotten in an HBS class was when I got to explain Milling Machines and 3D printers. I was most disappointed when we didn’t actually talk about electrical connectors in an accounting case. Wadhwa betrays bias in implying that women aren’t nerds. There’s a wide spectrum of women who work in technology – and yes – many of us are nerds.

The comment also supports the existing narrative that women should “lean in” and exaggerate. I’d much rather everyone give realistic projections than women start exaggerating as well. This isn’t everyone’s opinion, but it is mine.

Today, I wanted to find out where Wadhwa is getting information from because he clearly holds a different perspective from me.

I started out by trying to look at Innovating Women. On Amazon, there wasn’t a list of contents of the book or who he’d spoken to. I went to the book’s webpage and found a similar problem. While I can get to a photo grid of women, it doesn’t list their names. This makes it harder to find out more about these women – or ask them for comment in articles.

I also figured that day to day interaction probably counts for more than one-off interviews. I know that I say things differently when it’s “official” than when I chat with friends. So I also did some quick stats on who Wadhwa’s following on Twitter:

I tried to be generous with my counts. I was liberal in my definition of “tech” – I didn’t look so much at women in STEM as much as women doing operating roles. I included VCs and founders in the count of 33.

This data is just one indicator. It could be that Wadhwa uses Twitter entirely for media relations, and communicates with women in technology another way. He might just not be communicating with women who share my views, and that’s why his comment rings false.

Wadhwa did respond to criticism today:

I’m not sure if he saw my comment, or if included it in his group.

I don’t mind that Wadhwa spoke up. I think we need more allies making comments. I do mind that he made a comment that doesn’t seem to fairly represent women in technology. I also mind the way he’s portraying honest critique.

It’s crucial that we critique public statements on this issue. There aren’t many people who are willing to speak up, so the few voices are amplified to an unreasonable degree. This means we lack a broad, nuanced perspective that could propel us forward. If you’re speaking for a group, you should be anxious to hear how their perspective differs. You should also encourage new voices.

When I started writing about gender and technology issues, I was nervous for this reason. I needn’t have been – I’ve received criticism, my views have evolved, and we make progress. I’ll receive criticism for writing this piece, and that’s okay.

Women need to be able to speak about their own experiences in technology. Writers need a variety of perspectives to write good stories, including those from men. As long as we have so few voices speaking up on the issue, we need to be able to critique them.

The best way to make this discussion and critique less scary for everyone? Write something. Or go as far as to start your own brand.

 

 

 

 

Product Management Curriculum

This Spring I have an opportunity to do something that’s (quietly) sat in the back of my mind since I graduated: I get to teach a class at my alma mater, Olin College.

Olin strives to educate a new type of Engineer. Part of that is constantly experimenting with new things*. A recent experiment is having Olin alumni teach evening “seminars” to group of students. This Spring I’ll be teaching a seminar on Product Management.

It’s a unique opportunity for me. Most Product Management classes help people transition into the discipline. Oliners have most of the fundamentals – they know technical skills, they’ve learned about user centered design, and they’ve taken a Products & Markets class. This class can be based purely on how to practice and integrate those skills into Product Management. We’ll have fourteen weeks with about three hours per week to work together.

This is where you come in:

  • What do you wish you’d learned before your first Product Management job?
  • Is there one skill you think a PM needs? Which one?
  • Any (uncommon) must-read articles? Most work will be in class, but I’ll assign some light reading.

Let me know in the comments, on Twitter, or via email! I’m also open to hear about any exercises you think would be good. After the seminar concludes, I’ll put the curriculum and some notes online for anyone else to use.

* If you want to learn more about Olin, this book is great.

2014 in Review

I sat down to write this on New Year’s Eve and struggled. I’m taking advantage of my (jetlagged) time in Jakarta to get it out.

2014 was a very good year – possibly supplanting 2004 as my favorite. It came with a lot of changes: two months of travel, a move (back) to Boston, and starting at HBS. I definitely got more done than I had in many other years. If it had a drawback, I’d say I spent a lot of time doing things, but not necessarily prioritizing which ones were important.  I’ll need to figure out which ones are, because I don’t think I could keep up this level of activity every year.

HBS

This was (by far) the biggest part of my year. I learned how to read financial statements (FYI: an Income Statement and a Profit & Loss are used interchangeably). I learned how to use those financial statements to make future projections, or to value a stock based on a company’s expected income. I learned about discrete and continuous process flow operations – and the impact of adding a “buffer” to a system, or adding extra capacity. It’s impossible to summarize all the things you learn at HBS in one paragraph, so suffice it to say that I’ve learned a lot.

Reading

I read 115 books in 2014. This is the most I’d read since I started tracking in 2009, when my New Year’s Resolution was to read an hour per day.  This was more notable for me given how much more I had to read for school than I ever did for work. I could tell by the end of the year that my reading speed was getting faster.

It was pretty equal fiction/nonfiction again – 56/59. It was shockingly biased towards women authors – 80 books by women and 35 by men. The full list is available on Goodreads. Here’s a few specific recommendations…

Autobiography of a Face and Truth & Beauty – if you read these, read them paired. It was enjoyable to hear Lucy Grealy’s take on her own situation, and Ann Patchett’s relationship on the situation. I’d read a bunch of Ann Patchett before going down this track, so I have to admit I preferred Truth & Beauty.

Whistling Vivaldi – For as much as I talk about gender and tech issues, I often worry about a lack of hard data for some of the things we discuss. (Kieran Synder has done some good work on this this year). I enjoyed seeing more of the academic studies on stereotype threat, particularly because they were done across groups and industries.

Several Short Sentences about Writing – As mentioned below, I wrote far more this year than ever before. Earlier in the year, Yancey bought 14 copies of this book for the Kickstarter office. I then bought my own, and one for a Secret Santa gift this year. I like the near-poetry format of the book, and it has some solid writing advice, too.

The Opposite of Loneliness: Essays and Stories – This is a collection of essays by Marina Keegan, a Yale ’12 graduate who died in an auto accident shortly after graduation. I read the Opposite of Loneliness shortly after that happened, and enjoyed getting to read a fuller collection of her work. I’m very sorry there won’t be more of it.

Inspired – I’d avoided reading this book for years because I thought the title was hokey. In reality, it’s probably the most solid “textbook” we have for Product Management. It forced me to reflect on how I define the role – and particularly about what I want out of the role vs. what the role should be.

Writing

I wrote 52+ things in 2014 – 46 on this blog, three on Medium (for TheList!), one for the Popforms blog, a The Setup profile (which ended up in MacWorld!), one for ACMQueue, and contributed to aboutfeminism.me.  The most widely read was “I’m Angry because I’m Afraid” and my personal favorite was probably “Want to be a PM? Do a project.

One of the things I did during 2014 was try to only write if I had “something to say” – usually with a takeaway that was tied up in a bow. While some of the pieces were hard to write, I at least felt like I had an “answer.” I was afraid to write things if I felt like they left holes open, or people would be able to get traction to argue.

In retrospect, I think that limited my writing. This year, I’d like to be more courageous in a different way. I’d like to share more things that aren’t entirely resolved yet, and use the writing as a way to learn. That’s definitely been the case for some of the things I’ve written about HBS so far.

At some point I also lost a more personal nature that my blog used to have. If you read back far enough most of the entries are about baking cupcakes, and about my personal life. I’m going to try to weave that back in this year.

Shipping

2014 was a low year in terms of “shipping” – 2013 held my big three projects at Kickstarter – The Start Page, Advanced Discovery, and the Backer History changes.

2014 included smaller projects, like making the navigation menus match, and a security history feature. While they might not be as splashy, it’s still more than I shipped in 2010, or 2011. I think doing small improvements is an underrated part of Product Management.

On the bigger side, I did start working on a personal project. Tom and I made an iOS app that’s currently only on my phone, but I’m glad even that small version exists. Hopefully 2015 will involve a public debut.

Teaching, Speaking, and Events

This was also a big part of my year. I taught classes for Startup Institute again, and at General Assembly for the first time (including a 10 week class!) I spoke at #ProductSF and Beyond the Code. I also helped with a few cool events: a Women in Product networking event with Stacy-Marie, and ProductDebaters in Boston. Steven and I started a Product Management breakfast in NYC that’s still running regularly (get invites!)

I didn’t track exactly how many, but I met with a lot of people who were interested in getting into Product Management (I’d guess 1-2 per week, so between 52 and 104).

<update> Conclusions I was attempting to not do “takeaways” – but that was a bit abrupt. In summary, 2014 was a good year.

 

HBS FIELD Day 1 (Indonesian Recipes!)

I usually leave my blog for work that involves “takeaways”. Right now, I’m currently on a trip to Indonesia for HBS FIELD, and wanted to share some of what I’ve done.  This is more personal and less practical.

I ended up in Indonesia at 2am, after 36+ hours of traveling – BOS-SEA, SEA-Seoul, Seoul-Jakarta. I napped for a few hours, and at 8am we head out for our first day of exploration.

We started the morning at an Indonesian market to buy groceries in preparation for cooking class.

IMG_0001

 

I learned that duck eggs are blue, and quail eggs are speckled:

IMG_0014

Palm leaves are used to wrap rice, and tempeh:

IMG_0012

There are lots of fish and cool vegetables:

IMG_0008

IMG_0004

We paired off into groups to make six different Indonesian dishes. Indonesia is a geographically diverse country, and the food varies by region. The three chefs we worked with were from different areas – (I think) Jakarta, West Java, and North Java. There are also three primary types of sauces/pastes that go with the dishes. A white sauce, a red sauce, and a sauce I’ve already forgotten.

IMG_0031

I wanted to share the recipes for the dishes we made. I haven’t had a chance to type them up, so I’ve linked to images of the paper copies that I have.

Gado-Gado: A vegetable salad (not lettuce based), with a peanut sauce. The peanut sauce can be used independently with other recipes as well.
Soto Ayam Madura (IngredientsDirections) : A lemongrass-chicken soup (my favorite). I’d make a ton of this and eat it as a meal.
Sambal Fried Potatoes: I feel like every culture has a type of fried potatoes. These are chopped small and in a red sauce.
Tempe and Tofu Bumbu Kuning: A fried tempeh/tofu with spaces (this is the one I made!) It’s particularly good with the peanut sauce. We also learned how to make flower plate decorations out of chili peppers.

IMG_0024

Grilled Chicken with (coconut) Curry Sauce: this one was also a highlight.
Nasi Uduk: A rice/egg dish.

Why I’m Writing about HBS

I’ve written a couple times about HBS in the last few days - positive and critical. While I have a few more positive things coming, I wanted to pause to explain why I bother to write.

I’ve been lucky to spend time at places that are receptive to feedback. At Olin, students co-create the school. We went to President’s Council meetings, curriculum reviews, and helped in the admissions process. Nothing was off limits for discussion. At times I’d suggest something and it would happen within days. (Trust me, not all my ideas were good – but they were interesting experiments).

Kickstarter was similar. There aren’t many posts critical of Kickstarter on my blog. That’s because the conversation was open internally. I was able to work through the things I was thinking about with my colleagues. Those conversations have resulted in other output. For instance, this talk wouldn’t have happened without the tension & resolution.

This has become my expectation. I’m at HBS to have the best possible HBS experience that I can. I’m also at HBS to give back in the ways that I’m able to.

I try to give back in the expected ways. I went to every single class (first time ever!) and tried to add unique comments. I’m available to talk with any student who wants to run a Kickstarter project. I wrote a talk on how to interview for Product Management jobs.

But I want us to have more of a public dialog about what we’re learning, and how we’re learning it. I’ve also had some great conversations about that behind closed doors. But those conversations don’t seem to happen as a community. I wish they did. 900 new students come to HBS each year, with new ideas. I think they could make the program better.

That challenge isn’t unique of HBS – I found Microsoft to be similar. In an established organization, it’s hard to hear all the thoughts. It’s particularly hard to do so without causing chaos. You can’t change everything all at once.

So, no, I’m not struggling too much with my own tradeoffs. And no, I’m not worried that I could have spent my time doing something else. I’m not writing to complain.

I’m writing because I want us to have more of a conversation about what we learn, and why. I’m providing my thoughts and reactions as a way to start that conversation.

The Isolation of HBS

I was happy to get the chance to reflect on HBS. Since then, a few more classmates have as well. I wanted to share their reflections, as I think they bring a more balanced perspective to mine. I agree with the underlying message in each. Here’s Philip’s Reflection on Myths of HBS, and here are Sparsh’s personal thoughts[ed: if you're an HBS student with a reflection up, I'm happy to add a link here, just let me know].

Besides “busy,” I’ve also noticed that HBS forces students onto a shared path.

One night when I was feeling particularly cynical, I made a sketch of how it felt. I don’t have it with me, so here’s a written version:

HBS is a giant highway. All the students are on the highway. The highway is paved, the billboards give clear instruction, and the view is nice. The problem is, if you stay on the highway long enough, there are only two exits: consulting and banking.

Next to the highway there’s also a little trail through the woods. It’s technically a path through HBS, too. It’s lonely, but gives you more space to think and reflect. It’s bumpy and not as smooth as the highway. You feel like you’re doing it wrong pretty often. And the trail goes close enough that you can see the highway, so it’s easy to keep ending up on the highway, even if you don’t mean to.

HBS claims it wants those nontraditional candidates – the ones on the trail. Students who want to do something other than consulting or banking – and get involved in other communities. After a semester, I’m just not seeing it.

As mentioned yesterday, everyone is busy. “Busy” starts with the time constraints created by HBS.

Even a job gives you flexibility that HBS does not. Coffee with mentors? Only if they’ll meet you at 7am, near campus. Product Management breakfast? Not an option anymore – I have discussion group from 8-9, every day. Conferences that happen on a weekday? Once again, class has to take precedence – no vacation time you can use.

Even if you want to attend other events at Harvard, it’s hard. Lunchtime research seminars organized for PhD students, but open to the public? Definitely conflict with class.

Even just the class schedule restrictions result in a limited amount of time to do anything. Then you have to toss on recruiting and extracurricular activities.

Most of the things that fit in the time that’s available are planned for HBS students. No one else is planning around the HBS schedule – nor should they. It’s not impossible to do other things, but it’s hard and most people don’t. I have a hard time blaming students too much for that – the system pushes people not to. Instead, students take part in the HBS system. They create clubs, take leadership roles, plan conferences, use HBS mentors, go to parties.

To be clear, before HBS, people had a job, hobbies, and a personal life. At HBS, it goes like this:

Your job is going to class, which is at HBS.
Your hobbies are HBS clubs, which are at HBS.
Your personal life and friends are also attending HBS.

To me, these things feel superfluous compared to the resources outside communities already have.

Instead of attending existing tech conferences, HBS made it’s own (Cyberposium). Instead of outside design conferences? DesignxHarvard. I rarely see students discuss events outside of the ones sponsored by HBS groups.

For every new field of interest, a group forms on campus instead of getting involved outside.

Why do HBS need all their own events, anyway? I’m all for starting new groups, but I’m also all for seeing what already exists.

This would bother me less, but it isn’t just about the events. The same system seems designed to shove people towards a “standard” MBA path after.

Want to interview with a consulting firm? Great! There are dedicated days where they come to campus and talk to you. All their events will be scheduled around the class schedule, so you never have to be absent. Everything will fit in the areas HBS makes for you.

Want to interview with a small startup in Seattle? Much harder. They’re never going to come to campus, and if you want to interview – you have to tell them to put it on one of the days there aren’t class. The career days are often Tuesdays – no way to fly to Seattle and back for a Tuesday. Then you’d better hope you find out about it and get an interview scheduled over WesTrek or Spring Break. That makes you look back to the startup – who wants someone that can only interview on two days? To me, that seems arrogant.

I’m also disappointed in this from the town-gown angle. I’ve always been hoping for another significant tech hub outside of the Valley – be it Seattle, NYC, Boston, Boulder, or Austin.

One of the laments common in the Boston tech scene is that students always leave. This doesn’t surprise me: from what I’ve seen at HBS, going to a school in Boston doesn’t make you loyal to Boston – because you’ve never DONE anything in Boston. It’s all about the school environment that you were isolated in.

Obviously, HBS has designed the program intentionally. I know there’s the intent to have a bootcamp, to have a shared experience. But in my mind, following a pre-set path isn’t what “leaders” do.

If you want a job in consulting or banking, go to HBS. No brainer. You’re going to get all the fundamentals you need, and all the path is convenient, structured, and there for you.

Want to do something else? The jury’s still out.  I hope that it’s less likely this in the following three terms, and I’ll keep you posted. For now, we need more nontraditional people if this is going to change. But, I’m not sure if it will, I’m not sure HBS wants it to, and I’m not sure if it should.

update: I’ve noticed that many people think this post is a frustration about my own balance. I’m doing fine (thanks for the concern!) For me, it’s more about opening the conversation. I wrote a little bit about that here.