No walking, just sprinting: My six weeks as an ersatz PM

Background

Our most recent cycle of work at Customer.io was an eventful one. We were in the middle of hiring for several positions, not least of which was a Director of Product — welcome, Brian! As a result, our product team was really light on personnel. We had:

  • Our CEO, Colin
  • Front-end engineers Kate and Najwa
  • UX designer, me! 👋
  • …that’s it.

We had rotating help from the back-end team also. But you’ll notice that there’s no product manager in there. Colin would only be able to help part-time, given his CEO responsibilities. The show had to go on, though, even if we couldn’t run our work cycle the way we would want to. We had features to plan and build. We had previous-cycle work to follow up on, pitches to review, and feature requests to address.

What we did

The plan was for me to temporarily step into a product-manager-slash-UX-designer role, help plan and estimate the features at the beginning with Kate and Najwa, and then help facilitate building those features. I wasn’t a PM-only, or a UX-designer only, but both (sometimes), and Kate and Najwa would be engineers and sometimes-product-designers! We knew it’d be challenging, but we wanted to make it work and planned to do our best, identifying trouble as soon as we could and addressing it.

How it went

Note that this is just my personal experience here, as that’s what I have a front-row seat for.


For the record, I often feel like this at the best of times. Now it magnified tenfold; in my design role, experience enables me to identify gaps in my knowledge, and figure out the information I need. I didn’t even know what I didn’t know about being a PM. There’s only so many Medium thinkpieces you can read; applying it to your own company and situation takes work and time. I learned a lot about myself as a designer, PM, and human.

What I think I did well

  • Juggled a lot of unfamiliar tasks, and jumping in! I did want to meet the challenge head-on. There were lots of features in different stages of development, with different objectives and disciplines. I was involved in the development of functionality that I never would have been previously (backend-only changes, for example).
  • Wrote a lot. I try to write as much documentation as I can in general, but I did even more so this time around. I wrote a got-better post for each feature we released, as well as documentation for our Knowledge Base. I also updated and improved the docs that existed for existing features, and started on some solid new work!
  • Unblocking folks promptly. I was able to jump into UX work, documentation, customer research, etc. whatever was needed to unblock people if they needed extra information. It did, however, take me a bit too long to do so sometimes (see “what I think I didn’t do well” below).
  • Keeping scope down. I got better at this towards the middle/end of the cycle. It’s hard to say no to something that actually is really easy to add. That can snowball really quickly.

What I think I didn’t do well

  • Planning and estimation. The core of product management. Planning features as a designer vs. as a PM is very different. In our “planning week,” I wasn’t sure how to break apart a feature for all disciplines, not just UX perspective and what precisely needed to be defined and when. I could have planned less features more meticulously.
  • Document progress internally. I could have done this so much better. In just focusing on getting things done, I delayed documenting said progress; this came back to bite me a few times, because I couldn’t remember why we’d made decision B for feature A, and slowed us down.
  • Being proactive about asking when people needed something. Sometimes I was guilty of waiting too long for others to ask me for help. I could have unblocked people sooner!
  • Communicating to the wider team. While I wrote a lot of documentation for customers, I could have been much better at communicating product across to the company.

The result of all this was slowed progress as we uncovered knowledge gaps. Could we have foreseen them? Sometimes yes, sometimes no, but when you’re already a bit short, that tends to compound and feel frustrating. It’s hard to know that you could have done better for your team, but missed something along the way that retrospectively seems obvious.

To be clear, I am happy with the work we’ve done! It just took longer than expected in a few cases, and my execution of it was occasionally ham-fisted, but we were committed to shipping things that helped our customers, and we were sympathetic to each others’ unfamiliarity with roles. We worked for each other, which is what I’m happiest with.

What I learned about product management

To most, this won’t be earth-shattering, but it’s worth saying out loud (as it were).

  • There’s a lot of context-switching, much more so than I’m used to in UX, between features and responsibilities and roles. Wireframing one minute, docs the next, then estimation, then chasing up feedback, etc. This was very difficult for me.
  • It’s an immensely varied role, depending upon that particular PM’s previous expertise, and the expertise of those around them.
  • Structure and process are imperative.PMs and their teams need concrete structures to estimate and plan their work, and communicate those decisions outwardly. Having not been a PM, I didn’t know what tools I would need. I believe I could have taken more time to try and identify these gaps in my understanding at the beginning. Having a framework of any kind is imperative to managing products, features, and the people who work on them.
  • You’re not managing a product, you’re managing people (duh). At its core, this job is the enabling and facilitation of others, and I really enjoyed that aspect of it. I was most comfortable in the UX niche of it, of course, but being able to unblock and let other people do their best work when I could was immensely satisfying.
  • You’ve got to be okay with stuff not getting done. I hate this: the knowledge that there will be things (usually extra improvements that are identified somewhere along the line) that just won’t happen, at least not yet. It sucks, but you’ve got to be ruthless— it pays off in the long run, especially if you have a process or framework to follow up on those little “not just yet” improvements.

How I’m going to use those learnings

No use acknowledging the above if I don’t learn from it. So, I will:

  • Be a better leader, planner, and estimator. I’ve learned a lot about accountability, and what other people need from me to help them do their best work.
  • Know how to better and more directly identify if people are blocked on something, and know what to do about it.
  • Know when to resist context-switching, and be more deliberate about heads-down work when I know it needs to get done. I may think that there’s a quick win to be had elsewhere, but maybe I should just focus on this task.
  • Better understand our future product managers’ responsibilities and goals, and what they’ll need up-front when it comes to planning and estimation within Customer.io, not just from me but from the team at large. I will be a better communicator.
  • Be able to better evaluate our feature development processes going forward, and know when they’re going well (and not well) as we grow our team and find our way.
  • Be better able to say “I’m not good at that. I shouldn’t do it.” I sometimes over-commit because I want to help people, but sometimes not doing the thing is just as helpful.

In the end

Nothing earth-shattering there, I realise. But there’s value for me in reflecting, in reinforcing what I’m good at and shoring up where I’m not. A product manager working on our team would not be expected to juggle All The Things above — as a UX designer, I will help with planning. As front-end engineers, Kate and Najwa will be involved in planning and product decisions. But I am also going to be a better UX designer, facilitator, and communicator.

I look forward to working with Kate and Najwa in hybrid roles once again, as well as with Brian (our new Director of Product), Kevin (our new front-end engineer), and the product managers that will inevitably arrive!

I also realised how much I love UX work. What’s that they say about absences and hearts growing fonder?


PS: If you hadn’t noticed, we’ll be looking for PMs soon. If you want to come with with some brilliant folks and shape the future of Customer.io, give us a shout!

Join our mailing list for updates on our content and more!