Tiny Thursdays

Let’s talk about the magic of small things: delivering mini-features, fixing bugs. These things are often the difference between a poor product and something you’re proud of. But they are often undervalued. I’ll share an experiment that helped us ship lots of small things: Tiny Thursdays.

The origin of Tiny Thursdays

I’m working as an interim product and engineering leader at a company called Campus. The engineering team is quite small – there are more stakeholders than engineers. Every team needs so much from engineering, that they all feel like they are always waiting on engineering.

The team has been delivering more incrementally (using milestones), and that has helped. But the demand is high for the team’s time, and little things don’t get a lot of attention.

The CEO of the company, Tade, had a small navigation improvement he suggested to an engineer at the company. The engineer said, “that’s tiny” and just did it. Everyone loved the change – it was one of those things that was bugging everyone, and the improvement got as much attention as some of our feature releases.

Tade came to me afterwards and pitched the idea of Tiny Thursdays:

• Tell everyone we’re setting time aside for doing small improvements.
• Share a form people can use to submit suggestions.
• The engineering team spends all Thursday working on small improvements.
• On Friday, we tell everyone what we shipped.

I was intrigued. I was already thinking about two related problems:

• There were a lot of little improvements the product needed, and we weren’t prioritizing them.
• We weren’t triaging bugs, or fixing anything that wasn’t urgent. The customer experience was getting worse.

I also saw Tiny Thursdays as a useful way to keep a steady stream of value coming from engineering. Even if we’re working on something larger, that will take a while, it ensures a continuous drip of value.

I decided to try it out and see how it felt. The tradeoff, as I saw it, was we would potentially slow down our projects by 20%. Would it be worth it?.

How did Tiny Thursdays go?

It was so worth it.

On the first Tiny Thursday, the team delivered fixed some critical bugs, and shipped a few minor improvements. The response was enthusiastic!

At a recent senior leadership meeting, I mentioned Tiny Thursdays, and the whole leadership team perked up and spoke lavishly about how happy they were with the change. It’s been really appreciated!

How to do Tiny Thursdays

The way we implemented Tiny Thursdays was:

• We created a feature request form. It fed into our Notion database of feature requests.
• We agreed as a product team to go through those requests frequently. As we do, we add rough estimates. And if anything seems especially important, we prioritize it from P1 to P4 in priority.
• Anything that is estimated as a day or less of work automatically gets put in the Tiny Thursday bucket.
• Every Thursday, we have a repeating Slack message that reminds the team of how Tiny Thursday works, and has links to Bugs and Tiny Features. Team members are encouraged to start with a bug, and go back and forth between bugs and small features. They’re also encouraged to review other people’s PRs rapidly, so everything is done by the end of the day. They also have the latitude to fix things that are bugging them or that they’ve noticed recently.

A few tips

The most valuable part of the definition of Tiny is this: “you can deliver it by the end of the day”. One danger of Tiny Thursdays is that work can bleed into the next day or take several days longer. “Tiny == Today”!

Another thing we learned is that it’s important to communicate the changes. The way we did it was in both Jira and Notion, we use a status field. After the work is done, it doesn’t end in “Done” or “In production”. The final status is called “Communicated”. We make sure we communicate all the improvements as a natural part of our work.

Why were Tiny Thursdays necessary?

One of the challenges product teams often have is that it is difficult to prioritize small things.

Most prioritization schemes tend to be some variation of effort divided by time (my favorite might be cost of delay). So you would expect them to naturally surface low effort work to the top of the list. But in practice, I haven’t seen that be the case.

This surprises me a little. Perhaps part of it is that prioritization has overhead. A lot of the process you build around prioritization is too heavy-weight for small things. My experience with Tiny Thursdays was that it bleeded off smaller work outside of the more heavy-weight pile. It creates a separate group of work that was small, important, but could mostly happen at any time.

If your team is already delivering things in very small increments, Tiny Thursdays may not be necessary or a big improvement.

Challenges with Tiny Thursday

I don’t have any regrets about Tiny Thursday. It’s been overall a big improvement. But a couple of things you might find worth noting:

• People on a hard deadline will opt out. I think this is fine, but I ask people to be public about when they plan to not participate using “I intend to” language.
• Most people have no idea what is tiny and what isn’t. I recently had someone suggest a Tiny Thursday item that would have been a year long project! I’ve generally found it best to not communicate timeline expectations around any items, unless they’re truly urgent. A lot of the requests will end up being good roadmap items, but won’t be real candidates for Tiny Thursday.

Let me know your experience

Tiny Thursdays has been a great change. Let me know if you experiment with it, or do something similar!

Decoding leadership podcast

I covered much the same content in this podcast:

Thank you

Tade Oyerinde came up with the idea of Tiny Thursdays, I believe. Iris Hou, Sonia Sidhu, and Mateo Marcano all helped implement and improve Tiny Thursdays.

Image by Doris Rohmann from Pixabay