Product Management Skills Series — Part 3: The rightly-rated skills

Photo by Alexander Andrews on Unsplash

In the previous two parts of this series, I talked about

1. Underrated product management skills (User mindset, Data mindset, Communication, Scoping, and General Knowledge)
2. Overrated product management skills (Design expertise, Engineering expertise, Strategy, Idea Generation)

This post completes the trilogy and talks about skills which are necessary to get through the sometimes mundane, sometimes challenging, sometimes sad, sometimes ecstatic life of a product manager. I will touch upon three of those skills — project management, business understanding and writing PRDs. So let’s get going with it.

Project Management

A: Hey, you are a project manager.

B: No, I am a product manager.

A: Oh, same thing. Not an engineer or a designer, so project manager.

B: Arggh! Whatever! I have enough work to worry about semantics!

Often people freely use product, project and program management interchangeably while talking about product management. Some PMs get angry about it and dislike being called project managers!

Project management is certainly a necessary, largely boring responsibility that PMs need to take up. PM responsibility on a time spectrum looks something like this:

1. Past — Observing how products launched previously are doing, analysing data and behaviour from the past regularly to create new insights.
2. Present — Making sure that the execution is smooth, the teams are unblocked, the engineers are in sync with designers, the designers are in sync with the problem to be solved, everyone is in sync with the okrs (or whatever goal setting is to be done). Essentially machine is well oiled today.
3. Future — Are launches planned, what will we execute once we have the results of current experiments done, Do we have enough items for the next iteration, Do we have a clear vision of where our product is going in 3–6–12 months and so on. Something changing in the future that could impact us.

This mind time travel might look daunting, but PMs do train themselves to juggle between these three. PMs who miss out on any one of these three can get into troubles.

1. Ignore past — Likely that you end up building products on a hunch or unclear insights. Results in lower predictability of your work
2. Ignore present — Don’t need to say. If shipping is impacted, chaos increases by order of chaos. And no one wants chaos squared
3. Ignore future — You will end up stuck in execution and will depend on others for deciding what needs to be done. You are now allowed to be called a project manager then.

Now, how does all this link to project management? The ability to jump between these three time ships is aided by managing projects well. I am not referring Project management just as setting up some tool but essentially bringing structure to information movement in the organisation. Let’s look the same with past, present and future lens to understand it better

1. Past — Great PMs allow data to flow smoothly across the org. The orgs where data is democratised, chances are a larger number of insights will get generated every day for everyone. Data democratisation projects are boring and irritating at times but need to be done. Managing this project is product management
2. Present — The internet is full of ‘Start with the why’ which is an infallible argument. But what’s the cost of this? Does it happen all the time? Imagine every single person asking product managers “why we need to do every single thing we need to do?”, it will be almost impossible for PMs answer. This gets solved by a better flow of information and decisions throughout the creation machinery. Please don’t misread as — “Make rigid structures” or “Don’t ask questions”. Image a scenario where leadership decides on some objectives for the year and don’t tell the reasons for those choices. How difficult it could become for PMs to explain those to everyone to move things. Managing these projects every day is product management.
3. Future — Roadmapping, building pipelines, deciding how teams are structured, figuring out if teams are solving problems that will be around after 3–6 months or they are just getting together for something which will end in a 3–4 weeks, staffing, hiring. As you start moving from product management to product leadership, a large chunk of responsibilities move just from being creative and resourceful to being decisive and future-looking. As a product leader, you make sure your product managers are unblocked and are solving the most important problems for your products. And you help them with alignment across the org. Managing these projects for the team is product management.

Business understanding

Product management is often considered at the intersection of Tech, Design and business. This means that for a product to be successful, these three domains have to get together and solve problems. However, from a product manager’s perspective not having a stronghold of technology and design might still work, but not having a strong understanding of the business could be risky.

Here is a snippet from one of the best article ever written about product-market fit —

Products don’t just get built in a go. They are different from just software. They are the experience users get end to end. The expectations change, the markets change, users also evolve. The product needs to evolve accordingly (that’s why all the internet is full of the word ‘iteration’). And thus the PMs need to have a very strong understanding of how the businesses work. There is escaping the intricacies of business details. A successful product that is not a business will not survive, but an average product that is a strong business has a good chance of surviving, in fact thriving if the product gets better. Having a strong business understanding means having a strong understanding of the business model, how money moves in your business, what the current and possible modes of revenue, how costs can be managed, how revenue can be increased, how legal and compliance impacts the business and various similar aspects.

Some PMs cover the lack of this understanding by getting deeper into technology or design. The mindset of ‘Oh, my hands are so full that I can’t take out time to know about the business!’ is extremely risky. A deeper understanding of business will keep other business decision-makers sharp too. Every conversation you will have with your stakeholder should add value. Anyways, if product management was all about gathering requirements and passing on to the engineering and design team, all the PMs will get replaced by a tool of the CEO’s choice. Some might choose notion, others google suites or roam research or Jira.

Writing PRDs

Flight attendant: Is there a doctor on this flight?

Dad: *nudging me* that should’ve been you

Me: Not now Dad

Dad: Not asking for a product manager to help, are they?

Me: Dad, there’s a medical emergency happening right now

Dad: Go and see if “writing a PRD” helps

Let’s be honest. If the product manager had just one job, it would be writing PRDs. It’s a nice marketing gimmick to say that you’ll be mini CEO, but come one, the main responsibility is to write product requirement documents!

In the skills discussed earlier, especially communication and project management I have highlighted the importance of the movement of information and how PMs make it happen. PRD (or whatever it is called in your organisation) is that playground where this game is played. Soccer and cricket fans would know how a different pitch or a ground impacts in the result of a game.

I have to write a detailed blog on types of PRD, so I will keep it short here.

1. PRDs need to be the one-stop-shop about the product. Details matter when you are writing this. Don’t worry about concise and small document size etc. Write as much information as you can about the reason, about users, about edge cases, flows, data to be measure etc
2. Don’t worry about templates. Essentially, it’s the internal google search of your product. Makes sure the needs of everyone impacted internally are more or less taken care of
3. Don’t worry about the tool. If wiki works, do a wiki. Generally, docs work well because most people understand them
4. Do versioning but don’t make 10 PRDs for the same product. As the product grows, you can keep adding.
5. Link to as many documents as you need to on data /research/project management/design. Remember point 2
6. Those who are interested in your PRDs will go through all the details. You should love those people and make them read this before meetings
7. Use comments intensively, resolve problems on PRD, save everyone’s time
8. Don’t get overwhelmed by all the templates floating on the internet. I have seen some of them. They are good, but great PRDs take time and you won’t always have time. Those PRDs are their Instagram and not their driving license photos, Everyone who is posting their PRD are mostly posting their best. Sometimes if you need to get things done quickly for some reason, you might only make a quick one-pager with essential needs and that’s fine too. That shouldn’t become a habit but there are no perfect PRDs. Long post on this sometime!

And that’s the end of this series. Hope you enjoyed it! If you have any questions, please reach out to me on twitter @pentropy