On Product Management

[Last Revised: 07/10/2023]

In 2012, I accidentally started the journey of building products with a background in finance and accounting. It was a drastic career transition. At that time, I didn't know what product management was, but I was interacting with developers and designers without understanding their domain language.

I have worked both on physical and digital products as a startup founder and as an employee. As an employee, I have worked at a tiny startup with 25 people to a mid-size organization with 3000 people to a large size organization with 30,000 people. Each one of these organizations with various sizes presented its own challenges and opportunities. Learning never stopped because of an organization size.

Product Management can be a fulfilling career if you are an intellectual, polymath, enjoy solving hard problems, and like to think critically. It is analytical, creative and collaborative role. I love all 3 aspects about it. I love bringing abstract ideas to life by working with cross-functional teams. The discipline of product management allows me to jump boundaries while solving for complex business and customer problems.

This is my private repository of notes accumulated over time. A few quotes below before a deep dive:

Customers don't have needs, they just want to make progress within the system they belong. — Alan Klement

Understanding a problem well means also understanding your competition, and understanding the systems around which this problem exists. — Julie Zhuo, former VP Product Design at Facebook

People don't buy the problem, they buy your solution. Obviously they don't buy it if it's not solving something they care about, but there are many products that are solving what they care about. The real question is, do you solve it better than everybody else so that they buy you? And that's where you need to take time. — Marty Cagan

A good product takes chaos and creates order. — Brian Nogard

Actually using products helps you get better at your job, because you are more aware of the experiences your users are having. It hones your product sense and your ability to understand the user experience, and it allows you to learn in a hands-on way. — Shreyas Doshi

The best PMs aren't the ones who are always looking inward. They look outward. They're the ones who are seeking opportunities outside their own product to get better at what they do. — Shreyas Doshi

I think credit is infinitely divisible, and the atomic unit of success is a team, not an individual. You succeed or fail as a team. As a PM, your job is to ensure that recognition goes to the people working alongside you. — Shreyas Doshi

You are the conductor of the orchestra. You’re guiding the people who are playing the instruments. You don't have to be able to play every instrument well, but you need to make sure everyone is on the same beat. That's the role of the PM. You don't have to play the violin better than all the violinists. You don't have to code better than your engineers. You don't have to design better than the designers. But you have to make sure everybody is working in tandem. — Shreyas Doshi

Experimentation lies at the heart of every company's ability to innovate. — Thomke S

Know the industry that you are in. Know what competitors are doing. — Kate Aronowitz, Design partner at Google Ventures

People don’t want a quarter-inch drill. They want a quarter-inch hole. — Theodore Levitt

We don’t track tasks—we track whether you shipped what you said you were going to ship. No burndown, velocity, story points—a lot of this process actually slows you down because it takes time and sucks the oxygen out of the room. Talk about value, not story points. — Geoff Charles, VP of Product, Ramp

Take the bets with asymmetric upside. If an outcome has a 98% chance of failure and a 2% chance of massive benefits for the business, take the bet. That’s ultimately why startups are able to thrive. This applies to so many domains: hiring, selecting investors, building products, and even vendor selection. — Geoff Charles, VP of Product, Ramp

Taking risks demands humor, kindness, and gratitude. If you’re taking asymmetric bets, you’re making decisions under high uncertainty and high risk. There are sometimes unknown consequences for other teams. Rather than spend time in analysis paralysis, we publish our assumptions and take accountability. In return, PMs can’t take themselves too seriously. We need to stay kind, express gratitude to all the teams we support, and be ready to apologize and own our mistakes. Life’s too short. — Geoff Charles, VP of Product, Ramp

What is product management?

Before I answer what is product management, let me be clear, what is not a product management? It is not scrum management and neither project management. Scrum doesn't teach you how to develop just like a product owner course doesn't teach you how to be a product manager.

Product management is an organizational function within a company dealing with new product development, business justification, planning, verification, forecasting, pricing, product launch, and marketing of a product or products at all stages of the product lifecycle.

Product lifecycle management is the process of managing the entire lifecycle of a product from inception, through engineering, design, prototyping, manufacturing physical products, scaling software businesses, to service, maintenance and disposal of products or retiring old legacy software.

However, every organization does product management differently depending on several factors. If you are a small startup, PM is perhaps led by a CEO or some other executive or even by product development team. Product management is a structured discipline in mid-to-large organizations.

Product management is about setting and driving a product vision for potential or existing users. A set of process or processes drives the product vision. Process defines the framework and discipline to accomplish the product vision. Every organization has a different process, but the following should be a starting point when defining a framework.

• Product Vision: what do you want the world around you to look like in 6 months? 1 year? 2 years? 5 years?
• Outcome: what do you want to achieve to help realize this product vision?
• Goals & Metrics: what are the measurable goals along the way? How can you measure them?
• Strategy: what are you going to do in sequence to hit your goals in near and long-term?
• Resourcing: what resources do you need to hit these metrics? For example, how many engineers and designers do you need to build a feature or a product?

Product management model

In an organization with product model, product team exist to solve hard problems for their customers and for their business, in ways your customers love, yet work for your business.

• Value risk: will the customer buy our solution, or choose to use it?
• Viability risk: will this solution work for our business? Is it something we can effectively and legally get to market, sell, service, fund, and monetize?
• Usability risk: can the user easily learn, use and perceive the value of the solution?
• Feasibility risk: do we know how to build and scale this solution, with the staff, time, technology, and data we have?

In a cross-functional product team, these are the critical competencies and what each is responsible and accountable for:

• The Product Manager is responsible for the value and viability risks, and overall accountable for the product’s outcomes.
• The Product Designer is responsible for the usability risk, and overall accountable for the product’s experience – every interaction your users and customers have with your product.
• The Product Engineer is responsible for the feasibility risk, and overall accountable for the product’s delivery.

Product management can be engineering driven, design driven, business driven or project driven. If none of these focus on users, product management is done incorrectly. Every company has a different philosophy about the product development process and where PMs fit into that process. Below are the three most common types, with pros and cons:

• PM drives engineering: where PMs gather requirements, write product requirement document, and hand it off to engineering to spec out the technical requirements. Contemporary organizations may do this process in a more agile and collaborative way, but the expectation is that PMs know best about what customers need and engineering is there to serve.
  • Pro: engineering can focus on coding without a lot of distraction; this tends to work well for waterfall development shops with established products.
  • Con: engineers lose sight of the big picture and do not develop empathy for customers, which can lead to a poor customer experience. Often there are unhealthy tensions when technical debt and “plumbing” work needs to be prioritized over customer requirements.
• Engineering drives product: technically oriented product companies (cloud, big data, networking) tend to be engineering-driven, where engineers are advancing the science in their domain and PMs validate solutions or create front end access points (UIs, APIs) to tap into new technology. There can be a collaborative relationship and feedback loop between customers, PMs, and engineering, but typically PMs are serving engineering in these companies.
  • Pro: breakthrough technology can offer customers things they didn’t even know they needed. An engineer thought it would be cool to do, a PM figured out how to monetize it, and it became a billion-dollar game changer for the company.
  • Con: engineers chase the shiny new thing, over-architect the solution, or iterate forever, seeking perfection before getting customer feedback. PM input on priorities is ignored, which sometimes includes the most basic needs of customers.
• PM-engineering partnership: there is a strong yin-yang between PM and engineering, with joint discovery, decision-making, and shared accountability. Engineers join PMs in customer interviews, and PMs are in sprint meetings to help unblock tasks or clarify requirements. But the two roles respect the line where one starts and the other stops. PMs understand what is being coded but don’t tell engineers how to code, and engineers have empathy for customers’ needs but leave the prioritization to the PMs.
  • Pro: a streamlined prioritization process that values technical debt and plumbing projects; better design processes leading to a more positive user experience; higher-performing teams with improved product velocity, quality, and, typically, happier customers.
  • Con: breakthrough innovation may not get green lit; time-to-market may seem to lag (though I’d argue that what’s released is far better aligned with customer needs and more likely to successfully scale if iterated over time).

Startup versus large organization: Product management at a startup versus a large organization can be a very different experience. The role of a PM at a startup is far more likely to be responsible to wear “all hats,” whereas at a mature company their role will be more distinctly defined.

• Startup: beyond discovery, definition, and shipping, PMs may also be responsible for pricing, marketing, support, and potentially even sales. These PMs thrive in a scrappy environment and are comfortable with ambiguity and frequent changes to direction as the company works towards product-market fit and learns to operate at scale.
  • Pro: PMs are likely to be more involved with company strategy, get exposure to senior leadership and the board. Ownership pod is fairly large leading to making a bigger impact. They also have more influence and authority over company resources.
  • Con: There’s typically little to no mentorship, role models, or best practices within the company. You may have to seek it externally. Budgets are typically tight, and PMs may not have the requisite experience to succeed at some of the things they’re tasked to do.
• Mature organization: The PM may have a narrower scope and have coworkers who handle pricing, go-to-market strategies, and so on. And they are likely to be part of a larger team of PMs.
  • Pro: PMs are more likely to have mentoring and role models, as well as development standards and best practices. Close association with an engineering team can create strong relationships over time, which is great for long-term impact and career growth. And if the product has market fit, there is an established customer base and performance baseline to work from, versus guessing until you get it right.
  • Con: PMs have less exposure to company strategy and are just one of many voices of the customer. They can get “lost” in the system and have to deal with politics, process bottlenecks, competing priorities and tighter budgets. User feedback might not align with revenue goals which can make your job seem more like project management as opposed to product management (users are at the heart of product management).

Product management goals: Practicing the discipline of product management without goals is like traveling in an empty universe. Goals define whether the progress is being made or not. In its purest form, a goal is a way to track whether you’re achieving what you set out to do. When setting goals, start with what you’re trying to achieve as a company, team and product. What’s your ultimate mission? A goal should never be an end in itself—the end is achieving your mission. A good goal has the following attributes:

• Concrete: it’s clear and unambiguous (something that isn’t subjective).
• Simple: everyone understands what it is and how it’s measured.
• Quick feedback loop: the results of your changes can be seen quickly. Think about how long it takes for a user to reach the milestone you’re tracking, and whether you can expect movement in a reasonable time-frame.
• Business-oriented: it’s easy to see how this goal actually drives the larger business need.

The role of a product manager

There are many flavors of product management, but being a PM is a job of influence to drive positive outcomes for the end user. Let's simplify it even further—positive outcomes for a user. However, it is not as straight-forward as it sounds in theory. To drive positive outcomes for the end user, PMs do many things, but are primarily focused on the following:

• PMs are responsible to set overall vision, direction, capability, quality and delivery of products. These responsibilities are scattered between associates and mid-senior level positions.
• PMs are able to build coalitions and get a buy in from functional groups—design, data, business, sales, and other cross-functional segments.
• There is no room for an ego. If there is a key player missing, it will make the PM look weak. Resourcing is not a primary job but is a key element to executing on delivering a great product. This is where the previous point comes into play. A strong partnership with others can help fill the in the gaps.
• PMs are constantly learning and picking up on domain knowledge. Best PMs are autodidacts because they are curious about everything. Sales, marketing, negotiation, design, or tech—they are all equally important to learn.
• PMs should have strong collaboration mindset. PMs are like point guard playing basketball because they make others look great. A good collaboration between business, design and tech make everyone look great.
• PMs understand the roadmap. It is important even if you don't own it. Features are prioritized based on the roadmap. PMs turn goals into projects with the help of their teams and entrepreneurial spirit. Too much to do is always a battle. That's the perpetual state of being a PM, but the goal is to use a hammer on the highest nail.
• Building with user adoption in mind. Beyond shipping new features on a regular cadence and keeping the peace between engineering and the design team, the best PMs create products with strong user adoption that have exponential revenue growth and perhaps even disrupt an industry.
• PMs should be capable of writing well. Communication is a key and able to communicate with several stakeholders all at once becomes challenging. One way to overcome that challenge is to document for all types of audience. It is a good idea to document something that can be obvious to your audience. Different things mean to different audience. Writing helps bridge that gap. Documentation culture helps scale up the communication to an entire organization.
• PMs should be resilient. Being resilient is a key to becoming a successful PM because if you are doing something hard, there will always be failures. Resiliency is hard to find in a resume. Great PMs are people who have overcome adversity in their life. Emotional intelligence goes a long way if there is a product execution or a life failure. From failure, everyone learns.
• Your management expects you to have a good enough sense of your team’s capacity and velocity that you can make the call on the spot.

Brian Armstrong has excellent advice on what it takes to be a successful PM:

My goal is to set you up for success as a new product manager. First, you’re going to have to dedicate yourself to the art of product management. It is one of those things, like people management, that seems simple, but can take many years to really master. The only way to learn it is to actually do it. That being said, reading about it and learning from others does help. One suggestion would be to speak with 2–3 product managers (here or at other companies) to get their view. Become a knowledge sponge. Copy others before you try to find your own voice and do something unique (that can come after you’ve achieved mastery). The main parts of the job in my view are: 1) Understand the customer deeply — this means user studies, you have to go talk to the users every week and spend a lot of time with them to hear their pain, get inside their head. 2) Be metrics driven, you should be using time series data to give you insight into what people are doing with the product and see if the changes you are making are improving things. If you haven’t instrumented the app and chosen a metric you want to improve, you are just guessing. 3) The product manager is responsible for prioritizing the product roadmap and communicating it to the team. Not as a top-down dictator, but as a consensus builder amongst all the stakeholders, breaking a tie when necessary. 4) You need to be a communication hub, both when building consensus internally on priorities/roadmap, but also externally communicating changes to customers. Users need to see that the product is continually improving by hearing about it from you. Everyone internally needs to be on the same page when changes roll out. You are the point of contact for all things related to this product. 5) Once you master all of that, you will need to develop product vision (conviction about where things are going in the future, make the hard calls about what to eliminate, etc) and strive to make something truly great. You can think about it not just as eliminating customer pain, but actually creating customer delight. In rare instances, you can wind up creating something that people actually love. (very few products attain this — nobody says they love Tide detergent, but people do say they love their Harley Davidson). On a practical note, you are responsible for the following tasks on the team: running product review, maintaining/updating the product roadmap, and doing sprint planning.

Ian McAllister (former Amazon executive) response on Quora on how to become a top 1% — “The top 10% of product managers excel at a few of these things. The top 1% excel at most or all of them:

• Think big: A 1% PM's thinking won't be constrained by the resources available to them today or today's market environment. They'll describe large disruptive opportunities and develop concrete plans for how to take advantage of them.
• Communicate: A 1% PM can make a case that is impossible to refute or ignore. They'll use data appropriately, when available, but they'll also tap into other biases, beliefs, and triggers that can convince the powers that be to part with headcount, money, or other resources and then get out of the way.
• Simplify: A 1% PM knows how to get 80% of the value out of any feature or project with 20% of the effort. They do so repeatedly, launching more and achieving compounding effects for the product or business.
• Forecast and measure: A 1% PM is able to forecast the approximate benefit of a project and can do so efficiently by applying experience and leveraging comparable benchmarks. They also measure benefit once projects are launched and factor those learnings into their future prioritization and forecasts.
• Execute: A 1% PM grinds it out. They do whatever is necessary to ship. They recognize no specific bounds to the scope of their role. As necessary, they recruit, they produce buttons, they do bizdev, they escalate, they tussle with internal counsel, they *.
• Understand technical trade-offs: A 1% PM does not need to have a CS degree. They do need to be able to roughly understand the technical complexity of the features they put on the backlog, without any costing input from devs. They should partner with devs to make the right technical trade-offs (i.e. compromise).
• Understand good design: A 1% PM doesn't have to be a designer, but they should appreciate great design and be able to distinguish it from good design. They should also be able to articulate the difference to their design counterparts, or at least articulate directions to pursue to go from good to great.
• Write effective copy: A 1% PM should be able to write concise copy that gets the job done. They should understand that each additional word they write dilutes the value of the previous ones. They should spend time and energy trying to find the perfect words for key copy (button labels, nav, calls-to-action, etc.), not just words that will suffice.”
• Story-tellers: the best PMs are able to weave tales that incorporate market needs, strategy, and tactics into a story that their stakeholders can get their heads around and hopefully adopt the story themselves. It can be challenging when you see something clearly, but you can’t get others around you to see it. You work through other people's eyes, so it takes a lot of convincing. You have to be a great communicator and storyteller. You have to read your audience. You have to try harder to understand others and find an angle to explain that makes sense to them. People you work with are smart, they just need a great story to be convinced.
• Learning by doing: to master the art of product management requires several years of practice and doing. Natural talents won't be enough. Ultimately, the best thing you can do to prepare for a career in product management is to build. Manage and “own” a project from inception through execution and operation. Create KPIs to measure your impact.
• 3 Ps: analyze the 3 Ps—people, process and product, to assess on the quality of people, the best process to deliver the product, and excellence and relevance of a product. Keep in mind to not implement process for the sake of process. Relevance is a key to establish the right process.
• Hard decisions: be willing to stand up for what you believe in, especially when you are representing your users. Confidence of a PM comes from having a strong work ethic and conviction. Conviction can be built using both intuition and data. Hard decisions make great products. Success is not guaranteed, but confidence eliminates fear of failure.
• Questions: are a PM's best tool. The best way to understand what’s going on or how to get better is to pose probing questions to all stakeholders, and above all, to yourself. Stopping for a tune-up if you’re already further along the road is critical to leveling up as a leader. Questions help you travel on the right road. If you aren't on the right path it doesn't matter how fast you are traveling. Asking the right questions will help you choose the right road.
• Emotional Intelligence (EQ): the best PMs have the ability to empathize with customers during surveys and interviews. A PM with a high EQ has strong relationships within their organization and a keen sense of how to navigate both internal and external hurdles to ship a great product. People don’t talk enough about EQ. PMs get huge value from being highly empathetic with the team, not just with users. There are plenty of smart people, but not enough people with the right balance of emotional intelligence.
• Social capital: economic and social benefits derived from the preferential treatment and cooperation between individuals and groups. Components of social capital include reciprocity, trust and values. If these are shared between individuals within a network then the community will function as an organic whole. This is important for the next up, relationship management.
• Relationship management: probably one of the most important characteristics of a great PM is relationship management skills. By forming authentic and trustworthy connections with both internal and external stakeholders, the best PMs inspire people and help them reach their full potential. Relationship management is also vital in successful negotiation, resolving conflicts, and working with others toward a shared goal, which is especially challenging when a PM is tasked with balancing the needs of customers, resource-constrained engineering teams, and the company’s revenue goals. Authentic and trusting relationships within an organization can lead to more support when additional funding is needed for a product or when an engineer must be swayed to include a quick bug fix in the next sprint. Outside an organization, these skills could encourage existing customers to beta test a new feature for early feedback or to convince a target customer to try the MVP of a product still in stealth mode.
• Social awareness: PMs must understand customer's emotions and concerns about their product as much as they understand the concerns of the sales team on how to sell that product, or the support team on how to support it, or the engineering team on how to build it. PMs need deep understanding of how the organization operates and must build social capital to influence the success of their product, from obtaining budget and staffing to securing a top engineer to work on their product. Finally, social awareness ensures the best PMs service their customers with a product that addresses their jobs to be done, which is ultimately what drives product-market fit.
• Confirmation bias: PMs must be self-aware of their own confirmation biases to avoid projecting their own preferences onto users of their products. PMs should stay objective in despite of features they love which addresses their own pain points. The lack of self-awareness in any sort of biases could derail more important priorities or damage the PM’s relationship with engineers, who may lose confidence in their PM when a feature isn’t adopted by users.
• Self-management: being a PM can be incredibly stressful. The CEO wants one thing, the engineering team another, and customers have their own opinions about feature priorities. Managing tight deadlines, revenue targets, market demands, prioritization conflicts, and resource constraints all at once is not for the faint of heart. If a PM cannot maintain their emotions and keep it cool under pressure, they can quickly lose the confidence of all their constituents. The best PMs know how to push hard on the right priorities, with urgency but without conveying a sense of panic or stress. A PM should know when to take a breath and step away to regroup.

Lastly, according to Marty Cagan, it is critical for PMs to have access to 3 things for them to be successful:

• The first is that that product manager needs unencumbered access to their users and customers.
• Second, product manager needs unencumbered access to the engineers.
• And the third is unencumbered access to the stakeholders.

Core responsibilities of a product manager

PMs are always learning, but they should keep up with core competencies. The following core competencies are the baseline for any PM, and the best PMs hone in on these skills over the years. The following core competencies are reflected in shipping the great products.

• Conduct customer interviews and user testing
• Run team wide including design and engineering sprints
• Roadmap planning
• Feature prioritization
• The art of resource allocation
• The art of managing conflicts
• Perform market assessments and conduct competitive analysis
• Assess market trends to explore innovative features
• Translate business-to-technical requirements, and vice versa
• Pricing and revenue modeling
• Community (internal or/and external) engagement
• Gauge prospects and beta users to adopt a new feature or a product
• Act as a liaison with cross-functional business units
• Document stories, epics, technical requirements, user workflows
• Support training and conduct demos for cross-functional teams
• Define and track adoption metrics
• Collect and prioritize user feedback

What should a PM do on Day 1?

What should a new PM do in the first month? Joining a new product team is like starting a new position on a basketball team; eager to play, but don't know the chemistry or tactics to perform. Training and practice is necessary before a PM can score. A structured program can provide training, but many organizations don't even understand what product management is, let alone what to train the new PMs on. More often than not PMs are left to sink or swim. Here is a framework I created during the first month of being a PM at Morningstar.

• Company's mission
  • What is the underlying business?
  • What is the objective of the business?
  • How does the business help customers?
  • Where does the company fall short on meeting customer's expectations?
• Learn the product
  • What is the product?
  • Why are we building?
  • Who are we building for?
  • How are we going to build it?
  • Are there any OKRs for each milestone?
• Meet the team & stakeholders
  • How is the team structured?
  • What role does each member play?
  • Where does the team excel?
  • Where does the team fall short?
  • Is the team aligned on product mission and strategy?
  • What does the team expect of you?
• Review documentation & artifacts
  • Review product vision & strategy artifacts.
  • Review the product roadmap.
  • Review the product's technical requirements.
  • Review JIRA board and backlog.
  • Review the product's performance data.
• Execute
  • Provide and update Acceptance Criteria with appropriate context and information including design and data points.
  • Help team unblock during sprint rituals by providing product & business context.
  • Write documents that are missing.
• Test
  • Experiment & test hypothesis to find user engagement and value. Running physical experiments is relatively expensive, so companies have had to be parsimonious with the number of experiments.
  • Controlled experiments, also called randomized experiments and A/B tests, have had a profound influence in many fields.
  • The electric light bulb required more than 1,000 complex experiments. In modern times, with the magic of software, experimentation is much cheaper, and the ability to test innovative ideas unprecedented.
• Measure
  • Measure results from your experiments such as A/B tests.
  • Track down your team decisions on a decision log and assess which ones succeeded.
  • Measure team velocity for each sprint by tracking down start and close tickets.
  • Evaluate qualitative feedback from users via usability testing or incoming feedback.
  • Measure user growth. It is natural for a set number of users to leave. But on a longer scale, you will find product-market fit from users that stay around longer as time passes.
  • Focus on outcome not outputs. To do that, ensure you understand the outcome.
  • Metrics need to be understandable, comparable, actionable and normalized (ratio or rate).
  • Be as specific when measuring metrics:
    • OK metric: new events created per week
    • Good metric: new events created per week per user
    • Great metric: % of users who create a new task, per week
    • Awesome metric: % of users who create 3+ daily tasks, per week

What is hidden in plain sight?

Peter Thiel, in his book, Zero to One, outlines his belief that the biggest insights in life are “hidden in plain sight”—concealed only by our preconceptions or tendency to accept realities as they are (complacency).

Tell me something that’s true, that almost nobody agrees with you on. — Peter Thiel

The product manager's (PM, I will be using the acronym for the remainder of the article) ultimate quest is to answer the following questions:

• What is hidden in plain sight?
• What does a user want? And how do you want your customers to become better at doing their job?

From these questions above, I have realized from this past decade that product management is more of an art than a science. Product management is not formulaic. It requires a PM to come up with great ideas, but also build things that customers want and make their jobs easier. How to balance the two is the task on hand for a PM.

I also believe there are two types of product managers—generalist and technical. Great PMs are generalist who are able to jump many boundaries of engineering, design and business. As engineering and design becomes more specialized, the generalist fills the gap. But surfacing those insights are not enough. Those insights need to solve user problems and need to be delivered to them at the right time. As much as the discipline of product management focuses on strategy, luck also plays a key role. iPhone would've never been successful if it was introduced any sooner or later. Technological advances play an important role on when to introduce the right product and features. For example, Blackberry had the best smartphone when Apple introduced an iPhone. Blackberry today is almost non-existent. This is another example of art versus science.

Product management is also an execution job. Strategy plays a huge role, but strategy without execution serves neither the organization nor the end-user.

Knowledge without action, is like having no knowledge at all. — Ted Nicholas

The essence of strategy is choosing what not to do. — Michael Porter

HP Labs, which was a pioneer a few decades ago, defined their product equation in the 1980s.

Product = Customer x Business x Technology

User problems don't need to be invented for the sake of doing the job of product management. For every feature or product delivered, there is only one question that can tell if meaningful work is being done, “Are the users making progress with your product?”

How can you ensure your users are making progress? If you are not using data on user engagement, you are relying on your intuition. But I said earlier that the discipline of product management is an art not a science. Correct, but it does not hurt to collect data on what is working and what is not. Just like everything else, balance between data and intuition is required here. Intuition is what leads to opinionated decisions. If you hold strong opinions when making decisions, it is your job to explain why.

Lessons from personal experiences

• Creating value (business and clients):
  • Solving problems, not creating hype.
  • The essence of product management is to discover and create value for the end user.
  • A great product manager creates value by solving the right problem. The word “right” is key here.
  • Focus on why, not the what; client won't come just because your team built a feature.
  • Being a successful product manager requires the ability to thrive in ambiguity.
  • Focus on results, not output; solve client's problems that work for business goals.
  • People don't buy problems, they buy solutions.
  • Empathize for user problems.
  • People don't buy problems, they buy solutions.
  • Good marketing isn’t about hype, manipulating, or reaching out to customers without their permission.
• Learning from doing:
  • Action produces information.
  • Feature failure is not a disaster, but a learning step to get from v1 to v2.
  • Learning never stops because problems never go away; cherishing this mindset helps you deal with day-to-day.
  • Outcome driven culture is highly critical, but outcomes cannot be discussed without speed in mind or a launch plan. A project that doesn't get out to clients is risky. Outcomes with high velocity is what teams should strive for.
• Using data to drive insights:
  • Leverage data to craft a 5-star customer experience.
  • There's a huge difference between data driven and data obsessed. Data driven organizations have plenty of data, but the data is not leveraged to make decisions. Data obsessed organizations have data in their DNA. They embed data in every meeting, conversation and domain in order to make decisions.
• Seeking collaboration:
  • Define products collaboratively, not sequentially.
  • Collaboration can only happen when working in isolation is eliminated.
  • Address product risks early—value (user), usability (design), feasibility (engineering) and business.
• Documentation is communication:
  • Application workflows and product requirements are absolute must and needs to be communicated upstream and downstream.
  • It is also a product manager's responsibility to report and document bugs and feature gap.
  • Sweating small details in feature gathering documentation and design artifacts
• Maintaining decision log:
  • Making decisions with cross-functional teams and stakeholders, so execution teams can move forward—present the situation, list dependencies & risks, share options available, list pros & cons and finally make a recommendation.
  • A decision has both elements of data and opinion; knowing which one is a key to prevent analysis paralysis.
  • Feature prioritization depends on trade-offs. You need to weigh both pros and cons for each decision your organization makes.
  • While making a decision, look out for problems that are larger than the current scope. Able to deal with these trade-offs are impactful both in negative and positive way.
• Celebrating small and big wins to create product culture:
  • Celebrate if a feature optimization helps your product become faster. Celebrate if a feature optimization helps save a penny for your customer. Celebrate all small wins.

Major subtopics of product management

• Product Intuition: Excellent product managers have great product sense. Below are the tips to getting there. The more you practice them, the better you will build product intuition while helping you make high conviction decisions. Your management expects you to have a good enough sense of your team’s capacity and velocity that you can make the call on the spot. If you don’t, you’ll immediately lose the respect of the other stakeholders in the room. Build this muscle soon before you ask for trouble, and you’ll grow an intuition around sizing and difficulty.
  • Use your product like a real customer.
  • Validating business requirements in applications. Report bugs if something is broken.
  • Research behavioral patterns about your target audience.
  • Interview prospects.
  • Conduct on-site research via observations.
  • Read customer reviews (if there are any).
  • Review your metrics primarily client sign-ups and drop-offs over weekly, monthly, quarterly and annually.
  • Tag along customer service reps and sales.
  • Explore industry blogs and competitor space.
  • Understand the core growth loops so you can aim for the right features.
• Project Thinking vs Product Thinking:
  • Product Thinking:
    • Most important question: Why
    • Optimize for: Outcomes
    • Improves: Effectiveness
    • Most important capability: Insight
    • Biggest Differentiator: Creativity
    • Biggest Secret: Simulation
    • Effect on outcome: Exponential
    • Most important core value: Empowerment
    • When done in excess: Great plans gathering dust
  • Project Thinking:
    • Most important question: When
    • Optimize for: Outputs
    • Improves: Efficiency
    • Most important capability: Execution
    • Biggest Differentiator: Discipline
    • Biggest Secret: Influence
    • Effect on outcome: Multiplicative
    • Most important core value: Action
    • When done in excess: Heroic effort lacking results
• User Stories vs Job Stories: User stories capture broad needs of user personas. Job stories zone in on specific situations where a product is 'hired' for a task. The difference is between general vs specific. Below are a few examples of specific features:
  • Push notifications
    • User story: As a user, I want to receive real-time notifications about updates or important events in the app, so that I can stay informed without having to open the app constantly.
    • Job story: When an important event occurs, I want the app to notify me immediately, so l don't miss out on timely information or actions.
  • Dark mode
    • User story: As a user, I want to switch the app to dark mode, so that I can use it comfortably in low-light environments without straining my eyes.
    • Job story: When I'm using my device in the dark, I want the app to adjust its theme to reduce eye strain, so I can continue using it without discomfort.
  • Offline mode
    • User story: As a user, I want to access the app's content even when I'm offline, so that I can continue my activities without interruption when I don't have an internet connection.
    • Job story: When I lose my internet connection. I want the app to still provide me with essential functionalities, so I'm not left stranded or unable to complete my tasks.
  • Multi-language support
    • User story: As a user who speaks multiple languages, I want to switch the app's language to one I'm comfortable with so that I can use the app more effectively.
    • Job story: When I lose my internet connection. I want the app to still provide me with essential functionalities, so I'm not left stranded or unable to complete my tasks.
  • Social media
    • User story: As a user, I want to share content from the app directly to my social media platforms, so that I can easily share interesting finds with my friends and followers.
    • Job story: When I come across something share- worthy in the app, I want a seamless way to post it on my social media, so I can engage with my network without switching between multiple apps.
• Analytical Thinking: Being analytical isn’t only about numbers. It is about developing healthy skepticism and curiosity, validating your hypothesis (and having a hypothesis in the first place) and vetting with multiple data points to get closer to the truth. It gives you a competitive edge, and you will learn to make informed decisions.
  • Retrieve: First, you need to learn how to get data. SQL is most common in work places.
  • Analyze: Analytical thinking is to crunch numbers understand the why and execute at lightning speed. To do so you need the basic understanding of—patterns, nuances, absolute numbers & percentages, variances, expected vs actual, contribution to whole, peaks, margins and biases.
  • Look for clues by asking:
    • Why is this happening?
    • What is the impact?
    • What should we do about it (if anything)?
• Capabilities vs Domain vs Experience: When requirements are defined, the big question is where to host the requirements? Like everything else, it depends on business architecture modeling. This is mostly designed by a system architect. How it gets packaged is not a product concern, but need to understand to drive feature requirements. No system is right or wrong, but a core architectural system might have the following:
  • Domain: What is the core functionality that drives business objective? It is associated with one data store in a database. Domains can be grouped in many ways, but it should always be driven by business objective that drives business value. For example, Order Management.
  • Capabilities: How functionalities can be grouped. This layer can interact with several data stores.
  • Experiences: How it gets integrated with capabilities to drive different platforms such as native applications vs web applications. It can interact with more than one capability to drive client experience. Having this layer helps reduce rebuilding of redundant functionalities and logic for various operating systems.
• Go-to-Market (GTM): It is an organizational plan to deliver unique value proposition to customers and achieve competitive advantage. Below are the components of GTM. Start with debugging upstream or downstream of product cycle to optimize for GTM:
  • What exactly are you building? It starts with vision. But if the vision is wrong everyone is going home. It starts with product management.
  • How do you position it? How do you tell the story in a short-time frame without using product jargon? Great product use less words to spread the message. It starts with product marketing.
  • How do you do demand generation? How do you do sales? If the product does not sell, there is a gap in product market fit.
  • How do you do customer retention? If the customers are churning, there is value deceleration.
• Product Market Fit (PMF): It is another way to say you are in search for demand curve or another way to say you have produced value. Product market fit allows a company to sell product at scale. When people want to pull it out of your hands that is a product market fit. Company building should happen when you have a product market fit.
  • Use cohort analysis to measure product market fit. Look at a group of people that tried your product in a period of time (week, month, quarter). Then look at how many of those people continue to use your product for a while. You will have a fairly deep drop-off on the first month. Does it flatten somewhere? If so, that means that there are customers who are finding value in your product, which means you have PMF with these customers.
  • Create a retention curve by plotting the percent of active users over time (for each cohort of users). If it flattens off at some point, you have probably found product/market fit for some market or audience.
• Product Marketing: The product manager (PM) defines the product vision and strategy. However, you cannot create a strategy without market and industry analysis, which is theoretically the product marketing manager's (PMM) main job. The main areas of responsibility for a product marketer are:
  • Discovery: target customers, customers’ jobs/needs (methods like interviews or surveys)
  • Analyzing the market and the industry: Sizing market opportunities by considering Total Addressable Market (TAM), Serviceable Available Market (SAM), and Serviceable Obtainable Market (TOM). Analyzing market characteristics, like the average Annual Growth Rate, Average Revenue Per User (ARPU), average Customer Acquisition Cost (CAC), and average Churn Rate. Analyzing the industry (e.g., Porter’s Five Forces). Performing competitive analysis.
  • Shaping how others think about the product: formulating the positioning strategy, which defines target customers, the product’s place in the market, its core benefits, and supporting evidence. Adjusting product messaging. In short, it’s about explaining why the product is awesome (copywriting, storytelling) based on positioning strategy.
  • Enable others to tell the same story: training and guiding sales, resellers and other partners
  • Creating the Go-to-market (GTM) strategy. It should include business goal, target customers, value proposition, positioning strategy and business model, including pricing.
• Strategy: Business strategy explains how a company tries to beat the competition. The ultimate goal of a strategy is to help us gain a competitive advantage, which leads to better financial results. For example, companies that try to beat competitors by offering lower prices are pursuing a cost leadership strategy (Aldi, Walmart, IKEA, Southwest Airlines, McDonald's, etc.). On the other side of the spectrum are companies that want to win by being unique. These companies can charge higher prices because they are perceived differently (Apple, Whole Foods Market, BMW, Qatar Airways, Four Seasons Hotels, etc.).
  • A strategy isn’t: a goal (goals only talk about why; a strategy also explains how), using best practices such as Design Thinking or Six Sigma (can be implemented by any competitor so they are not trade-off decisions) and merely a plan (strategy needs to lead to a competitive advantage).
  • A strategy is: choosing what to do and what not to do, a series of trade-off decisions, a quest for competitive advantage, about being different (not merely better), focusing a company’s resources on the most critical issues.
  • Blue Ocean Canvas is one of the most useful tools for designing strategies. To create a blue ocean we need to:
    • Define 5-12 competing factors.
    • Plot a dominant industry line.
    • Create your blue ocean offer by asking what competing factors can we eliminate, decrease, raise, and introduce.
• Competitor Analysis: Understanding competitors’ strategy, business model, and future plans help us design better products and experiences. We can anticipate how competitors will react to our innovations, and how we can differentiate better (create unique value for our users).
  • The first step of competitor analysis is identifying competitors.
  • Divide the competition into direct and indirect competitors. Direct competitors are companies that offer the same product (or service) and indirect competitors offer a different product that solves the same problem. For example, Uber’s direct competitors are taxi companies and Lyft. The indirect competitors are bike sharing services, public transport, car sharing services, and walking on foot.
  • Gather data for insights. Divide data gathering into three buckets:
    • Business data: revenue, market share, etc.
    • Product data: product portfolio, features, etc.
    • Customers data: target group, reviews, etc.
• Application Programming Interface (API): APIs are mechanisms that enable two software components to communicate with each other using a set of definitions and protocols. For example, Morningstar's software system contains daily stock market data. The stock market app on your phone “talks” to this system via APIs and shows you daily stock prices on your phone. People interact with software through Graphical User Interfaces (GUIs) while software interacts with another software through APIs.
  • APIs are developer friendly. APIs can serve as [Placeholder]-As-A-Service. The placeholder can be wealth management, inventory management or ride-sharing. Simply by writing a few lines of code, platforms can let their customers set up any services. APIs abstract away code and business complexity. I can use ACH services through API without writing code or understanding how ACH works. APIs can be internal or external facing.
  • APIs consist of functions, contracts, business logic which helps scale for adoption. Businesses today can use APIs from other software providers without having to invest their own resources to build out capabilities. If I am in the business of stock data, I do not need to build a payment gateway. I can use Stripe's API to build my business.
  • Business model for API is pay-as-you-go. Every time an API is consumed, you get charged. API first companies have deep moats because they are highly specialized, but can also pose risk if a bigger company enters the market.
  • Components are derivatives of APIs. They are reusable objects based on API specification.
  • API architecture is usually explained in terms of client and server. The application sending the request is called the client, and the application sending the response is called the server.
  • There are different kinds of APIs: SOAP APIs, REST APIs and Websocket APIs.
  • REST APIs are the most popular and flexible APIs found on the web today. The client sends requests to the server as data. The server uses this client input to start internal functions and returns output data back to the client. REST stands for Representational State Transfer. REST defines a set of functions like GET, PUT, DELETE, etc. that clients can use to access server data. Clients and servers exchange data using HTTP. The main feature of REST API is statelessness. Statelessness means that servers do not save client data between requests. Client requests to the server are similar to URLs you type in your browser to visit a website. The response from the server is plain data, without the typical graphical rendering of a web page.
    • One software system sends a request to the API of another system and in return, the API sends the response. The request has a type and a payload. These APIs can be accessed via API keys or authentication tokens.
    • REST uses various representation to represent a resource like text, JSON, XML but JSON is the most popular schema. A schema is a structure, which is defined in JSON format. It provides data type information for the data record fields. The schema defines whether a field in the record is a string, integer, floating point, or other data types.
    • The request has a type and a payload.
      • Type signifies what should the API do: Add something (POST), Delete something (DELETE), Update something (PUT), or Fetch something (GET).
      • The payload contains any important information that the API needs.
      • Some APIs also have headers, which contain the authentication information, so that only the right systems can access the APIs.
      • This request is sent to the end-point of the API, a place on the internet where this API lives (generally URL).
      • When API receives the request, it takes some action, generates the response, and sends back a response.
      • A response along with the returned data also contains a status code, which signifies if the API request was fulfilled or not.
  • It is critical to know the ins and outs of a contract. You don't set your house on fire to test your smoke alarm. You test the contract. This ensures your applications will work together. The contract is between a consumer and a provider.
  • GraphQL is a query language that was developed specifically for APIs. It prioritizes giving clients exactly the data they request and no more. It is designed to make APIs fast, flexible, and developer-friendly. As an alternative to REST, GraphQL gives front-end developers the ability to query multiple databases, microservices, and APIs with a single GraphQL endpoint. Organizations choose to build APIs with GraphQL because it helps them develop applications faster.

Further reading