Maybe 10 years ago I would’ve gotten upset about an article like Spencer Fry’s No PM, no problem: how we ship great products fast, in which he explains why they don’t have product managers at Podia and how great that is. Luckily I’m now too old to stay up late just because I think someone’s wrong on the internet. Instead, I approach articles like these—ones I viscerally disagree with right off the bat—with a bit more curiosity. What is the source of the author’s assumptions? What is the data that led them to this particular set of conclusions? What is the problem they’re trying to solve, and what led them to this viewpoint as the solution?

As it turns out, we get the answers to those questions pretty early on in Fry’s post:

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.

Ah, see, this makes sense! I can see why Fry concluded that PMs are unnecessary if his experience is that they (1) “hand off a spec to stitch together with code”, and (2) don’t give developers ownership over their work. The problem is likely that he has never worked with a PM that understands their role and does it well, so of course the data would lead to the conclusion “no PM, no problem”.

So let’s talk about those two assumptions for a minute.

Handing off specs to developers

This is just 100% not what PMs should do. If designers, developers, QA, marketing, and customer success are not part of the planning and design process of a feature, it’s just bad practice. There should never be a handoff in software development, only collaboration. A developer should know exactly what they’re doing once they start coding because they have been intimately involved in the design decisions and trade-offs that go into a project right from the start.

The role of the PM during this phase is to bring all the right customer and business data to the table to help the team through their decision-making. It is rare for them to say “this is the decision,” but in some cases where teams can’t come to an agreement it’s also their responsibility to make that call, explain it well—and be accountable if it ends up being the wrong decision.

Ownership of work

Engaged team members (not just developers) who feel ownership over their work is an essential element of an empowered team. If the teams don’t have that and the PM “calls the shots” then that is, again, bad product management.

At Postmark we have a similar role to the Champion role Fry uses at Podia. We call it the Driver (part of the DACI model). The PM is sometimes the Driver on a project, but not always. In every case where it makes more sense (such as a deeply technical back-end improvement, or a pure front-end redesign) a developer or designer or marketer is the Driver. We define the role as follows:

The Driver is the project leader. This is the one person who will be driving the team through decisions. They’ll be responsible for making sure all stakeholders are aware of what’s happening, gathering information, getting questions answered, and action items completed. A Driver, for example, will schedule and run project meetings, gather and distribute ideas, coordinate tasks, and track the team’s progress.

Drivers ensure a decision is made but don’t necessarily make the decision.

The team has autonomy and ownership to drive the project and make decisions as they see fit. Each project has an Approver assigned, usually someone on the leadership team, but they are there to support, answer questions, provide context, and in rare occasions, help make a decision if the team is at an impasse. PMs shouldn’t “own” projects. Teams should own projects.

So what do PMs do, then?

Fry’s post does allude to an age-old question, though: Why do you need separate PMs? Why can’t someone on the implementation team just do it? The short answer is that what goes into good product development and successful features is so much broader than just the code being written and shipped. And if we require designers or developers to be responsible for all of it, they would simply never ship anything.

So what value should PMs bring to the team, whether or not they are the Driver/Champion on a project? In addition to input on design/scoping decisions they should be responsible for all the things that are not directly related to building the feature at hand, but essential for its success. Some possible examples:

• Customer input on what their needs are to help with the design and scoping of the feature.
• Revenue modeling to figure out pricing and packaging.
• ToS updates due to legal implications no one else thought of.
• Working with the marketing team to figure out the best positioning and launch activities based on what value customers can expect.
• Connecting the dots between this project and that failed one from 3 years ago as well as that thing the Lead Architect said in a meeting last month to ensure we don’t forget about an essential library dependency so that we actually build something that’s scalable and reusable in the future.

You get the picture.

There is enormous power in someone being around for the team as the person who’s got this so that they can focus on their work and relax in the knowledge that nothing will fall through the cracks. More than any other role in the organization, it is good product management that enables teams to work in a calm, empowered environment that produces consistently great software.

I have no doubt that Podia ships great products fast. They clearly have a culture of trust and empowerment, which is great. I do wonder how adding a good PM to the mix would enable them to go to even greater heights.