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