A weekly changelog makes us go fast 🏃‍♂️

@nilkanthjp and I started working on Herald in December 2019. Herald is the best space for teams to collect, analyze, and collaborate on user feedback. Working feverishly over the winter break, we got the MVP in the hands of our first customer in on January 2nd. From then onwards, we've maintained a weekly changelog.

As you may notice, our changelog is nothing fancy - just a simple Notion document. We also follow a simple format for each update:

• Date of update (always a Friday so far) along with a brief theme of the weekly changes.
• Details on the top 2-3 changes alongside a video/photo artifact exhibiting the change.
• A "Bug Fixes & Other Improvements" section with less important changes. We aim to provide details succintly here.

Every two weeks, we also rollup the changes for the past two updates and send out an email to our users.

As you can imagine, producing the changelog is a fairly taxing task: planning and completing the work, and producing the copy and any associated artifacts demontrating usage. Given that as a super early stage startup that's always stretched for time, we often wondered why do we maintain this changelog? This was especially a big question early on, when we only had one customer and it could've been far easier to just show them any changes.

After maintaining a changelog for the last 3 months, I'd have to say that it's a large net positive. In fact, we'd love to maintain our weekly changelog for as long as possible. The two primary benefits we're getting out of our changelog are:

• Accountability: Make sure we ship at least two customer-facing product
  features every week. As a young startup, we're glad that our product iterations
  adhere to a certain product velocity floor.
• Iterate with Customers: A short window to get new features out means
  that we do not have the luxury to come up with grand plans, execute them,
  then reveal it to our customers. From our previous experiences (and
  failures), we've learnt that we are suckers for grand plans that don't pan
  out. With the current model, we descope feature work to something we can ship
  in a max of two days. Often, it means shipping half-baked features, but it
  still seems to be working out for us. When customers engage with the new
  changes, they often ask us for additional features we had descoped -- but now we can work on them knowing fully that it will be a meaningful change. However, just as often, when customers don't even end up using the new features or ask us for entirely different things than we had imagined, we can course correct at a far lower cost.

It's still early days for us at Herald, but we are totally loving using the changelog as a mechanism to plan our weekly sprints. You may have noticed that I didn't even mention that the changelog informs our users about new changes as a benefit— it is just an added bonus and not our primary motivating factor. Our most engaged users check our changelog religiously and provide us earnest feedback, which we obviously save in our dogfood instance of Herald.