You have like a hundred people, so everyone else has to watch from YouTube. Okay, so thanks for putting where you're calling in from in the chat. I can see most people from Lagos, some people from the UK—which is awesome… ooh South Africa, Nigeria, Nigeria, India? Oh, isn't it really late in India? I don't know, it's like 9:30 or something? Jamaica, oh my gosh, thanks for being here. I'm always so excited seeing where all of you are from.
Okay, cool I think we can get started. I'm just going to talk about some house rules now. Hopefully, you can see my screen. Maybe let me know in the chat if you can. Okay, so I'm just gonna… okay, thanks for letting me know. Basically, this event is hosted by EntryLevel, and hopefully you already know what we do, but we help you learn and get experience so that you can get hired. Oh and, please keep your mics muted unless you're a panelist so we can hear what I'm saying. So yeah, these are available programs and you can check them out on our website if you want, but I'm sure most of you are interested in Product Management, which is what we're talking about today. But before we start, I want to know your experience level in tech, just so the questions can be better tailored and Douglas's answers can be better tailored to you. So, just put in your chat; are you a beginner? Have you taken a few courses or do you already like have some internship experience?
So, ‘Beginner’, ‘Taking Courses’, or ‘In’? Oh coding courses… interesting! Most people are beginners, currently doing bootcamp. Interesting! Okay so, Douglas, maybe you can keep that in mind. Okay, someone has taken a few courses, already working. That's awesome.
Okay, let me just mute everybody who needs to be muted okay. Okay, interesting. Haven't started internship. I did get a lot of questions about people asking how to get an internship, so maybe we can cover that today as well. Oops! Sorry, it's so hard to meet everybody here. Okay, so I'm gonna move on to house rules and agenda; so, first I'm going to pass it to Douglas to introduce himself and then we jump into the Q & A with all the questions everyone has sent in and then after that, I… we can go to your questions. So, feel free to ask in the chat or, like, raise your hand and like say it out loud, and then we're going to end the event.
So, some house rules before we start; please be respectful; you can use—oh, not Q & A, but like—use the chat to ask questions and I'll save a lot of your questions and ask the most relevant ones. Okay, so I'm just gonna pass it to Douglas to introduce himself so, can you unmute and introduce yourself?
Good day, everyone. Can you hear me?
Yes, I can hear you.
Okay, um… thanks for taking the time to join. I can't imagine waking up by, I don't know, 5:30 to join a call. My name is Douglas, Product Manager at OkHi; currently Product Lead—Consumer Product Lead. I'm based in Lagos, Nigeria. I have about four years of experience; I've done products for a couple of companies; Per Diem, Demos, Crisp, and Eden Life as well. Before I start, I would just like to share my screen and get you on board with stuff. Okay, could you please give me permission to share screen?
Okay, so let me know when you can see my screen.
Oh, I can see your screen now but you're unmuted… Err, you're muted so could you please just unmute yourself again? Thanks. Oh okay, you should be able to do it now. No, I can't hear you… I still can't hear you but what we can do is, I can share my screen with that document and then are you able to unmute yourself because you should be able to. I'll ask you to unmute there.
Yeah, can you hear me now?
Yes, yes. I can.
You have to share the document and then… just the first part of the document.
Yes, I am going to open it right now and share it. But okay, let me zoom in so everyone can see it.
Sharing now. I have so many windows open, but… okay, can everybody see that? This is the right document, right?
That's the right document.
Okay, so a lot of stuff you would hear here today—you'd hear today—will be advanced stuff. It does not mean it's always good for you; it can backfire if you use them without the necessary skills or platforms; I just want to make that known. Don't take any examples I share literally. Understand the principles—the online principles. Adapt them to your context, and use your judgment. Clear? It's fine for Jennifer to interrupt me statements like, “Oh this person has a question.” I'll sometimes hand the question instantly or pick it up later. It's fine to talk; it’s a casual environment. If there’s a problem or issue, bring it up and share to Jennifer. If I get dropped—rarely happens—I'll be back in a minute or two, so just be patient. And then, it's just helpful for me when there's no noise when I'm talking, so just help me mute your mics except you have questions.
Is that okay?
Awesome. Also an interesting fact that I learned hosting one of these events is that when the power goes out in Nigeria, I think, and then it comes back, people say, “Up NEPA!” Right?
That was so cool. And then in the chat, I remember at one event, everyone was saying “UP NEPA” when one of the panelists power came back on and it was a wholesome moment.
It’s an inside Nigerian joke. Thats nice. Okay, so let’s get started.
Yes, so I already have a few questions that were sent in and some of them were more advanced, but since we have mostly beginners here, I'll start with the beginner questions.
So, there were a lot of people who were asking about a road map and, like, how to start with Product Management. Like, what would you recommend as the steps to start learning?
Okay, interesting question. I will tell you how I started. So, my school had a strike; students rioted, and so we went on break for like a year. I had an uncle who was a product manager in a startup studio in Germany, and so during my one year leave, he took me on board. Status Associates in a startup studio, so it meant I was working on multiple products at the same time with multiple squads, and it was a very good a learning environment for me. I've seen other of my peers who worked in other departments; customer success and products analysts, and some were Engineers, some were designers, and they transitioned internally. There are also some people who took courses and from there, they became PM.
So, it's like four ways you could do it; you could start as an intern and work your way up there, you could work in tech—which is what I always advise—get a job in tech, learn how product development works in that company, and then transition to being a PM. And then, there's a regular route where you become a PM by taking a course. I think that helps you learn the trade secrets on the job, helps you land your feet very, very well as well. So, those are like, common ways you could become a PM.
I do not think anyone is best, but yeah, everyone has a part.
Okay, that makes sense. So, you recommend experience and a course. But like, in what order should people… like, can you do both at the same time and search for internships while taking the course?
Yeah, so it's… I would say it just depends on you. If I were to go back and start again, what I would do would be; create a learning resource myself; EntryLevel has a very good program. There’s Treford, the other really good programs; take a program, it should not cost you a lot of money. The aim of the program is for you to understand what a program manager does, right? Just want to know what the PM does; figure out if you really like this stuff. It's a difficult job—I hate it—we just want to figure out if you want to do this, right? And so, because it's going to enable you do that, I would also say it's a lot more difficult to get a PM job as a beginner, so I would advise you to get any job you can get in a tech company. That's what I'll do now; try and get a job internship with the company—any role at all—and then I would work my way up there, transitioning to become a PM.
This has hard; some companies don't have paths to uphold the transition, but that's what I will do again.
Interesting. I feel like a lot of people don't think about that. They don't think they can just transition from one role to another within the same company, so thanks for mentioning that. And then, I think what you said—pick one learning resource—is really important because people get overwhelmed with what to learn, but you just need to focus on one thing, so you can get it done. And I took EntryLevel’s Product Management course before I got hired and it was pretty good.
Awesome, so my next question is kind of related because you mentioned, “...get any job, even if it's unrelated to product management.” What if you're already in another job or you have previous experience but you're trying to transition?
Good question. So, I have lots of my friends who were working in different roles and transitioned. I would say there are core skills you need to become a PM and those skills you did them in the you do. So, talking to users; that's a skill you need on stakeholder management. Planning your calendar—which is very difficult task for a PM, just knowing what the writing is you have to work on, also voicing your opinion, listening to people; these, like, traits you need on the job, it's stuff that when you're working, you just take it up on the job, right? Yeah, so those are like the common traits.
I think anyone can transition to being a PM. My preference would be people who work in tech because you just understand how product development works. Even if you're not a PM, you know what goes on in your company during the development process. It's a lot easier for you to pick up on the job from there.
Okay, so trying to get a job in tech; what about like, would you recommend working with bigger companies or more startups? Or is that dependent on the person?
Depends… depends on the environment. In Africa, there's very few big companies. I think Flutterwave recently hired lots of people, so that's one way you could have become a PM. But it's just difficult getting a job as an intern from Africa, so I would advise you startups would probably be a better landscape for you here. if you're in Europe or in America, I think probably, you could try going through the internship. I think, Google… lots of bigger companies have APN programs.
Okay, perfect. Thanks for sharing.
Do you have any experience with like, remote jobs? Like if you're in Africa but you're searching for a job somewhere else, do you have any advice there?
For remote jobs, I think talking about even looking for jobs is a bigger topic and it’s like a full one-hour discussion. For remote jobs, what I have seen that works for me and for a couple of my folks, it's just a numbers game. I think that's what you have to put in mind; it's a numbers game. If you applying 100 times, probably 10 persons reach out to you and then you have maybe two persons reach out to you since all the numbers again and we can't apply for 10 jobs and expect to get a job. Most people… very few persons will, but it doesn't work that way all the time. I think it's more of a numbers game.
There are companies abroad wants to hire PMs from Africa; really, really good talents coming from here. There's also companies who are taking interns, but I think you have to do your research very very well. So, one thing I've seen that's worked is, go to LinkedIn, search for people who are in Lagos who are working for foreign companies; you can guage that those companies hire from Africa, and then, you can reach out to people on LinkedIn. A very easy way is, you could search on Google how the company has their email domains. So, some companies, it’s first_name@company_name.co or .com, and then you go to LinkedIn, you see someone's first name, you go to Google—Google has autocomplete—you type firstname.lastname@example.org and if it's an email address, you’ll see it there. Then, you could send a email to the person asking them about the role. I don't think it's easy just asking, “I want to work for your company,” most times it won’t work. So, you could just ask them about their job and try to create relationship. And, then you can learn from that; tell them you're looking for an internship position. Yes, that's something that's worked for lots of employment.
Okay, it sounds… it's interesting because you said, “oh, I think it's just a numbers game,” but then you dove into, “oh, you can go above and beyond just applying. You can start building relationships with the people who work there just to get insight into what it's like to work.” Because I feel like if you're trying to get a job at a company you're going to work at for a few years, then you want to make sure it's a good company; that you'll be happy there, right? So, thanks for sharing.
So, kind of changing topics a little bit before we dive further, I think we should talk about the difference between Product Management versus Project Management because I think, sometimes, people get those confused. So, how are they different for you?
For me, in my day-to-day job, it's the same thing. For some other companies, it's completely different. So a job of the PM is split into two functions, right? There's the delivery work and, yes, the discovery work. So, look at it; there are two phases of product management, right? Discovery phase, delivery phase. The discovery phase is about making sure we're building the right thing. That's all the stuff we do to ensure, “Oh, this is what's wrong with you,” right? Most companies split that function and say a product manager handles that, right?
And then, there's a delivery phase which is; how do we make sure what we're building, we're building it in the right way on time and with the best cost possible? Some companies give that job to someone they call a Project Manager; a product owner. But for lots of people, the role of a PM and the Project Manager is merged into one role.
For me, I've worked somewhere where the technical lead was a project manager, so I had my job as a product manager. But then, I had a project manager which was the head of the engineering squad that was managing, so it just depends on the way the company has the structure. But just take it in mind that most days your job as a PM would include a lot of project management.
Okay, that’s a very interesting way to tackle it and I think it finally makes the distinction clear, so thanks for sharing. You talked a little bit about your role and how you kind of do both project and product management. Can you dive in more detail about the task that you would do on a typical day?
Oh, I wish I could share my calendar to you guys. So, on a typical day—let me go to my calendar and let me just read out what I do every day, I think that'll be the best—right, so I don't just tell you what I wish to do every single day and, you know what I do every day. Is that okay?
Yeah, yeah. Of course.
Okay, typical day starts by… interesting; typical day starts by because at 8 pm… 8 am, sorry. So, first task; check and respond to Urgent tasks. So I go through Linear—we use linear for task management, project management—typical day, go through Linear, look at comments, look and see where tickets are, go on slack; all the messages I didn't respond to the previous day, I try to respond to them, right? I do that for about 20-30 minutes, and then I have Google alerts set up for my industry, for my competitors, for big players in my space, and I just check regardless and see what's happened within like 24 hours, and then I just read for about 15 minutes—just glance through all the information that's happened—right? Then I spent like an hour… I just block my calendar for like three hours and no one can book meetings; that starts from like 10 a.m up until like 1 pm in the afternoon. And so, what I do first is, I talk to users for an hour. I do this twice a week; Mondays and Fridays. I just talk to users for one hour I call my users, talk to them, speak to users who are using the product as power users and those using the products as “not power”users, and then I do data analysis for like an hour. I go to Amplitude, go to Kibana, query data, try to check hypothesis and validate them or invalidate them. And then, after that, I have a session where I take all the users I talk to, I go into Miro, try to create a board and copy all the insights I've gotten from all the conversations, try to put them and see their common themes, right?
When I get those insights, I create documents I share with the team—mostly the designer who works with me on that process—and so it's easy for us to share to the entire team; just have a short meeting and say, “oh this what we've noticed, this is what we've seen,” and then I start reviewing stuff. So, I review designs, I review on wireframes and user flows, I spend like 30 minutes to an hour making comments, reviewing them, reviewing stuff that has been built already, stuff that's in QA, all that type of stuff I do. Then, I take one hour lunch. When I'm back, I check in with my team members; how’s the day going? Are there blocks or anything; all that type of stuff. And I spend 20 minutes checking my email—reply to email; external emails, reply to internal emails, and then I spend like 30 minutes before the day ends going through my backlog, priming the backlog, going through the task management into ensuring that everything is an order, and then I spend the last part of the day planning the next day.
Pretty interesting, right?
I think when you plan the next day, it saves you time because in the next day, you know exactly what you're going to be doing.
That's very interesting. I… wait, so you talk to users two times a week.
Yeah, so I have a very easy method for doing that. When I first started, it was very hard talking to users; you call people and they’re busy and all that type of stuff, right? So what I started doing was; I'll go to a shopping mall and you just have lots of people who have all the time in the world on their hands—they don't have all the time, please—and I take my app, say, popular products, most people know it already. If it's not, I take my product, I just meet people and say, “Oh, look at what we're building. Could you check it out and tell me what you think?”
I do this on the dev environment so we can make changes on the fly. So, one thing I've noticed anecdotally; if you go with two boys, most people will not talk to you. You go with a boy and a girl, most people look at you. Two girls and a guy, everyone is going to respond to you, and so you take the device and say, “Oh, could you check this out?” They go through it, they watch what you're doing, they ask a question, it's completely recorded, I can hear everything they're saying so I can listen to it later. Then, if someone says… if 10 persons say, “Oh, I didn't see this stuff,” I'm calling my engineer immediately, “Could you please take this stuff up,” or could you do this, could you do that? And then, I showed the next set of users and I see; oh okay, this hasn't validated. I do that on the spot and so it takes probably five minutes to deploy and changes are live and I can get all those insights immediately. Then, I also have another list where I just call people. So, I look at all my key metrics and say; this is what I expect my users to be doing. Users who do that, I just call them and then I give them vouchers; probably the end of the month or something, then users who are not doing what I expect them to, also call them to find out why.
Very interesting stuff, but something I've built as a routine for the last, probably 18 months.
Oh, that is so cool. I never thought about just going like, in person. Everything is… wait do you work on like a software product, like, online or like…
Obviously, software. It’s an Address Verification Products for emerging markets. So, it's… it lives on mobile devices—it's smartphone based—and so, most people have smartphones. I can just say, “Oh, could you help me check this out?” And it's very easy—it works like magic.
Well, that's so interesting. I think the insights there will be very unique because you're talking to people who might never have used your app before. But a lot of people also have questions because you mentioned, like, making changes on the fly. But what if you don't know how to code, like, do you think it's necessary to learn as a product manager?
Interesting! I would send you stuff. I wrote an article this week—quite interesting—and the name of the article is, “Know Enough to Call Bull$%#!”. Kindly permit my bad language.
And what is it saying? It's saying that as a designer… as a PM, as a designer, anyone who works in product but doesn't code, I don't think you need to know how to code, I don't think you need to know how to design, I don't think you need to know how to write your SQL queries, right? If you know, it's perfect, right? Perfect. But I think you just need to know enough to call Bull$%#!. And so, a designer tells you, “It's going to take me four hours to work on this stuff,” and you know because you've done it before, you've worked people who have done it and took them 30 minutes, then you asked, “Why is this taking you four hours?” or your engineer tells you it’s going to take him a full day—because we asked Engineers when would this be ready, “it’s tomorrow”. Like people always say tomorrow, but there's like six hours left today and you're saying tomorrow and so it just helps you to be able to say, “Oh, this should not take this long,” “Oh, how about we do it this way?” It helps you reframe those things.
So, I'll give you an example this week I was talking to my designer and we noticed users were taking a certain action on the mobile app, right? And he wanted to do something entirely different, and because I understand design to a certain extent, I could ask some questions that enabled him to look at the question… look at the problem with different frame entirely and that enables us to solve that problem. I do not know how to design, but I could ask him those questions that enabled him do his job better; do you get? So, that's it. I think, just know enough to be able to call Bull$%#!.
That's really interesting I think it never hurts to learn more, but at the same time, don't get overwhelmed if you're a beginner; start with one thing at a time. Also, something that this reminded me of is that someone—like another product manager—said you're known as the CEO of delivering bad news to people who have the power to fire you. So, do you find that's true?
So, I have my own version of that which is; you're the CEO of saying “No!” Because everyone has ideas… everyone has perfect ideas, and everyone has “something interesting we could be working on here”. CEO has a new idea every morning he wakes up, your customer success people talk to customers every day and should have brilliant ideas, your engineers want to re-architect the entire code base again. It's always Tech them somewhere. Your designers feel like this could get better, this could always be finer stuff could always be finer, to be honest. Your devops guys have a problem and so your job is just to say, “No, no, this is beautiful—amazing idea— I love it. But, I'm sorry we can’t work on it today.”
But it's not just saying no all the time, it's… and that's why if you… where you work matters a lot. For us, it's very top-down, so we have the goal for the quarter and from that goal, the strategy comes from that. And then, we have the metrics, and then we have what we need to work on to achieve those metrics, right? So, look at it this way, there's a goal we want to get. Let's say, a million new customers, right? The strategy document to be written, how can we get to meet your own customers, right? Write all the strategy what we can do, what we should not do, and all that, right? And then you start asking yourself; where… how can we actually get a million customers? If, say one of them could be talking to people every single day, a million persons, right? One of them could be running an ad, one of them could be building this product, right?
So, those are things you could do, and then, you go one step further; “Okay, what can we do?” So, we can talk to a million persons daily? If people bring ideas that do not fall under that bucket, you just know. Like once, everyone has top-down Clarity of what we're working on, people start filtering bad ideas and stuff. But then, you have to also be careful; you don't want people to filter the good ideas, and so I have something on slack; a slack Channel just called ideas, and people just come and put all the ideas and just…
We have that too…
Yeah, I just go through it, probably once or twice a month and just; “Oh, this this makes sense.” Then I moved it to the backlog. “Oh, this doesn't make much sense,” and I put a very funny emoji there.
Yeah, thanks so much for sharing. I actually think that for people who want to break into Product Management, you can start practicing this now. Like, it's New Year, so you can set a goal for yourself, and then, create a strategy about how to reach your goal. Maybe in your career or personal development, and then figure out where to work on from there. So, if like, people are asking you to do things that don't align with your goal, you can practice telling them no, which is what you would do as a Product Manager. You can prioritize like that.
Awesome. Thanks for sharing. We have some questions from the chat, so I'm gonna pause for my question list and ask these questions; a few questions about your job. So, do you work remotely with the client overseas?
My job is completely remote until it's not. I think we are split into six different countries, so a lot of my colleagues are two hours ahead of me and I have someone who's probably six hours ahead of me. So yes, I have three colleagues in Nigeria, the rest of them are outside Nigeria. So, it just depends; sometimes, people come to Nigeria, we go to the office, work in person. But mostly, I'm at home working.
Do you have any advice for juggling all these different time zones?
Interestingly enough, so we have one calendar and I think companies should do this more often. We have an official time zone for the company, and so people who are moving to different time zones—because it's remote work you can travel around the world, right—they have to adjust to that time zone. Also, not every work is important; some things can wait to the next day. Some things are not as important, and so, there's affordance for people working different time zones.
Okay, interesting. So actually, that reminds me, same here because EntryLevel is fully remote; I'm in Canada, the rest… everyone else is in Nigeria or India or Australia, and I found that here, I work in the evenings, but when I went to Thailand, I worked like 6 am to 2 pm, so it's very interesting.
Okay, so we had a few questions about how you gather data. So, what tools do you use overall?
How… what tools we use to gather data; is that the question?
Like, what tools do you use, either to gather data or like, for user research? Just like, all the tools that you use—also, you turned your camera off, is that intentional?
It’ll come back on. I think I lost bandwidth there for a couple of seconds. Okay, better.
So, what tools do I use to cut that user feedback; Is that the question?
Yes, but I'm also curious to know, like, all the tools that you need to use as a product manager.
interesting. I do not think there are specific tools you need to use. You just have to get a job done. So, for data; the two types, right? Yeah, there’s the qualitative, there’s the quantitative one, right? And the tools are split those ways as well. So, for quantitative data, um… Bro, there are lots of tools you could use, so I'll try and segment them and go deep, right?
For user actions, I want to measure what users are doing, right? I use Amplitude I use Kibana; which is a logging tool. It's not optimal, but I use it. That's what the company uses. We also use Amplitude; some of my folks use Mixpanel; if I want to see what the user is doing, I could use FullStory, I could use UXCam, I think that's the name. Hotjar, I think, also works if you want to see what your user is doing.
What else again? If you want to go very deep and you want to look at funnels and create other type of stuff, you could do it on Amplitude for collecting data from people directly; you could use Forms, you could use Spreadsheets, you could send emails. I think collecting data is just lots of different things which depends on what you need and how fast you need it.
Thanks for sharing. I think it's very interesting because we don't use Amplitude but we use Mixpanel and the insights from there are very interesting and very insightful. Do you use any other tools? Not like user interview, but…
Um… any other tools I use; I use Sunsama—S-U-N-S-A-M-A—shameless plug, I use that to manage my task, so it’s like my daily planner. I use Linear for task management, I use Amplitude for analysis—Data Analysis—that has to do with user events, transcript, funnels, trying to look at conversion rates. I use Amplitude for all that. To query, Stop Dipper, I use SQLite. There's also a very nifty SQL tool; I can’t remember the name—SQL stuff—but it's a very good tool to create data as well. I use metabase for visualizations. I also use; what again? Let me see… I use Miro for Team collaborations. If we want to do stuff and collaborate together, we use Miro.
I use… we use figma for designs—Figjam if we don't want to use Miro. What else again, what other tool? I use Producteer for User Feedback. We use Coda for document management, I use Google Docs—I love Google Docs a lot—to write my PRDs. I use Google Forms to collect information; on forms, you could use TypeForm but it's quite expensive. What else again? I don't know, we could just keep on listing tools all day.
Perfect. Just to clarify for other beginners here, a PRD is a Product Requirements Document. And wait, can you define PRD for us? Because I don't think I'm gonna do it right.
Okay, so I should not have said that. PRD—Product Requirements Document—and I always tell people you write a PRD mostly for everything you do. Just take off Product Management out of this. When you want to start doing something; let's say you are in school and you want to plan for the new semester, what do you do? Oh, you write, “Oh, what is this that I want to do? I want to get a First Class this quarter,” then you write “how can I achieve this?” Then you write stuffs you do and you write, “oh, what are the assumptions I'm making,” right? You write that. “Oh, who is going to help me do this?” You write that.
So, that's what your PRD is when you're developing products; it's all the information that you need to work on a product. Yeah, so that's what the PRD is.
Okay, perfect. Thanks for clarifying. I think something that I realized just like working is, sometimes, people make PRDs, but then they never go back and reference it, which is really bad because that's what you're supposed to reference.
So yeah, do you have any tips there?
Yeah, funny story. So, the way we write PRDs in our company—I have experimented like probably six different PRD writing formats in the last 12 months, it just depends on the product, so I try not to use a format or a template—it depends on what we actually building. Some PRDs isn't only some sections, so it depends on what we're building.
So, what I figured is, we have two must-haves in every PRD. I call one, decision log, right? One of them is the decision log; one of them is a decision maker table. So, look at it this way; it's just a decision log which is, “why did we do this?” So, sometimes you see a product where there's a button somewhere, and then six months later, a new designer comes and takes off the button and everyone who was in the company has left and you don't know why that button was there in the first place. And then, when you take it off, two weeks into it, you see that all your metrics are flat-lining and you're like, “oh, why do I do this?” and you put the button back there so decision tracker helps, you know. Why we made certain decisions right we took off this button because when we took it off, we noticed engagement drive from this screen to this screen, we noticed conversion went up this high and that's why, and who made that decision, right? That's a table; we always update it. So, when we write the first edition of the PRD, actually into development, if new things come, there's an appendix. So I make changes to it and I reference it at the bottom.
And then there's also a decision maker table which is; who made this decision, right? So, there's some certain decisions that a stakeholder made, some decisions an engineer made, “oh this is why we wanted to go this way,” there's a table for that. And then, there's… with Coda, you could create a column and you put the people involved, and it would send a mail to every single of them that, “Oh, this decision was made.” And so, that's why I use Coda personally.
Yeah, but I think people should have a habit of updating their PRDs. Some PRDs are different from it… entire different from people build; just like some figma designs and what is out there and what's on the Fima file; completely different things. And so, you just make it a habit. Set it, probably time in a month where you go into your PRDs and try to make updates.
Oh that's very interesting. We don't have that in our PRD, but I feel like it's very useful because often, the decisions get made in meetings or on slack and it just gets lost, so it would definitely… yeah having documentation and such an important skill that I feel like it’s so underrated.
Awesome, so thanks for that awesome advice. I'm definitely going to implement this for EntryLevel’s team. But in the meantime, what do you enjoy most about being a Product Manager.
Interesting story! Talking to users is surprisingly refreshing. I think the best part of my job is when I get to build stuff and I see someone using it. It just feels so good.
My colleague went on a boat ride and the driver used a bank that had our product integrated, and it just felt so good; the driver telling him how he did not have to submit a NEPA bill or have someone come to his house to verify his address and use that product. Whenever that happens, it just feels so good and all the stress and everything you pass through to build a product, it just looks like it's worth it.
I think that's the most important part of my job; solving actual user problems.
That makes so much sense why you talk to users two times a week for like three hours now. Awesome; one more question for you. This is also submitted via the chat. So, someone's asking; do you have any ideas that a job seeker could develop into like a slide deck or a pitch to build their portfolio? Or like, what would you need to see in a portfolio to hire somebody as a Product Manager?
I had just once before guided someone… just once before. What did he do?
Okay, so for designers… you see, designers have portfolios and it feels so good. Engineers have portfolios; this is what I've built. For a PM, what I’ve advised people I’ve mentored to do has been; a PM is someone who should have very keen understanding of… there are two ways; you can be a very strong Biz-dev person who is a PM, so all your strength isn't coming up with business cases, right? There’s PM who's very good in doing UX Research, like you're so good in user experience, right? They are technical PMs.
So, I think you should take a product you like—don't take a product that could be too popular so everyone says, “what are you doing?” Everyone has an opinion on Instagram, right? Take a product you like. If you're very good in UX, write it a case study about the product; what are recommendations you would make? Make assumptions of data you don't have; “So, I'm assuming this, I'm assuming that,” so people know you’re assuming, right? And then, you say; this is what I would do, this what I expect. So, make hypothesis, right? If the company does this we expect this to happen and then you assume stuff and then you build case studies.
If you’re a business person—a PM who's like, a super biz guy—you could write business case studies for companies. You could say; oh I've looked at your Market Segment, I've spoken to users. The trends say that your consumers need this product in the next couple of months because I think you could build it and you could send it to those people who you have kept a very good relationship on LinkedIn with or via emails, and you send it to them. And they’re like, “Oh, this guy spent the time. He knows my users more than I do. Maybe we should hire him and he can give us those insights,” because I think the job of a PM is the same job you do when you're looking for a job, right? So I think you should Project Manage that entire process; you should make changes, you should iterate, you should measure it, you should work it and see.
If you have a resume, you send 100 companies that nobody replied; you have one sent to 50 companies and 30 of them replied, you should tell yourself the one you sent 50 companies and 10 percent implied probably is the best resume. If you sent a certain message and no one reply, you should just… the job you do as a PM is the same thing you do when looking for a job. So, just Project Manage that experience. I think that’s my advice there.
Oh my gosh, I love that you said that because I say it all the time. At first, it helps you get experience with PM stuff as you're managing your own life, but also, you need to empathize with the recruiter. Think about what they would want to see. And I think for a portfolio, maybe having a product that you like, showing your passion, having like a unique project will really help.
Awesome. Looks like your advice is really helping people because we're getting lots of people in the chat loving all the insights you're sharing. Let's move on to like, the actual job. So like, the demand, salary, things like that. We have a few questions asking about, you know, how lucrative it is; the salary, is their demand, so do you have any thoughts on that?
The demand for PMS… I think most companies—most tech companies—in their life cycle, need PMs, so you can just to a simple search and check on how many tech companies there are. You could run… take it one step further; tech companies who have been funded and just assigned probably one PM, then we have a very good number.
I think the PM role is probably 20+ years; it's still young. In Africa, it's very young; probably 10+. There are very few PMS above 10 is experience. I think, in Africa, economy is going to be improving, hopefully, companies are starting. We have Lagos now, bubbling Tech Capital. We have Kenya, you have Nairobi bubbling. And so, tech companies would definitely come and there will be engineers and there will be designers, and definitely the people who would be hired as PMs to help manage entire process. So I think, yes, very lucrative.
Looking for salary; she can see me, I look good. That tells you they pay very well.
For the salary thing; how do you negotiate salary as a beginner? If you're landing interviews, like, how do you even approach that conversation?
Interesting. I always tell people that… so, it's… this is privilege talking, but if you do not have a salary band before you get to that stage, I think, probably you've done a poor job yourself. So, I think it's very good early enough to get ranges before the interview goes anywhere because you don’t want to interview and figure out they're going to pay you $500 and you're like, “Oh, this can’t even solve my problems.”
So early enough into the process, try to get the salary range; you should look up companies. So, what I always tell people I mentor is, if EntryLevel wants to hire you, you should check out how many… how much EntryLevel has raised, you should look at companies who are in the same same space with EntryLevel; same probably amount raised, same time they launched, and you should look at people who work in those companies and try to have stuff like a lookout benchmark for how much they pay for that role. One other thing is to just look at companies in the same vicinity. Some companies pay based on location; you could also ask people who work in the same company. Like, the employees give the best reviews; trust me. So, you should just ask people working in the company if they pay well enough; people are mostly truthful enough to tell you, “oh, this company doesn't pay very well”
Also, you should actually recruiter early into the interview process, you want to get that early enough so you know if it's something you should spend time working on. You have too many… once again, think like a PM. You have 10 interviews you're doing; do you want to do 10 different interviews for like a month or you want to filter out the ones that cannot pay you what you need and you do five interviews?
Like, think like a PM.
Okay. Love it… thanks for sharing.
Do you have any tips for getting in touch with the employees of a company? Like, how to make sure they respond to you?
Okay, so step one; look for the company; type a company on LinkedIn. Step two, you go to people on that LinkedIn search, you see people who work in a company. Step three, type the company name on Google, type the email address of certain company, you see the way the domain is; some companies first_name@company_name.co or .com or .net or something, right?
And then, once you do, Google is amazing… Gmail is amazing. If you type email@example.com, if you hover over it, you would see Jennifer and you know this is a valid email address, right? And then you know you're talking to Jennifer. So, that's a very easy way. It takes time, but it's something I think you should spend time doing. A lot of the time, you would have a very high success rate.
That… when you said first_name@company, I felt called out because that's me. But I think it's because I work at a startup; like, EntryLevel has 15 people, so it worked for me but might not work for everyone.
It could be firstname.lastname@example.org. You can always find that taxonomy on Google—definitely, you'd see it on Google—and then, you can just… you have LinkedIn, you have the first name, you have the last name, you keep on trying. But once you get it, you will know you've gotten it on Gmail.
Okay, perfect. Do you have any advice for what to put in that first email?
Frst email… I have something but it take me a while to find.
Most times first move is just to connect with the person, oh you probably congratulate the person on the job, ask them how the job is, you want to know more about what the person does. They… just try to want… care for someone, you don't just meet someone and, “oh, please, could you give me a job?”
Like, try to like, give something fast, and then, the conversation is just going to go from there.
Okay, yes I agree. One more thing is also… try to give a compliment because, who doesn't love compliments? So, maybe you can start with that and then go in with your ask.
Okay, so another question is, what is one thing you wish you started doing earlier?
As a PM?
Yes, as a PM.
And maybe it could be like something you wish you started doing earlier. Like maybe in your job search? So, anything job search or PM-related.
For my main job, what do I wish I started doing earlier? Influencing without authority.
I think the entire job is influencing without any real authority. As a PM, you have no single power at all, but everyone thinks you have some power. I think your job is to be able to influence without any authority. So, I think that's something I wish I learned earlier.
When I first started, I thought Engineers were my subordinates and I could tell them, “you do this.” I was the General, I could command people. And then, a few weeks into the job, you figure out the engineers have all the powers… and so, I think you should learn how to influence people without authority, you should learn how to talk to users; I wish I'd learned that, sincerely enough. Well, yeah.
Do you have any tips on how you learn like influence and persuasion skills?
There’s a book on influencing people and win friends. Give me a sec, I think… it's very popular, but I think in the community in France and Wessex.
Yeah, I've heard of that book, but I've never read it because I thought it was just like, not that useful, but did you find it useful in your career?
Yeah, and really really good. I think, for books that I would tell upcoming PMs to read, there's Higher Output Management by Andrew Grove, there's also this book—I’m trying to remember the name—Influence and Win Friends or something.
Oh I found it. It was, “How to Win Friends and Influence People”?
Yes, by Dale Carnegie. How to Win Friends and Influence People; perfect book, you should read it as a PM. But the first book you should read as a PM is High Output Management by Andy Grove; best book for people want to go into product management.
High Output Management book?
I'm going to link that in our website after this event ends because we always put the event stuff on our website. Perfect, thanks for sharing.
Okay, so we just have one more question. This one is about remote jobs. So, any tips on… okay, let me just go back to the question; “so can you speak more about getting a foreign internships?” was the question.
Um… foreign internships. I think we talked about this…
Like, how how did you get… oh sorry, go ahead.
I think you talked about this earlier.
Look for people on LinkedIn who work in those companies. If they hire Nigerians who are probably in Nigeria or Africa or they hire people in New Zealand; if they hire people from your country, chances are that they will hire more people from that country, right? Also, look at people who have worked there, people who on their LinkedIn put Intern, Associates, you can tell if the company does that. Also, talk to people who work at the company.
I think once you do your preliminary search, you would figure out companies who hire interns. And then, from there, I think it's just the same thing to find the job. You have to do…
Oh, okay. I think that's a new insight because, like when you're looking for employees from the company, you want to work with, try to find similarities especially if you're from the same country, if you went to the same school, or like if you stalk their profile and you see they're interested in a hobby that you also into, like maybe, you can use that and make sure to like leave a connection note on LinkedIn with that fact.
Awesome, so don't worry if you missed anything today because this entire session was recorded. It's on our YouTube. I will also email it out; all the resources I've copy-pasted and it's going to be on our website, so everything will be emailed to you. So, if you lost connection, don't worry about missing anything because I will be sending everything out to you.
Okay, I think we can close off the event now. Do you want me to screen share again, Douglas, or…?
Yes. Can have a screen share?
Okay I have a screen share and then, you can talk about all the links that you have. I hope you have learned something here today. If you want to talk to me, you are a PM; I try to talk to people every day, so that's my Calendly link; you can book and you can have a 30-minute session with me.
If you want to follow me Twitter—I’vel stopped tweeting; I lost my old account—that's my Twitter link. If you want to read when I write a medium, that's linked to my Medium as well. And if you want to connect me at LinkedIn, that's the link to my LinkedIn as well.
Awesome, I think another thing that is so underrated when you're breaking in is following people who are already there because, like, you want to surround yourself with people you want to be and Tech Twitter is just so good for that community. Be sure to follow EntryLevel on Twitter too.
And also join products communities too; there’s people in Product; Treford has a slight group if not mistaken; there’s non-tech in tech, find communities. I think people—some people—learn a lot better by being in communities. So I think, if that works for you, you can also try that.
Perfect, so if you have any more questions that weren't addressed, you can use the links above. If you have a specific question that's like, for you, your personal situation, you can use the Calendly Link and talk to Douglas like one-on-one and then, also connect on LinkedIn.
So, thank you so much everyone for being here, and thank you, Douglas, for being such an amazing panelist. Maybe I'll see you all at the next event. Thanks, everyone.
Good morning. Good night.
Make 2023 the year you become a Product Manager.
Learn what Product Managers do day-to-day in a real-world environment. You will get the opportunity to ask questions to figure out whether Product Management is the career for you.
Product managers are one of the most highly-priced and sought-after worldwide. But often, the role is not well defined, so aspiring PMs looking to transition into the role often have difficulty in knowing where to start.
Pick 1 learning resource, like EntryLevel (it should not cost a lot)
Get any job, internship you can - you can work your way up to the role
Might be easier if you get a job in tech first (the role or title doesn't matter when you're trying to break in).
Leverage your previous experience (linked example for UX designers).
Depends on your situation, but in Africa there are very few big companies. It's mostly startups, and you can learn a lot. It might be easier to get a job at a startup too - but things move fast.
Sometimes, it's just a numbers game.
Some companies take interns - do your research well.
Can send mail to employees to build relationship and ask questions.
Look for employees with similarities like the same country, school, hobbies, etc.
Douglas does both in his day-to-day job, but it depends on the company and your specific role.
2 phases of product management: discovery and delivery.
Morning: look at comments, go on Slack, check messages
Late morning-early afternoon: talk to users for 1 hour - twice a week
Afternoon: talk to data analysts for insights
Late afternoon: go to Miro and summarize insights from users. Share with designers
Late afternoon: reviewing designs, wireframes
End fo work day: backlog, email, team, plan next day
Hack: go to a shopping mall, where you can find people who have time
Take product/app and talk to them
Douglas has a dev environment set up and makes changes on the fly - get better insights
As a designer or PM, don’t need to know, but you should know enough. Check out the article below about knowing enough to call BS:
Knowing enough can also allow you to ask more insightful questions.
As a PM, you're the CEO of saying no.
It's very top-down - have a goal, strategy comes from that, metrics, what to work on.
You can apply this to your job search and personal development - have a goal for your career, create a strategy, set metrics, and work on the tasks. If something doesn't align with your goal, say no.
Data: qualitative and quantitative
Coda (like Notion)
Google Docs, Forms
There were many other tools mentioned - check video recording for full details.
A document of all requirements.
Create a PRD format you’ll actually use.
2 sections needed (that should be in every PRD but aren't):
This keeps you in the habit of updating your PRD.
Douglas works completely remotely - the company has employees in 6 countries.
1 thing that worked is having 1 central work calendar so you can see everyone's availabilities - even when traveling.
Talking to users - feels so good.
Especially when you get to show the developers and designers the impact their work had - it makes the stress worth it.
You're actually solving a user problem.
Take a product you like and an industry you'd want to work in (edtech, healthcare, finance, etc.).
Project manage your job search.
Make changes, measure, set metrics, etc.
Depends on the company. The PM role is still young - especially in Africa.
In Africa, the economy is (hopefully) improving, tech companies will definitely come and people will be hired.
Get ranges before interview goes anywhere - don't waste your time. Ask a recruiter early on.
Checked how much the company has raised.
Look at similar companies and people working there - how much are they paid?
Can ask people working at that company - employees give best reviews.
Think like PM - do "user interviews" (talking to employees at the company, recruiters, etc.)
Step 1: look for the company on LinkedIn
Step 2: find the people who work at that company on LinkedIn (names)
Step 3: type company name on Google and find their email address (or you can also send LinkedIn connection with a note)
What to write in email:
A customized compliment about their work at the company or their hobbies (after stalking their LinkedIn)
Ask specific questions you have about how the job is
Learning persuasion, influencing authority, and talking to users. Very useful skills in the workforce.
Books recommended: High Output Management and How to Win Friends and Influence People.
Book a one-on-one call: https://calendly.com/idamezhim/get-in-touch?month=2023-01
How to know enough code to call BS
New Year's Resolutions - tracking your goals like a PM
Time travel to reach your career goals
How to Win Friends and Influence People
Free mentorship: https://adplist.org?ref=ADP-EN-BYM20
Douglas Franklin is currently the product lead at OkHi.
In the past, he was formerly a product manager at PerDiem and spent time at OurEdenLife, Deimos, Crisp, and more.