8 Lessons Learned in My First 3 Years in Product Management

Four years ago, I took my bachelor’s degree in Journalism and Spanish to its natural next step — a support role at a software company. I liked the fast pace and culture, but didn’t know if there would be a home for me in tech. And then I got my first product manager role. I couldn’t believe a role like that existed — as I understood it then, I would basically be responsible for talking to people and making decisions. Sign me up! Of course, it’s been a bit more complicated than that. I’ve learned a lot since then, and met with dozens of people trying to start their product careers. Here are my biggest lessons learned so far.

1. Build your product network.
   This was key to my survival in product. I didn’t have a product mentor at my first company, so reading and networking were how I learned, and that network has helped me over and over to sort through hard problems. Start with someone at a company you admire, and ask every person you have coffee with to introduce you to one more person that would be good for you to know. Remember that everyone’s time is valuable, so come prepared with questions. Looking into online communities such as Women in Product and your local ProductTank meetup can be a great place to start.
2. Be an expert in user interviews.
   Interviewing users is hard work, and it takes practice to get valuable insights. Even if this isn’t part of your job description, you should be talking to users to understand their world and their problems. The principles behind great user interviews should shape the way you talk to users to make sure you’re using that time efficiently and not biasing your results. Be consistent in your technique and always ask for feedback from your product colleagues. I started with reading Interviewing Users by Steve Portigal. My favorite takeaway: be comfortable with silence. People give you their best answers after they have time to think.
3. Collaborate at every step in the development process.
   I learned the hard way that it’s still possible to waterfall in an Agile / Scrum framework. Even if the actual development is agile, you can waterfall from the executive team to the product manager, from the product manager to the designer, from the designer to the engineers. A process like story mapping at the beginning of a project can help get everyone on the same page before every decision has been made. I’ve also become less rigorous in my story writing — instead of prescribing every detail of a solution, I might say, the problem to be solved is letting users manipulate the date range on this page. Here are a couple of potential solutions. What does the team think? Work through it together, and stay involved throughout the sprint.
   Another way to foster collaboration is to involve design and engineering early. Engineers are smart (duh), and they often want to be involved in the ideating, not just handed a brief of exactly what to build. Another practice we implemented is a biweekly meeting called Chew on This. We bring a very early idea to the table and brainstorm with whoever is interested. Everyone gets more invested in the problem, our solutions are better, and we don’t get too far down a path before identifying technical hurdles.
4. Values, vision, and strategy are everything.
   When we were having trouble getting useful and timely design feedback, we put together a design heuristics workshop to get on the same page about our design values. Having a shared language and understanding of our design priorities helped us get the right feedback on design at the right time, and informed important tradeoffs.
   Similarly, if your team doesn’t understand the vision for what your product is (or even more importantly, what it isn’t), it will be difficult to make decisions about what to build next. I find the Jobs to be Done framework especially helpful for starting these conversations. If you don’t have a good sense of your product’s vision or strategy, speak up! It’s likely that others don’t understand, either.
5. Pick up a side hustle.
   Every quarter, I try to see a need in the business or product org and make some time for it. Some of these include the Chew on This meeting I mentioned earlier, conducting the Superhuman Product/Market Fit survey, and creating a company-wide roadmap. These are great experiences outside of your daily responsibilities that will sharpen your skills and make you more valuable to the business. Everybody wins. Picking up a product-adjacent side hustle could also be a way in the product door from another department.
6. Think about what you need out of the next 1–2 years of your career.
   It’s hard to forecast 5 years out, no matter how often you may be asked to in interviews. Someone once told me to think instead about what you need most out of the next 1–2 years, and go after that. When I moved to my current role at Springbuk, it was because what I needed most was mentorship in product. You might be looking to fill in an area of expertise, or jump from product owner to product manager. Once you identify this one thing, you can make decisions and set goals based on that ambition.
7. You’re doing a million things. Know what they are.
   I have never had a moment in product where I wasn’t juggling many responsibilities. It’s easy to lose track of what’s important or what you need to do to make progress that way. Regularly take stock of how you’re spending your time, and share that with your manager. Make sure their idea of where you’re needed most lines up with your reality, and be aware of how you’re balancing the urgent with the important.
8. Be 100% honest and 100% kind.
   This is a golden nugget from Crucial Conversations, the book that has influenced me more than any other as a product manager. Product is wrought with conflict. There will always be someone — many someones, probably — let down by your decisions. They won’t always be empathetic to the demands and considerations of prioritizing problems. It will be tempting to be angry with them, to speak poorly of them. It will be hard to lead with influence but not authority. I tell myself at least weekly that it is always possible for me to be 100% honest and 100% kind. I won’t always succeed, but it’s my north star for how I treat people.

Product management is a big job. There’s no such thing as busy work, no such thing as turning off your brain for the day. The impact you have goes all the way from the engineers you work with every day to the users you’re here to serve. This work matters, and there will always be more to learn by doing it. What are the biggest lessons you have learned in your product career?