4 key lessons I've learned to become a better product manager

I did not begin my career as a product manager (PM). I worked in digital marketing for a while after graduating. But it was through learning UX that I discovered product management and have never looked back since. I wish I had reflected on and documented down more of my learnings. Even though I made a good list, they are mostly mistakes (lessons, if you will) that I want to remember so that I don't make the same mistakes again in the future. There wasn't a system in place to keep track of my notes. Honestly, I just scribbled down whatever I remembered from the day. I categorised them and came up with the following top lessons. These three years as a product person have taught me a lot, but I'm still learning and growing to become a better product manager. There is still SO much to discover. Without further ado, here are some of the most important lessons I've learned as a product manager. Feel free to pick a section from the table of contents.

1) Product management > project management 2) Be more product-centric a. Walk in your user's shoes b. Walk through the existing design flow c. Customer interviews 3) Planning and prioritising a. List out all the experiences you set out to do b. Scope and descope the experience c. Design and descope the experience 4) What would you do if you were 100% confident?5) Other brief lessons Supporting documentation Don't forget to prototype your designs if you can Pivoting your main target audience - yes or no?

1) Product management > project management

My apparent superpower is that I'm organised, detail-oriented and good at getting things done. It's great to make sure the sprints run smoothly and efficiently. Project management is part of product management, but it should not take up the majority of the time. But in my (poor) defence, it's especially prominent when things are hectic at work and I needed to act quickly. I get blindsided and go into project management mode, i.e. getting things in place and done. It's easy to fall into this mindset but if you're in a PM role, you got to be thinking like one — think about how to improve the product. If someone approaches you and inquires about a customer's request, take some time off to understand the problem and if possible, offer a workaround or a potential solution. What I used to do was acknowledge the problem and inform the team that it couldn't be done at the time but I didn't ask additional questions to better understand them nor did I offer any other potential solutions. I didn't do that because I needed to figure out what was wrong, look for any workarounds, or come up with a solution — all of which takes time especially if there are a lot of requests or questions. That, however, is still not an excuse. Not putting your product thinking hat on is not befitting of a product person. Yes, there's work to be done, but prioritise what is most important. If it's difficult, ask for help from your manager or boss regarding your priorities. Make a suggestion, and ask for feedback from them. If there is a lot of work, consider what type of work you are doing and whether you should delegate some of it to someone else? Identify it with your manager early on, and see what can be delegated over. It does not imply that you are delegating everything to someone else. I'm still involved in the project management work, but not as much as I used to.

2) Be more product-centric

With more experience, I'm getting better at engaging questions more earnestly, i.e. asking more questions to dig deeper into the problem and offering more thoughtful responses, rather than just making offhanded remarks. We have a channel where we receive a lot of customer feedback, sometimes to the point where it gets too overwhelming. I would make quick remarks instead of devoting more time to comprehending the questions. Now I try to slow down and set aside some time within a specific timeframe to go through them. When we provide our feedback about the product, other stakeholders may have a different opinion which may affect their work. However, as PMs, we should do our best to find the best compromise. Take a stand and make a decision. Mistakes are unavoidable, but that's how you learn. Here are a few tips that I learned that could help hone your product thinking:

a. Walk in your user's shoes

How do we know what's a good decision? One thing you can do is put yourself in the shoes of your users — who they are, what do they do for their jobs, how big is their team etc. Then talk through the entire path (or flow) in a specific scenario as if you're your user. That's why a user story is important. For example, let's say I'm a user and I'd like to sign in. I click sign in button. Nothing happens or maybe an error occurs. What should I do? I could see a help button, or I see a forget password button. I could pick either one and give it a shot. That may not have been the best example, but you get the idea. Talking through a scenario step by step might reveal inconsistencies if something doesn't sound right or something is missing.

b. Walk through the existing design flow

You have a new design and you're wondering if it flows better than your existing design. If something doesn't sound right, for example if the existing design is more user-friendly than the new design, going back to the existing flow on the existing app might help. Talk it through as you go through the existing steps vs the new steps. It may be easier for you to identify what's missing (what makes the new design better or worse) and it can be clearer for others who are in the discussion with you as well, so they understand your thought process behind it.

c. Customer interviews

The best way is to talk to your customers. At the end of the day, they are be the ones who will use your product and our job is to turn the insights we gain from them into a good product experience for them. When speaking with customers, don't just ask about their problems. Get to know their businesses and what their use cases are — find out what they do on a daily basis for their job. How do they start their day? How big is their team and how do they use their product? It's best to observe or, at the very least, have them talk through their day to day process while asking questions in between to get a better idea of what they're trying to find. Don't consider yourself as intruding — as long as you're asking relevant questions, your customers should be fine with the questions. Then you might be able to suggest some solutions or workarounds. Remember not to take your customer's suggestions or requests for specific features at face value. Even if it appears to be a new request, it is not always the case. A better approach would be to ask them what problem are they attempting to solve. They'll talk about their problems and from there, you should be able to tell if it's what they're looking for. Most of the time, it's possible to solve it with a workaround in your current product or it may already exist but in the form of another feature. In that case, you might want to look into it as a messaging issue.

🔖

Read The Mom Test. It's probably The Book to learn how to talk to your customers. Check out a quick summary of it here.

3) Planning and prioritising

Is it really an MVP if the MVP is planned out but still requires more descoping and cutting things from the roadmap? It's fine if there are minor changes that we can make, but in our case, we did not descope enough for our MVP. If I could go back in time, this might be what I would have done differently:

a. List out all the experiences you set out to do

Make a list them and have a rough idea of each experience entails. This could be something like:

Signup and onboarding experience

Team settings experience

Dashboard experience

Your core product experience and so on

Start by prioritising which experiences to work on first, and ideally it should be your core product experiences first. We made the mistake of starting with the signup/onboarding and settings experiences first. It wasn't the best strategy because:

We didn't yet have a good understanding of what the core experiences would entail yet.

We had to revisit the signup and settings experience frequently and revise based on the new insights we gained from the core experiences, which we only designed later on. Even then, there were some things that were still overlooked as a result of the back and forth.

b. Scope and descope the experience

Make a list of features by breaking down each experience. Scope out what can be done out within the timeline given. Find the essential features and plan them into the initial release first. The remainder can be descoped and scheduled for later phases. If the features aren't integral to the product, we can always remove them and save them for a future release. As we gain more customers, we will be able to build and release those features as we go along. Take Instagram, for example. Instagram has a lot of features that you can use now, but they didn't release them all at once. Their main feature is that you can take photos and post them on your profile. You don't need videos, bookmarks or even stories just yet etc. You can work on them in the following stages. Release in stages. This is the gist of it. Just make sure you communicated this to your team and other stakeholders.

c. Design and descope the experience

Even if we already have a scope, that doesn't mean we should be restrictive of the designs. Always give the best ideas and designs while keeping the best interests of the product in mind first. Don't think or worry about how or how long it might take to implement something just yet. When we brief the developers on the designs, that's when we can begin to descope further based on the design and cut out what's unnecessary if the implementation itself is complicated or takes up too much time. This is the time to go over each design aspect with the designers so that you fully understand it. In our case, we didn't say no very often in the design stage, and many questions were raised during the documentation and even the development stage. It's okay to say no to things for the time being. Descope and divide them into several different phases. Prioritise the most critical paths. When that's complete, you can proceed to documenting specifications for the developers to implement next. Also, make sure you talk to your designers and give them feedback too!

4) What would you do if you were 100% confident?

It was prominent at first. My impostor syndrome was almost always lurking behind me, but I did my best. But If only I had been more vocal, if I had been loud enough, if I had been consistent enough to bring things up — which I wasn't, not in the beginning. For example, I could have planned and suggested better alternatives such as moving features out of the scope especially given the tight timeline, but I didn't want to appear uncooperative. Or when I know the timeline for delivering something is unrealistic, even with the MVP. One thing that helped jump start my confidence was asking myself, "What would I do if I were 100% confident right now?" or what would I do in that situation if I was the person I admire? This question pushed me to do more and be more assertive. With more practice, I got a little bit better each time. If you're addressing a topic on which your team might disagree, prepare your justifications and stick to your guns. Most importantly, it's okay to make mistakes (at least you got your point across and you can bring it up later again if what you said turned out to be true 😄). Learn and use them as lessons to remember. My imposter syndrome held me back from accomplishing and learning more than I could. But I gradually overcome my fear of sounding stupid to speak up more and ask more questions. I'm able to guide the team with a renewed confidence. I still have my doubts, but I'm better than where I was before, especially getting to know my team better. Even if you're an individual contributor who doesn't directly manage a team, your team will still look to you for support — whether it's with specs, requirements, or even making product decisions. Do what is best for your team and work together to create the best product possible for your customers.

5) Other brief lessons

Supporting documentation

We know that documentation is important, but good documentation is underrated. What I mean by good is not only having complete specifications that people can refer to but also having it structured in a way that's more readable and digestible manner — include more tables (and emojis), for example! And keep it concise. I wish I could have written my previous ones a lot better, but I know better now.

Don't forget to prototype your designs if you can

Another thing that is underrated is prototyping. This is important because it allows us to test how the design flows rather than just looking at the designs one at a time. We can easily identify usability issues that would otherwise go undetected until the app or feature is completely built. In fact, if you're using Figma, you can download and use Figma Mirror to mirror your prototype to your phone. You can use the prototype directly on your phone just like you would if you were testing the experience on an app. Also, a reminder to go over each design as thoroughly as you possibly can. Even though it appears to look cool, some of the features aren't critical for the first release and can be dropped for the time being.

Pivoting your main target audience - yes or no?

What if you get more enterprise users than you anticipated? Especially since your marketing website has a new design. The bad news is that you aren't yet ready for enterprise users because your current design is geared toward small to medium-sized businesses, not businesses with over a hundred or thousands of users. An example is a lack of a search function for a list of items that a user may rarely use. However, for enterprise users, the situation might be different. Should you have planned ahead of time to cater for the enterprise users before beginning the design? Or is it acceptable to easily make a pivot this big after the release? There may not be a right or wrong answer to this question. But personally, I'm not sure. It might be strange to end it with an open question, but it's something for me to think about. If you do have a say here (or in any area), happy to accept any opinions and feedback!