Product Process & Culture
Code4rena, 2024–2025
When I first stepped into the Head of Product role at Code4rena, I set out to fix our product delivery lifecycle. Our engineers and designers were starting to feel burnt out from constantly changing scope and priorities. We were shipping too infrequently, with projects growing in complexity, until suddenly, there was a chaotic sprint to the finish line, before shifting to something new. Much of this was driven by the executive team not having visibility into what the product team was working on, or the current status of projects. To them, it was like trying to steer a ship without knowing where they were on the map.
The team built in an unstructured “waterfall” manner. While everyone was motivated and skilled, there weren’t established expectations or a clear, repeatable process for delivery. The team was operating with too few guidelines, and there was a clear gap in communication that needed to be solved.
To solve this, I started by resetting expectations via an all-hands, establishing operating principles and processes. This also doubled as a morale-booster—I wanted to reassure the team that we were and could ship excellent work, we just needed some better guidelines to work by.
Slides from our quarterly all-hands, establishing new operating principles and practices for the Product team.
From this foundation, I worked with the team and leadership to create tangible processes that would allow us to move faster.
We created a system of tracking work in ClickUp, where we previously did not use any product management software. Work was categorized into projects, then organized into one-week sprints, with individual tasks sized to fit within the week. This allowed us to easily track what was currently being worked on, and the progress of any project.
An example of our weekly sprint board.
Leaders could easily track the overall progress of each sprint, and for each project.
To replace ad hoc meetings, where teammates that weren’t present would simply miss context, we organized a weekly standup ritual every Monday. We would spend the first ten minutes individually writing a brief summary of what we’d each work on the upcoming week, and what we shipped last week. We’d then each read over the notes, and go over anything that required extra discussion. These notes lived in a shared Notion document, accessible to anyone on the team.
The template for our weekly standup notes, used to drive each meeting.
We created a product brief template that explained why we were working on any given project, and a write-up of the technical solution. This would be updated as the product was built out, so any shared context could be easily found in a unified source. It would also link to any key tickets or epics relevant to the work.
The product brief template we’d use for each project.
Security audits require a lot of human-in-the-loop systems, and our Engagement Managers were very close to the customer experience. They would ping the engineering team with technical requests, where sometimes these were urgent needs, and other times they were feature requests, but we had no way of tracking them. These would often throw a curveball into that person’s time, so we created a system that would help us better understand how to prioritize these ongoing needs.
Our internal feature request board, used to keep track and prioritize needs from our operational team.
Lastly, we created an automated #shippy channel that would post with every merged commit from our engineering team. Nontechnical teammates would also post here for things like updates to documentation or processes, and designers would share when design work reached a milestone. This was a tiny, but beloved tool by the rest of the team, as they would know whenever work was shipped, as it happened live. It was also great for team morale to see the momentum of shipped work.
