Welcome to the latest episode of Product to Product—a product management podcast for / by product people.
As Aman was getting ramped up at Square, he noticed that the PMs he was working with all came from different backgrounds and had varying perspectives on what the role of a PM should be within an organization. So, he decided to get them all together to come up with a singular definition of what it means to be part of their product team. And they created what Aman calls a PM culture guide.
Aman spoke to Nick, our own product manager at Roadmunk, about the guide (the process of making it, how it’s used, the feedback it received, and how other teams can benefit from the same exercise.)
The episode can be listened to above, and we’ve also included a transcript below. You can subscribe to Product to Product on iTunes (here) and Google Play (here), or get the latest episodes delivered to your inbox by subscribing here.
Nick: Thank you so much, Aman, for joining us today. I’m really excited to have you on Product to Product. Before we get into this really cool idea around creating this product management culture guide, maybe you can describe to us what you define as product management culture.
Aman: I think culture is really interesting. The way I got introduced to a product management culture was at Box—where I felt like everybody I worked with was a friend. We were able to share the same values. We had the same passions. We were really about driving the business forward. There wasn’t a lot of hidden agendas or ulterior motives or politics that can be seen when you get to bigger companies.
But really, I think a great culture is one where—especially for product managers—you’re really sharing best practices with each other, you’re connecting around making each other better, and you’re ebbing and flowing around a common set of principles.
At Square, we all came from different backgrounds. We were product managers but we were all working on our own products. We were doing great in our own right, but there was an opportunity for us to connect a little bit deeper beyond being coworkers and friends, and really share what our expectations of product managers were.
Even you Nick, you came from a different background, so your idea of a product manager and how it fits at Roadmunk is probably very different than how a product manager fits in for me. So a really good culture is one where you can join on a common set of values and really build from there. I don’t think there’s a recipe to create a PM culture.
Nick: Yeah, I agree with you on so many levels. A great foundation when you’re in any organization, is trying to start out with camaraderie and friendship—getting to know people on a more personal level and seeing how those attractions lead into a more professional culture and environment. But as we go deeper into product management culture, how do you feel that lives independently from the company culture?
Aman: So, what I like about Square—and I think what keeps me there—is our passion for the small business owner. I feel like everything we do is about growing their business. And that’s macro and everyone has a common language and understanding. But when you get into product management, it’s separate because that’s more of a functional role. That’s getting one level deeper, about how do we actually get our products better, so we can serve our customers better.
Other roles like sales and customer support are there to help customers get started and solve issues—and it’s pretty standard across different companies. But when you talk about a product manager, in my experience, PMs all have their own general understanding of what a product manager does. It’s not a bad thing. It just means that everybody has their own shape and view of what a product manager does. And this is probably the reason why there are unlimited resources online for what a product manager does and how they can be successful, because there are very different ways a product manager can fit into a company.
The way I think about product management culture for us at Square, is that it’s really a union for us to share best practices and codify what a product manager is, in terms of their roles and responsibilities and day-to-day. Whereas, the culture for Square is more macro.
Nick: I can definitely see the similarities when I interact with other PMs myself. Everyone does have a unique definition within their own organization. And it is a very fluid understanding of what a PM does. Was there a certain incident that sparked this interest to create a PM culture guide? Or were you inspired by another team that was doing something similar?
Aman: So when I joined Square—I probably do this naturally as a human being—I tried to find places of familiarity. You know when you go into a building that’s dark, you’re always looking for the light switch; it’s something familiar. I came in and wondered are there other PMs at the company. How are their roles compared to mine?
What was really awesome at Square, we already had this product management ‘all hands,’ where all PMs would get together every month to talk about interesting topics and customer journeys. And I kept talking to PMs at the company, grabbing coffees, and having one-on-ones about the company. I found out that other PMs had very different understandings or views of how their role fits into the company.
The instance that was interesting to me was when I was getting ramped up at Square and I started getting my stride with one of my engineering managers. We were working really well. People were like, “Wow, you guys are really moving fast. You guys are beating milestones. What has been working really well for you?” And it’s funny, I took some advice from an older friend who’s happily married, about setting expectations in your relationship. So I thought to myself, fundamentally, the relationship cascades across everything, in my work as well.
So one thing I did differently with my engineering manager was go for a coffee when we first met and started working on a brand new project together. I asked him, “Let’s take the product management title out of the way. Let’s take the engineering manager title out of the way. We’re both partners here in trying to meet these goals. What are your expectations of me? Based on what we know about the project, where can I really excel and make our team’s lives easier, and make your life easier?” And he started doing the same thing back to me.
That exchange was really awesome. He pointed out that he really wanted me to shield the team from scope creep. He really wanted me to be the domain expert in what our customers wanted and help us prioritize. But even getting down to this is how we want to work together, this is how often we want to meet and this is the transparency we want to have when we speak.
So I shared that with a fellow PM and she thought that would be a really fun exercise for us all to do; to share our expectations of each other and our team. Because sometimes you feel like you’re doing exactly what a PM is supposed to do, but sometimes, I feel like I’m doing a lot of other things outside of that. It moves around; you wear multiple hats. So honestly, we made this process up and we pitched it to our head of product, and he said, “That sounds like a great idea!” So the other PM and I brainstormed how to do it and we ended up putting together a guide that we disseminated to the rest of the team to say this is what we think we should be doing. Here are some areas where we could improve.
Nick: So before you even introduced this idea to your head of product, what were the steps you took to bring this guide to life?
Aman: In engineering, you have paired programming. So I asked a fellow colleague, “Hey, do you wanna pair on this?” We would then just sit down and brainstorm the best way to structure this.
We started to throw ideas around and so I thought, why don’t we get everyone to write down their ideas on Post-It notes. We didn’t want to bias anybody in the room; we wanted everyone to write down freely what they thought about their role. What are some important themes? Aspects of their role that they thought we should be doing or we shouldn’t be doing.
We put all these notes on a whiteboard. And then we started adding some structure to all these ideas. Once we got everything structured, we asked, “How do we turn this into something that’s readable and approachable? Our north star we can point to.”
I got together with my colleagues to share it with the head of product. He suggested the best thing we should do is rate ourselves on how well we’re doing in each of these categories. And that could be used to find areas of improvement for us as individuals and as a team. We coalesced our original idea with the head of product’s idea and began using the guide as an exercise in improvement.
Nick: When you were going through that sticky note phase of gathering feedback to build your culture guide was it limited to only product managers? Or was that open to other departments or members of the executive team?
Aman: We made an explicit choice not to involve anybody else. And I think that was good idea, now looking back at the feedback we got. I think it was a fun exercise for us a group to do together, because everything we’ve done as PMs is always involving other parties. We’re always involving stakeholders in our meetings and thinking about the customers. So it was the first time where we wanted just PMs to figure things out internally. We also weren’t sure what was going to come out of this process. So we kept it to just us.
We actually started extending our weekly product meeting by an hour to actually go through this exercise and add more Post-Its to the whiteboard. The intention was to eventually share this as an editable Google Doc to everyone else in the company. But we at least got the foundation out there, and then let the document evolve.
Nick: When you did share this with the wider company, what kind of feedback did you get from these other departments?
Aman: The thing that people loved the most was the empathy and insights aspect of the guide. One of the things that we all talked about was having better domain knowledge of our stakeholders, the customers, the customers’ “jobs to be done.” We thought, “Are we doing a good thing of gathering those ‘jobs’ from our customers?” All of us felt we could always do more.
So when we put that as a big area in the guide of where we could improve—gather more empathy and insights from our customers whether it be our diners, couriers and restaurants—other departments wanted to piggyback on customer visits with us and jump on support calls as well. That was awesome, because it showed that people were interested in this, but no one had broken the seal, so to speak, of actually putting a concerted effort of doing it. Some of us already did that implicitly anyways, it was just now that we put it into a doc and formalized it.
Nick: Let’s say that you had gone a different route during the sticky note phase and gathered outside feedback earlier. Do you feel like that would have had a negative effect on the PM guide?
Aman: No, I think what that we could have created something together, but it would have been a lot more feedback for us to sift through. I think the exercise would have taken a lot longer. Imagine if we had added 10, 20 or 30 more people! I think it would have taken more of a village to organize and go through all the feedback.
It was really impactful to stay small and test it out because it’s a brand new process. Just like product management you don’t want to just say, “Alright here’s what we’re gonna do.” And do whatever you want. You start small. It’s one of our cornerstone values at Square, as well.
And starting small was great because I think we can revisit this again next year, because the role evolves over time, especially as we mature and grow as a company. Maybe next time we could even invite somebody from design over. Maybe we could invite one of our representatives from marketing—and not make it super large—but add a few more flavors. Or maybe even have an independent discussion with the marketing team and conduct it for them in relation to product development.
Nick: Did you notice that even after you had released this culture guide that it was received well? Was there any friction? Did you have to address anything immediately or maybe you completely missed something?
Aman: It’s funny, I was hoping for some bad reception just because naturally everybody’s like, “Whoa, you guys created this yourselves. Did you put in my input?” But actually everybody was very supportive of it. I think it was a surprising delight. No one knew we were doing this. At one of our company “all hands,” one of our engineering managers said, “I’m very impressed and excited with our product management team. I feel like our team has a lot more structure now. I have a better understanding of where they’re coming from and what they want to do.”
I think everything was well received. I think people are anxious to see the progress. One thing that we’re going to do at the end of the year, or quarter, is we’re going to grade ourselves on how we did on our OKR’s and use that as a feedback loop to the guide. So that we can ask, “How was this guide helpful?” “Did it miss anything that we should be improving as a team?” “Are there other expectations we can include?” I’m really excited about that exercise coming up.
Nick: And has this guide been able to help onboard new product hires at Square?
Aman: Absolutely! It has. We just hired two more designers and we hired a bunch more engineers—and it’s great. When we hire someone new, as part of their onboarding each person meets everybody on the product floor, every engineer, design. I used to just talk about what we do on product, sort of high level, based on my understanding and experience. But it’s so great that we put this guide together, because I actually have a structure I can go down.
Here’s how we want to drive the business forward. Here’s an example of how we did that, how we’re doing that and how we’re continuing to do that. Here’s how we do empathy and insights each month, and this is how we conduct that. It also lets me ask, whether it’s a designer or engineer, what are some of your expectations before I share what we do as PMs.
Nick: As I’ve gone into the product management community and spoken to other PMs, I’ve noticed there is one similarity that’s been flagged by people—and it’s that they feel the PM culture in many organizations is defined as the “shit umbrella” of the organization. I want to know your thoughts on that definition of a PM.
Aman: So I think this kind of applies generally for a lot of work, and especially for me. One thing that was kind of interesting was when looking back at my time as Fastbite as a startup, and then even looking back on my time at Square, I noticed the times I was most successful was when I was the most proactive. I think that definition comes in when everyday is reactive—like all the time, because everybody is just pulling you in different directions.
It is really tough and I think there’s no real strong way to give you a general answer here that can apply to anyone, but what I can say is take a look at all the shit that’s coming in onto your umbrella and see if you can identify some themes. I know it sucks because maybe you’re really tired and you’ve spent a lot of time. But what I found when you don’t put any time to plan a structure, the chaos ends up just building and forming. It kind of takes a mind of it’s own, right?
You want to make sure that you control your time, not let your time control you. I think it’s a feeling; it’s a symptom; it’s an emotion that we’re all going to have. I think a big part of this is taking a look at what that shit is and trying to really organize it a little bit. Let me get more context on where this stuff is coming from. Just the way you speak to your customers, you start talking to your stakeholders and your colleagues, and ask them in the same way, “Tell me more about the job I’m serving for you and where do I fall short?”
Nick: Love it dude, it’s time to move away from the shit umbrella. How would you help facilitate other organizations to take the same steps that you did to implement this PM culture?
Aman: I think what I would first do is create a guide for other teams of here’s how you conduct your own PM culture. And what I would do is sit down with the team, help facilitate and make sure they’re doing the right thing. Because I think it’s really easy to have a discussion and not put stuff on paper and not grade yourself. (It’s an awkward thing to do sometimes.)
So I would go in and create a step-by-step guide. Definitely, get buy-in that the team wants to do this. Because if they don’t want to, it’s going to be hard to get anything done. Once the buy-in is there, set up a time. Maybe it’s in the office, maybe it’s done outside the office.
Nick: Could you sum up why PMs in other organizations should do this?
Aman: It is really important to know what’s expected of you and what’s expected of others. And taking time on that with your team can help you build a culture and common fabric that you can grow from. Just as you may want to reflect on your year and what you’re doing the following year, it’s a great sort of PM reflection. I can’t see why this would not help improve any type of experience for a PM, their company or their team.
Nick: Love it. I know that I’ll start looking into this myself and start getting the feedback loop going with our own PM culture here. So, I appreciate the learnings. Thank you so much for your time!
Aman: Yep. Thank you!