Many things surprise people about how differently we work at Podia, but one that comes up often is that we have absolutely zero product/project managers at our company of more than 30 people. Despite this — though I’ll argue below that it’s precisely because of this — we’re shipping features faster than companies many times our size and resources.
First of all, this isn’t personal; I know many PMs who are great people. When considering our product development process and track record, however, I simply don’t see the value in the work that they would bring to our team that a developer, designer, or head of product can’t drive themselves.
That’s not to say that the work of gathering data, researching customers, developing features, working on specs, and organizing a project isn’t valuable. Rather, I believe that work should be done by someone closer to the implementation of it.
Why shouldn’t the developers — or designers — be tasked to work through the problems, instead of being handed a set of solutions?
Every single project, a developer is assigned what we call a Champion* role and it’s that person’s responsibility to act as the PM in addition to their work as an individual contributor. This approach, as opposed to handing off a spec to stitch together with code, makes for much more engaged developers who feel more ownership of the work.
That means that in addition to coding, they’re tasked with…
- Creating the project in Basecamp, and organizing it as they see fit (e.g. setting up the to-do lists)
- Running the weekly project meetings that we hold, including setting an agenda, presenting questions, moderating discussion, and demoing anything that they need feedback on
- Writing an end-of-week update on the project’s status outlining what their team got done and what they’re working on the following week
- Presenting the project update to the team during our Monday weekly all-hands
- Setting an up-to-date estimate of when the project will ship to production
- Communicating with marketing and support to coordinate the launch
This Champion might end up doing less coding because they’re handling all of the PM tasks, but they’re (1) learning a new skill or refining an existing one and (2) enjoying ownership in their work by taking the project from start to finish.
Some developers we hire have never done any PM work before, and it can be intimidating the first time they step into the Champion role. But after they’ve gotten their feet wet and gone through their first project, developers on our team are itching for another project to Champion.
Ownership is such an important piece of building a great product, and the Champion does just that.
This system of not having any go-betweens means that we can act more quickly, and I have to give a lot of the credit to this system for helping us continually ship new, innovative features with remarkable speed compared to the rest of our market.
Don’t be so quick to hire a PM for every 2-3 developers that join your team. Instead, think about adopting the Champion system, or trying something similar. I think you’ll be pleasantly surprised by the results.
Below you’ll find a copy of the Champion position as outlined in our internal wiki.
What’s the Champion role?
Every project will have a single “Champion”. The Champion doesn’t necessarily need to be the more senior developer, but it does need to be a developer that’s 100% focused on the project.
This person is ultimately responsible for:
- Writing the weekly update each Friday
- Updating the project's timeline for Lineup: "…" → Update the name and description → Project schedule
- Surfacing blockers to managers/Jamie/Spencer
- Acting as liaison to marketing and support
- Ensuring support documentation in Slab and help docs in Intercom are written
- Providing marketing with update details for upcoming announcements as needed
- Updating the team on the project’s progress in the weekly call
What if the Champion is on tech rotation this week?
The Champion continues to be the point person for the project and involved in any discussions even if they’re on tech rotation. This creates better continuity for the project.
Is the Champion the boss?
Not exactly; the job of the Champion is not to manage people; it’s to manage the flow of information about the project. They’re not more “in charge” of key decisions than anyone else on the project, but they are in charge of making sure that everyone - both within and outside of the project - has the information they need about what’s happening.
Does the Champion assign work?
Divvying up the work should be a collaborative effort. The Champion might have a better sense of how to divvy up the work, because they’ve been either:
- Working on the project longer
- Involved in more of the preplanning product work
But the Champion shouldn’t be assigning things unilaterally.
As the Champion, am I the point of contact for other departments?
Yes, it’s your responsibility to keep marketing and support up-to-date with anything they might need. They’ll be reaching out to the Champion with their questions.
If you don’t know the answer, you can bring Spencer, Jamie in or anyone else in that knows, but they’ll be looking to you for answers. It’s your job to find the answer, even if you have to ask others for more information.
As the Champion, do I give the ETA?
Yes, as the Champion for the project, it’s your job to note the ETA as part of your weekly writeup. ETAs are never set in stone and you’ll need to adjust it over time as things change.
It’s important that you talk to the other people you’re working with on the project to find out how long their work is taking to better inform your ETA estimate.
How does the Champion role differ when there are 3-4 developers on a project?
Our goal is to never staff a project beyond four developers, because things can get messy and overly complicated.
With that said, even at 3-4 developers on a project — one of them being the Champion — you’ll be spending more time on project management than you might on a two-person team.
The core set of Champion responsibilities hasn’t changed, but there are more of them. You will likely find yourself having to spend more time on project planning, allocating resources between developers, assessing project risk, making sure everyone is on the same page, etc.
It’s not necessarily only because there are more people working on the project, but also because a project with that many developers is going to be larger in scope.