My first month as an Engineer doing Product Management

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.

Now, with your understanding of how this works, here's my perspective on how it feels.

And how does that feel?

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.

My mistakes

As usual, I made mistakes. Nothing crazy, but I'll be unlikely to make them next time.

Chronologically from the top, they are:

• As I did market research, I didn't consider that after I do all of the research on what exists (thinking as a developer, reading customer feedback, sourcing developer opinions, looking at existing products), I'd still have more thoughts that I would personally come up with at the end. So I ended up rushing near the end, and I don't think I did a good job capturing (and thus prioritizing) some of my more experimental ideas.
  • Giving me a hybrid PM role for a whole 6wk eng sprint is already experimental (for context, this is also the first time we've tried 6wk eng sprints at work), so maybe it's better to not add too much variance with experimental ideas. But I do wish I had more time to flesh these ideas out, they seem interesting.
• As I was writing PRDs in week 2 and week 3, I suddenly realized that while a PRD communicates product requirements to engineers (and that had been all I'd experienced as an engineer), there was something more to a PRD.
  
  Turns out, a designer also needs to know the product requirements. So I went back and typed out the full user flow from the perspective of what the user needed to do, for PRDs with complicated flows. Then, for PRDs with specific cases that needed to be designed, I went back, and typed out the cases that needed to be covered.
  • This wasted both product time and design time. Design time was more important, as it was more limited.
• Next, as I allocated engineers, I realized that I didn't chart out the allocation of engineers earlier, I just kinda winged it and estimated in my head. It wasn't a huge mistake—I hadn't overpromised any customers. But I had gone through the design process for most of our features, and it'd be a waste of design and product time if we had to cut a fully-scoped feature.
  • Luckily, we managed to fit everything in (or I just made another mistake and overpromised my own capacity as an engineer, we'll see).
• Finally, for the fifth week, I didn't think to show to the team what our sprint would look like on Monday at standup (to get them excited), to involve marketing (to give them heads-up), or to pipeline the work I was doing (to make sure people are unblocked in the future).
  • Luckily our PM-founder Dani thought of these things, and mentioned them to me, so I managed to benefit from her foresight 😛

The biggest mistake

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:

1. I've been getting my wrists checked out, and going to Occupational Therapy (OT) to get this sorted out, which takes 2.5hrs a week on average
2. Two of our engineers recently joined, and as engineers onboard, they need help with:
   • dealing with our tooling, CI, local dev env
   • architectural overviews of dataflows/parts of our codebase
   • pair programming and/or debugging
3. Having regular 1-1s with teammates, which used to be a nice forced-break from programming, lost this benefit, given I was already frqeuently context-switching.
4. Being the engineer with the most experience on our devtools codebase (due to my earlier chance to improve them) and devtools-adjacent data flows (coincidentally, due to other feature work I'd done), I was the go-to person for background on them.
   • This meant that after I kicked off devtools features with an engineer, I'd spend additional time in calls/DMs giving background for architecture or technical decisions

What I've learned

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:

• When work feels meaningless, I feel demotivated.
• When work gives me potential to do good work, learn, and make a product people enjoy, I feel excited.

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.

Obligatory callout

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 ;)