Startup Lockdown – Day 5 – Goalie

Day Five was our broadest day. We started from the idea of “using your time better” and “doing tasks when you’re at the right energy level.” This somehow related to time usage and major goals.

For me, it was also the toughest. After four days of focusing from 9am – 8pm, it was hard to get the energy at the same level.

Fast & Slow Time

We tried to get a balance of the processes on this day. We had the idea of having some time that was talk, which was “slow” – and then some time that was pure execution that was time boxed very specifically.

I don’t think we optimized it as much as we would have liked to, but it was harder by Friday. If I were starting on a Monday again, I’d try to include this.

Designated Breaks

Day Five was also the first time we followed our designated breaks. Our photographer got goofy and asked us to juggle lemons, which ended up being really fun. If I were doing this again, I’d include designated breaks with wacky activities.


This was also the first one where we didn’t just have “normal” and “extreme” users. We also managed to talk to an industry expert, Leslie Perlow, a professor at HBS.

You can watch her TED talk here. Perlow’s work centers on the idea of how you have better balance in terms of achieving both professional and personal goals – and around having a shared team mentality for doing both.

This helped us move from the idea of interviewing individuals about their calendar, to how our tool might fit in for groups of people.

Idea Iteration

This was the day we iterated the most on the idea. We talked about times of day, energy levels, how necessary tasks were, “types” of tasks, long term goals, medium term goals, priorities, and “elephants” (our catch all word to try to express that not everything is a task or a goal). We talked about how these things are used in teams vs for individuals.

We sketched the most “different” products on this day, and also spent the most time exploring other calendar/task products that were available.

Consumerization of the Enterprise

This was also the first day we spent more time thinking about a specific trend in products. Caitlin brought in a lot of experience from having looked at many different deals involving individuals bringing tools to the enterprise.

We also learned that semantics matter a lot – these were some of our tensest arguments, even though it turned out we were all in relative agreement.

Personal applicability

This day was also fun because it was personally applicable. While we were working, I cleaned off my computer desktop (it feels so much better now!)

I also got to test out our frameworks using my calendar – so now my events are colored by:

Have to/want to
Have to/don’t want to
Want to/don’t have to
Don’t want to/Don’t have to

Just being able to see my calendar and how I feel about the events per week makes a big difference for me.

Sloppiness at the end

The last part is that we definitely got sloppy by the end. We accidentally made our logo the Windows logo. We moved more slowly. I can attest that the quality of my work Friday afternoon was rock bottom for my week.

I spend a lot of time thinking about “finishing strong” – but I definitely didn’t manage to this time around.

Final Product: Your Goalie - a way to re-evaluate your calendar based on what you want to do, and what you have to do.



Startup Lockdown – Day 4 – Freelancia

Pivoting Before Starting

The fourth day of Startup Lockdown was challenging. We’d decided on Wednesday not to pursue “Day Launcher” because we didn’t have a viable business idea.

My best Product idea for Day Launcher was inspired by Eddy Adams’ shower method: An alarm clock that immediately started a Mission Impossible countdown sequence. Five minutes to shower. Five minutes to dress. Two minutes to grab your (pre-made) breakfast from the fridge to take with you, etc.

As much as I think it’d be fun (I’m up for spec’ing if someone’s up for building) it seems more like a project.

Instead, Ananya came to us with the idea of “Employees as a Service” – a way to hire some time from repeat contractors, depending on the skills you needed (but not all the time).

Marketplaces are 2x the work

Like with Waggr on Tuesday, we had to interview two different sets of users. After this week, I’m more in the camp of “Marketplaces are twice as much work” – because you’re basically trying to find Product Market fit twice.

In this case, by the end of the morning, we hadn’t found it on both sides. We’d found more interesting issues on the Freelancer side – so we decided to start there instead.

Some insights from freelancers: a lot of the job is educating clients, it’s frustrating to have to do all the “business overhead” instead of just working, and it’s hard to not have a community and mentors around.

Energy Levels

We also struggled on Thursday with our Energy level. By Thursday at least a few of us were distracted by our “real” lives. I was trying to schedule some meetings that couldn’t wait, Nate needed to tend to his nonprofit.

The energy levels hurt focus. I knew this before, but even moreso now: you cannot sprint all the time.

Leadership styles

Thursday was also a leadership contrast. Lots of HBSers are lead-from-the-front type leaders. Ananya is much of more of a guide-from-the-side leader (which I prefer!)

At least one team member felt they did their best work on Thursday. I felt that I did the work most outside of my comfort zone on Thursday.

Working outside your comfort zone

Part of why I was interested in this topic was that I would like to do more freelance work. I felt like I didn’t know how to start – let alone how to teach a class on it!

But as I started to read more literature – I realized that wasn’t the case. I just hadn’t been thinking of my work as freelance, even though it was. On top of that, I’d defined a very specific niche, so it doesn’t look like a lot of other work.

Probably the best thing that will come out of Freelancia (for me) is a better understanding of my own skills and goals.

Final Product: Freelancia - courses, content & community to build your freelance business.

Startup Lockdown – Day 3 – Voyahago

The third day we started with the most defined idea – a tool to help people build a skill over their vacation. This was prompted from Caitlin’s Kiteboarding vacations. She spent a month in Cabarete over the summer practicing – but it took her forever to find the best place – compiling information from forums all over the internet.

It also wasn’t just Caitlin, Libby tweeted about the same problem:

I’m also in this boat. I spent part of January doing Yoga in Cambodia. I went to Italy because my friend was doing research in Pompeii. Longer ago I went Horseback riding at Bellota Ranch in Arizona. I would use this product if it existed!


This day was definitely one where we “frankensteined” the process more than was helpful.

Caitlin wanted to stay truer to the original Startup Lockdown process (focused primarily on validation) instead of on the process we’d been using (starting from a problem area and finding customer insights). She felt obligated to keep pieces of what we’d done on days one/two – in part because I’d been really emphatic about user testing.

Pick the Right Users

We should’ve built for the few people we knew had this problem. Instead, we spent some time interviewing people in coffee shops – but most people don’t think of their vacations this way. If you already decided what the exact problem you’re solving for, don’t interview people who don’t have that problem.

Impact on Me

I think the most important thing I got out of this was that my process isn’t necessarily right. I’ve been really attached to the idea of doing deep user research to get insights. I’m also relatively bought in on “founders solving their own problems”. That said, I’m pretty deeply attached to my own process. I didn’t realize how inflexible I was until this week. I’m going to commit to being more open minded with trying out different ones.


This was also a day that I felt “prioritization” keenly. We spent a long time finding good stock photography and actually researching good travel sites. This ended up being very time consuming. We might have been better off outsourcing that to someone else to research, and continuing to test and see what types of trips people were interested / tried to actually book someone a trip.

Naming Stuff is Hard

Each time we had a really hard time nailing the name, logo, and brand voice for the company. This was no exception. It was the first time we managed to get a .com domain though!

Final Product: Voyahago: Book your trip based on what you want to learn.

Startup Lockdown – Day 2 – Waggr

Day 2 of startup lockdown was “Ethical Puppy Marketplace”

Let me stop right there.

My first big learning was:

People really like to tell you about ethics and puppies.

I had not yet found a topic that people would so willfully share their opinion on (or not). This is HUGELY charged in a way I hadn’t realized.

Some people were personally offended that I’d tackle this topic for a day. One of my friends refused to discuss how he purchased a puppy because I might judge him. Any posts on Facebook walls resulted in a long stream of comments pontificating on their perfect purebred dog, or on the horrors of why people shouldn’t buy dogs.

Everyone has their own definition of what an “ethical” puppy means. Also, for the rest of this, when I say “puppy” assume I mean a purebred puppy.

So what is ethical?

I’m still struggling with this. Gutenberg, my cat, is adopted. I adopted her from an acquaintance when she was a kitten (their cat accidentally got pregnant). I’m pro-adopting of animals.

I also learned a lot more about why people don’t necessarily adopt dogs from the shelter. Sometimes they want a dog that has certain qualities. More often, they’re nervous about being able to properly care for a rescue dog. Particularly when someone is getting a first-pet, they want to set the relationship up for success. Buying a puppy feels less risky. We also learned that first-time buyers are more open to adoption the second time around: when they’re more comfortable.

Maybe those people need another way to buy puppies?

”Good” Puppies are hard to buy

That’s the other thing I didn’t realize. It’s very hard to buy a puppy from a breeder now – most breeders have few (think: 2-10) puppies available per year. They do extensive interviews to find the right home. They aren’t super tech savvy.

It’s important to go to a qualified breeder if you want to get a healthy dog. Even breeding clubs don’t think that all of their members meet the ideal standard (the AKC “Breeder of Merit” distinction is one metric people go off of).

Some people have even had assistants go through and call lots of different breeders to get through the process – but everyone agrees that it’s a lot of paperwork.

One thing I’m wondering is if this dynamic makes people more likely to buy from a puppy mill/pet store.

Can we help people get puppies, without encouraging puppy mills?

So that brings me to: how should this work? If someone decides they definitely wasn’t a purebred puppy – is there any way to talk them out of it? Does a clear system make it more likely for people to get good dogs? Or does it increase demand/access, and thus also increase puppy mills? I’m not sure.

In class last week we discussed a case on HR Block and if they should adopt a product that was similar to Payday loans. From a business side, their competitors were and they needed to remain competitive. If you need to do something unethical to stay in business, should you do it? In my mind, no. Another student raised the perspective of “if all the good people avoid ethically challenging businesses, how do we force them to get better?” It really resonated with me. A significant number of people are going to use payday loans – particularly unbanked people. If this is a system that’s going to happen – do we want to avoid it at all costs, or do we want to figure out a way to build it without gouging people?

(I’m still not sure).

I feel a similar way about the puppy situation. Lots of things aren’t perfectly ethical. I think rescuing dogs is probably better, but I can also see why people are nervous. Is it better to let people have a puppy the first time along?

I’m still not sure.


That qualm aside, we came to the idea of Waggr.

Waggr is a broker system for people who are looking for puppies. Rather than having to call and build relationships with each breeder, we have a staff of “experts” who are familiar with each breed. They build relationships with breeders, and also with buyers, to make sure each puppy is placed in the right place. The top priority is always making sure the puppy ends up in the right place.

Personal Learnings:

  1. One of the problems with building a business in a day is you can’t properly sort out the ethics and long term consequences of a lot of businesses within a day. Puppies is more obvious, but people also pointed out that Pickld won’t solve the underlying problem of helping people focus on who matters.
  2. Having a day limit makes me more likely to do things I wouldn’t normally. With Pickld its as making the SquareSpace page (normally I’d want to build from scratch). With Waggr I had to get comfortable with quickly sketching a logo. It’s not ideal, but I’m glad I did it once.

Here’s my logo!




Startup Lockdown – Day 1 – Pickld

As mentioned in my initial post, Day 1 of Startup Lockdown was for “personal CRM.” When we went in, we were thinking more along the lines of “personal system for the sorts of things professional CRMs do.”

By the end of the day, we’d gotten to Pickld – Pickld allows you write down a few friends and get an email 1, 3, 6, or 12 months later prompting you to reach out to the friends you’d mentioned.

This first version of Pickld is a step in the right direction, but it’s not the full vision. We took a ton away from interviewing a bunch of interesting people yesterday. Thank you to those who helped!

Here’s some of what we learned yesterday*:

People don’t remember all their friends:
If you have to make a list of your friends, it’ll be based on your mood and you’ll miss a ton of people. You can’t do this all at once.

A personal aside, this is a personal problem too: once I made a list of “My Best Friends” (for my list book) and Nikki was like, 18th on the list. Nikki is one of my very best friends, but I saw her so often that it didn’t even occur to me to write her down).

People put their friends in tiers

People put their friends into tiers. It’s the closest friends (people you’re going to stay in touch with no matter what – your partner, your best friend), a larger group that tends to be around the “Dunbar number” and everyone else.

The middle group is the issue

In professional CRMs, it’s all about tracking everything. You don’t know which lead is going to end up being the most valuable – and you care a lot about the people on the periphery.

For personal life, that’s not the case. It’s the group in the middle that causes people most angst. People are perfectly okay with letting go of someone connections – or only reaching out when they need to. It’s considered acceptable.

The middle area is where guilt comes up:

  • The family member you aren’t too close with, but want to know to visit if you’re in their city.
  • The roommate you fell out of touch with after moving.
  • Someone you met at a conference, and an instant bond with, and want to get closer – but you live in different cities.

It’s worse during transitions

This middle place is particularly rough when you go through a life transition. People you see all the time in casual space stop being people you see all the time – and that means you might fall out of touch.

Ideally, once you’ve stabilized after the transition, you’d have the option to make sure you were still close with everyone who matters. Unfortunately, you often forget about it – few people have angst of “oh I was close with this person” – because we come to terms with our choices. People do have fear of losing touch with people now, even if they don’t remember the past people.

Reconnection is based on triggers

You don’t always remember people at a convenient moment. You might remember your best friend who likes water towers when you see a water tower, but that’s not a good time to call. You might see a post in your Facebook feed and say “oh I should get in touch to actually catch up” – but again, it’s not. The comment doesn’t feel like the right option.

So, Pickld

We didn’t know a ton about personal CRMs in the space before starting. We did a bunch of research yesterday – and most of them are in the space we expected. It’s similar to a sales tool (importing everyone) or requires a lot of personal effort to remember who you want to talk to and set it up.

Pickld is meant to “preserve your friendships” – in the future we imagine something like a Chrome extension & mobile app combination that allows you to take advantage of the triggers and build out your reminder set as it happens – not all at once.

Right now, Pickld was built to be what we could get done in a day that aligned with these principles. I’m actually impressed that we built a (functional) MVP and it’s up on Product Hunt!

In particular for the current tool, we’d want to point graduating students towards Pickld.


I need to get started on Puppy Marketplace now, so here’s a few reminder notes of what I learned that I might come back to later.

  1. I’m emotionally tied to my process. I have a harder time getting feedback on the “design process” than personal characteristics or basically anything else.
  2. If I’m working, I assume everyone else is working. I was our theoretical leader. In the past, I’d mostly led technical projects – write a spec, people execute. I had a much harder time figuring out how to make best use of the interesting, diverse set of skills that we have. I just went heads-down to build things instead of engaging everyone. Whoops.

* I wrote this very confidently. I’m more confident about some of these assertions than others, but this was from a day of work, and all of this could still use more fleshing out.

Startup Lockdown – Day 0

I was pretty clear last year that one of the reasons I was coming to HBS was to try to start my own venture. HBS was busier than I thought. While I’ve been doing a better job of having ideas, execution is another story.

This week is Spring Break, and I’m going to be doing something a little different: Startup Lockdown. Startup Lockdown is a project out of, started by a team of five in the MBA class of 2014. They cofounded and now run a successful company, Alfred, that came out of this process. There’s a video on that here.


This year we’re replicating their process, with some twists and experiments along the way. We still have a team of five, and we’ll be pursuing five ideas. You can follow along on our team Tumblr, Twitter, and Facebook – and I’ll try to post each day here, too!

(Here’s a hint: the full idea descriptions are towards the bottom).


Everything came together pretty quickly. Caitlin floated the idea by me during lunch on February 3rd (I was intrigued from moment one). We decided we were definitely doing it while I was in Iceland she was in Breckenridge in mid-February. On February 22nd we sat down to start hammering out what we needed to accomplish before this week. I’m happy to say we’re going in with as many cards as we can get stacked in our favor.

The Team

As anybody who has worked on… anything… will tell you, the team is the most important thing.

The top line was building a set of people who would challenge our ways of thinking. We didn’t want to be afraid of constructive conflict (conflict around ideas – not personal issues). We’ve already had this come up in several ways – do these ideas have deep enough impact? What’s the balance between starting from customer insights, and starting from an MVP product idea? How much time do we need to spend each day to get the best quality?

We also selected for a diverse set of skills. We wanted to make sure we had the know how across a variety of different things. The easiest way to explain where we landed on this is to share the skills people bring. At the broadest level you could lump them into: technical, design, sales, nonprofit, strategy consulting, venture, documentation. You can read all the specific bios if that’s up your alley.

Each of us will be driving one idea forward as “founder” over the next five days, even though we’re all working on them together. This gives us the ability to divide responsibilities more effectively.

The Process

Each day we’ll be following a set process – the process is just as important as the ideas. We want to make sure we get faster and more effective as the week goes on.

9 – 9:45 Framing: Go over the “one pager” an owner has prepared with a summary of what we know so far and our key questions. Together, we’ll work on specific questions to ask during interviews. Prepare the worksheet that we’d like each person to fill out during our user research phase.
9:45 – 11:45 Customer Research: Two teams of two work on research, where one person gets going on deliverables. The research teams will focus on some in depth research (long conversations, deeper insights) and some quicker talks to get a feel for the space.
11:45 – 1:30 Debrief + Pick an MVP
1:30 – 6:00 Work, Feedback, Iterate, Work: This is when we start to work on deliverables – do we try to get customers to sign up? Do we get people to pay us for a concierge system? Do we start building app mocks? It’ll all depend on the concept and what’s going to get us furthest. We’ll have regular “stand up” meetings during this.
6:00 – 7:00 Finalize Output Deliverables, get ready for Report out.
7:00 – 7:30 Report Out: We’ll invite guests into our studio at the Harvard Innovation Lab to see the day’s work. (Interested in dropping by? We’d love to have you – just let us know!)
8:30 – ? Team Dinner

The Ideas

We came together as a group last weekend to start to brainstorm the ideas. We started from ideas that each of us have had, and then did a round of “pain points you’ve encountered recently.”

We shared the ideas with the group – which sparked more ideas that we added to the board. We clustered them together to see categories emerged.


When we reconvened a week later, we used our initials to show which ideas we were most interested in, and made a list of any with votes.


We quickly eliminated most of the “one-vote” ideas – either because they weren’t well scoped for a day, we didn’t have enough expertise, or we knew someone would work on it anyway.


Monday: Personal CRM

This is still wide open. It came from an amalgam of ideas and pain points – a bunch of different angles.

Why are there professional tools like Salesforce and RelateIQ, but not something personal? Is it sleazy to use a system to manage friends? What about the gap between friends and acquaintances? How can I be a less bad friend? how can I be a better friend? how can I stay in touch more effectively? Why do I drop the ball? Do my friends really forgive me? Will future me forgive me?

Tuesday: Ethical Puppy Marketplace

One of our team members (Steve) has been trying to buy a puppy. It’s apparently harder than you’d think. We’re going to figure out a better way to get a puppy you feel great about – from a place you feel great about, too.

Wednesday: Day Launcher

Lots of people have cool morning routines. Lots of people (me) don’t. How can we make sure we get up on the “right side of the bed” every morning?

Thursday: Skill Building Vacation

Vacation doesn’t have to be sitting on the beach. Caitlin learned to Kite Board while on vacation. I just learned some cooking in Indonesia, and yoga in Cambodia. You basically have to travel to learn to surf or scuba dive. If you want to learn a specific skill, how do you plan the best trip for that?

Friday: Energy Cal

None of us are happy with the calendar solutions that exist. It’s impossible to schedule meetings with teams. You end up taking meetings you don’t want to take, or five meetings in a row (eating the last two are useless) but never making time to exercise or learn a new skill. How can we re-think calendars?

These are the five we got to that all of us were interested in. Of course, everyone comes up with ideas in different ways. If you’re looking for more, Katie Bolin (Spark Capital) just posted offering a few different techniques.

Want to help?

If you think you’re an interesting case for any of the five ideas, we’d love to include you in our user research – particularly if you have time for a longer conversation.  We’re also open to anything else! If you have any idea you think we should hear for how we go about doing this, please let us know. And follow along on Twitter/Tumblr/Facebook.

UPDATE! The Results

Monday – Pickld
Tuesday – Waggr
Wednesday – Voyahago
Thursday – Freelancia
Friday – Goalie

pm@olin: Building (Class 5)


1) Understand your personal work and productivity style
2) Understand that others also have a style, and tailor project management to the team.
3) Understand the software process (waterfall & agile)
4) Understand bug triage.

Optional Reading:

1) Whiteboard markers.
2) A chart of your own day.


I wanted to open this class with some more personal aspects of how to get things done, and get software built. Hat tip to Steven Benario, who helped me brainstorm some of these exercises.

The reason I wanted to start here is that people often think PM is just trying to “keep Engineering on schedule.” This is usually not the case – getting a team to run well is far more complicated.

On top of that, I find that PMs often say they want to manage other peoples schedules, but don’t have a good sense of their own time. I wanted to build empathy and for why project management and scheduling are hardd and important.

Understanding Your Own Time – One Hour

I opened this class by explaining my day. “Today, I’ve been super productive. I woke up early, prepped some cases before class, went to my classes, ordered lunch delivered to give me more time to work, came out here, read some more cases, and now I’m teaching!” It sounded good.

I proceeded to show them an actual snapshot of my day from 7:30 – 5pm. This wasn’t so embarrassing to share with students, but is a bit worse to have on the internet (at least it’s honest!)

7:25: Alarm Goes Off
7:34: Get up
7:34 – 7:40: Get Coffee, Feed Cat, Sit at Desk, Email
7:40 – 8:10: Read LCA Case, Read FIN Case, Twitter, Facebook, Distractions
8:10 – 8:20: Get Dressed, Take out Recycling
8:20-8:40: Walk to HBS
8:40-9:10: Get More Coffee, Get Water, Answer Email
9:10 – 10:30: Class
10:30 – 10:50: Awkwardly Stare at Email, Answer Peggy, Answer Cole
10:50 – 12:10: Class
12:10 – 12:20: Awkwardly Stare at Email
12:20 – 12:30: Move for Meeting
12:30 – 1:04: Lunch Roulette Meeting
1:04 – 1:30: Walk Home, have Postmates bring lunch
1:30 -2:15: Eat lunch, chat, email, shower
2:15 – 2:27: Chat
2:27 – 3:28: Get coffee, walk to Zipcar, drive back to house, get cables, drive to Olin
3:28 – 4:00: Chat, useless things
4:00 – 4:50: Read LCA Case, Skim TEM Case, Email bio to Caitlin, read this article:
4:50 – 5:05: Write this document, inefficiently

Even though it sounded productive, there was a lot of wasted time in my day. I sorted my time into three groups: productive, necessary, and unproductive. Necessary means things like eating, my walk to school, and other required activities.

Conservatively, I wasted 33% of yesterday (about 177 minutes). That includes staring at email while not answering it and awkward time between meetings. It’s also the time I try to work and read Twitter at the same time.

I did this not to shame “unproductive” time. I find that I need a certain amount of unproductive time. It’s important to have fun and see friends. The thing that matters to me is that it’s “quality” unproductive time. I’d rather save up an hour to grab coffee with someone, rather than staring at my email for three twenty minute chunks.

It’s good as a PM to have a baseline for how you use your own time. If you think you’re “busy” – you often aren’t.

I had each of the students do the same exercise, for their own Wednesday. We had a range of values: the most productive student only wasted about 12% of her time! The most time wasted was right around my 33%.*

Once we had this baseline, as a group we reflected on “what made today (un)productive?” and what things help us to be productive and unproductive.

Each student shared an item and it helped us to build a framework to consider productivity (my whiteboard plan got kinda messy this time).


  1. Getting or staying focused: Some people have a hard time getting in the zone to begin with; some people have trouble staying in the zone. Knowing what times you are likely to be “on” and “off” can help with this. For me it’s important to have large uninterrupted periods of time to work in.
  2. Environment Shifts: Some found these helped, some hurt. For me it’s hit or miss by the particular space, so if a space doesn’t work in the first few minutes, I need to move.
  3. Teams: Some people work well in groups (actively collaborating), some people work well in groups (individually working nearby each other) and some people work well alone.

A few others that don’t need explanation:

  1. Routine
  2. Micromanaging time / task blocking
  3. Rolling task list
  4. Historical task list
  5. Deadline pressure
  6. Caffeine

Next, we talked more specifically about being accountable on laptop time. Two tools I’ve used are WebTimer and RescueTime. Both are tools that help you track how you spend time on my computer. I shared some of my own data (based on 238 days while I was working – not at HBS). This is work + personal time – the large purple 21% is “other.”

Screen Shot 2015-03-12 at 5.24.44 PM

This doesn’t bother me much – I’m one of the few people who uses Twitter (web) more than mobile. Since I haven’t seen how this changed lately, I turned Webtimer back on and I’ll report back. I also showed how I use Trello as a personal tool to manage tasks and fill in gaps in my time. I also gave an example of using Trello in the group context to start off the discussion below.

Group Time – 45 Minutes

Next, I wanted to apply this to the projects that students were doing in class.

After spending time reflecting on how hard it is to get yourself to work, it’s easier to have empathy for others’ work styles. Everyone has all the idiosyncrasies that students learned about themselves in the first part.

I mentioned one team in particular that I worked with for a class, and our own styles. I’m hoping my memory holds here (this project was back in 2008, and I enjoyed it quite a bit).

Me: When I’m on, enjoys meetings, likes collaborating. When I’m off, I’m sarcastic and hard to work with.
R: Also sarcastic, enjoyed group parts of the meeting. Less likely to do tasks outside of meetings.
A: Hated meetings, wanted to work on specific tasks, with headphones on.
G: Didn’t like the class, didn’t want to be there, made stuff out of blue foam.
L: Most motivated to learn, wanted everyone engaged, enjoyed meetings.

The result was that this group usually divided tasks according to those preferences. The person who wanted to do graphics did that, the foam did that, and the other three of us did more of the “group stuff.”

It’s important to keep these things in mind if you’re coordinating to move towards a goal. I wanted students to reflect on their team members and why they might be participating (or not). Things that seem to be “schedule” problems sometimes turn out to be personal/motivation problems.

(In the classroom I shared a few more work/personal examples of this).

I also wanted to give a bit more of a framework than “think about your group.” I drew on the the board from “now” (March) to Expo (May) which is when most student projects will be ending.

To tie it back to how people build in the real world, one of my recommendations was based on the Amazon Press Release Strategy.

Amazon has Product Managers write a “press release” of the Product before the begin spec’ing or working on it. I tried to turn this into the Olin equivalent of “think about what you’d want to present at Expo” before you start your class project.

My other recommendation was to think about the process of the two week timeframe. How often would you meet? How would people be accountable for their work?

There’s a note at the bottom, but I wish I would have taken some time here to refresh and expand on the difference between Waterfall and Agile.

By the time we’d finished discussing, we opted to move into Bug Triage rather than spend the time on working on projects in class. I’m hoping the students will do that another time.

Bugs & Bug Triage – 30 minutes

This section was pretty standard. My main goal here was just to get students familiar with some basic software concepts around bugs. Bugs are common knowledge for most PMs, so I’ll just share the skeleton. If you’re trying to learn, there are lots of other good resources about this.

First, we talked about the timeline of the process as the software in waterfall. Notably: Feature Complete, Code Complete, “Bug Bar” and ZBB. This might not be common in startups, this definitely still happens at places, and it’s something I’ve run into during my work.

Then we talked about opening a bug. That included the idea of writing “expected vs. actual behavior” with a description, as well as the difference between Severity (how bad) and Priority (how obvious/often) and the rankings from 1-3 for each.

Finally, we talked about the decisions a PM makes about how to resolve a bug: By Design, Dupe, Won’t Repro, Won’t Fix, and assigning to a Developer (for discussion).

For me, the most amusing moment of the class was when a student realized for the first time that all software has bugs.

Suggested Notes/Changes:

1) I forget how different college and real life are. The students anchored much more harshly on “productive/unproductive” than I did. I fielded many questions along the lines of “is eating lunch for half an hour unproductive because I could’ve done it in 10 minutes?” In retrospect I might let them make their own categories for how to group things, or call necessary “reasonable life management.”

If I was going to rank when I’ve been the busiest it’d be: Olin, High School, HBS, Work.

2) I really flubbed in the middle of this lesson. I meant to go from group dynamics into Waterfall vs. Agile. Luckily we’ve touched on it in other classes, but if I did it again, I’d definitely wedge that in between there before moving on to triage.

3) To save you some time, it’s hard to come up with non-software bug examples. It’s just so primarily software based.

The HBS Classroom Experience

I haven’t written down the mechanics of what HBS is like day-to-day so far. I wanted to share this as context for some other pieces I’m going to write soon. (To be honest, I explain this at least once per day, so this should save me some time, too!)

The Cases

An HBS case is like a long story. Overtime, you get familiar with the format. The introduction almost always includes a sentence like:

<Protangonist> sipped their <beverage> and contemplated what to do next. <Ponderous Question>.

The question relates to what you’ll be learning during the rest of the case. It’s colored by the class the case is for.

Finance-y: “Should Bob take the financing offer or hold out for something better?”
Operations: “Justine wondered, was now the right time to outsource, or would another year of experience help?”




I really enjoyed this lego case – just wanted to show what the page looks like & the opening sentence, but you can get the full case here.

Then the case jumps backwards in time to explain the history. The history starts from the founding of the company, progresses from there. This provides context for how the dilemma arose, and the company culture.

The background also contains a lot of other industry context. If the case is about Tesla, you don’t just think about Tesla. You think about all the Electric Vehicles.

In my opinion this alone makes reading the cases worth it. My only industry context was tech. Before coming to HBS I couldn’t even name many other industries. There are a lot: Pharma, consumer packaged goods, finance, air travel. Other industries face different challenges, or approach the same challenges in different ways.

The case isn’t just a story – there’s a lot of data, too. While reading the text you’ll be expected to notice (and remember) how many banks shut during the Great Depression. You’ll learn about the gross margins of used cars, not just how used car dealers buy cars.

For me, reading the case feels a lot like trying to solve a puzzle.

If you’ve done a cryptic crossword it’s the same feeling. You try to hold a bunch of pieces of information in your head at once to figure out which ones are important, why, and how they fit together.

There’s not one “answer,”  but there’s often something interesting lurking beyond the surface. I enjoy the cases. It’s nice to read something that feels like a puzzle instead of a “takeaway.”

The Assignment

Along with each case is a set of assignment questions. They start simple: a calculation, something to summarize what you read. The last question is usually the same as the one the protagonist is facing.

Some people opt to read the questions before the case. I read the case without looking at the questions. I often read all the cases on the weekend and then do the questions the night before class.

I  focus my preparation to be prepared for the Cold Call.

The Cold Call

My favorite part of every class is the famed/dreaded “Cold Call.”

Most professors open class by asking someone to start. The “someone” doesn’t volunteer. Some professors use a random number generator, others go based on participation of experience.

The individual will be asked to do one of two things:

1) Lay out an action plan of what the protagonist should do (and why).
2) Provide a summary of the case.

The latter is more popular in subjects like Financial Reporting and Control (accounting). That allows everyone to learn the mechanics before getting to the answer.

So why is this my favorite part?

1) It raises the energy for the entire discussion. The second before the professor says the name is usually one of the most tense parts of class. The tension at the beginning helps get the energy up for the rest of the discussion. I’ve noticed that classes that don’t start with the cold call seem to lag more.
2) It saves  time. The cold call gets a bunch of facts on the board quickly. That leaves more time for interpretation later on.
3) You get to see (or show) a whole thought process. Most of the time in class things are quick comments – one more fact, one more idea. Rarely do you get the chance to hear or make a complete argument. It’s fun to hear someone’s plan.

The Rest of Class

After the cold call, class usually shifts away to continue the discussion. People add supplementary factual points. Someone might present a counter argument to the original proposal. There’s some back and forth conversation.

The heart of this is that ~93 people sit in a room and discuss the topic for 80 minutes. Most classes only 30-40 people get to speak, meaning you talk every 2 or 3 classes. You can raise your hand, but there’s no guarantee you’ll called on. The class often moves quickly past the point you wanted to make.

As I’ve mentioned, it’s hard to balance adding quality and quantity. You want to add something unique.  Last week, I had three cases in a row where I wanted to say something specific, but it didn’t fit.

The overall discussion depends a lot on the professor. Some classes are fascinating to watch and fly by. Some classes I stare at the clock and draw on my case packets. More on that in another post.

After class

The case has a short life. After class, it’s done. I might talk to a friend over lunch or break. Mostly the case just gets tossed on a pile on my desk so I can move to the next one.



pm@olin: Negotiation (Class 4)

An aside: I’d written a new “one page” spec since the previous class, so I spent the first 15-20 minutes walking through it to show the students a real example and reinforce what we covered last time. It’s not topically related, so I didn’t put it into the goals below – but it did work well in terms of the overall class flow.


1) Practice negotiating in the type of situation a PM would be negotiating in.
2) Build basic negotiation skills.

Optional Reading:

1) Two separate “brief” documents for the two negotiating teams.
2) Two spaces – one for each team.
3) Timer (if you type “Timer” into Google it provides one in the browser).


This week’s lesson was the first “workshop.” Rather than having a lecture, exercises, and a back and forth, the entire lesson was filled by a Negotiation Exercise.

I was motivated to do this after Negotiation experience I had during HBS FIELD – the Riva/Charlton Negotiation. Unfortunately, I don’t think the teaching papers from HBS are available. The HBS FIELD negotiation was more formal (everyone wore suits) and more structured than the one I describe below.

Phase One: Prep – 20 minutes

Each team had 20 minutes to read the “brief” I’d prepared and plan their initial negotiation strategy. Since I wanted to make the negotiation applicable to the PM experience, I drew from personal experience. I created a dramatization of a discussion I had with the SkyDrive team while I was working on Office Mobile. I put three major issues on the table for the teams to negotiate.

I’m not putting the documents I gave out online, because while I used some details to make the document realistic, most of the document was fictional. I’d recommend working from your own personal experience so you can add detail/clarify if you need to. If you’re teaching this class to a group of students and need help, I’m happy to chat.

One important facet of the documents was that the two sides got “points” for various outcomes in their negotiation. These did not need to be evenly balanced – it was just to incentivize the teams to strive for different outcomes.

I gave very little direction during this phase.

Phase Two: Initial Negotiations – 20 Minutes

I let the two teams start talking. Initially I thought they were going to solve it in five minutes (and I was disappointed and going to have to find another plan). Thankfully it went back and forth – and at the end of 20 minutes, they were still talking, but had a detailed proposal on the table. I will note that a few times they misinterpreted what I’d meant. I was tempted to correct them, but had to let it go because I might have given away part of the “answer.” It ended up working out fine.

Phase Three: Regroup – 20 minutes

The teams got back together in separate rooms to discuss the proposal on the table and alternate proposals.

Phase Four: Final Negotiations – 20 minutes

The teams came to an agreement that was agreeable to both, and signed a piece of paper.

Phase Five: Discussion – 40 minutes

In the end, both teams felt like they’d successfully negotiated, in part because of the loop holes they found. We talked about how it went – techniques that were effective, things that didn’t work, and how they mis-read the other team. I’m not going to make a list because there are lots of things you can “learn” from a negotiation, and the value was in going through the exercise.

Suggested Notes:

1) Be very careful how you split the teams. I accidentally put all the seniors and the two people who had taken a negotiation class on one team. It worked out.
2) If you leave a loophole in your exercise, they will find it. Both of my teams found loopholes giving them substantially higher “scores” than they’d have had otherwise.
3) Afterwards, a student who had had a formal negotiations class recommended including some of the theory – BATNA, pareto efficiency, and anchoring. I think that would have been wise during the wrap.

pm@olin: Specs (Class 3)


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)


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.


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 (!)


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


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:



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.