Project Logs

Context is king, and if you’re not careful, you will lose all the beautiful context uncovered while building products. Teams are making hundreds of tiny decisions every day, and you never know when that information will be relevant. But one thing is certain: It will be relevant again.

So how do you capture this context?

At the end of my Project Plans, I include what I call the “Project Log”. Even though it’s at the end, it’s one of the most critical parts—certainly a last-but-not-least situation. The Project Log is used to detail key project updates in a single timeline. Think of these as small mile markers along the product road. If your car breaks down or runs out of gas, it will help to know where the nearest gas station is.

I keep the Project Log in its own spreadsheet, which is useful to share with the team or anyone else looking for context. Each row includes a set of attributes:

1. Date: When the event occurred.
2. Channel: Where (email, message, meeting).
3. Type: What type of update.
4. Participants: Who was involved.
5. Description: What and why (the context).

And there are three distinct types of updates in the Project Log:

1. Decision: We made a decision.
2. Discussion: We discussed something.
3. Data Point: A notable event occurred.

Decision

Decisions are the cornerstone of the Project Log. They typically come in three varieties:

1. Scope: We’re modifying the scope of the work in some way.
2. Priorities: We’re changing priorities based on new information.
3. Technology: We’re making a technology decision that affects the product.

When detailing a decision, include the why. More often than not, that is the piece of information lost when trying to recall later on. Detail the why, keep the context.

Example:

We decided to combine the messages list and the search results screen into one component to keep the UX consistent, while leveraging Algolia for autocomplete search and the database for the full search results to avoid redundancy.

Discussion

Discussions are notable conversations you want to document. While they don’t include a decision, they are valuable checkpoints of information. Save them. They build your tree of context and knowledge.

Example:

We reviewed the latest pitch for search improvements. The feedback was positive and there are no blockers to start building this in the next cycle.

While nothing was decided here—and the stakes may seem low—this is one of those breadcrumbs you’ll thank yourself for dropping later on.

Data Point

Data Points are any specific events worth mentioning. This could be things like:

• A meeting getting canceled or rescheduled.
• An email being sent with the latest project updates.
• Any feedback presented by the client, customer, or other stakeholders.

Again, it’s important to view this as part of the trail. If anyone were to read a Project Log, they should be able to quickly get a sense for the rhythms of the project.

Create Your Project Log

Project Logs are great for fixed-time projects, but if you’re building a SaaS product, you can use them for the projects that make up the ongoing work. They work well in the client context when you need to cover yourself, and they can save you when the team tries to recall why a specific decision was made. You’ll be there with the answer—with your Project Log.

Create your own Project Log. Use what I’ve detailed as a foundation, but make it your own. The underlying principle is “write everything down”, which is part of my philosophy of “working with the garage door open”. It helps teams work more collaboratively to build better products.

If you want to jump-start your Project Log, you can view my spreadsheet template.