07 July 2023
Well, I'm not exactly a Product Manager. I'm still an engineer, but we're trying out something new at Jam (where I work). For this 6 week engineering sprint, I'll be PM'ing the features we build.
This is partly because the sprint has a highly-technical focus (our developer tools), and partly because once earlier, around a year ago, I asked to improve our developer tools.
That time, I gave my case for why our devtools should be improved, and asked for just three weeks to clean up the UX to make them look and feel more like native browser devtools. I got six weeks, and the option for Jam to pay Bernat (the designer I worked with at Tandem) to do designs for us for a couple hours—an option I obviously took.
That project turned out well, and Jam as a whole has been doing great in the year since. So we're at the point where our devtools yet-again have access to resources to make them even better.
Namely, engineering resources: me, and the rest of the engineering team. That takes us back to the title. For these 10 weeks (4wks planning + 6wks eng sprint), I'm not exactly a full-time PM. I'm a PM who's also an engineer. So I've even allocated myself to the engineering sprint.
Essentially, I'm an optimization algorithm for a human, as I decide where to put my time between product and engineering. For my first four weeks, I'm trying to do product work, while only taking on eng work when there's an urgent or relevant bug. For my last week, I'm prioritizing some eng work ahead, to keep my teammates unblocked in their current project, then doing product work to keep them unblocked for their next project, then doing eng work so I can finish my current project.
For context, Jam is a Browser Extension which lets PMs, QAs, support, etc., quickly report bugs to their issue tracker, for their engineering team. Then, when an engineer views a bug on Jam, they see the console logs, network requests, and a video, screenshot, or session replay. We call the eng-specific part of our app the "devtools". My goal is to, with 6 weeks of our engineering team's time, improve the experience of engineers using devtools as much as I can.
An example of what a bug filed with Jam looks like today.
A developer may read the bug description, watch the session replay, look at console logs, or inspect the body of a network request, as part of their debugging process.
Now, with your understanding of how this works, here's my perspective on how it feels.
Well, I just finished week 5, and it's been like a plunge in cold water! Remember on a hot summer day, you might hop into a swimming pool, and even if the water was cold, it felt refreshing? But first it felt cold?
So first you're eyeing the pool, and it looks great. Then you jump in, and it's cold. But then you start swimming, and heat up. As you reach the surface again to breathe, it's starting to get refreshing.
Here's how it went:
On my first week, I was still wrapping up a feature and some bugfixes unrelated to devtools. At the same time, I was doing market research: thinking of ideas, asking friends/developers/our eng team, looking at customer feedback, and looking at other products (mostly Chrome devtools), to create and pick features we might build.
This felt relatively simple. I'd already done market research for half of my eng/product internship at LinkedIn. I'd compare it to looking at the pool.
Then, the second week, I scoped out the cost and the expected impact of the potential devtools features, and decided which ones we'd prioritize for our 6 week sprint. Once I had that list, I began writing Product Requirement Documents (PRDs) for the features we were going to build. These are documents that should contain everything an engineer needs to build the feature, including handling edge cases, design mocks, and text copy.
This felt adventurous but doable. I'd have to express my opinions and be the authority on product decisions here—previously I was always able to ask the PM if I felt unsure. I'd compare this to jumping into the pool, cannonball style.
Then, the third week, I continued writing PRDs, and started pairing with our designer to mock designs for them. This is a lot more involved than your normal product + design collaboration, because devtools are very opinionated and intricate. As a technical PM, you need to be there to assert those opinions that engineers (users) will have, but at the same time, you're not a designer. So it's a tight collaboration.
This started to become a little overwhelming, as the sheer amount of meetings began to balloon. I'd compare it to jumping in the pool, and feeling the cold shock of the water.
Next, the fourth week, I continued writing PRDs in tandem with designs, and finished designs for these PRDs with our designer. I also worked with our PM-founder, Dani, to decide how to allocate engineers onto these project.
This felt a little tricky: meetings decreased, but decisionmaking and managing my own time increased. I'd compare this to swimming up from the bottom of the pool.
And most recently, the fifth week, I did a couple of engineering kickoffs to hand off two PRDs to the engineers working on them. Then, I quickly finished a small feature to unblock them—they'll hook into the code in it as part of the ticket they're currently working on. After that, I continued writing PRDs, creating the final PRD (but not finishing designs for it).
This again felt overwhelming and tricky. meetings increased, decisionmaking increased, and I had to manage my own time better than before. But I knew it'd get easier soon. I'd compare this to swimming, almost at the surface.
At this point, I have to kick off two more features with engineers next week, work on the last two unfinished PRDs (one has design assets, one needs both product and design work). Then, I can work on the next feature that I've allocated myself onto as an engineer.
I expect the following weeks to be calmer (starting 2wks from now), as most of the product planning will have been done, and I'll be mostly in engineer-mode. Then, when other engineers wrap up their projects, I'll kick off another project with them and work with our marketer to launch updates.
So that's the overview.
As usual, I made mistakes. Nothing crazy, but I'll be unlikely to make them next time.
Chronologically from the top, they are:
But the biggest source of pressure was my last mistake: the unexpected time-cost of things I needed to do that didn't produce deliverables.
For example, a few sources of time pressure:
These 5 weeks have given me more respect for PMs. It's easy to see a good PM do their job, without realizing all the parts they have to keep coordinated in lockstep.
I already knew how important communication was, but I didn't realize how hard it was. It's easy for things to slip between the cracks, yet optional communication (like giving an overview of the sprint to the whole team in standup) often has an outsized impact (like getting everyone excited).
Most importantly, I learned how important excitement is. Most of us would agree:
So, when kicking off features with engineers in last week, I tried to group features together for each engineer, allocate enough time to do features well, and be flexible when engineers want to make product and design changes. The idea is to let engineers own the features they're working on—just like when I upgraded devtools myself, last time.
It ended up being helpful to me, too! It turns out that when an engineer feels that they're allowed to make product and design decisions, they might make better decisions than you—the PM! Think about it: they're focusing deeply on one feature, while you're spread out over multiple features at a time. That means they have time to focus on the nuance of tiny behaviors that they implement, but you might not think to cover in your PRD.
Anyway, if you enjoyed reading this journal-style post, and thought you might have fun working here—check out Jam! To be clear, my engineering weeks are much more relaxing than the hybrid role I've written about here ;)