Don’t give up on the value of product management because of bad past experiences

Also the beautiful design inside everyday electronics

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.

When we measure how quickly teams ship stories & code, we’re measuring speed—how quickly they move. It’s only when we measure the effect it has on the target metric—the value that we’re after—that we’re actually looking at velocity.

It doesn’t matter how much you ship if the end result doesn’t deliver value to your customers and your company. If you’re measuring story points, you’ve fallen into the trap of measuring outputs, not outcomes. When we talk about slowing down to speed up, this is the point: the only thing that matters in this equation is how quickly we can deliver actual value. Everything else is theater.

—Randy Silver, The Myth of Velocity

In You can’t stand under my umbrella the Raw Signal team makes the case for when it’s not appropriate for managers to be “sh*t umbrellas” for their teams:

When things are steady, and people know the right things to work on, teams are constrained by velocity. We know the course we’re racing, the question is just how fast we can go. In that context, it makes sense for a manager to clear every obstacle out of our way. But during times of significant change, teams are constrained by agility. It’s not that velocity doesn’t matter, it still does. But when everything has changed about the race, we need the ability to steer. A manager who tries to preserve velocity at all costs risks running us into a wall.

They go on to talk about how to Accept, Adapt, and Act in such moments of significant change.

---

Also on the blog… I write about Technical debt, product debt, and how to prioritize addressing it:

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.

---

Some Stray Links

• Open Circuits is “a photographic exploration of the beautiful design inside everyday electronics. Its stunning cross-section photography unlocks a hidden world full of elegance, subtle complexity, and wonder.”

• Good conversations have lots of doorknobs. This is a fascinating essay about the elements of good conversation and the difference between “takers” who keep things going, “givers” who tend to ask a lot of questions, and how the wrong match-up can cause a conversation to stall. Includes good advice backed up by tons of academic research. This is one to save and revisit often.

• Why do modern pop songs have so many credited writers? Some of the examples are wild. “When these cases are settled in favor of the plaintiff, more songwriting credits are added after a song’s release. This is why the number of songwriters listed on Mark Ronson’s “Uptown Funk” has increased over the years. To avoid a Mark-Ronson-style-courtroom-induced headache, artists will sometimes preemptively credit writers of older songs even if the similarity between the older song and their composition is purely coincidental.”

• A “Last of Us” Episode 7 musical mystery. I just want to say don’t worry The Last of Us fans, I’m thinking about the important things over here. Light spoilers here.

• The choice is easy. Robin Sloan with a good reminder: “Anyone who adds one of those email newsletter pop-ups to a website demeans them­selves and makes the world worse for everyone else.” Reminder that if you are an author using Substack you can turn off “Subscribe prompts on post pages” in Settings.

• SoundPrint is an app to “discover quiet places and share them with others.” This looks really useful, especially if you’re a fellow tinnitus sufferer.