A bit over a year ago, I took a chance on my career.
I was a Product Manager for 3 years already, but I wanted to try something new, something that would stretch and challenge me. I stumbled onto this friendly-looking Toronto startup with 5-star reviews called PartnerStack, which helped other tech companies run successful partner programs.
Not knowing much about what that even meant, and not thinking much would happen, I clicked the “Apply” button on one of their job postings.
I couldn’t have anticipated how much would change, and how much I would change, after that one application.
I’ve had the privilege of working on fascinating projects that have stretched and informed my perspective. More than that, I’ve had the privilege to learn from amazing colleagues and leaders who I deeply respect.
So, as my way of saying “thanks”, I wanted to share four lessons I’ve learned over my first four quarters spent at PartnerStack:
- #1 (Q4 2021) Stakeholders hate surprises more than anything else. When in doubt, reach out.
- #2 (Q1 2022) Reactivity is the enemy. When in doubt, pause and double-check.
- #3 (Q2 2022) Your job isn’t to guarantee a plan. Your job is to adapt the plan when things inevitably change.
- #4 (Q3 2022) You owe it to your future self to know your user inside and out, even when it feels “useless.”
- Let’s wrap up :-)
- Credits & Help
#1 (Q4 2021) Stakeholders hate surprises more than anything else. When in doubt, reach out.
I began at PartnerStack with an obsession for research. My supporter handed me a very ambitious assignment: study how we currently onboarded new customers, and make it ten times faster. I would have one year, and one scrum team, to make it happen. The scope potentially included every part of the application, and was incredibly exciting to consider.
I was hypnotized by the research, spending several weeks watching our onboarding process unfold one recorded Zoom call after another. I saved every slide, document, and piece of homework into a monolithic Miro board, and soon exciting opportunities to save time and money emerged. I eagerly prepared a presentation to tell my team all about it. The year to come was an exciting prospect.
About two months into this project, I got a Slack message from one of the leads of the onboarding team. “Hey, are you in the office? I’d love to meet for 5 min.”
We spotted each other easily in the mostly-empty cafeteria, shook hands, and commented on how nice it was to meet in person. Just as quickly, he informs me, “I’m not seeing the level of excitement on the Onboarding team about the self-onboarding idea as I’d like. I think we need to do better here.”
In that moment, it struck me: the onboarding team wasn’t excited because I wasn’t informing anybody outside my team what I was doing. There was no channel for communication to the onboarding team, no space for questions or updates. The team had no insights into this project that threatened to deeply change their day-to-day working lives, creating uncertainty and worry. It needed to change.
I made a couple of quick pivots. I created a regular set of 1:1’s with a leader of the team. I presented the project’s status at the onboarding standup. When I apologized for taking up the team’s time with very early-stage plans, I received another quote I won’t forget: “we don’t mind. What will really piss us off, though, is surprises.”
I also created a small advisory team for the project consisting of a delegate from onboarding, integrations, and sales. Meeting regularly not only facilitated better communication, but helped provide needed perspectives on early designs and ideas we would have never gotten otherwise.
With time, the project would be deprioritized as other business needs flared up, demanding our team’s attention. However, I’ve never forgotten that 5 minute chat in the cafeteria, and what it taught me about cross-team communication. Over the year, those lessons would lead to great relationships with people I respect and trust.
It rarely hurts to over-communicate. It always hurts to under-communicate.
#2 (Q1 2022) Reactivity is the enemy. When in doubt, pause and double-check.
“Oh, okay,” is my nemesis. It’s this sneaky phrase that adds itself into conversations where I have no idea what’s going on. Conversations where I should really say, “um, sorry, what?” or, “could you say that one more time?”
Case in point: in one backlog refinement session with my team, an engineer brought up that he had agreed to the team injecting a couple of extra stories into the backlog to help out the IT team - they “needed” it, he said.
Here’s what I probably should have said: “wait, what? We should have talked about this before committing to anything - and what is this thing anyways?”
Here’s what I actually said: “oh, okay.” I selected the stories, and without even looking at them, dragged them into the upcoming sprint. After all, the IT team needed it.
It was the March of 2022. COVID numbers in Toronto were down, the days were getting longer, and the PartnerStack office just reopened after a 2-month hiatus. I was one of the few that attended the office every single day. So was the lead of the IT team.
My product designer and I were just wrapping up discussions. Those IT tickets were bigger than we both thought. I updated our company’s Slack with an announcement: “Unfortunately the team was needed on some critical IT work, so the big feature is pushed back 2 weeks. Appreciate your patience!”
Almost instantly, I hear the IT lead yelling for me across the hall: “Paul, you’re delaying for my stories?! They aren’t that important! What’s going on?” It quickly became apparent that there was a miscommunication in just how needed the stories were versus the other work on our team. I was shocked: by choosing to say “oh, okay” to those extra stories in a backlog refinement, I cost my team a sprint & prioritized the wrong piece of work.
It was a difficult truth for both me and the team to accept, but it was a good lesson for all of us. We slimmed down our designs, cut scope. This time, the IT leader was in the discussion alongside us.
Still, the shock of that conversation never entirely left me. What was to stop the next time this might come up? I created a playbook with detailed instructions about how to handle pressure from outside the team to take on extra work. The first step is always to pause, take a breath, and to note that you have the right to say, “I’ll get back to you later.” Relaxing the expectation of an instant response has saved me from “oh, okay” more times than I’d care to admit!
Ultimately, just reacting and saying yes in the moment spares your present self a bit of a headache, but it costs lots for your future self, and your future team, in the long run.
#3 (Q2 2022) Your job isn’t to guarantee a plan. Your job is to adapt the plan when things inevitably change.
There’s a cliche for this: “change is the only constant.” I like to think of this way: as soon as you plan it, it’s not going to happen. Reality is too complicated to capture in a roadmap.
Everybody’s plans abruptly changed as a tech recession and huge layoffs swept across the world.
One morning I received a meeting invite ominously titled, “H2 planning.”
Seeing team leads and PM’s from across the organization on the invite list, I think that it’s my turn on the chopping block.
Thankfully, the meeting wasn’t about layoffs, but about change.
The Director of Engineering, sending us a Miro link, made the exercise clear. “We need these five business problems solved as soon as possible. You can get rid of anything else that you’re doing. Any ideas?”
To my surprise, my team’s senior engineer volunteered that we’d be equipped to take on a data discrepancy issue in the application. It would take us at least a month or two, and push a new exciting feature back a whole quarter.
It was a difficult reality for both me and my team to accept. We felt like the top-down decisions from leadership were too frequent, like the higher-ups were willfully shuffling around our priorities. Our calendars booked up with extra meetings to plan the changes and coordinate information from one team to the next. Morale took a hit.
Those months of change, though, brought about a crucial realization: Our team is not the customer of PartnerStack. PartnerStack is the one and only customer of my team.
It reframed everything. The company didn’t exist to give value to my team. Rather, my team existed to give value to the company. And in the midst of a recession, the list of most valuable problems to solve changed dramatically.
As sprints continued, our plans would change, then change again. But a subtle shift took hold. As we all got on the same page about why our team existed, the changes didn’t bother us like they used to. We grew resilient in a way we would have never anticipated.
I didn’t conduct a depth of research for anything that quarter as I would have liked to, but just my adaptiveness to the changes was enough for leadership to give me an award:
Good product managers don’t insist on a specific plan happening no matter what. They adapt to the situation, insisting on, no matter what, solving the biggest problems.
#4 (Q3 2022) You owe it to your future self to know your user inside and out, even when it feels “useless.”
I was halfway through 2022, and I felt good about my progress. In June, I got an opportunity to work on a rapid research project that saw me crunching data and interviewing customers. It felt great!
I mentioned it one day in a discussion with my supporter:
- me: wow, I really enjoyed the handful of times I got to chat to customers recently! Maybe I should more of those…
- supporter: hey, you do know that’s part of your job description, right?
- me: oops
I realized that I wasn’t talking to users, actually, because it felt a little “useless” to me. I already had a long backlog of ready-to-go stories that were just waiting for development, already backed up by user research. So, why go talking to users when I already knew what changes they needed to make in our application?
My supporter introduced me to the idea of a “discovery call”, a kind of user interview where the goal isn’t to answer a specific question, but to simply discover new information about the customer’s backgrounds, values, and high-level problems. I decided to be ambitious, and set a goal for myself to complete 23 by the quarter’s end.
I found myself struggling to even start reaching out to customers. Who would want to call a product manager not about a particular bug or feature, but just… their own lives?
To my surprise, everybody in customer success I talked to voluntarily referred me to the program managers and partners they worked with, and many booked a call with me.
I conducted 15 calls, all in all. And I’m deeply grateful I did.
I learned about how valuable PartnerStack is as a piece of automation, how valuable our software is to leaders to be able to “run in the background” (and, how frustrating it is when it can’t be automated).
I learned about how crucial data and detailed reporting is in the world of partnerships, how it can ruin a person’s day to have to miss that one report they deeply need.
Most importantly, I learned who our customer were: some were recent university graduates like myself, and others industry veterans who’d seen the dot-com bubble burst. Some were one-person teams, others scrappy and small business units.
All of this “useless” knowledge helped me to grasp the bigger perspective. It gave me confidence in decisions that used to rattle me: saying “no” to new low-priority stories. And when it came time to prepare product marketing materials for a new release, I could easily draw on my knowledge from those interviews to frame new releases in a simple way our users could recognize: “less time in tedium, more time doing what you love.”
“Talk to your users” is cliche advice for product managers for a reason. It helps to understand the worldviews, joys, and concerns users carry. We start thinking like them, carrying their perspectives into our meetings and heads-down time. Even if these perspectives don’t make it into an epic or user story, I’m more informed for knowing them - and deeply grateful to everybody who shared their stories with me.
Let’s wrap up :-)
I’m not perfect at any one of these lessons. There’s still a depth to stakeholder communications I’ve yet to grasp, especially between teams with different understandings and ideas. I still reactively say yes at times when I might have done better to pause and think. And I still find myself too easily deprioritizing talking to the users.
But perfection isn’t the point here. More than anything this year, I’ve learned that consistent effort in the right direction is more valuable than anything else. Failure is to be expected and prized because failure helps us to learn and to be human. Consistent effort amidst failure helps us to dive deeper, get closer to the people involved, and learn more deeply.
Projects, deadlines, and to-do’s all have their place, but they all come and go. It’s the lessons that stick with us for a lifetime.
Credits & Help
Special thanks to Ashlyn Conway, Shivana Van Wymeersch, Brianna Hugh, and Lynda Ogude for providing early feedback on this piece. You’re all 🥇 in my books.