Product management demand has grown substantially over the last half-decade. In the US alone, the demand has gone up by 32% (2 year period as of June 2019), beating other roles in software. It is no wonder than new product managers are thrust into this maddening management of chaos we call Product Management.

So, there you are! With a non-technical or technical background, standing at the edge of the precipice, peering down into the valley of Product Management. And you are taken aback by the abundance of information and the winds of change and anxiety that is sure to sweep you off your feet.

Fear naught, we’ve all been there.

We’ve experienced the glare of the bright light — unlike other roles, product management is one where you can simply google for the pertinent information. The wealth of information will dazzle you.

But, heed this warning from someone who has been there where you are: if you do not build your foundation beforehand — before you take the leap of faith — you’ll be blown away by the winds of change/anxiety.

Build your foundations before you are swept off!

So let’s start simple. Let’s build on the foundations that you need to tether you to the ground when the winds blow. I’ve listed further reading links for you to pursue as you go along this route at the end.

1. Simplify problems by asking questions

Let’s face it, you are not a subject matter expert (SME). Your role isn’t to be an expert developer or UX person. You are entitled to an opinion and the power to ask questions. Use it well! Don’t let your personal experience or biases get in the way — but keep in mind that the more questions you ask the SME, the more they are forced to think resulting in a better outcome.

Breaking problems down into simple, easy to solve mini-problems is a key foundation you’ll build.

Ask the following questions:

1. Can a layperson understand the solution you’ve proposed?
   A useful question that forces you to empathize with someone who doesn’t have the same system/domain understanding as you.
2. Does this product require a manual?
   If your app/product requires a manual to navigate, you’ve done something wrong. Interfaces should be intuitive.
3. Does this feature reduce complexity? Or adds to it?
   Your feature/solution should reduce complexity/chaos in the system. Uploading an image shouldn’t require 3 levels of confirmation. It only adds to the complexity of the image uploading experience.
4. Is the solution moving the complexity from the customer to the technology? If yes, how reliable is the technology?
   Ideally, anything that can be done by technology should be done by technology. You need not add the onus on the user! However, the technology behind it should be reliable. Asking the development team the reliability of the solution helps in figuring out if the user will have a smooth experience. Example: If your profile picture requires a square image, you can have a tech that finds the face and crops the image to the appropriate dimensions automatically — however, if the tech is not 100% reliable, you might need to add a screen with the crop shown (and adjustable) for the user to make adjustments.

2. Balancing customer obsession with business viability

Most literature will tell you to build customer obsession as a key foundation in your product journey. And they are mostly right. Being customer-obsessed brings to light problems the customers face — and mostly, customers find a way around it (or through it — think of products that were designed for one purpose but pivoted to their actual customer use)

However, bear in mind the cost of building a feature v/s the benefit the business gets from it. Understanding the business model of the product you’re building/working on is critical to assess which problems you prioritize in your solution pipeline.

Example

Building a costly feature that 80% of the customers want over a cheap feature that 70% of the customers want is a bad bet — especially given that you can see returns on the cheap feature faster. This does not mean you won’t work on the costly feature, but your prioritization matrix should account for the cost to build. Note that the cost here denotes both money and time.

Find a Product Management Framework that works for the team and stick to it.

Be customer obsessed when looking for problems — be balanced when implementing.

3. Communicate based on your audience

Communication is key for a product manager. Subtle, concise, and correct are the 3 adjectives stakeholders should use to describe your communication. Where a graph would do, don’t send a paragraph.

It also helps in knowing your audience. You may be an English major, equipped with an arsenal of words that can accurately describe the pain of the customer, but leave the thesaurus at home. Simple words & graphics are easy to digest. You are not showing off your way with words — you are communicating your vision.

Spend a little extra time honing your wireframing or graph making skills to depict the right amount of information. Use the Minimum viability approach for your graphs:

Communication is not only restricted to the written word. Sometimes, you’ve to lead by example.

4. Good > perfect

Repeat after me — “Good is better than perfect”. Now, remember that before you finalize the scope of your feature. Time is your greatest enemy — be ruthless when prioritizing. Remember, you can thin out the scope only when you know that there is a possibility of an iteration soon.

It is better to have a minor inconvenience to a feature than to have no feature at all!

Remember your competitors, mostly coming from the left field, will launch that feature before you. Sure, first to market hasn’t always won — but that doesn’t mean you won’t lose being late!

“Good enough” is what you need to aim for when launching features (given a shorter timeline). You can iterate based on demand.

Example

When building a profile image upload feature — in the first iteration, do not add things like image manipulation. A simple crop would do. Invest in a good feedback tool to gather sufficient data to justify the extra cost of image manipulation (brightness, filters etc).

5. Set consistent product & feature goals

Feature goals

It is commonly known that everything you build has to up a set of metrics. And you need to know beforehand an indicative uptick in the metrics before you deploy. However, remember that there has to be a consistent set of metrics that you track for all the features you’ve rolled out that can be used to compare the features.

If you ever find yourself comparing apples to oranges, you’re in trouble. Sure, some features increase only a set of metrics — but there has to be a basic set that moves.

Example
Both profile image upload and profile flair (self-anointed badges for the profile) improve the user experience. However, this is a qualitative metric. This does, however, increase the engagement rate (or reduce the attrition rate). By keep a track of those, as a % of usage, you are better able to prioritize the updates to the feature

Product Goals

Product goals are centered around your actions. The following set of activities have to be consistent across your role as a PM:

1. Define & share feature goals with stakeholders & development team

2. Announce releases across the board in your organization

3. Sprint demos — even after a particularly hard sprint

4. Bi-weekly updates to your stakeholders on product progress

There are no shortcuts here. Consistency is defined in product management. You cannot skip a demo because the team is busy. It reflects badly on you and your team.

6. Really understand your data

Again, the literature says PMs should be focused on data. However, knowing the data is not enough. Treating data as evidence, you need to know the circumstances for that data.

Example
An A/B test revealed that a variation A for landing page bounced at 50% v/s 35% for variation B. Would you then simply dismiss variation A? What if you dug deeper and contextualized the incoming traffic? What if you looked at another metric — conversion rate? What was your goal for the landing page?

Simply by segmenting the data — i.e. understanding that the traffic type distribution for the variations — can lead you to make better assessments of the A/B test:

Data is the core foundation for the above foundations. You can pretty much get away with not building the other foundations — but knowing your products’ stats is critical to your success. While they not only impress stakeholders, they can also help you build better intuition.

I’ll throw in a final foundation, one which I’m sure, as you’re reading this, is already ingrained in you: Always Be Learning. Learning never stops. However, remember that the lie of wisdom is in monologue. Only through discourse can you truly see if your assumptions are valid.

The lie of wisdom is in monologue —only through discussions, you can reveal the truth.

So, build a network of individuals and discuss your product ideas and thoughts.

Here are some resources to get you started:

1. Hitchhikers guide to Product Management— by Yilun Zhang/@yilunzh.
   Overarching understanding & tasks involved with product management.
2. Project Aristos — PM Training — by Manas J. Saloi (Manas J. Saloi)
   Self-driven course for learning product management — find a friend and work together. Beautifully written and categorized. Highly recommended for gaining top PM skills.

Apart from this, you can read the following books:

1. When Coffee & Kale Compete for Free — A free ebook written beautifully by Alan Klement on Customer Jobs — read it even if you think you are customer obsessed — for both new & veteran product folks! 
   For the lazy: Summary
2. Influence: The Psychology of Persuasion by Robert Cialdini
   Understanding of the socio-economic behavior of customers and how your rationality fails when it comes to certain nudges.
3. Atomic Habits: An Easy & Proven Way to Build Good Habits & Break Bad Ones by James ClearThis one’s for you and your users (there are a few tips in there that can help you dictate behaviors on your app/service)
4. The Product Manager’s HandbookThis was one of the first PM book I bought. It’s detailed and is good to keep for brushing up on your basics.

Well, that’s that! Good luck with your product management journey!

If you have questions or want to reach out for further clarification, please do! You can reach out over Linkedin (very active) or Twitter (where I lurk).

Thank you for reading!