ProductFTW #33: Product Talks with Corey

For our second post in the Product Talks series, we’re talking to Corey McMahon, Chief Product & Technology Officer of HopSkipDrive, a late-stage startup that provides on-demand and scheduled 1:1 transportation for youth. I met Corey when he joined AT&T Interactive through a rotation development program. While we were on different product teams, we sat in the same pod of desks and we had a number of opportunities to collaborate. 

Matthew: Thank you for doing this, Corey. Let’s start at the beginning - what’s your name, where are you at in your career, and where are you working right now?

Corey: I’m Corey McMahon, I’m the Chief Product and Technology Officer at HopSkipDrive. That means I’m responsible for our Product, Design, Engineering, Data Science, Analytics, and Information Security teams. 

Matthew: What did you study in college, and what did you think you were going to do when you grew up?

Corey: Great question. I grew up sitting around the table with my dad and uncle, who were both small business owners and ‘CEOs’ if you will, although I’m not sure they actually held those titles. I saw that they often talked about both the people side of what they do, like managing people and customers, and then kind of business strategy, like “This new thing happened, what are we going to do?” Those two things always interested me, so I went to UCLA and studied communication studies—specifically, interpersonal communication—and eventually followed that up with an MBA. 

Early on, I had no clue exactly what I wanted to do, but I thought maybe management consulting was a path. I did some management consulting internships, primarily supporting the public sector.  In Business school, I actually had the entrepreneurship bug, and I wanted to start a video scouting platform for college sports teams and eventually pro sports teams. I had connections from being a manager for UCLA’s basketball team, so I had a bit of an ‘in’ in that industry, so I thought I might follow my dad’s footsteps in starting my own business, but I didn’t pursue that path.

Matthew: How did you go from that to becoming a PM? What was your first PM experience, and how did you end up getting that job?

Corey: Everybody comes into product management differently. I came in sideways, I would say. I came out of Business school looking to do corporate strategy without the travel of a management consultant. So I went to AT&T, and they had a leadership development program where you could rotate around a bunch of different business units within AT&T, with the intent of giving you a view of all things AT&T while giving significant leadership training, so you could make a bigger impact with higher leverage. My thought was that I would end up in a corporate strategy role there, at AT&T, but after going through that process, I was looking for something faster-paced and something a little more tech-oriented. Eventually, I landed at a subsidiary of theirs called AT&T Interactive which was my first real taste of a tech company. 

I joined in more of a Business Management role rather than Product Management. I was managing the publisher network, and as part of that, I became the owner of our strategy of “Where are we going next with this?” So it started from business strategy, and from there, we started to ask, “What are we going to need from a technology perspective?” We saw we’d need some ad-serving technology, and we’d need certain things from a user experience. I then started partnering with Product Managers and Engineers as the business owner for a portion of the platform. 

Over time, that role became more and more technical. If you're going to have a viewpoint of where we ought to go strategically, and you're going to prioritize what we do, that starts to look a little bit like Product. If you're going to understand the unique value proposition or the sequencing or relative impact of things, it begins to look like Product, too. And so I actually managed Product Managers before I was a Product Manager and grew up in the Product Leadership track. Eventually I founded a startup and had to be very hands-on as I was the Product Lead. And so I essentially had these simultaneous paths, where I was learning how to be a Product Leader while then simultaneously learning how to be the actual PM on a product.

Matthew: And so, to finish that all off, how did you end up at HopSkipDrive?

Corey: So that company, AT&T Interactive, eventually spun out from AT&T as a standalone business, and I took on larger and larger and more and more technical roles there. I helped re-platform that business and rethink the product portfolio. 

The business was in the Yellow Pages industry, which was declining, and eventually, we ended up being acquired by our largest competitor. Soon it was time for me to find the right next opportunity, and my first boss at AT&T Interactive was Joanna McFarland, who founded HopSkipDrive and is our CEO. She was looking for someone to help lead things internally as she was focused externally. So I came in and took on Product and Operations, in a COO type of role, when we were fairly early stage (we had just closed our Series A), and the rest, I guess, is history.

Matthew: So AT&T, I thought was interesting in that you, at least once you came out of the leadership program, reported to Joanna. Joanna and I were peers, and we reported to the Chief Product Officer. It was the Product Management team, but we had this delineation between what we called Business Managers and Product Managers, which I actually think that they're the same thing. And there were a lot of folks who were very adamant about what they perceived to be less technical Product Managers, which, not to get into my story but used to frustrate me because I actually am quite technical and have written a bunch of software. And they perceived that because I had this title, I was not technical. 

So, how do you think about what Product Management means to you, both from that experience and now? And taking a step further, is it a technical role that requires you to be an Engineer (which you’re not), or is it broader?

Corey: I love thinking about this and honestly grapple with the answer to this day, partly because I think the discipline of Product Management is so wide. The responsibilities could involve anything from market analysis and user feedback all the way through to QAing the feature before it goes live or go-to-market and communications. Not to mention, the demands of the job are materially different as you scale. So, depending on your industry, scale, and the type of products you make, it can vary widely. You could have a product manager at a CPG company versus a hardware company. The role and responsibilities are just so broad. And so, while I share some of your sentiments, there's certainly that stereotypical answer that “it depends.” 

So to me, I will say that Product Managers absolutely have to understand the way a system is architected at its fundamental level, have to understand how data flows back and forth, and have to be able to communicate clearly with Engineers. You also have to develop a really strong sense of what's technically feasible and how long something should or shouldn't take. Those things require a certain level of technical understanding, and you can't be an effective Product Manager, even if the role is defined as fairly business-oriented, unless you're able to do that. And so oftentimes, those skills come from having lived it and having been an Engineer, but that doesn't mean you have to have been an Engineer to be successful. 

We grapple with this question a bit even today at HopSkipDrive, because we have both an online and offline component of what we do. We’re a digital platform, but the experience happens in real life, and so there's a very operational component of what we do. Some of the things that we would do to improve the Product experience could be something like rolling out billboards on the campuses of our school partners that say, “This is the HopSkipDrive pickup line.” Is it best suited for a Product Manager working with Engineers to “project manage” that rollout? Or is that responsibility better suited for somebody else? Is that an Operational role? Or even the strategy of deciding what the Operations team wants to do or want to look like; where should that ownership and accountability be? 

So in many cases, where we have a core product, with product-market fit that we're trying to grow and push, we try to put Business or Functional Owners, Product Managers, Designers, and Engineering leads together in sort of a ‘four in the box’ type of model where they share accountability. The Business Owner owns business metrics, and the Product Manager shares those business metrics, as well as some product metrics they're accountable for that may move faster and are more directly tied to them. Whereas when something is a little earlier stage, Product's taking the lead and needs to partner with a technical counterpart, and probably should have the business strategy and be driving that themselves.

Matthew: I want to dig in on that structure, but I want to come back to what you said about the physical world. That really resonates with me because I used to work at Green Dot. Green Dot is a technology payments platform that sells its product at retail, or used to (it sells it online now), and one of the reasons I went to AT&T was because I wanted to work on the Internet. 

I actually spent 90% of my time talking to retailers about pieces of cardboard in their stores because our acquisition channel was entirely physical. I spent an insane amount of time on what the package looked like, what it said on it, how it was constructed, how it was printed, what color it was, and it was just like traditional CPG Product Management. Although I also did API connections to the retailer's point of sale, and it was very slow-moving because it was retail. 

So I think it's a really interesting point that a lot of people think about Product as Software Product Management, and that's obviously a large part of what we have both done. But there's so much more - many products have hardware, with operational needs. And I think you're right, that Product Managers have to own a lot of that.

Corey: I think that's right. And to me, the purest image of what people think of as a Product role is if you have an entirely digital platform, you’re a B2B SaaS player with Product led growth motion, and that's where the easiest answer is. Things just get more complicated the more real-world components you layer in there.

Matthew: Let's return to how you're structured at HopSkipDrive. Correct me if I’m wrong, but my impression is that you've been there long enough and early enough that the Product Org probably looks like you want it to. And so, what are some of the tools or systems you guys use? Are you guys agile? Do you use Jira? Are you none of these things? What's the methodology for how you actually build products, and what do you expect your PMs to be doing? 

Corey: The first thing I have to comment on is the fact that the Product Org and the Product processes today reflect what we need at the moment with an eye toward what we will need in the future. We haven't gone more than six months before something material has changed about how we're organizing ourselves, how we're structuring the work, and how the product processes have gone. Which is the story of a startup turned scale up. And so even to this day, much of my job is actively changing our software development lifecycle or who's in what seats on the bus or how the processes work. And so there are things that we do today that aren't exactly how I think they need to be six months from now. 

Digging into this a bit, our Product Managers are primarily focused on particular portions of the business problem that ladder up to key business KPIs, typically have clear business partners, focus on a particular end user, and where we can define clear product goals and KPIs. It doesn't always work out that way, but that’s the primary model. For example, school districts are one of our key users in the platform, with a primary web app that they use. We have a PM who's responsible for the client experience and everything associated with our clients. His ultimate business outcome might be net revenue retention, which he shares with our VP of Client Experience. However, he also has more product-oriented key results, like active users per account or time spent per ride booked. We pair him with a Designer and an Engineering pod led by an Engineering Manager, and they work hand in hand on the roadmap. So, using that one PM as an example, he works directly with sales, support, and clients to solicit feedback and is prioritizing a roadmap based on impact to the ultimate goal.

From a tools perspective, we currently use ClickUp, which is more of an Asana or Trello. It's a fascinating tool because it tries to be everything for everyone - for better or worse. So it is currently our company Wiki; it's our product roadmap, and it's all sorts of other things. That's where we collect the ideas, prioritize them, and size them. We write what would be essentially a PRD in other places, although it isn't defined that way; it's just in the description of the epic within that. That's where we do our prioritization, and as things go through scoping and design and then once they're tech planned with the engineering lead, we actually then turn over and create specific engineering tickets in GitHub. GitHub is where our engineers are working for both tickets and pull requests. So a typical epic might have Android, iOS, and backend tickets that might get created for three independent engineers. So that's kind of our tools flow.

Matthew: I love tools, so I always love asking. But switching gears a little bit, now that you're at this later stage in your career, with more seniority, what would be your advice for someone who comes to you and says that they want to get into Product or are just starting their first Product job?

Corey: The thing I would say is that a lot is expected of a product manager, especially a good one. Product management, especially at a high level, is a demanding role with significant expectations, visibility, and impact. My advice for aspiring product managers mirrors what I tell those climbing the career ladder: take your time to develop a solid foundation rather than racing up to higher and higher levels of responsibility. To be successful, you need to collect some serious skills; you need to be an exceptional Project Manager; you need strong business acumen; you need to be able to work with Engineers and demonstrate technical fluency, et cetera. I always say start there, think about all the things you're going to have to do, and find ways to do them because it's much easier at a junior level to develop those skills than at a senior level. 

And then from an actual entry point perspective, I always look for things that are right on the periphery. That could be Project Management types of roles, as well as a lot of Ops roles, where Ops starts taking on tasks like requirements writing for how the IVR would work or configuring how the CRM works. From there, you define some requirements, and you get into some tooling and technical writing. So there are some entry points there that I've seen work really well, and people can demonstrate PM skills. 

For new PMs, I know it's cliche to say, but I would say two things: You should spend as much of your time as possible with your users and invest as much of your organizational capital as you can with your Engineers. 

You have to have a really strong perspective on what's actually going to matter, and the only way to know that is from your users. Sometimes, you can directly talk to them, and sometimes you're in a product where that has to be done through surveys or combing through customer support tickets. It’s important not just because it helps you pick the right thing but because you need to have a ton of internal credibility when you go to bat for something or prioritize something. You only gain that credibility by having firsthand knowledge, data, and experience that you can bring when you're talking to anyone else.

On the Engineering side, you are only as successful as what you ship. So you have to have a really strong partnership and relationship with your Engineers. They are not only how you succeed but also how you learn and often have better solutions to your user problems than you. 

Matthew: Yeah, that’s good stuff. Thinking back, and now this is starting to sound like a job interview, but what was one of your biggest challenges as a PM? What happened, and how did you overcome it, or what did you do to solve it?

Corey: I'll start with one answer, and then maybe another one will come to me that is more relevant. I’ll start with what my biggest challenge was as a Product Leader. And what I would say is that every startup that is growing and scaling is looking for people who will wear the hat that needs wearing, who will roll up their sleeves and do whatever it takes to get the job done. I'm cut from that mold, and we hire people that are cut from that mold, and a good PM is cut from that mold. You have to be; you have to wear the hat that needs wearing. At some point in time, you sort of reach a point in your growth as a company where you can’t keep living in the trenches. You have to get ahead of it and think about what the Org needs: the right structures, processes, and people in the right places. 

For too long, I did things that people beneath me on my team should have been doing because I was better at them, or people on my team did things because they happened to have that skill set rather than because it was their job.  Unfortunately, it kept me from doing everything I needed to do, limited the growth of others, and did not set us up for efficient growth. So, as a Product Leader, one of the things I've learned and certainly failed at is getting ahead of that. Knowing when you're scaling, you have to put the right person in the right place at the right time, and that's the job. Yes, you have to be scrappy and you have to execute with what you've got, but knowing the right time to disrupt the status quo is key. 

Matthew: It's a good general management lesson, learning how and when you teach someone to fish versus handing them the fish. That can be a very tough one.

Corey: Exactly. I would say the thing I have failed at in Product Management time and time again, and I consistently try to improve at, is remembering that I am not always designing for myself and that I am not the user. One of my strengths is operating from first principles and envisioning a future state. That superpower can also be your kryptonite. It’s probably a cliche and what every PM book says somewhere, but I have absolutely reached that moment multiple times where I, as the user, would want this, and therefore this is the right answer. Then we actually talk to users, or we do a paper prototype or build a feature, and we find out that it’s not exactly what the users want. I need to learn to put aside how I would want to use the product. 

Matthew: That’s such a hard one; it reminds me of that saying where nobody asked Apple for an iPhone, but everyone wanted one. There’s a really interesting balance where there’s a difference, especially for Chief Product Officers, between designing new functional day-to-day product features and figuring out what the blue sky and new ideas are because users will not tell you those things. They don’t know what’s possible or what they want, and how do you identify those in such a way that you can learn whether they’re valuable from understanding user needs rather than user requests? 

Corey: Yes, I think that is so spot on, and I also think that at a company, you are sometimes structurally set up with roles that only allow you to do one or the other, or at least encourage one type of thinking or the other. We have Product Managers who are exceptional at listening to users and building for user needs, and they run that machine super efficiently. But, it is challenging for that same person to step back and paint the vision of where we need to go three years from now, how it all comes together, and what is strategically important. So in some ways, I’ve grappled with how much long-term vision and strategic ownership you put on individual PMs. I don’t think there’s a perfect answer, but on the balance, I lean towards the thought that some of that has to come top–down. There’s just no other way that someone who is thinking day to day can be thinking about product strategy and articulate that to people. 

Matthew: This may be a little off-topic, but do you do any personality or strength assessments of your PMs?

Corey: Not as part of the hiring process. Afterward, though, we have done a little bit. For example, DISC is a personality assessment that we have done to see where people sit. We usually use it more within a team to figure out team dynamics and how a team can work well together to make sure we are putting them in the right seat.

Matthew: Yeah, I think that's the right approach. You don't need ten identical PMs to solve ten slightly different problems. 

Alright, we are running a little low on time, so a couple of quick-fire questions: What are three tools, pieces of software, or methodologies that you would say to a new PM that they should learn how to do, use, or have this skill because it’s going to serve them well?

Corey: The first skill I would call out is to self-serve and access data, however your organization does it, so that you don’t need to go to Analytics or a BI team. It’s also helpful because you learn so much - that is where half of my technical knowledge has come from. From the analytics side, you learn the data models and the interplay between product features at a technical level when trying to dig into the data tables and build analytics or reports. So, whether that’s learning Tableau or Looker or just direct SQL queries, you should definitely learn to do that first. 

From a tool perspective, the one I’ve been using a ton FigJam. I don’t have a specific process for how and when to use it, but I’ve been using it a bunch. There’s something about the infinite canvas; the Product job is wide and encompasses a lot, so having something that can be high-level or granular, low-definition or high-fidelity, in one place is really effective. I have just found it really great to get the chaos in my head for a particular problem onto paper and then get people to collaborate on that. 

And then the other one, related to that, is if you are at the size and scale of an organization where it’s hard to get all parties you need live, I would be an advocate for asynchronous video communications. It’s just such a quick way to communicate to a bunch of different stakeholders, rather than trying to schedule a 30-minute meeting for a group of 15 people. Just record a quick video that they can then watch at 2x speed, and then boom, they’re caught up, and you’ve just saved everyone a bunch of time. 

Matthew: What’s your favorite Product Management book, blog, newsletter, or podcast?

Corey: ProductFTW, obviously. But I have been enjoying following the Twitter feed of the PM who is building ChatPRD. I don’t know if you’ve come across it, but I’ve been getting a kick out of her progress and her perspective on how we should inject AI into the Product process.

Matthew: Yeah, that’s fun. We spend a lot of time as a team talking about how to use AI as a tool. Last question: What do you think the future of product management looks like? this could have something to do with AI a little bit, but how has it changed over the course of your career? What do you think is coming?

Corey: Product is the nexus - it’s the decision maker and the executor - and for so long, most of what you had to do was lead by influence. You don’t have direct reports; you have to marshal the troops, and you have to communicate with others. I do think a lot of the tools and technologies that are coming out that enable someone to write marketing copy or get a wireframe turned into visual designs with some AI help, or communicate something in a more technical language, I think a lot of the teams that Product relies on, Product is going to be able to get closer to high fidelity output. So I think it’s going to make the Product role more and more critical because that’s where decisions happen and where the driving force is. The task execution is what gets a little bit easier over time. I think a Product vision, roadmap, and requirements can get a lot closer to the end product a lot faster. So, the iteration cycle will be a lot quicker, as will the feedback cycle, and we will probably be able to execute with smaller team sizes and less coordination costs. At least, that’s what the optimist in me thinks is the case.

How’s it changed or where has it evolved from? There’s a lot there. I think your business versus product distinction is an interesting one. I would also point to some ebb and flow I’ve seen around what role Design has, particularly UI/UX Designers versus Product Designers. Also, what role do Engineering or Tech leads have vs. what role does Product have? There are certainly effective teams that have just a Product Designer and an Engineering Lead, and there really isn’t a Product Manager, and that is all you need. Of course, there are other instances where the PM is the “CEO of the product”. I think product, design, and engineering work tightly together and each should have some of the skills of the other. For example, a good designer should have some understanding of technical feasibility and business impact; a good tech lead will have user empathy and good design taste. But at the end of the day I think that no matter your size and scale, people look around the table and are looking for someone to lead the conversation. 

For me, I think that any effective team needs a quarterback to start the conversation, and to drive things forward, and I look to Product to do that, and I think that has continued to be the case over time. 

Matthew: Awesome, thank you, Corey. 

 

Subscribe to ProductFTW

Don’t miss out on the latest posts. Sign up now to get access to the library of members-only posts.
[email protected]
Subscribe