Heidi: Hi. I'm Heidi Wong. I'm a product manager at Marvel.
Suzanne: Welcome to the show, Heidi. I always have to look into my guests, of course, coming online and try to work with whatever information is readily available on the internet and one of the things that caught my eye while I was sleuthing you is your degree in International Relations, which is atypical for the path into product management. I'm just curious how you came to have a degree in International Relations and how that readies one or not for product management.
Heidi: Before I got into International Relations, I was studying psychology, so that does have a direct role in product management since you're understanding human behavior and the type of consumer products that you're building for them, but I started taking HTML CSS classes and Photoshop classes when I was in high school just because I was interested. By the time I graduated and realized that I really didn't want to work for the UN, it wasn't the path for me, I joined a software company called Everyday Health where they were building a new product, needed someone to do wireframes. Since I happen to know Photoshop as well as some HTML CSS skills, I started doing product management or a subset of product management for them. I helped them build out a lead generation funnel and that led into a business analyst role at my following company.
Suzanne: Now, when you went to this company, were you looking to be a product manager or you were just looking for a job and you're like, I have some skills that could match with this job? It wasn't even a product manager title that they were seeking.
Heidi: Nope. I joined that company as a marketing assistant, basic entry level role. Pretty much a lot of just admin work and doing things on Excel or just printing stuff out because I was an assistant, but because I had this extra skill set that I gathered when I was in high school just because I was interested in it, I demonstrated that I knew how to do these things and I had the ability to think critically about what I was working on, so they just decided to put me on it.
Suzanne: Then, you left that company and you took on what appears to be a couple of back-to-back business analyst, BA roles in different organizations. Can you describe that jump from being this kind of marketing assist? Obviously, you were doing more than just kind of basic marketing functions, but that shift into the business analyst role? I'm just mindful of the fact that on paper you weren't qualified for any of these positions, but you went for them anyway, which I love.
Heidi: Yeah, so a lot of it had to do with working with clients on gathering their requirements, understanding what type of data they were looking to collect about our users through our registration path and because I had a lot of client facing, or in this case stakeholders, that led into a business analyst role, which is more about working directly with internal stakeholder, external stakeholders, gathering their requirements and understanding how this would execute into whatever product we were working on.
Suzanne: Right. One of the things that I think comes up a lot for folks, well, there's this ongoing theme of, “I think I'm a product manager, but my title doesn't say so.” What's connected to that concept is that a lot of the product manager jobs that are out there are sometimes masquerading under different titles. For example, many organizations see the business analyst role really a lot of the same ways that many organizations consider product management to be its own role. Given that you've done both, right, that you've had this BA title and you've had the PM title, can you, in your experience, kind of delineate what is a business analyst as opposed to a product manager? How are they different and how are they the same?
Heidi: I think there's a lot of overlap, but the key distinction I make with it is product managers have decision-making capabilities whereas business analyst is more gathering and collating and writing it down into documentation. Which some product managers do, but product managers ultimately own that product and has to make final decisions. They gather all the requirements from stakeholders, but they have to make a decision, whereas business analysts don't have necessarily that level of, I guess, leverage.
Suzanne: Right. You say like compiling all this documentation and my mind goes to the infamous PRD.
Heidi: Yeah.
Suzanne: The Product Requirements Document, which some people would argue is kind of a relic of waterfall methodology versus more agile thinking, incremental improvement over time, smaller batches, do it, test it. How does that challenge, like for a business analyst potentially listening in who might be more familiar with these kind of long form, up front requirements gathering, how do you begin to make a transition or become more adaptive in your role as a BA knowing that long form documentation has its downfalls?
Heidi: I would say there are certain stakeholders that still look for that PRD, a vision statement, something that's written down so they understand, you know, a one sheeter for what this is supposed to do, but it doesn't need to be a 20-page document on every single functionality. Where that agile aspect of it comes in is rather than writing everything out and defining how it's supposed to function, I would say with a business analyst in an agile role is think about how a product can scale back into its MVP. Allow that breathing room to let it grow and iterate into something else, especially when you're working with developers or working with designers and finding out that maybe this solution isn't quite right and you need to pivot.
When I was at The Knot and since it's a 16-year old or so, 20-year plus old company, it operated in a very waterfall fashion and a co-founder had come back and wanting to reinvigorate the product organization and make it much more agile. We brought in a consultant, Pivotal Labs, that focused heavily on bringing agile methodology to the companies, such as The Knot. As a business analyst, traditionally there isn't this need for heavy documentation in agile world, so as I was working on this project and realizing that there wasn't really a need for me here or I could potentially expand my role from a UX perspective or being able to educate myself on how to negotiate with stakeholders on the things that they were saying and how that could translate into the product or potentially aligning multiple stakeholders thoughts and into one single solution that may work for multiple groups.
Suzanne: Was it at The Knot then that you kind of made your pivot from BA title to PM title?
Heidi: Yeah, definitely.
Suzanne: You saw an opportunity to evolve your role because that BA role was maybe evolving away from the direction the product organization was going to.
Heidi: Yeah.
Suzanne: Very keen. That's the hunger for knowledge. I talk a lot about hunger for knowledge as being an integral skill of great product managers and it's a landscape where a lot of the ideas are still very new. We're still being introduced to new frameworks. People are still iterating on best practices, so I love that you said, well let me go and be agile and show up in the form of this product manager role.
Heidi: Yeah, definitely. I mean, that's how I got into wireframing and the business analyst role is because I happened to have an interest in computer science and design when I was in high school. Nothing to do with my degree, nothing to do with what I was studying at that time.
Suzanne: Right. I noticed that, this was before The Knot, but I noticed that you spent some time working with SEO, Search Engine Optimization, and I thought if you were game for it, we could talk a little bit about what is SEO and to what extent a product manager should or shouldn't concern themselves with that discipline. I mean, it's its own discipline I think.
Heidi: Mm-hmm (affirmative).
Suzanne: It gets nested under marketing as an umbrella, but really there's lots of different channels and tactics that make up the modern marketer experience and SEO is of course a big one. For a typical PM, should they even know anything other than what the acronym stands for? Where's the knowledge need to be?
Heidi: You absolutely need to know about SEO. If your product has any KPIs around growth in conversion, in traffic, you need to know enough about SEO to make good judgment calls on what needs to ship, how it should ship, how you should be talking to stakeholders about SEO and how that parlays into what you're building. For example, if it's a content-driven site, you need to know SEO. If you don't happen to have an SEO analyst on your team, you're going to be playing that role de facto as an SEO analyst. If you happen to have an SEO analyst on your team, that's awesome, but learn enough about it so you can have an intelligent conversation around these are the things that you need to do, is there an alternate way to pursue that direction?
Suzanne: Are there some fundamentals, you know, let's say I'm approaching SEO from I know nothing other than this is an opportunity to kind of organically rise in search engine rankings based on content that's embedded in my site. If I were in this PM role and needing to be the person because I don't have an SEO analyst or I'm part of a startup, what would be like a handful of basics that you would say you need to stop listening to this podcast right now, go away, do these three, four, five things and then come back once those are in place?
Heidi: I would say learn about metadata. This is how Google and other search engines read your site and surface it up to consumers on what the site is about. Then, also learn about how a site is indexed and crawled. For example, learn about client-side or service-side API calls because that also plays into how Google crawls your site, but it also makes technical implication decisions on how your pages are built.
Suzanne: Great, great. So, XO Group is a well-known company here in New York. It's the parent company to The Knot, which you worked at and I laugh a little bit because when I talk about XO Group here to other product managers, they're like, oh yeah, they've got like 100 product managers over there. It's kind of like a product manager's empire. Is that true, by the way?
Heidi: It's grown a lot since I first joined the company back four years ago and it started out with, I would say, one or two PM's to I think 30 plus at this point, so definitely under Brent's leadership the organization has really grown and matured.
Suzanne: This is the place where you made that pivot that we spoke about from BA to PM. Talk to us a little bit about your learning curve as a "product manager" in the context of this group that was also redefining itself structurally at the time?
Heidi: I think when it first started and we were contracted with Pivotal Labs as a consultant, it was much more ad hoc, learning on the job, just reading articles online about how to do this right because we didn't really have that structure. When Brent came along, he formalized it and really created workshops and education around what's the baseline for being a good PM, how do you level up, and just creating structure around it so people could operate off of the same foundational knowledge before growing into a senior level or a VP or a director. What I thought was really helpful is everyone comes from all these different skill sets, industries, and we needed to level set and say this is how XO operated and expects out of its product managers and these are the certain foundational skills you need to know.
Suzanne: Based on either on Brent's doctrine or even on kind of the doctrine that you've evolved yourself and your own experience, what would you say is the baseline expectation of a PM? I mean, if I want to become a product manager, what do I need to know going in or what do I need to be fundamentally good at going in?
Heidi: I would say looking at data and being able to translate it into something that's meaningful and can communicate it to stakeholders for having a perspective on what this means in terms of how it's going to move our business forward and how it should evolve our products, but it's very data driven. Learn about what kind of metrics matter, learn about systems that do analytic tracking and a lot of it is on the job because you're interpreting data, but figure out ways to understand what are the important numbers to look at and also how to gather like quantitative and qualitative data.
Suzanne: Now, given that you have kind of come from some other positions, you were doing the BA stuff, you were doing the SEO stuff, you made this adjustment into product management. You're talking now about data, but it's sounds like you wouldn't have been encountering significant amounts of data or the requirement of analytics in the same way in those previous roles. Can you share a little bit about that moment where you realized, oh, I've got to understand data and how you kind of went about leveling up or getting stronger in that area?
Heidi: Yeah, so when I was looking at these numbers, at first, it's very intimidating, but you start creating hypotheses around this number is saying this in a particular pattern. A lot of it is, I feel like it's pattern recognition, but deducing from that, I think a user is doing this when our numbers are going in this direction. A lot of it has to do with user behavior and I think that's where it stems from, you know, understand your users first even on a macro level and eventually you'll be able to recognize some of those things in the data itself.
Suzanne: What about the data scientist role? I mean, XO Group is a large organization. Were there data scientists there or the product managers were kind of expected to be very, very strong in data?
Heidi: I would say the latter. Product managers were expected to be strong in data. We did have a analytics person ...
Suzanne: Mm-hmm (affirmative).
Heidi: ... that would help us along with that, but it did come down to the product managers for the day to day and looking at their data, analyzing it, and if they needed any help we had this person to rely on.
Suzanne: Then, you may have a unique perspective on this, but one question that I do surface a lot is sort of similar to the BA question is, where do you delineate from product manager into data science? We understand how important analytics is as a skill set for product managers. You validated that here. How much do I need to know before I'm starting to tread in the terrain that is truly kind of data scientist terrain?
Heidi: I think data scientists are expected to be able to run their own SQL queries, much more of an engineering role whereas product managers don't necessarily have to have that skill set, but there is definitely a lot of overlap. I think data scientists are much more technical than what product managers are expected to know.
Suzanne: Right. Then, I guess then that would hold true in reverse in that if you're a data scientist, you get to sort of stay comfortably working with the numbers and not have to have that 360-degree perspective that a product manager needs in terms of the ownership of the product and the customer as well.
Heidi: Yeah, for sure and I think in that working relationship, it's definitely necessary for a product manager to express this is the vision for the product, so this data scientist has direction and know what to potentially look for or pose opposing viewpoints to help your product grow.
Suzanne: Right. Ever any temptation to just retreat back to the comfort of a data scientist role and say I could just be over here being in the data all day long and not have to do all of the other things?
Heidi: Not for me. I actually love the user aspect of it. I love getting in front of our customers and learning why they do or do not love our products and how we can improve it for them and having that human interaction, that personal aspect of it.
Suzanne: Today, you are at Marvel. This is a fairly new role for you. You left XO Group, you joined Marvel, what are you doing over there as a product manager? I think comics when I think Marvel.
Heidi: That's definitely right. We also have movies as well and game and other lines of business, but at Marvel I'm the sole product manager for Marvel.com.
Suzanne: Oh, wow. Okay, so sole product manager, that must have been an adjustment from going to such a heavily structured team environment at your previous place. How has that shown up for you in terms of new challenges and opportunities working as a PM of one?
Heidi: Big adjustment. I would say when I was at The Knot, we had squads where every squad had its own focus and had its own feature or product that they're working on. Whereas, at Marvel, I'm the sole PM of all of Marvel.com and every PM needs to know how to prioritize and focus. This is requiring me to do so much more of that. There's only so much I can do to push our acquisition numbers or build features around content engagement, so a lot of negotiation and a lot of pushing back and saying no to things because we are very, you know, we're very scrappy and tight on resources and the amount of time that we have to execute on things.
Suzanne: Right, which a lot of times is the best possible learning environment you could ask for because it's like that Parkinson's Law of things filling up to the space allotted and I think the same is true with resource or time. If you have it, you'll take it. When you're in those constraints, it requires learn it quickly, do it quickly, kind of discover as you go, which is, of course, inherently part of that validated learning or experimental modality of product managers. You talked about having to kind of learn data and get really proficient in making data-driven decisions as a big adjustment in being at XO Group. What skills have you had to level up on since you've been in this new role, especially given that you don't have the same luxury of larger sized teams and supporting resources?
Heidi: I think at Marvel the product organization is still defining itself, whereas at The Knot, Brent has done a great job at maturing the product organization, so I've taken a lot of the learnings that I sort of dabbled in or knew about tangentially from The Knot organization and brought that into Marvel to try to help move that organization along. At The Knot for example, we had such a heavy emphasis on defining KPIs and regularly reporting it to stakeholders, whereas at Marvel, we don't have quite have that regular cadence and also the definition of KPIs, so it's not so much leveling up, but continually maturing those processes and ways of thinking about product.
Suzanne: Yeah, well I'm glad you're sharing that experience because I think one of the challenges that presents most product managers on their journey, so wherever we start, we're all constantly trying to get to the next thing at some point whether the next thing is a higher role within the current organization or moving over to another company or another vertical. One of the reasons this show exists is to shine a light on all of the different ways in which different organizations tackle product management so that listeners can get the spread and say, oh, these are some patterns. You talked about pattern recognition, here are some products of product management I've heard about and here are some that are over here. What we don't talk about a lot, but what I think is incredibly important is many times your own personal laddering up will find you in an organization where the processes haven't been defined. Where the baseline is not the baseline that you once knew and it does really put you in a circumstance where you have to kind of raise a hand and say, hey, do we have KPIs here or that's new. How have you embraced having to kind of be an educator or an advocate in the new context? Is that a comfortable role for you?
Heidi: I have a director above me and so that definitely becomes an interesting situation where you come in to an organization and you have to bring some of these learnings in. You don't want to be presumptuous, you don't want to go above other people's heads, so it's definitely a, I wouldn't say necessarily walking on eggshells, but you have to be sensitive about the way that it's communicated or the way that you're pushing for this type of progress.
Suzanne: Yeah, the example that comes to my mind is joining on a ship. Right? On a ship there are lots of different roles and there are lots of things happening and maybe there are opportunities to improve upon that, but a big part of it is starting through observation. That you can't just kind of come in to a new organization with an I know best mentality, even if maybe you do know best. Even if maybe you do have a lot of expertise or experiences with certain processes where this new organization can certainly benefit, but I think there's an art to starting, sitting back, watching and observing the flow, beginning to look for the gaps, which is what we as product managers do best, and then finding a diplomatic way to start to surface ideas. This agile notion of incremental improvement I think applies equally to process, you know.
Heidi: Definitely.
Suzanne: We talk a lot internally at my company, The Development Factory, every time we add new folks to the team, process needs to be sort of reevaluated because somebody's coming in and learning it. There is a great temptation, especially at a senior level, to want to kind of just define all the process and then hand out the manual. That brings us back to waterfall documentation style where it's like just because you can sit and type and organize a process document doesn't mean that process is going to be a good fit for the team and it doesn't sort of allow for the learning and the adjustment, so like minimum viable process as an approach and kind of being comfortable with a little bit of chaos as everyone's working toward new or higher levels of performance.
Heidi: Yeah, definitely. Change takes time, so it's definitely necessary to take a look at things. Be an observer for a while, sit back, learn why things have been done that way. There's a reason for it as with every product. It's hard to aim for perfection, so you do the best you can with what you have and same thing goes for processes. You have to have that level of diplomacy to push things along and persuade people that this might be another process or approach that is worth trying. Also, having a level of empathy to understand decisions were made a certain way for a certain reason and not being insulting about the way that you have that conversation. Devil's advocate, here's another way that we could pursue this and have that conversation, an open conversation about it. It's partnership and it's a collaboration.
Suzanne: Yeah, absolutely. It's tempting, I think, if you're listening in on the podcast or you consume a lot of content around best practices, I know certainly, I've experienced, the temptation is to take up a process that you learned about that's working really, really well or there's that temptation and then it's met with the constraint of not being able to do that. I think all of us could benefit from letting ourselves off the hook just a little bit. I think best practices are precisely that. They're an ideal to strive toward, but in reality, it's a lot more of grabbing up fragments of what works, cobbling that together in a context that works, and then just trying to get better all the time. It's like don't be too hard on yourself if you don't have the right process. XO Group, they're the edge case, they're not really the norm. That's what makes it such an exciting organization in the work that Brent is doing, but we're all going to have to kind of find our way on our own, so it's like take it easy everyone. You're doing just fine.
Heidi: Definitely.
Suzanne: Cool. Have a lot of the products that you've managed been B to C type products?
Heidi: Yes, definitely.
Suzanne: Is there anything on your kind of product manager career road map, I mean, I know you're still very much at the beginning of this new opportunity and probably looking to sink more deeply into that and the learnings, but when you think about yourself as product and you have this long history of iterating, even on your own interests and experiences, do you have something tucked away that's like one day being a founder or moving more into usability or some other adjacent domain?
Heidi: There's a saying that product managers are mini CEO's and for the longest time I thought that that was the career path I should be taking. I went into a talk recently with Gibson Biddle of Netflix and he had this really insightful way of looking at his own career trajectory and applying product management philosophy and processes to your own career. Figuring out what is right for you and how do you measure your own success. He had a moment where a mentor had told him he might not be appropriate for a CEO role, which took him by surprise and I think that also took me by surprise as well because it really hit close to home. It's a role that I don't necessarily feel like I'm fit for. I don't think I have the aspirations to become a CEO, but that doesn't necessarily mean I'm a failure in my own career if I don't get to that point. I think it could be interesting to be the founder of my own company, something small, but not part of a large corporation for example.
Suzanne: Right.
Heidi: I'm still definitely trying to think through what is the right thing for me, but having this framework of redefining my own measures of success in my own life.
Suzanne: Well, one of the things that I love about our show, to be just a little self-promotional here, one of the things that I love about a show that is centered around the product manager experience is it is a very, very exciting role. I think that society kind of distorts the glamour of CEO. Like, when you're a good one and when you do well in that role, there's a lot of upside, but there's also a lot of risk and most of the time you're very, very abstracted away from a lot of the creation. I mean, even if you think about the moment that an organization needs to start insourcing product managers, that's a hard place for a founder because they often play that product manager role to a point where the seams are starting to burst and then they know that it's time. Being a product manager, I don't even think it should be compared to being a CEO because in one way it kind of sets up this idea that one is better than the other. I don't think that that's true and also, I think it does a disservice to one of the things that I think is so exciting about product management, which is just how much expertise or knowledge you need to have about a lot of things. It's like we're specialized generalists, ...
Heidi: Yep.
Suzanne: ... which is something to wear as a badge with pride. I mean, your own history is a perfect exemplification of that as well.
Heidi: Yeah. When I first started out, you know, the general advice is you want to be a jack of all trades so you can get as into many jobs as possible because you're applying to entry-level jobs. Eventually, you start moving away from that because you earn more money if you're a specialist, but product management is really being a jack of all trades. You have to learn and know enough to do something, but you're not necessarily the specialist in every aspect that contributes to your product.
Suzanne: Right. If you had to market your kind of unique blend of skill sets, right, because knowing that any product manager out there has kind of a different blend of skill sets, how would you position the type of PM that you are?
Heidi: I would say that my specialty is getting teams to work collaboratively and aligning well together. It's not to say that I'm a people pleaser or we design by consensus, but I find myself capable of working really well with various stakeholders and various engineers and designers to really understand from their perspectives why something's important. I take the time out to listen to them rather than putting a stamp on this saying this is the way that we're doing things. I'm a good listener.
Suzanne: I'm laughing to myself as you're giving that answer because I realize at the beginning of the interview I had asked how does a degree in International Relations actually help you succeed as a product manager and we came full circle. I think that like, yeah, you're expert at collaborating or synthesizing viewpoints, which you would have to be if you'd gone down that path of being part of the UN, a true diplomat.
We do a segment on the show, Heidi, called Get the Job, Learn the Job, Love the Job. What would you tell somebody who's looking to get into product management, but maybe hasn't worn that exact title yet, doesn't have that title to be able to leverage and ladder up?
Heidi: I would say demonstrate the impact that you've made on whatever that you're working on. Being able to translate those things into growth numbers, that's what product management roles really are looking for, that you can evolve and generate traction for what you're building.
Suzanne: I love that advice because one of the things, I talk about this a lot with students, is get comfortable evaluating ideas from a why would this matter perspective. I think a lot of us can come up with ideas and get excited about ideas, but it takes a certain type of maturity to say, well excitement or not, is this going to create value? Whether that's value for the business or whether that's value for the customer or ideally value for both and I'm a big advocate for applying product management ideas to ourselves kind of as we spoke about. What have you done in your life, doesn't matter whether you were a marketer or whether you were a real estate agent, whatever your role, framing it in the context of how did I make an impact as a result of doing this role.
Heidi: Yeah.
Suzanne: Awesome. What about hard lessons learned either in your own experience of learning on the job and going oh, okay, I'll make a note never to do that again or, oh that one kind of caught me by surprise?
Heidi: I would say it's communication. So oftentimes you're working so quickly that you may forget to communicate something to a group of stakeholders or, not because you're doing it maliciously, but it's just, you know, it's the routine of the day. You're going down a particular path and you may accidentally neglect to communicate something. It's worth carving time out of your schedule or putting some sort of checkpoint along the way to make sure that you are being as transparent as possible to everyone that you're accountable to.
Suzanne: Great. What about the love piece? Why do this role? Why do you love product management?
Heidi: I love being able to build something that ultimately gets in someone else's hands and they're able to derive value and improve their own life with it in some form.
Suzanne: Do you have any recommendations for us to add to our growing resources list at 100ProductManagers.com/resources? Books, blogs, podcasts, anything that's inspired you along the way that you'd like to pass on as a recommendation to our listeners?
Heidi: There's a newsletter at a Slack channel called PMHQ, Product Manager Headquarters. Their newsletter comes out on a weekly basis. Excellent resource for various articles that are quick and consumable, that helps you level up or might be able to provide something relevant to your day to day right now and the Slack channel's great for networking or just tossing ideas out there and having access to such a wide pool of different product managers with different perspectives.
Suzanne: Great. Last question for you Heidi. Is there a “side of the mug” quote, personal or professional life philosophy that you use to guide you through?
Heidi: Don't be a jerk.
Suzanne: Can't think of one better myself. Thank you so much, Heidi Wong, Marvel, really appreciate having you on our show.
Heidi: Thank you.
In this episode:
- Where do startups go wrong with implementing OKRs
- Can OKRs really scale for enterprise?
- What are pipelines and how do they change the way we think about product roadmaps?
In this episode:
- From retail to product management
- Why relationship building is the number one required skill a product manager could have
- The value of having confidence with humility
In this episode:
- Establishing a clear vision of your career path
- Using metrics to answer burning product questions
- What product managers can learn from biology