I recently marked the 2nd anniversary of being in the Product Management profession here in the US. I first heard about this profession almost 3 years back when I was in graduate school at Stanford. Back then, although I had been trained as an engineer, I had little clue on how a technical idea can be scaled for customer adoption. In these years, I have had the pleasure of working with an amazing set of people from whom I have learned a lot about products and technology. I would like to share some of what I have learned more broadly. While every profession has its own unique jargon, I’ve tried to stay away from it, and make the content more widely consumable. Hope you find this insightful.
Products are not built in a vacuum
Products are not built for the sake of technology alone. To illustrate, electric vehicle technology existed for more than a couple of decades but it required a Tesla car to change the way we consume this technology. Products are built to address an unmet need in the market. Technology enables you to get there quicker but it’s not the goal in itself. Thus, before building a product, every product manager individual on the product team (A product team is composed of engineers, designers, data scientists, etc.) must ask themselves – “Why does this product matter, why us, and why now?“. As a PM (product manager), it’s your responsibility to answer this question on behalf of everyone on the product team.
In order to answer this question, a PM must be context-aware.
- Market context – How’s the market for my product? What does success look like in this market? Who are the players to beat? What are the underserved needs?
- Customer context – What are the top customer pain points, unmet needs? How does a day look in the life of our <insert your product persona>?
- Business context – What are the top priorities of my organization? Which internal outcomes (higher revenue, enter a geography, or something else?) are we looking to serve through this product? What are the constraints (funding level, hiring, geographies, etc.)?
- Time context – What’s the cadence of product release? Is it sufficient? What are the important events in your industry?
- Team context – What are the skill sets of your product team? How’s the culture? Are we addressing the needs of the extended team (sales, marketing, customer success, support, etc.)?
- Technology context – What are the technology trends in this market? How does the product architecture help address the customer use case?
- Product context – What’s the stage of the product (not yet launched, early, growing, mature/captive customer base)? Is the pull for your product greater than the need to push (aka product market fit)? How successful were the past releases of the product?
Being context-aware will not immediately help a PM. The missing piece is – generating insights a.k.a product discovery. This will require you to engage the entire product team and the extended team to find the right tactics for success (almost like being a detective). As the context changes, share it with the team, test your hypotheses, and only then begin the execution process. This is 50% of the job of a Product Manager and the most often ignored in the drum roll of execution.
World-class products need patience
It takes patience to build a world-class product (on that note, check out version museum). Great product teams are learning and execution juggernauts, built over years of iteration. However, in a world where moving fast is valued, this hard reality goes for a toss. There are many reasons why a product team can lose its patience – senior execs might want something out of the gate ASAP, the sales team is banging on product’s door for a new release, the marketing team has identified a product launch event as a “make or break” opportunity. In these times, it’s the PM’s responsibility to maintain sanity and set the right expectations for everyone – including themselves. Unlike many other professions, there is a long gestation period to see the fruits of your efforts or ideas, at scale*.* So, don’t be unreasonable for your own self*- you probably won’t be able to build Google Maps in 1 year.* So how do you know if the product is headed in the right direction if success takes time? Read the next point.
Thinking Agile
No one goes to a supermarket to buy the latest version of Google. Unlike physical products, software products can not only be delivered over the internet, moving up to the latest version is also much less of an issue. If this wasn’t enough, most products connected to the internet can also measure how users actually interact with the product. Building a product for a fast-changing environment becomes much more seamless if you can measure and learn in order to improve your product in the next iteration. For software products that operate in an environment where requirements are unclear and failures can be tolerated (in comparison to building a rocket), product features can be thought of in smaller chunks. The idea is simple – think incrementally about customer needs, address that need, get feedback, and work on it in the next iteration or release. This avoids the pressure of waiting for 2+ years before knowing the result of a product development effort. Through my own experience as a PM, I’ve realized that thinking incrementally is a skill that takes practice to master.
Notice that I didn’t use the word agile to introduce this concept. Because it is often misunderstood. Agile has become a dreary word and associated with processes like Scrum/Kanban, backlog grooming, etc. While I’m not denying that those processes could be a good way to implement the agile way of thinking, it’s important to not lose focus of the forest for the trees. Point to note – the original agile manifesto has no mention of those concepts.
Bringing focus and clarity
In the agile world, it’s really easy to run in different directions after every iteration or release. Thus, it becomes necessary for a PM to bring the team’s focus to solving only the highest priority issues. One way to do that is by setting clear outcomes and measuring against those frequently. A tactic I’ve seen work is taking along members of the product team to meet a customer or sharing notes from your customer interviews with everyone on the team. Distractions can also come in many other forms, especially from the top of the corporate ladder. It will be hard to ignore the head of sales when he or she gives differing marching orders to the product team for the upcoming release. As a PM, you need to be engaging with stakeholders early, learn the art of managing up, be wary of the highest-paid person’s opinion (HiPPO effect), and filter out the noise for the product team. Who said being a PM is easy?
Communicate! Communicate! Communicate!
As you may have realized by now, communication is probably the most important skill in the life of a PM. Communication doesn’t just mean being able to launch your product like Steve Jobs on stage. It includes all the softer aspects as well – picking up on what’s not being said, active listening skills, and a very high emotional quotient to deal with tough situations. Remember, everyone, especially your top customers, will have an opinion about your product. Sifting through all the voices, deftly asking the right questions to get to the bottom of people’s real needs, and then maybe even saying a diplomatic “no” requires a high level of empathy. In these situations, it’s always useful to have a well-thought-out opinion on most aspects of your product yet be open to changing it in the face of new information. The mantra I live by – “Strong opinions, loosely held”. Till now, you must have felt there is not much written communication in this process. In reality, however, quite the opposite is true. On any given day, you’ll find a PM most often working on user stories, product roadmaps, or a requirements doc.
Always in service of the team…
Products don’t build themselves and I’m glad they don’t. It’s intrinsically a human endeavor. Here is the truth – as a PM, you’re not at the forefront of this endeavor. It’s essentially the product team’s journey and the role of the PM is to serve the team through this journey. Some PMs often take up an unhealthy level of interest in execution metrics (burndown chart, sprint velocity ) and use them to push the team’s productivity. However, always remind yourself that you can’t dictate terms or deadlines to the team. PMs only exert influence over the outcome without any authority. Truly embracing this is the hardest part of the PM journey.
So, how does a PM serve the product team? By empowering the team! There are many ways to do this – sharing the changing context with the team, unblocking any major engineering or architecture decisions, inspiring and motivating the team, etc. A service-oriented mindset is a key here. There are many books I’ve been reading to understand servant leadership and what motivates people – Turn the Ship Around by David Marquet, Drive by Daniel Pink to name a few.
A great product isn’t everything
It’s easy for PMs to get carried away and believe that product is at the center of the universe. Over time, I’ve learned that there are many other factors responsible for the success – great sales teams, brand positioning, operational efficiency, target market, and much more. One of the single biggest ingredients for the success of your product is team culture and values. Only in the right environment can innovation thrive in any organization. As a PM, there will always be many aspects beyond your sphere of influence. In these cases, you have to play the best game with the cards you have been dealt with. While this might sound unexciting, great products have been known to single-handedly change the fortunes of companies. The best PMs are always optimistic about the future and keep pushing for a change with the actions under their control.
Do you want to be a product manager?
The field of Product Management has gone through a revolution of sorts in recent years. As the success of Silicon Valley spreads across the world, everyone wants a piece of the pie. Product Management has gone from being a nondescript career to being perceived as the secret behind the success of tech companies. So, how do you become a product manager?
In the past, most people stumbled into product management from related careers. There wasn’t even a clear path into this field. However, it’s become much more systematized in recent years. There’s even a master’s program for people interested in this field. From my own experience, I’ve found that nothing trains you more than actually working in this field.
Is it necessary to master tech and computer science to become a PM? The answer is no. Technology keeps evolving over time and what’s relevant today might be completely irrelevant tomorrow. Hence, I’d put more emphasis on curiosity and the ability to quickly grasp the basics. However, having a high-level view of how different systems interact and the functions performed by various parts of the stack can come in handy when interacting with various stakeholders. Setting up 1-1’s with engineers on the team in order to learn what they do is a great way to get this understanding.
Yash Tambawala 