I'm a manager at Splunk here, and I work on the Dashboards framework, and yeah, really looking forward to giving you guys this presentation. Hey everyone, my name is Neil. I'm a product manager at Microsoft, and I'll also be giving this presentation alongside Eason.
Let me share my screen, and we can jump right into it. So, before I start actually, just using the Zoom show of hands. Who here is considering a career in product management?
Okay, we got one hand. Two, okay. And who in the room is confident that they kind of understand the role and they know what product management is? Okay, less hands. That's good.
Hopefully then the session will be helpful for everyone. Okay, jumping into it. So Neil and I already introduced ourselves, so we don't have to keep going there.
But Neil, I think you're gonna, you're gonna take the baton and get started first. Cool. Yeah. So we're going to talk about today's agenda is going to involve a bunch of things. We're going to start off by talking about what is product management.
And then Easton and I are going to share our journeys to becoming PMs. And then we're going to talk about some tips and tricks on landing your first product job. And we're going to end off the workshop with some frequently asked questions that we have. and that will answer and then some Q&A from all of you folks.
Cool. So what is product management? Yeah, I can take this one. So product management is the intersection of a lot of the other kind of tech roles that you guys might traditionally be familiar with.
So you have your designer. You have your technology partners, so that's your engineers, your architects, and you have your business partners, so that's finance, pricing, operations, marketing, and so on. And a product manager really sits within all of that because you essentially own the product.
So when you're in that role, you consider all of these various facets of what makes a product great and balances everybody to make fundamentally good decisions to drive product roadmap. So that sounds kind of vague, and we'll break it down deeper and deeper into more and more details. Yeah, so this, as you kind of alluded to, like, as a product manager, you're basically responsible of getting your product through the entire lifecycle. And what the lifecycle kind of looks like is you start off with like the problem discovery.
And so the problem discovery is where you sort of like, take a moment to like really understand the user, their needs, their pain points, what kind of like journey they go through when they're using the product, and then you identify the problem. Once you have the problem, you work with your stakeholders, your designers, your engineers to sort of ideate on solutions. And then once you have some solutions, you prototype them. And then when you prototype them, you basically go out and you test them with real users to get some real feedback.
And once you sort of align on the right prototype that, you know, sort of like had the best sort of success, then you go and you finish it and you launch it with real users. And most people kind of think that once you launch your product, you're done. That's actually not true.
Once you launch it, then you have to measure the success of it. You have to see if it performed adequately. And if not, what went wrong?
And once you sort of measure the success, you can then use that information to go through the cycle over and over again. Because product development is not a one cycle thing. It's an iterative process that continues over time. So you can continue to improve the user experience of your product.
Yeah. So for example, I work on the Splunk Dashboards framework. So what that means is I own the editing and kind of the rendering experience of what it feels like to build a dashboard using the product. So when we deliver a new feature, so customers are like, hey, I want to be able to export something. We ship that feature and then we look at, OK, so how many people are actually using it?
Is this the number we expected? And then we go out and look at the customers who are not so happy with the feature and understand what is it that we did well and what is it that we didn't do well. And that's when we start the problem discovery process all over again, so that you can go back, iterate, and then deliver better and better results and better experiences for your customers in the end. I'm going to talk us through a day in the life of a product manager. I think when I was starting out.
I kind of got all the high level stuff, but then my question was always like, what does that actually look like? So this is actually a typical kind of one type of day I'll have at work at Splunk right now. So 9 a.m., go in the office, you know, you make a cup of coffee, you have about 30 minutes of relaxing kind of your own time in the morning. And that's when you have a chance to answer emails.
Typically, as a product manager, you are the point person for your team and your product. So what you'll end up having is tons of questions on Slack. from external user groups, internal consuming team product managers, other engineers who are looking to use your tool with questions that you'll be answering.
And then you'll have a series of syncs and meetings. So one that I typically have is a sync with my designer. So if I design a business case and kind of a framework for what a solution could be, the designer takes that and goes off and creates the actual mocks and the actual interaction. So twice a week, my designer and I meet. and we look at progress.
We exchange ideas, trade-offs, and we give feedback where I represent the user and then he represents kind of the designer perspective. You also participate in team stand-up. This is something that you typically do in a scrum-based tech company. So those who don't know what stand-up is, it's essentially you stand up, you stand in a circle and you give updates on what you did yesterday, what you're going to do today, and what are you struggling with that the team can help you immediately overcome. 11 a.m.
you sync with your dependency team similar to your designers to share what your team has done in the past two weeks. If you have any things that, you know, frameworks that you depend on, tools that other teams create that your team uses and to share updates there. And then you'll also be doing a lot of internal team building to champion your product. So for me, that means internal dashboard build sessions where every two months I basically pull in salespeople, you know, engineers, designers and everyone who has a say. and an interest in building good dashboards and delivering a good tool.
And then we sit down and we build a dashboard together. We use our own tool. And then we analyze the experience of using it ourselves before it even goes out to customers.
And all of the planning kind of falls on the shoulders of the product manager. You take a full lunch. So 12 to 1, you take an hour for yourself.
And then you'll also be doing lots of public speaking. So sometimes that's speaking at a conference. Sometimes that's speaking internally. So for me, this year, I'll need to be presenting at at the Splunk annual conference in a breakout session.
So basically going through to customers on site, like, you know, what have we done in the past year and how that's gonna benefit their workflows as they're Splunk customers. Yep, so then you do a dry run, you take out that feedback and then from people who watched your dry run, you spend half an hour updating your slides. And then you have another half an hour of alone time where you continue what you were doing at 11 in the morning. So continue preparing that build session.
And then inevitably, somebody is going to pull you into a pretty complicated conversation on Slack. It's going to be a future request. It's going to be a bug or somebody is just going to be a little bit unhappy about the philosophy that you've taken in developing a future.
And they're going to bring us some good points. And then this happens a lot. You just, you know, you've taken all that feedback, you digest it, you answer questions, you address concerns, and, you know, you're just kind of playing a listening role every day and all of the different stakeholders in your team. And Splunk is unique that.
My organization gives everybody an hour off every day in the afternoon. So from 3 to 4, that's kind of your free time. So I take 3 to 3.30 to walk my dog. And then typically I try to find some other time to talk to customers.
So 3.30 to 4 would be a customer interview. So sometimes they've requested a feature. You want to learn more about, you know, exactly what problems that they're trying to solve by requesting what they're asking for. So meet a customer. 4 o'clock is something that's...
something that's called spec review. So what that means is as a product manager, you write documents that outline all of the specific, you know, business case, the motivations and the requirements for a future. And that is the document that designers and engineers basically take as the source of truth and also for the clarity that they need to deliver projects.
So who is this for? What are we doing? What's in scope? What are we not doing as part of this effort? When does it need to be delivered?
All of that is encapsulated in the spec that you deliver. And then you're also in charge of the backlog. So this is getting to nitty gritty, but, you know, what is the team going to work on next week? What is the team going to work on next month? And if you work in Jira and Scrum, you have all these tickets.
So prioritizing them, making sure they're ready for engineers to pick up is one of those day-to-day tasks that product managers do. I'm at five o'clock, you know, you wrap up, you're going to have missed some messages and some emails. So before you go home.
I typically write everything down on like an Apple notepad. And then I start the next morning and, you know, make that cup of coffee and start answering everything on Slack again. So yeah, that's a typical day in the life of a product manager. I would say it's a lot of interacting with people, not a lot of alone time and not a lot of downtime.
So if that's the kind of thing that keeps you energized, then this career might be the path for you. Yeah, so after looking at like a day in the life, you can kind of see how there's some certain parallels with the kind of the key responsibilities listed on this slide. Like one of them is like owning the roadmap.
So as you mentioned, you kind of have to like look through your backlog, sort of figure out what your feature is going to look like, or what your product area is going to look like a year from now, two years from now, what are you going to invest in right now. And that's a really, really like cool part of the job. You basically have a lot of like ownership and a lot of like, sort of power and responsibility with how the feature you have is going to look like and how it's going to impact the world.
So that's a really cool part of the job. Another thing that's really interesting is that you get to you get to be the person who advocates for the customer. As a product manager, you're expected to be very in tune and on the pulse with exactly how customers feel.
So I spend a lot of my time, I work on Windows Widgets, which is a very user-facing product. I spend a lot of my time sort of triaging feedback from users. So I have a good idea of what customers feel and what they want us to be working on in the future.
And so when I'm in the room with other engineers and designers and other product makers, and we're heading in a certain direction, it's kind of my job to make sure that... users that the product, the direction that we're going in aligns with whatever is best for the user. So if I see them going in the wrong direction, then it's my job to speak up and make sure that we head back in a direction that's advantageous for the user.
Another key responsibility is championing your product and your team. As a product manager, you basically reflect the work that your product, your team does, and you reflect, you own and you sort of like communicate. your product and its results to other people internally at the company as well as externally. So it's really important that you sort of like have really really good communication skills and you're energized by reflecting the work of the group that you work with. I find that a big part of my job is also sort of energizing my team.
You know like you're the person who's going to keep the project moving in the direction that it needs to go and so it's really important to you know be sort of energetic with your team and make sure that the morale is high. It's a really cool part if you're a very social person of the job. Another part of the job is also defining product specs. That's something that Easton spoke to earlier with spec reviews.
Product specs are a very, very important part of the job. That product spec becomes the one source of truth. And all other stakeholders sort of look at that document before coming to you for any questions. And so whatever you write in there will basically form the backbone of whatever product that you're trying to ship.
So it's a really interesting idea, basically, of how you boil down a product to a couple pages in a document. And then the final key responsibility you have is measuring success. And this one's really interesting because you have to think about after investing all this engineering, product management, design resources, what are we trying to get out of it?
What is the impact that we want that will say this was all worth it? And then being able to figure out the mechanisms with the data team to say, like, how do we actually find the telemetry we need? to be able to measure success appropriately. So those are all like the key responsibilities you have as a product manager. Cool, thanks Neil.
Next up we're just going to jump into quickly like our journey, so how we got this far and how we got into the jobs we have today. Yeah cool, so I started off joining the University of Waterloo in 2016 as a system design engineering undergraduate. When I first joined I had no idea what I wanted to do, I was just looking for something else.
kind of technical and very open-ended and so that's where I ended up. And Waterloo has this sort of like six internships sort of program and so it allows you to basically get some real work experience while also sort of trying out different things. And so when I first started off my internship experiences, I did a little bit of coding in high school and I thought that that's what I wanted to do and I started my first, my second, and my third internships all as developers. And by this point in time, I had never heard of product management at all. I didn't know it was a career.
that existed. I didn't know anyone else who did it. And so when I got to my third internship at RBC as an iOS developer, I actually sort of felt myself gravitating towards some of the product decisions that they were making.
Like as a developer, you kind of just get handed a very predefined ticket of exactly what you need to build. And I found myself asking, well, why are we building that? Like, why are we investing in this specifically? What is the impact we're trying to gather? And I think my manager saw that in me and sort of like fostered that in me by basically pulling me into...
more product-oriented meetings. And I got my first taste of what product management would be like. And so eventually I was able to transition. from an engineering internship to a product management internship in 2019 at Oracle. And that was my first like real taste of a PM and basically thinking about the real responsibilities that a PM has and actually going through the day in day in day out as a PM.
And I really liked that experience. So I kept moving forward with it. And I got my next internship at Microsoft, which was very different from Oracle, I will say that PMs tend to be very like the role of the PM and like the day to day responsibilities do differ a lot.
from whatever company you go to. So you'll try to, you'll basically find that like, based on industry and based on size of the company, the role kind of changes a lot. And so I found with Microsoft, things were a lot more segregated in terms of responsibilities. At Oracle, you sort of had a lot more sort of ownership over the design and the data and all that stuff. And it was kind of as a PM, you were just like, responsible for all of it.
And you kind of just like worked with a couple people on it. But at Microsoft, you had very specific teams. You had a data team, you had a user research team, you had a design team, and it was all the stuff that you basically then like say, I want to test this out.
And you send it out to the user research team at Microsoft, and they come back with you with a study, and then you'd be able to take that information and move forward. So that's all to say that the role differs a lot, but at the end of the day, you are responsible for taking an idea to all the way to delivery. And that's something that's unique, is common amongst all product management positions.
And then now at 2021, I graduated from university and I'm working full-time at Microsoft. So that's my journey to PM. Cool. Thanks, Neil. So this is mine.
Also, so Neil and I actually graduated in the same class. So I was also doing systems at Waterloo in 2016. Got my first internship in manual quality assurance at a company called Q4, based in Toronto. And then thought I wanted to be an engineer. So I started doing mobile.
So I started doing it. Android development internship at Toast in 2018, which is a restaurant company based out of Boston. I started as a backend engineer.
So that's when I really felt like I was hitting my engineering ceiling, where the architecture was getting incredibly complicated. The demands for the type of the quality of code I had to write was a lot. And at the same time, I felt like I was losing interest in development, where kind of the day to day.
you know, the debugging and, you know, the designing of the algorithms that I had to write was, you know, it was getting really challenging. And at the same time, I was losing interest. So at the same time, I realized, you know, I wanted to be in the other meetings that I wasn't invited to. So the meetings where you talk to customers, the meeting where you can, you talk to marketing to figure out, you know, like how to sell a product. And then just defining the roadmap in general, I realized that role was actually for a product manager.
And even the most senior engineers typically focus on. architecture and implementation and not so much of the customer and the business case problems that product managers solve. So that was a chance that I saw where I approached my product manager on the team when I was an intern. And I basically said like, hey, can I learn more about what you do? And I showed a ton of interest.
And I was able to transition internally from an engineering intern to a product intern because I was able to gain this PM's trust and taking me under her wing for four months. And that's kind of how I got my foot in the door. So then after Toast, Splunk hired me for an engineering for a product internship. I really enjoyed it.
That was already on the dashboards team that I currently own. So yeah, I did two consecutive internships there and then got a full-time offer. Now that I've signed it, I've been at Splunk for almost a year now.
So yeah, that's my journey. Cool. So next, we'll jump into some tips and tricks on landing your first product job. Neil, did you want to take this one?
Yeah, sure. Okay, so the first tip and trick is prepping with the best. This is something that helped me quite a bit too when I was trying to transition from engineering to product.
And it was basically like reading, cracking the PM interview. This book is an amazing sort of overview of what PM is, how to tailor your resume so that it's more product-facing, and then how to basically prepare for your interview, what kind of questions you'll get asked. how to sort of approach them and like what to expect when you do get the job. So it's a great resource to basically prepare yourself for transitioning into PM and also like understanding whether or not PM is a good fit for you.
They do a good job of really describing what the role is like and so like reading through that book will also give you an idea of if maybe PM is right for you or not. And then the second tip and trick is shadowing PMs in action. So if you already have a job working in some sort of tech company or working in another company where PMs exist, It would be a really good idea to shadow the PMs around you. Maybe ask them to sit on a meeting, or maybe ask them to give you a small little project that they're working on.
Basically working with them and seeing firsthand what the PM's role is like at a company you already work for is great. Also, being able to talk to other people that may not be in a workplace with you, but if you know someone else who's a PM, reaching out to them is also a great resource. And then doing something similar to what Eason did with transferring internally is also a really good idea. If you're already working at a company and there's an opportunity to then keep your knowledge of that industry and that company and transition to a PM in a space that you're already really comfortable with, it makes it really easy to make that harsh transition.
and also makes it easy for you to succeed in a new role. So that's another great tip and trick. And then finally, a big part of PM is, you know, being really good at being a leader, having strong communication and public speaking abilities.
So volunteering in certain spaces where you're leading a group is really, really helpful. I know for me, I was having trouble going from engineering internships to PM internships. And one of the things I started doing was I started volunteering a lot more. as a leader and as a PM, I remember one of the things I did was I sort of led a engineering design competition.
And I think like small things like that, and being able to like learn from those experiences, get those skills, and then put that on your resume and be able to talk to them in interviews really helped me sort of move from engineering to product. So in one way, it helps you get the job. In another way, it also makes you better at the job. And another way, it just makes you feel like whether or not PM is right for you. Awesome.
Okay, so we thought we'd end kind of the prepared portion of our deck here. And we wanted to jump into some basically Q&A. We thought we'd structure it with some frequently asked questions.
So we can start going down these questions and answering them one by one. And if you've got a question that's not on the list, you know, seeing that we've got about 10 minutes left, please put them in the chat and we'll prioritize that over the rest of these. With that said, I think... I'll jump with the first one.
So do I need to be technical to be a PM? That's a good question. And the crappy answer is that it depends.
If you have an incredibly front end user facing role, typically those require less product, less technical skills. So, you know, if you work on, you know, if you work on Google search, like you can't just dream up like, hey, I want the search to perform this way next week, right? Because you have to have a fundamental understanding of like how the algorithm works and what are its limitations.
But, you know, if you worked on, say, the Uber homepage and you had an idea for, you know, maybe if we restructure the user flow this way, maybe instead of, you know, checking the route and then suggesting a ride, maybe there's another flow that users can take and they get more and they were able to book more rides. That's a much more front end, you know, UI facing problem. And for those types of use cases and those types of roles, having a technical. kind of background is less important. So in general, I think Neil and I can both say that some of the best PMs we've ever worked with were not technical people.
So you definitely don't need it to succeed. But you know, for some roles, that having that understanding a technical background is a strength, but not a requirement. Yeah, I totally agree with that. Like I've had so many in my product internships and my experience at Microsoft, some PMs I've worked with that I thought were you know some of the best PMs I've ever worked with were not you know technical they didn't have an engineering or CS degree some of them came from marketing and some of them came from business I think the key is just being able to be like hungry to learn because you'll most spaces you go to as a PM you're not going to know everything right away even if you have a technical background there's still so much you have to learn and so being hungry to learn more from the people around you is is more important than having those skills right up front but obviously it does help Cool.
Do you want to start the next one? Sure. I think we've got a question, actually, so maybe we'll defer to that one.
Do you have a specific framework you use for structuring your approach to identifying slash tackling problems? I heard that PMs are pretty fluent with answering questions by stating how they frame, structure their answer, and then answer the question. Eason, do you want to answer that first?
Yeah, sure. So I think the question is, Like there's part of it that's like, you know, how do you, how do you like identify problems? And then there's another one where it's like, like, how do you answer questions? I think, I think how you identify problems, I really like a framework called like the jobs to be done framework.
It's from a really book, good book called competing against chance. So essentially, the framework is, instead of asking customers what they want, ask customers, what is the, what is it that they're trying to achieve? And you really go deep.
You know, you really go... you know, it's not the future, it's not even the workflow, it is the job that you're trying to get done, it is the insight you're trying to get out of the tool, and really understanding how to ask those questions and get deeper, and then coming back from that, you're able to create a better solution that's, you know, not necessarily what they asked for in the beginning, but sometimes an even better fit. In terms of like how to structure their answers, this is actually like an interview skill.
Um, and like, I would say as generic as it sounds, I'm doing a really good, you know, situation. So the star framework, so the situation, the task, um, and then just like, uh, I mean, the book will cover more, but the idea is, you know, as long as you're able to always go back to the root problem, um, that, that is what shows that you have the insight to really drive good, good product decisions. Yeah, totally.
I agree with everything that Easton said. Um, The other thing I want to add on to is when you do the job to be done framework, you sort of understand what the user wants to do. And then I think like augmenting that with certain other frameworks like user journey maps is really, really helpful to basically understand where the user is having problems on their way to complete a certain job.
I think that helps me a lot in my job right now to understand exactly where I can improve a user experience. And then, yeah, answering questions that the star framework is super, super helpful. And it's something that's covered in.
the Cracking the PM interview book. So again, highly recommend that book. Yeah.
I can take this one too. So qualities that make you stand out as a PM candidate. From my experience, PMs, especially those who like get lots of interviews, have resumes that are outcome driven.
So the most basic tip I always give people is, you know, if you said, you know, I did task X to move metric Y. that's actually not as impactful. So actually back up a little bit.
Most people, you know, the mistake that people tend to make is like writing a resume that's only, I did X, right? One level up from that is I did X to achieve Y. And I think the ultimate way to structure it is I achieved Y while I was in this role. And the way I did that was by doing X.
And what you actually did is actually not important. The idea is that you moved a meaningful metric in your time there. And- An interviewer or a recruiter looks at it and goes, okay, this person made a meaningful impact at their previous role, and I want that person to move the same metric for my organization. So whether that's did a thing, but ultimately got 10% more users to sign up, right?
You didn't necessarily introduce a new flow for the sake of doing it. You got 10% more sign up, and the way you did that is not the most important thing. So making sure that your resume is structured, impact first. That's the... the how what you achieve first and the what you did second is a really big help for getting resumes kind of through the door.
Yeah totally and that's something that I did on my resume when I was transitioning from engineering to PM. Another thing I want to add is I think like displaying passion is really really important. I have a an intern who just joined my team and the way they got their internship is basically by like cold emailing and cold messaging. certain people in Microsoft and they just displayed so much passion that my manager actually was like this person like I just like you know even though they don't have too much PM experience I really want to give them a shot because you know that that passion is going to be so good for our team and they're going to be so like energetic and so hungry to learn and do stuff at this role so I think that's another sort of aspect that you want to emphasize in your resume in your interviews in order to get into like competitive tech companies. Yeah.
One more thing I can add is if you have already experience in a non-PM role in an industry, so maybe you worked in payments, maybe you worked in restaurant tech, like I did, or maybe you worked in some kind of mobile app, applying to other companies in the same space is really, really helpful because then you already have knowledge of the industry. I'll just read this one out. What happens when you have a customer that thinks they're asking for a product that addresses problem X, but they're really trying to address problem Y and directly impact X in a perfect world way?
What do you build to what your customer is asking for? It's a good question. Neil, do you want to take this one? Sorry.
So what happens when you have a customer that thinks they're asking for a product that addresses problem X, but they're really addressing problem Y? When do you build? to what your customer is asking for. So is this question asking, what do you do if your customer is asking for something that isn't actually what they need? Okay.
Yeah. So generally, and I think that's why the job to be done framework is so helpful because some, as a PM, you're not always going to build exactly what your customer asks for because your customer isn't always right about what they actually need. And so focusing on the job to be done is how you sort of like sidestep that sort of bias. I think that as, as, as my role as a PM at Microsoft, one of the things I've been doing is triaging a lot of feedback.
And a lot of people have a certain idea of what needs to be done. For example, like, oh, we want to, I think specifically in widgets right now, they want to remove news because, you know, they think it's not, you know, relevant to them right now. But what we're trying to do instead is make it more highly relevant to them.
So in a way, they've identified the problem to say, like, we don't want this, but we're saying there's another way to make this more relevant to you. So I think the way you sort of approach it. It's just to focus on that job to be done framework and then use that to basically make sure that whatever the root cause of the problem is that you're addressing that.
But you don't necessarily need to be pigeonholed into doing it the way the customer wants to be done. Hope that helps. Yeah. And I would say typically if it's not clear, the easiest way is to work with your designer, come up with a few solutions and then give that back to the customer on a call and say, hey, I know you asked for this. But very simply, we also put together why, because we think this might help you do job X.
And then getting that feedback, because sometimes you think you're smarter than them. And you're like, no, I actually I think you want something that you don't even know you want. But you could be wrong. And part of being a PM is really accepting that more often than not, your first try is not going to be correct. So having that perspective and getting tests done.
Getting user feedback as early as you can is one way to mitigate building the wrong thing. Cool. I realize we're at time.
Team, should we cut it off at this point and hand it over to somebody else? Yeah, there is nobody else after this, so you should be fine to continue if you want. Okay.
I'm good to stay another 10. Neil, I hope you keep answering questions. Yeah, sure. I think we've got another question. How big is the product team and how do you collaborate with other product managers? This is going to be a very different answer from Neil and I.
So on my direct product team, there's five product managers. And it's really interesting because when I originally came, I was like, oh, yeah, we're all going to work together. You know, like your team, you work together on things. But actually, we own our own areas and it's kind of very siloed.
So it's really interesting. But yeah, there's five people on my product team. And then like the greater org for product managers is much bigger.
And then how do you collaborate with other product managers? That's the other side of the question. A lot of that comes down to meetings, just like, you know, booking a meeting with another product manager who you maybe need to integrate with.
So, for example, I work on Windows and Windows is essentially just a top of the funnel. It's basically there to then integrate with other parts of the company. for example, with Teams or with Edge, all these different services. So I often have to interface with other product managers.
And the way that really happens is you schedule meetings, you work together, you collaborate on specs. And so you basically come together and you share and review and bounce ideas off of each other. It does get complicated sometimes when you're working with other product managers that aren't on the same team as you, because they're classified as partners then and they might not have the same priorities. and sort of the same goals as you, but you're still working on the same product.
And so that sort of becomes an interesting position where you have to do a lot more bargaining and negotiating. And so that's like a pretty exciting part of the role as well, at least for me personally. Yeah, I can talk about that a little bit as well.
So I'm in a significantly smaller company. So Splunk is nowhere near the size of Microsoft. I think in general, if you want to estimate the size of how many product managers there are in a company, You have about six to seven, I would say, engineers for every product manager, because typically one team has one product manager and six to seven engineers. So that's kind of how to think about it. I would say Splunk maybe has about 100 product managers total.
you know, eight, nine hundred engineering staff. So within my area, I collaborate with other product managers, mostly since I just started my career in product. I reach out to other product managers mainly for feedback. So when I write a spec, I send it to someone more senior than me to read over, you know, how is this that I how can I do this better? When I run big meetings, I'll have product managers who, you know, are more experienced than me.
I'll ask them to join and give me feedback on how well I ran it afterwards. So it's a lot of like, you do things on your own because you own your product, you own the spec and you own the management of how the engineer is implemented. So you can definitely feel siloed in a lot of ways.
But you typically collaborate when you need help, when you want to get a second eye on something and you go to a product manager by the team. If you tend to work in a product that integrates heavily with another product. So that was a lot of product words. But for example, if you own the... Apple App Store, right?
And you have tons of product managers who each own an app. When you want to make a change to the App Store, you need the consent and support of everybody who depends on you. So when you work in that kind of a situation, you will have tons and tons of integrations of other product managers where you negotiate, you communicate roadmaps, you go back and forth on what's the right way to make this update that you want to push because it impacts everybody around you.
So that is another way that, you know, PMs tend to interact very closely. I actually forgot to answer that part of the question. So at Microsoft, there's probably at least hundreds, if not a thousand people working on Windows as PM. And then across the bigger org, there's thousands of PMs.
So it's a really, really big company and a huge product company. Yeah. Product managers and consultants. I've never worked in consulting, so I don't have the best lens to answer that. But I will say that...
I tend to see consultants move over to product management. I've seen it at my old job and I've seen it now where, you know, it's actually, you know, people tend to not, you know, put it as they're like, here's who I am. But you end up like you go into a meeting and someone says, wow, that's a really nice presentation you gave. And they're like, haha, I used to be a consultant.
So these things do come up. I think in general, consultants have like an outside view. of the company.
So you're typically hired, right? So you don't typically see the full execution of your proposal, whereas product managers kind of do all of that investigation, the recommendation stage, but then also has to live to see through the building, the release and measuring success. So I would say like the early on skills is very similar to what consultants do.
But then the execution of it is like another part that you have to learn. to be a product manager. Yeah. And just to add on to that, like I also have not worked extensively with consultants, but based on my like sort of outward perspective of them, it sounds like they just, you know, they don't have the full scope that product managers do.
Like they come in, they try to solve a problem and then they propose something, but they don't, as you said, they don't live to see the entire sort of like the release and then maybe even the measuring the success part of it. And they don't stay on the same product for years like product managers sometimes do. And so there's sort of like sort of depth that you get working as a product manager and sort of like knowledge of the of the of the specific product. Like I have a colleague who works on Windows taskbar for the last five years.
And so because he's been able to stay that long, he's been able to realize these long term visions that he's had for the space. And which is really, really cool and fulfilling for him. But something that wouldn't really be possible for a consultant. But on the flip side, as a consultant, you probably get a lot more sort of variety in your role. Some people might not like working on the same project for that long.
Cool. I think we're right about 10 over, so we can take one more question. But, you know, if not, thank you guys so much for your time and we hope this was helpful. Okay.
Yeah, definitely. Find me on LinkedIn. I can send my information.
Oh, actually, I'll just paste it in this right now. That's probably the easiest thing. All right, yeah, please connect.
Hit me up with questions and I'll do my best to respond back to you as soon as I can. Thanks everyone for your time. Hope this was helpful and have a great weekend.
Bye everybody. Thank you.