Growing as a Product Manager: Working with a Product Team

Anesii
5 min readNov 28, 2020

--

A product team may consist of developers, designer, marketers, a product owner, and pretty much any stakeholder playing a role to bring a product to life.

As a budding product manager, one way to grow your skills is to put what you have learned into practice. That’s how to succeed in any field! You have read books, listened to podcasts, watched tons of videos and taken a course or two or more! While that’s great, what’s more significant is a product, an actual working product.

As a product manager, it’s not so complicated building a product yourself.

This product doesn’t have to be the next Facebook or YouTube. It could be something straightforward like a to-do list or a fun app. Now that you have an idea of what you want to do, the next thing is to carry out research. There is a huge possibility that something similar to your idea already exists so you could draw some data from existing products, try to see what you can do different or improve. You can also ask people what they would love to see, this can be done through surveys or polls or face-to-face interactions, whatever works for you, but you want enough data for this. When you have all the necessary data, you want to design your app. You can use wireframes to see how you want the basic layout to look like, and if you can translate to user-friendly UI or develop it, you can go ahead and do that. But if you can’t, you’ll want a designer or developer friend to help with this.

For my first ever product, I got to work with a team of developers and designers — two developers and a designer actually. There were definitely a lot of mistakes I made, and I have learned from this experience. I’ll be sharing some of the things I’ve learned, and while there is still a lot to learn, I believe this would help an aspiring product manager looking to work with developers and designers for the first time. Before I go on, I would like to say I have been involved in frontend development and UI/UX previously, so they have helped my interaction and understanding of certain things. So, let’s shoot!

When building a product, here’s what you want to do:

1. Research. Research. Research. Once you have an idea of the product you want to build, you want to research similar products. If it’s a completely new idea, that is, something that has not existed before, you would want to research your potential market and see how they would react to this. This survey can be carried out with a small number of people.

2. Secondly, you want to hold a meeting with your product team (psst! You’re going to be having a whole lot of meetings as a PM, but don’t worry, you’ll get used to them…I guess). So yes, you have to meet with the team and communicate your idea and findings. You basically want your teammates to really understand what you’re trying to pass across.

3. After that, the UX researcher on the team would help to carry out more research pertaining to the user experience on the product. If there isn’t one, you might want to wear the shoes of a UX researcher. If you’re working with marketers, they can also help to research your potential market/customers and the business aspect.

4. All this research should help to properly define your product features. Here comes another meeting! J In this meeting, your developers would help to determine the important features needed to build a Minimum Viable Product (MVP). Note that an MVP isn’t a prototype but a fully working product that can be launched into the market — call it version 1.0.

5. Now that that’s done, you can write your PRD which guides your team throughout the process. This PRD also keeps your stakeholders in the loop and lets them know your plan for the product (I have discussed how to write a PRD in my previous article).

6. You also want to draw out your product roadmap. A roadmap guides the team on what should be accomplished per time, and it contains a list of prioritized features. Meaning the most important features should be worked on first. This can be determined with the help of your developers. Also, note that a roadmap should not be drawn alone, your developers are in the best position to tell you how long it would take to implement a feature.

7. While your team builds the product, your role changes again. Now you act as the mouthpiece of each team within your product team, especially if they can’t get to each other. You want to tell the developers how designs should be implemented, tell designers to change a design that’s too complex, and stuff like that. You also want to check your team’s progress, see if you can help when there are hindrances and overall ensure everyone is happy. A happy team makes a happy and working product (I came up with that lol).

8. When you have a working product, the next step is to test. There are various ways different companies do this. For example, employees can use the product by themselves to see if it works as should. There’s also A/B testing where you test with beta users to see if they’re doing what you intended them to do while you were designing the product. Let me rephrase, so when designing a product, you envision your users would use it a certain way — A. Now that it’s built, and the users get to use it, you want to see if they’re using it just as you envisioned — B. I hope that’s clear?

9. After tests are done, and necessary corrections made, if any, it’s time to launch! I’m launching my first product soon so I can’t really say much about this, but I guess this is where marketers come in if there’s a business aspect to your product. My product has no business aspect, not now at least. It’s a learning management system, and I’ll be talking about it in my portfolio which is going live pretty soon! I’ll talk about launching then.

So, there you have it! This is what I have learned/experienced so far, and I really hope it helps someone out there. I’m here cheering you on and rooting for you! Go build that amazing product. You rock!

Anesii.

--

--

Anesii

The Life and Times of a Young Adulting Product Manager. I share what I've learned, not necessarily lessons to live by.