I recently participated in the #AI4ALL hackathon and it was a great experience. I grew in my Product Management skills, built a Bitcoin + AI product called Bitcoin-PAL, and teamed up with some pretty awesome bitcoiners.

One thing in particular that I appreciated about this hackathon is that Johns Beharry carved out a space specifically for product managers, which isn't a role you typically see in hackathons.

But what exactly is a PM? How can they help a hackathon team? Well I'm glad you asked!

What is a Product Manager?

One loose definition I found helpful is that a product manager does anything and everything to push a project across the finish line. In this way, they are kind of like a janitor.

Now I know that sounds a bit vague. So let's get specific. Below is a short list of some of the responsibilities I had on my team. I hope this helps you get a better picture the value a PM can bring to a hackathon project.

Assembled the team

I first reached out to a couple of former coworkers, namely Ron Stoner. I knew he had some backend experience but also was dabbling in AI. He and I also worked really well together when I was at Casa. I also had a couple of people reach out to me on twitter (Anthony and Niku). They had found me through the bolt.fun website, saw that I was participating the #AI4ALL hackathon, and that I was looking for a team.

I reviewed both Anthony's and Niku's github profiles. Anthony had more backend experience than Ron and I saw that Niku had experience with frontend. I felt like both skill sets would be needed. So I checked with Ron and then invited them to join the team.

As a PM, your job is to figure out if you have the right people on your team. If you don't, you need to go and get them.

Organized the team

One of the primary responsibilities of a product manager is to make sure everyone is on the same page of what needs to be built and what their responsibilities are. The two main tools I used were : 1) Project Charter and User Stories Document 2) Github Projects as a Kanban Board.

The Project Charter sets the table for the team. It provides a high level overview of everything someone might need in order to get caught up on the project. It typically gives context as to what the project is, the problem we're trying to solve, and links to various resources the team is using such as other documents/figma/etc.

User stories are helpful because they describe what we expect a user to do with our product. Then people from each department (design/engineering) can fill in the gaps about what they need to own in order to make the user story possible. It also helps everyone agree on what is and is not in scope for the project.

Kanban Boards help keep track of project progress. For my team, I created high-level tickets and assigned them to the appropriate members. By moving tickets across various statuses (To Do / In-Progress / Done), it gives visibility on where people are at with their work.

Tickets also provide a place to define requirements, update statuses, and add info needed to complete the specific task. For example, here's a design ticket with basic requirements that I wrote for the frontend.

Another example is the ticket to create a presentation. Here, I left comments for the color palette and potential slide templates we could use for our presentation. That way we could easily refer back to them later when needed.

Other less "glamorous" but still very important ways I helped were organizing documents in a google drive, scheduling and inviting people to meetings, setting agendas for our calls, and pinging people for updates throughout the hackathon.

Submitted and gathered information

If you look at our project updates, I was the only one posting updates. This allowed the rest of the team to focus on their work. It actually wasn't until the last week where people on my team actually created bolt.fun profiles.

Providing updates may seem like busy work, but it is important for two reasons. One, "building in public" was a criteria of the hackathon. (PS providing progress updates is pretty similar to what you would do as a product manager at a company). Two, our team was busy with their normal lives of being a full-time student, a dad, and full-time work. The hackathon was not their #1 priority.

With regards to gathering information, participating in hackathons often have a lot of information coming from coordinators and other participants. My job was to sift through the "noise" and surface relevant information for the team.

One example of that was sharing with Anthony potentially relevant lightning tools.

I was also responsible for doing "competitive analysis". I regularly checked the status of other projects and updated the team on how I thought ours would do. I also made sure we were moving in the right direction with regards to the criteria for the hackathon. For example, we submitted our project to the "training" track because there weren't a ton of projects in that group and ours would be a strong contender.

Said no

Probably my least favorite thing to do as a PM is to say "no" because I'm a people pleaser. Often times when people start diving deep into their work, they have other ideas to make the product better. Or perhaps they ran into an issue and have thought of a different way to architect a solution which would require more work. It's precisely at these times that it's important for you to defend the scope of your project. Small feature suggestions might seem innocuous at first but could impact the roadmap severely .

During the hackathon, Anthony had suggested the idea of "displaying a release/model number at the bottom of the page to show the user when the model was last trained. Could be enough to remove statefulness question on the bottom left as user can just check if model number has updated."

I dug deeper into what purpose the feature served by asking him questions. After the conversation, I determined that it was a "nice-to-have" but not needed for the MVP. I'm glad I defended the scope as much as I did because we barely made the deadline!

As a PM, your job is to have a crystal clear understanding of what the end product is. That way when curveballs come your way, you know what to scope down or adapt to defend your deadlines.

Final Thoughts

Hopefully this helped conceptualize the value of a PM for a hackathon team. I highly recommend others try it, especially if you're not technical and are looking for a way to contribute to bitcoin. By participating, you build product chops, gain experience, and come out with a product you can use to build your portfolio.

Also if you're curious about how to be a non-technical contributor to bitcoin, come hang out with us in the Bitcoin Product Community Discord. Learn more about who we are and what we do on our website and our introductory blog post.