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.

Mike Fisher argues that we should rebrand technical debt as “product debt”, and I think it’s a good argument! That said, I’d like to add some considerations to two of his points. First:

We usually think of refactoring as “cleaning up” code, where we change the code to be more easily understood, perform better (faster or more efficiently), or follow current conventions/standards. The goal of refactoring is to change the code without changing its functionality; it should continue to pass all unit and functional tests. 

I take a slightly different approach to refactoring, and how to prioritize the work. I believe it’s important for teams to have a stated and agreed-upon value of “leave the code better than I found it.” This means that refactoring shouldn’t be a separate activity, for its own sake, that needs to be scheduled. It should be a natural part of feature development.

If you’re creating a mechanism for add-ons on the product, spend a few extra days to refactor the billing code you’re already working on. If you are adding metrics to the dashboard in your UI, take the time needed to refactor the front-end code to make it more performant. Whatever code you’re touching while you’re working on a project, leave it better than you found it. It is way more efficient to extend a project by a week to refactor code you’re already working on than it is to create a separate project that needs to be planned, prioritized, and worked into the roadmap.

Second point:

So, how do we ensure we are paying down technical debt when there is so much pressure to ignore it until things really break? I think one part of the answer is to use a different term. Instead of tech debt, which implies it is the responsibility of the tech team, let’s call it product debt.

I think this is a good first step to getting more teams to care about technical debt—but it’s not enough. One of the issues with getting technical/product debt prioritized is that often “the business” doesn’t see the value in statements like “we’re going to clean up the code so that it doesn’t break a few months from now”. Instead, we need to frame the work in terms of the benefits to customers and/or the business.

For instance, we could make the case that refactoring this piece of code would significantly increase our deployment speed, which would mean faster time to market. Or we could argue that fixing our slow staging environments would result in happier, more productive engineering teams.

With technical debt—as with most things in software development—the thing you do is never the main thing. The main thing is what the thing you do enables. What value it brings to customers and the business. That’s the framing we need for working on technical debt.

There’s a sentiment I started to see in the agile development world that advocates for deleting old/stale items off a backlog completely. A good recent example is Jason Knight’s latest newsletter:

The backlog becomes a dumping ground for every single customer support query. Every account manager and every salesperson has something in there from conversations with customers and prospects. […]

It’s tempting to see “length of time in backlog” as some kind of vector for prioritisation, but it really isn’t. It’s quite the inverse, in fact. So let’s all try to get comfortable, embrace the idea of getting rid of old stuff in our backlogs, and give people a “no” rather than a “one day”.

I’m not trying to pick on Jason—his work is great and it’s another very good edition of his newsletter! I am just using it as an example that got me thinking about this a bit more deeply.

My take is that we should absolutely keep all customer feedback around in our backlogs, because that is continuous discovery data that would be a shame to lose. Instead, my proposal would be to normalize the backlog as a place to build organizational memory and a customer feedback knowledge base—not as a list of things that all have to get done.

Two tactics can help with this approach. First, a Now/Next/Later roadmap keeps the focus on the list of current priorities. The entire backlog doesn’t go into the “Later” column—only things that are currently prioritized to start within the next few months.

Second, have a standard process that the entire company (especially the customer success team) can use to collect user feedback and attach it to features. In our case that’s Productboard, and our success team can easily add and process customer feedback via a browser extension.

I guess our list of features in Productboard is technically our “backlog”, but it doesn’t cause us stress in terms of feeling like we need to work on everything that’s on there. However, as part of our planning cycle we can go through this list and figure out if anything is important enough to pull into the “Later” column of our roadmap. An added bonus: if/when we start to work on any of those features we have access to lots of customer data about each feature, and we can reach out to those customers to have more in-depth conversations with them about their needs.

So instead of deleting old issues off our backlogs, let’s rather remove the pressure and stigma around what backlogs are for (maybe we should rename it to “customer needs knowledge base”?). And then let’s use our actual roadmaps for the list of things we know we’re going to work on.