Explore

I learned at least 6 things in my first week as a Product Manager

Still need to figure out what the P stands for

Jeremy Olson

Project Manager? Program Manager? Pun Maker?

This is so confusing.

I guess I’ve been a designer at

Coda⁠

for kind of a long time now — 3 years this month if LinkedIn is to be trusted.

Three years ago I definitely didn’t think I would be a Product Manager. Partly, well mostly, because — I kid you not — I didn’t know what a Product Manager was. I’d never met one in the flesh before joining Coda. I guess co-founding a

company⁠

of 7 people kind of made me a Product Manager, but I sure didn’t know that’s what I was doing.

My journey into Product Management was a long and winding and... gah. That's pretty much everybody who ever got into Product Management, right? Long story short, I ended up falling into doing quite a bit of PMish work in the last year as I contributed to figuring out how on earth we were going to monetize Coda. I found that I liked it, and a few weeks ago Lane — our awesome head of product — posed the crazy idea of jumping fully into PM land. I saw it as an opportunity to both learn a ton and make a different kind of impact at the company, so I said yes and here we are.

I made a new year's resolution to write once a month. Now that I'm a PM, I guess I'll write about PMing because I'm a millennial and one week on the job definitely qualifies me as an expert on the topic (hey, I made sure to do my due diligence on the first page of Google results for "how to be a good PM" so back off.)

I've gotten a ton of good advice about Product Management in my first week and these are the six things that really stuck in my first week, so here goes.

1. Fill the shoes before changing the shoes

⁠

As a new PM, I want to show my team that I can make a big impact on their lives, work, state of mind, and just general fulfillment as humans. If you had any troubles in the past, fear not — I am here to make things awesome from here on out. I've got my big ideas and, as Steve Jobs always said, "we think you're gonna love" them.

If I don't make some big changes fast, people are going to think I don't have brilliant ideas — right?

Thankfully, Shishir — Coda's CEO — rescued me from my delusions of grandeur (spoiler alert, many of these tips come from Shishir, some of which you can find in

this doc⁠

Shishir's recommendation was so counterintuitive: don't change anything! Fill in the shoes of the old administration first. Learn how things work today. Talk to the team and understand what is going well and what isn't. Then, once you have much more understanding and context for how the team currently operates, make changes based on that.

So in my first few weeks I am mostly learning. Lots of 1:1s with my team, partners, other PMs, and executives.

And boy am I glad I am. Even after just a week my perspective of my team has changed drastically — both around how we operate and around our charter and vision. Things that I thought were key problems were not as important as others that I uncovered during the process. I think I'll be much better prepared, and have much more trust built up, to make changes in a few weeks.

2. Want to influence your team? Take notes.

⁠

Speaking of building trust—which is kind of important in a role all about influencing an outcome without any explicit authority—a really counterintuitive way to do that is to do a thing that a lot of PMs may feel is the most basic, junior, or degrading part of the role: take great notes.

Take notes in team meetings, in 1:1s, in meetings with partners and stakeholders. Email the notes to the relevant parties, ensuring to highlight key decisions, action items, or key context.

Capturing thoughts, clarifying them, summarizing them, and turning them into action is an opportunity to show the people you are working with that their thoughts matter and can be the difference between idle chatter and a meeting that pushes the project forward. Doing this consistently will build trust and credibility, giving you a much better shot at having your own ideas taken seriously.

3. Chase ambiguity

This one is from Lane, Coda's head of product. Another great thing about taking good notes (and, importantly, summarizing them and sending them out) is that it forces you to sniff out, chase down, and remove any and all sources of ambiguity.

Let's take an example.

You are in a meeting and someone says:

"Some users are complaining about having trouble with the sharing dialog."

This sentence is almost pure ambiguity.

"Some users" — how many users is "some"? Are these users on our free plan or key stakeholders in an important enterprise account?

"Are complaining" — how severe are the complaints? Are they slightly annoyed? Are they about to churn because of this issue? Are they outside with pitchforks?

"about having trouble with the sharing dialog" — is it a bug? Is it the user experience? Is it a feature request? What aspect of the sharing dialog are we talking about? Will this require a quick fix or a complete refactor?

We should clarify the most important of these questions to determine if this is something we should take action on.

Suppose an engineer responds:

"Yikes, sounds like something we should work on. Thanks for sharing."

Ambiguity sirens should be going off. This is such a dangerous way to end the conversation. The person conveying the feedback feels like the team heard their concern but this interaction is unlikely to turn into action and is in perilous danger of being a waste of everyone's time.

As a note taker (see point 2), you have the opportunity to clarify the ambiguous request in order to capture it in the notes, and because you know you are responsible for communicating a summary of the meeting, you will want to also make sure to eliminate any uncertainty around next steps. Either you, the feedback giver, or the engineer need to be responsible for doing something and recording it somewhere so that everyone else knows what's going on. You are responsible for figuring out who and what that is and making sure it is captured in a form that will be followed up on.

This tip has been fun to apply. When I have been actively thinking about it, I have started to see ambiguity everywhere — meetings without clear agendas, discussions without conclusions, vague agreements to do something with no clear owner or next step. If unchecked, ambiguity ends up wasting a ton of time and kills morale. It's not fun to feel like a meeting was just a bunch of talk — it feels great to turn that ambiguity into action and make people feel like their time was well spent.

4. Know thyself to grow thyself

⁠

One of the primary reasons I was interested in leaping into a new role as a Product Manager is because I knew that it would involve growing in areas that I am currently weak.

Shishir has a really helpful way to think about what great PMs do, so I used that list to evaluate myself.

Loosely paraphrasing Shishir, the best PMs focus on PSHE:

Problems: Take an ambiguous space and uncover the most important problems.

Solutions: Develop creative and insightful solutions to those problems.

How: Figure out how to assemble an appropriate team for the solution, drive prioritization, influence and resolve contentious issues among team members and other stakeholders, and communicate on behalf of the team.

Execute: And finally, execute the solution in an efficient way — establish clear requirements, catch important details, collaborate well with design and engineering, run efficient meetings, and make appropriate tradeoffs to deliver the product on a timeline.

Reflecting on these, I found that my biggest need for growth was around the last two. Some PMs are naturally organized — I am definitely not. If I don't make a conscious effort, both my personal life and professional life very quickly fall into a state of dismal disarray. And living in chaos doesn't bother me as much as it does a naturally organized person, so I also don't notice the problems as readily as others. I often forget to follow up. My Figma mocks often degraded into a state of framepocalypse.

Knowing this, I am focusing the majority of my learning and energy into turning my weakness into a strength. Things like:

Making sure I'm prepped with an agenda for the next meeting so that it doesn't waste people's time.

Sending out a follow up summary and notes, and making sure every important item is captured somewhere the person responsible will see and can follow up on.

Breaking down work in our tracker, always making sure to track new items as they come up in conversation, and making sure the tracker reflects our daily progress.

And other stuff like that.

I don't yet excel at all of these things but I've found that by making a conscious effort, I can definitely "fake it" pretty well in the short term and build up those organizational muscles for the long term.

5. Seek out feedback and act on it

⁠

If you live in Silicon Valley, or have seen the show, chances are you've heard of the book

Radical Candor⁠

by Kim Scott. But there's a good reason for that. I'm naturally inclined to want to avoid confrontation and not give feedback to someone if I think it may hurt their feelings — this is a pretty common mode of operating Kim calls "Ruinous Empathy". It's ruinous because the thing you don't want to tell someone is likely the very thing they need to hear to avoid that misstep in the future and grow in their career.

On the flip side, I have learned to consider receiving feedback as a gift, especially because it requires so much vulnerability to give. There are a lot of people like me in the world, so it can help to seek feedback out. In 1:1s, make sure your team and partners understand that the thing they may feel uncomfortable telling you is the very thing you want to hear, the thing that will make you a better PM. After a meeting, ask someone you trust how they think it went? Probe and pry to get concrete feedback — good or bad, not taking "think it went pretty well" as an answer.

Folks knowing that you are actively seeking feedback can sometimes remove some of those natural barriers that cause well-intentioned colleagues to hold back. Quick story from my first week.

I was presenting the team's work for the week during our weekly all-hands demo time. I hadn't prepped well and when I was trying to explain a thing we did that I didn't fully understand, I made a joke about how I didn't understand what it was. I intended it as a joke about my onboarding but someone gave me the really great feedback that the joke undermined the hard work the team put into that thing. That feedback made me realize that there were actually quite a few things our team does that are hard to understand, appreciate, and celebrate. This has given me the chance to try to actively find creative ways to celebrate the hard-to-appreciate work our team does.

6. PM yourself first

⁠

It was my first day as a PM. I was trying to balance onboarding, making sure my team was unblocked, and prepping for a meeting that I had moved twice already. I vividly remember sitting at my desk and going into a state of panic. I've committed to these three important things. I literally have zero way of doing all of them adequately.

I froze. I think I sat there staring blankly at my to-do list and calendar for about 15 minutes.

This ended up turning into a moment of clarity for me. Everything is a tradeoff. PMs prioritize work for their team, but the same goes for their own time. So I took a step back, looked at what I had committed to, and weighed the trade offs of letting one or the other slip. My priority became clear and I was able to focus again.

Since then I've realized that when you own an area, there really is no end to meetings I can be better prepared for, user research I can be doing more of, product problems I could think through more thoroughly, designs I can be giving better feedback on, partnerships I can be investing in more, and the list goes on. I've found that spending a few minutes a day making sure I'm prioritizing the right things makes a huge difference. I look at my to-do list Coda doc (which has gotten quite a bit more sophisticated over the last week), compare it to my calendar and figure out what I can slot in for the day. I've been trying out actually putting solo work onto my calendar to block off the time and be realistic about what I'm going to get done. So far, investing in this area has paid big dividends in making sure I'm laser focused on things that are making the most impact.

⁠

Screen Recording 2020-02-19 at 10.20 PM.gif

⁠

I've added some features to my personal to-do Coda doc like a simple checkbox if I plan to work on something today and a quick way to size items so I quickly find items to do when I have 10 minutes versus an hour. GTD people don't @ me, I know I can be doing more. Don't worry, next week I'm adding a sizzling hot calendar integration, so take that!

⁠

Well that's it. This transition has been crazy, uncomfortable, and rewarding all at once. It's been a long time since I've learned at this pace. At the same time, there are plenty of insecurities that come along with it. As the longest-standing designer on the team, I was pretty comfortable — I had a pretty good idea about where I stood and personally felt pretty secure in the value I was adding to the team. Jumping into something new means feeling more vulnerable. It feels risky. But it's exhilarating too. But it... okay — I'm going in circles. Back to work.

There's a thing brewing

Oh, and I'm starting a thing. It's initially just a newsletter but I've poured several dozen hours into a project I think a lot of Product Managers (n00bs and pros alike) will get something out of.

⁠

Tweet me⁠

if you want an early look (I’d love feedback!) or sign up for my newsletter below and let me lob stuff directly into your email, Gmail, or $30 Super Duper mail.

⁠

Loading…⁠

⁠

About me

⁠

Hey, I'm Jeremy Olson. I'm a newly minted Product Manager at

Coda⁠

after being a designer at Coda for 3 years.

Before that I ran a little Apple Design Award winning app studio in North Carolina called

Tapity⁠

for about 8 years, as well as a time tracking startup called

Hours⁠

, which was acquired in 2016.

⁠

Wait, Coda?

So why on earth did I post this on

Coda⁠

? I mean, publishing a template or interactive doc with Coda would be understandable — but an essay? 3 reasons.

It's a free country. I love Coda. I work at Coda. I wrote this in Coda. And I actually plan to post all my stuff on Coda from here on out — and there's really nothing you can do about that.

I know stuff you don't. This will make more sense soon.

Why choose? I'm planning to make Coda my primary publishing platform but I'll be reposting stuff on Medium and Substack too.

Want to print your doc?
This is not the way.

Try clicking the ⋯ next to your doc name or using a keyboard shortcut (

CtrlP

) instead.