I’ve been working in product management for a bit over a year now and I can hardly believe it sometimes. I set out to be a UX researcher after spending over 15 years as a paralegal. And by luck and happenstance, I’ve found myself in product management.
Funny story — I had actually applied for a UX role with my current (contract) employer. They didn’t think I was a good fit for that, but they were impressed enough by my UX research skills that they offered me a contract as a Business Analyst.
That Business Analyst role was just the beginning. A ridiculous number of reorganizations, one promotion, and a few contract extensions later, I’ve gathered a significant amount of experience in product management. I know you just rolled your eyes at that, because I just said that I have a little over a year of experience. To that I say: it’s been a turbo-charged year in a very fast-paced organization. My 1 year of work there feels like 4.
At the risk of sounding like an infomercial, I want to share with current and aspiring product managers what I learned as well as what I did to be successful in my first year in Product.
A little about me: I develop enterprise tools for managing digital media assets. My first project as a Business Analyst focused on an order management system for content. It was a small product with a group outside of the company’s larger product organization. The product had been around for a while and we were trying to increase the number of users. A reorganization landed me in the larger product organization with a brand new boss and eventually a brand new project. This new project was very high-stakes. Lots of executives with eyes on it and millions invested in it. This project also involved working with a vendor which was quite a unique experience. Lots of personalities, processes, JIRA boards, and sprint rituals to observe. It was during this particular project that I was promoted to Product Manager. Eventually, the company ended this project because they felt that the third party tool wasn’t the right fit and they didn’t want to sink any more money into it.
Now I’m working in building a new front-end for our bespoke Content Management System…from scratch. Yeah, you read that right. How a noob like me became a Product Manager on this project, I have no idea. Well…l have some idea 😉.
Short and unhelpful answer: working hard and stepping up. Nuanced answer: finding that balance between believing in your own skills and learning everything that you can from the most knowledgeable and capable people in your organization. And here’s the more complicated (but helpful!) answer:
- Knowing my stakeholders and users.
This is at the top of my list because undoubtedly, this has been the biggest reason for my success in product management. I’ve already racked up so many instances where the knowledge of my user has made an incredible difference in what we built, how we built it, and how it was received by stakeholders.
I work on enterprise products, but our internal users/stakeholders still have a say in what products they use. So in that respect, we still essentially have to market our product to the stakeholders. Our users typically report to major stakeholders. Happy users + happy stakeholders = my product continues to grow and I continue to be employed.
Hand in hand with this, is developing a relationship with your stakeholders. As I moved from project to project, with the same or similar stakeholders/user, they were happy to see me. And I’ll tell you why. For one, I’d spent a lot of time with them to understand how they work, ask them questions, and really create a tool they needed/wanted. But even more importantly, I actually showed them that I heard them by building features that were valuable and usable. I also resolved issues they complained about. For instance, on my first project with the company, the product had several features that users complained had been complaining about since the product was created. Within about 3–4 months of joining, those features were gone or buried in the system and replaced with something useful. I literally had users email me and thank me. And resolving those issues made it possible for us to increase the number of users we had.
Knowing my stakeholders and users and having a deep understanding of their pain points and needs, as well as the ‘whys’ associated with those pain points and needs definitely pays off.
2. Diligent yet flexible process management
Ask yourself this: How can I foster engagement in the project from the entire scrum team, while maximizing the time that is spent on efficient development of the product? For me the answer is strong processes which include structuring how tickets are written, productive backlog refinement and grooming sessions, knowing how to engage engineering in the design process, and effectively conveying requirements to engineering.
I pretty much conduct observational UX research on my scrum team every time I engage with them. This has been critical for me. I’m able to continually find gaps and weaknesses, and work to correct them. In doing this, I’m also showing my team that as a product manager, I hear them, I see them, I am paying attention. It builds trust. And like I said above, processes are not one size fits all. You need to understand the personalities, behaviors, attitudes, cultures, and work ethic of the folks on your specific scrum team. Then develop processes taking those factors into great consideration. I’ve had 3 different products so far with a different scrum team and processes each time.
Sound processes are important, but know that they are not one size fits all. It’s really important to continually re-evaluate processes and improve them. Like, week to week. If you’re in a strong agile environment — take the retros seriously. Those are great places to see the weaknesses in the team’s processes. You can look for patterns in what others are saying, and also critique yourself. What could you have done better this past sprint?
I also think of story points as currency. My sprint rituals, processes, sharing of requirements, and shipment of designs help me maximize my ROI in terms of sprint points. Too many meetings? You’re paying for them with sprint points. Leaving your meetings with engineering with more questions than answers? You just burned some sprint points. Bad requirements in your tickets? A huge waste of story points and your credibility as a product manager.
3. Know the tech behind your product
Possibly unpopular opinion: I think product managers should have some level of knowledge of the technology that powers their product. There, I said it. Can you get by without it? Yes. Do I think managing a product would be more painful without this knowledge? Yes.
Now I’m not saying you need to know how to code. But you should know the architecture. How does the product work and what are the limitations of the technology? Having some knowledge leads to much smoother and more productive engineering discussions. And again, it shows that you are engaged and invested in the engineering team, and increases your credibility as a product manager. Not to mention, people are more willing to follow and work with someone who they view as knowledgeable. It also levels the playing field in terms of advocating for features for users; you can discuss the merits of a feature with full understanding of the engineering effort involved, and thereby be an active participant in developing a solution for the delivery of a particular feature.
4. Design and engineering are your partners — treat them as such and never forget it.
You may have already gleaned this from the tips I gave above, but it bears repeating. Your scrum team — comprised of design, product, and engineering — should operate as a partnership, with product in the middle to facilitate the flow of work and structure, as well as creating effective working relationships. Let’s dive into what that means.
I see two main components when I am looking at the product, design, and engineering partnership. One is functional and one is psychological/emotional. Functional goes back to point 2: Effective process management. You need structured processes, agreed to by both you and the relevant party (design or engineering). Yes, I went into a little legalese because your processes really should be like a contract where the terms have been set and negotiated by both parties. And by negotiation I mean a conversation about expectations and methodologies that make up your processes, and coming to a general consensus on how your functional relationship should work.
The psychological/emotional part deals with creating a safe, cohesive team environment driven by a growth mindset. This connection with the team happens on a deeper level. It’s crossing the gulf between people being assigned to work on a project with you and them being excited about working with you and sharing a similar enthusiasm for the product goals and vision.This means way more invested design and engineering teams, better collaboration, unabashed sharing of ideas, and working together to solve problems. It means epic levels of synergy.
Now there are many ways to achieve this level of camaraderie; it simply requires that you pay attention to the humans on your team. Kinda like UX research, with the goal of understanding the goals, behaviors, pain points, and needs of your colleagues. For example, the current team I’m working with complained that they didn’t get enough requirements and information was frequently left out of tickets. In response, I templatized our JIRA tickets based on the questions that I heard the most from them. I recognized that the engineers already had a group dynamic and mentality all their own, and that group had already made up its mind on what information it wanted (we’re talking like 10+ engineers here). So rather than fight against that with some ticket template I had in mind or was used to, I just listened to the team, and let them drive the creation of the template. So far, it has greatly improved communication between product and engineering, and made our refinement sessions smoother. The team has also expressed gratitude.
A second example; I know the backend team is really passionate about the system architecture and database (as they should be). They’re also really experienced engineers who know what they’re doing. I happen to be really curious and interested in system architecture and databases. I let my curiosity come through in all of our conversations. Not only does this show empathy and interest in what they do, it makes me an ally who can have a fruitful conversation and make an informed decision.
These are just a couple of ways that I was able to build synergy and trust within the team. They all stem from paying attention to my colleagues.
5. Make plans for features and actually plan them out from start to finish — and then loosely have a plan B and a plan C because something out of your control will likely ruin plan A.
I think this one speaks for itself. In our organization, goals and plans from senior leadership change right quick, real quick. Also from stakeholders too. Don’t get caught off guard because you didn’t plan. I work in a space where agile is really: “do you know your stuff well enough that you can pivot on a dime?” Also: “Can you achieve a new random goal with little to no notice?” Always have a plan, but also know when your plan is going up in flames so you can pivot to your back up plan. Or be ready to scrap everything just because the most important thing this week will not matter at all next week.
Now also, I will say that I don’t think the folks who are OGs in our product team have to have so many back up plans. They might just be able to pivot on the spot. However I, as a newbie product manager, plan ahead and have back-up plans to safeguard against unknown unknowns. I expect (more like pray) that I won’t have to have so many plans as I get more experience. This connects perfectly to…
6. Understand organizational agility, your [psychological] agility as a person, and agile as a process.
I work in an organization that changes rapidly. Like, really really rapidly. I’ve already survived a ridiculous number of re-orgs. And we very strictly follow the agile process. Very. Strictly. We even do a quarterly planning exercise where you (product manager and owner) are expected to plan an entire quarter of sprints before the quarter has started. Yes, really. And since the organization is also agile in the true definition of the word, unknown unknowns usually make themselves known a few days after quarterly planning in completed. So all your quarterly planning becomes trash. I’ve been at the company for 18 months. This has been true for every single quarterly planning.
That last paragraph makes it seem like I have a negative opinion about how my current organization uses the agile process. Quite the opposite. Knowing where the organization stands in terms of agile methodology informs how I manage building the product and the scrum team (in as much as any product manager manages the scrum team — which is not on paper but in practice).
There are huge asks of the product teams in my organization. Adhering to the agile process helps me understand what I can deliver and what I cannot. It also helps me get ahead of my work, and plan features pretty far in advance. I even plan my sprints way in advance given the chance. Having a good grasp on our work and what we can actually deliver also makes me able to respond to sudden changes from executive leadership. At the drop of a hat, I can push the team in another direction because by being ahead of the work, I’ve actually had time to think about and plan for “what-ifs.” And lastly, knowing what is possible to deliver and understanding the risks that impact delivery, allows me to socialize this with key stakeholders or leadership very early. And that allows us to make changes to what we want to deliver in a truly agile fashion. As long as you don’t come in at the last minute raising a bunch of previously unknown issues, the organization can typically work together to refactor the initial delivery plan.
7. Make sure that your partners (engineering and design) are behind your product. If they’re not, take initiative to get them there.
“ I would love to have an engineer or designer on my scrum team who thinks the product we’re working on is garbage and will never succeed.” — said no product manager ever. You need to look out for this kind of attitude on the team. And if you find it, address it. I can tell you from past experience and old wives tales that one bad apple spoils the bunch. It only takes one person on the team with something persistently negative to say, to bring down the whole team. But also be aware: the culprit may not know that they’re doing it. In my younger years, I have been that person on the team with negative things to say, not realizing that people were actually taking in and feeding off that negativity.
Dealing with these personalities doesn’t have to be confrontational. I’ve been able to boost morale and engagement (and thereby enthusiasm for the product) simply by generating a high-energy, enthusiasm-filled approach to product management, and sharing the product vision with the team effectively. I also show the team lots of empathy and quite frankly — I’ve shown them that I’m not an idiot. Let me explain that last one. No one will follow you if they think you don’t know what you’re doing/talking about.
Presenting the product vision, roadmap, and answering the teams’ “whys” have all been opportunities to show that I, as the product manager, have a clear understanding of the vision and goals for the product. I’m fairly certain that before I presented that information to the team, engineering thought that we in product were absolute naive fools. They did not agree with the approach to development. But once we could explain all the factors that went into the decisions that were made, they realized that we had actually given the plan careful thought. And now engineering has ideas on how to develop the product faster. See the shift? From engineer assigned to a product, to ally in product delivery.
8. Conduct user research
It seems obvious, but now being part of a large product organization, I see how easily this crucial step of product development just falls off. And several times a week there’s some question or problem that could easily be solved if someone knew what the user wanted, needed, or hated. Most of the time, I know the answer because I had the luxury of conducting lots of research before I started development on the product. But there are still use cases outside of my core set of users that I’m not familiar with. And what happens when those questions that could easily be resolved by knowing our users come up? We get stalled. Someone has to find the person who would be best suited to answer. Maybe have a conversation with them. Maybe have a discussion with multiple people. Questions that can’t be answered can quickly eat up your time and put you behind. For instance, an engineer has a question about a ticket mid-sprint. Responding with “I don’t know, let me find out” means that the engineer can’t finish that ticket until you respond. Or you’re writing a ticket for a refinement session. What happens if you can’t finish it because you’re looking for answers? That ticket misses refinement. Save yourself from these scenarios. Conduct user research beforehand and make a research plan that continues to evolve as the product grows.
So that’s it; those are my tips. Now, I was totally honest about the depth of my experience so please don’t think I’m claiming to be some guru of product management. This piece is really written for people looking to break into product management, in their first product role, maybe mid-level product folks, or those needing to learn how to manage without actual reporting authority over their product development partners (design and engineering). I’m no guru but I do believe in knowledge sharing. The tips I’m sharing here definitely attributed to my success as a product manager, both from a KPI/OKR standpoint and in terms of recognition from peers and managers. Use them at your own discretion.