On the outside, if one doesn’t understand its working, any advanced technology product is indistinguishable from a magic trick. On the inside, it’s like a submarine — made from a blueprint by labour with tools and materials.
Every work is worth what it adds to the subject or material on which it is done. Profit/wages of jobs are in proportion to this value. CEOs, product managers, salesforce, designers and developers contribute mutually exclusive parts in the value chain of technology products and work the part which gets them the highest return for their labour. This is an account of what product managers add to the value chain, how they do it and what gives them an edge to do better.
Of construct and purpose
Owners can’t be managers
When startups grow past product-market fit, founders’ workday changes to steer the new scale of customers and employees. They can no longer focus on day-to-day product discovery and growth. However, monitoring and improvement of the product remain crucial to the company’s immediate future. Someone with the founders’ interests, therefore, must take this up in their stead. This need is similar to large estate owners keeping a principal clerk they can trust to monitor and maintain their estate, and replace their anxiety with trust in his ability to protect their capital. In the absence of the clerk, they can’t sleep at night.
No two characters are more inconsistent than a charismatic, enterprising founder with Midas touch and a calculative product manager holed deep in analytics, keeping all data in his head, always thinking in small targets and experiments. Founders’ place is to make the few high stakes, difficult decisions no one else can make. They can’t have the privilege to carry on the day to day research and experiments they once did. The company can’t be very great whose founder/CEO has the leisure to indulge in important minutiae of each product’s usage and coordinate with working teams to optimize them. Successful founders are bad keepers (optimizers). Think of Kirk Vs Spock in StarTrek or think of William C Durant Vs Alfred P Sloan who played completely different roles in the growth of General Motors.
Tackling value risk
In even the smallest company, someone has to represent users. When the designer needs to know something about users — he must ask real users or someone who represents them, rather than build on intuition alone. Similarly, developers can practically ask someone who represents users (a product manager) than reach out to outside users. In companies of decent size, the responsibility of speaking to users and creating a structure for product teams has to be met by someone outside these teams. This same person who is a proxy for users to design and engineering teams can be a proxy for these teams to management and vice versa.
The biggest risk in building tech products is whether people will use them. If prototyping and user testing are not done while building, a speculative low performing product will be published. Any big design changes afterwards will be too inconvenient. In the absence of a product manager, users are not involved in product development (via prototyping, feedback, and data analysis), so success cannot be estimated early on. Whether a feature is critical or redundant, or what should be prioritized can’t be decided based on evidence. Out of box designs (A/B tests, etc.) can’t be explored.
Once a product is in market, qualitative feedback from customers, sales and support teams guides what to build or change. Fundamental knowledge to make these trade-offs and navigate towards product vision is always outside the office, so someone responsible for success needs to go out in market to fetch this data, well in time.
Even in stable running products, things break all the time. Without someone who has a larger sense of usage data and metrics, big anomalies signifying gaps in value chain or that something is broken are likely to go unnoticed, causing significant opportunity or revenue loss. Someone who understands what usage data means can often spot these anomalies with just a glance at regular usage numbers. One time when I was a product manager at ETInsure, the same OTP was going to all users, which was a potential security loophole. A support executive spotted it 2 months later, despite OTPs getting logged on big screens of all engineering team. No one was looking.
Not all good ideas can come from inside, and surely not all the time. To maintain competitive edge and ensure that users get the best possible product, someone must pay attention to industry trends and integrate new technologies/ideas that provide distinct advantages in the product. No one but the product manager is situated in this position.
Thus, some members who are not specialists or don’t even work — almost like philosophers or men of speculation — generalists whose job is not to do anything but observe everything can generate disproportional value by combining together the power of most distant and dissimilar things, by finding what no one but they can find. They increase the quantity of science available in the business. They are the most knowledgeable men in a company.
Getting users to love the product
A lot of out of box designs, A/B testing, and customer interviews are needed to get to a product users love. The interest of the most prudent designer is to come up with the best design in the first go — with their expertise — to minimize effort and meet timelines. To align designers’ interest with overall success, the responsibility of early user involvement in testing prototypes and managing customer engagement to ensure enough user testing has to be owned by someone other than the designer.
Where’s the spanner
A CEO’s judgement might be limited to whether a feature works or not, a sales VP’s to how easily it sells in the existing market (by additional propositions it creates to show/sell users), a designer’s to UX (prestige, look and feel), and a developer’s to its technical complexity (and dependencies on other systems). None can see the whole picture and agree on anything that compromises their stake. When agreements cannot be reached, endless discussions lead to design by committee => klutzy product hugely compromising user’s needs (think of My Airtel App). To navigate functional turfs, someone who understands all these perspectives and has the interest to listen to each stakeholder, measure trade-offs with all needed knowledge is indispensable. Only he can span functions and switch perspective from say delivering superior value to market in meetings with tech and design teams to achieving market share and revenue goals in meetings with sales/external teams. Only he can decompose cross-functional problems and solve them in direction of overall value to the customer and prevent bloated products built with a lot of money in a lot of time that don’t solve customer needs. By virtue of overall understanding and a higher interest that aligns all teams, he sets expectations with the product team, manages their workflow and decisions, and empowers them by procuring what they need to meet those expectations. Hence he’s not part of the product team, but he manages the product team.
A shared understanding of what is to be done is key for large teams to produce anything. In the absence of someone who is organized and can lay clear strategy in running documents around vision and strategy of the team, neither management knows what to expect (and is worried), nor the team know what to build. Since there is no leader among them who they can approach or have faith in, they feel disconnected or else they flock to management for direction. Conversely, if an organized PM can gather information informally and crisply define the target — the ‘what’ (instead of the ‘how’), and manage the delivery of this target, then everyone is aligned to the same north star (document or prototype). When PMs publish documents and prototypes, it opens the design process to the team and creates clarity — and also gets management buy-in (as they can now see) to allocate resources. This extends to taking written positions on important issues — e.g. architectural choices, product decisions, markets to attack, etc. — without which serious product flaws can go unnoticed. Without this clarity, there’ll be too much rework and frustration, and no one can know what or who failed.
Maintaining stakeholder confidence
CEOs/management own capital risk and take allocation decisions no one else can. They cannot process detailed documents like the rest of the team. They need high-signal (insightful), trustworthy conversations/updates to summarise how things have been in the last week/month/year. These updates should be proactive and clear, anticipate and answer their concerns (demonstrate value or loss) and should not hold back how good/bad things are to enable execs to contribute and swiftly act if needed. Without someone with this key ability to effectively summarise status in 1–2 lines to answer ‘what is going’ and ‘how are things’ questions — with always too much going on — execs will soon neglect the project, then throw it off their radar and finally abandon ship. I know this from experience.
Moving pieces with soft hold
There is good reason why product teams shouldn’t report to product managers. It is also the reason why CEOs and management can’t do the job. Pride of man makes him love to call the shots (order around) whereas he is humbled by having to persuade his allies. Hence if he can he prefers subordination of his aides and tends to boss around. However, product teams produce best work if they can think freely and are motivated by their own interest. Strong teams can’t be controlled — they can only be organized by someone with superior vision/taste who can subtly pump energy in them, make them believe in what they can do and that they can, identify and build leaders in them, and give them ends, means and tactics to work.
With time this position becomes pivotal in information flow and keeps up the morale of the team. Without someone in this position to uphold the vision and convince engineers and designers to get behind it with zero authority on their day-to-day, quality of the product team and their output can’t be maximized.
Custody of right decisions with long-term perspective
Many decisions are taken day-to-day by design and development teams. Many of the choices therein look similar except in long-term effects which causes much discussion and still bad decisions are taken to be reversed or repented later. A technology prophet who can foresee the effect of every such decision w.r.t. the company’s vision and predict how it will turn out is thus needed. A product manager with ample perspective in technological innovation who keeps in mind where users’ priorities will be 5 years in the future (and not just the present) can best appraise these decisions.
Someone must work to determine and declare what’s the best way for the product to succeed in a short time. He works to answer whether an idea will work or is working in the market, which small outcomes should be chased to lead to the bigger one, how should the product be designed for maximum effectiveness, and how much it will cost in labour and time. He understands complex cause-effect relationships among factors in the business for e.g. how much does unreliability of internet speed on mobile affects market share and achievement of AOP numbers. He should know multiple ways to reach strategy milestones because at times teams can insist and be inflexible (or constrained) with their way. His absence means the absence of a product strategy => whether an idea is working in the market can’t be determined, and without a plan, the same things take up much more men, time and energy.
Also, to ensure product milestones are hit, someone must ruthlessly prioritize activities. All user groups can’t be pleased at once. Everything can’t be done together.
Sounds good doesn’t work — who is keeping score?
Problem with strategies is that many seem good intuitively but don’t work due to bad assumptions, missing factors, and interdependence between factors. Someone must devise mutually independent metrics that correlate highly with objectives and set up tools to track user actions and system data. In the absence of correct metrics and measurement, you can never know what’s happening, what went wrong, why is the product succeeding and how much can it succeed. If you cannot measure it you cannot improve it.
Metrics based culture
A measurement approach to all aspects of business is necessary to reinforce good decisions and to build a shared understanding of the working strategy. Detailed goals can be measured by highly correlated metrics and factors responsible can then be altered to optimize the metric. A culture of accepting experiments and data to dissolve deadlocks between teams and to set performance objectives has to be built. Only the one responsible for those objectives will have the interest to do it.
Promotion of product (evangelism)
Marketing teams do this at large but someone has to own the GTM strategy and constantly feed them with the product’s proposition and initial collaterals they need. Without promotion within the company, products can go under without good marketing. Everyone on the team should realize the power and proposition of the product to do their best in making it a sustainable business.
Of tasks and priorities
Tackling value risk
Depending on how far the company is from product market fit — whether the company is a startup or an established product, one day a week to one day a month goes in product discovery interviews to address value risk. This means getting in touch with users, who are the ultimate source of truth and can’t be wrong, collectively. These interviews could sometimes be focussed group discussions with marquee users but mostly the idea is to get people of different profiles in a room, make them use your product and observe where they get stuck. Listening and watching without leading or intimidating users is key because customers never give direct answers but they expose a list of problems with their usage patterns.
Discovery of components to build or improve can also come from wants and needs (discussions with) business customers and internal teams like sales, support, and marketing. In particular feedback of engineering team often has great ideas that sometimes can floor you.
Holding the fort
Most product managers analyze usage metrics at the start or end of every day with analytics tools, high-signal reports and alert systems on key services. These set a concrete understanding of limits and base rates (normal usage values) in the PMs mind so when something breaks, they’re the quickest to know what or if not what, where might something be broken. This keeping of score is key to improvement over time, generation of insight and avoiding significant business loss.
To keep current on management’s radar, PMs send concise, high-signal status reports (a combination of carefully selected metrics and data points to describe product success and progress of ongoing releases) once a week/fortnight. These summarise overall performance numbers like growth and conversion rate, value gained from previous releases, schedule for the upcoming release with features and expected increase in business value for each feature, and whether things are as per plan and justify resources vs returns. These reports contain strategic business insights based on metrics to assess how the product is doing — going up or down, and actions needed from management. While they’re always concise, they never conceal how good or bad things are so that execs can swiftly act as needed. After sending these reports, PMs necessarily communicate them verbally (the report is actually for PM’s preparation, to get management’s attention and for their notes) to obtain stakeholder buy-in and feedback. Additionally, they actively send emails, ping on slack, etc. when required to not fall off their radar.
Design improvements to make the product easier to use are key to making the product a sustainable business. To incite design changes and to coordinate on UX with teams — design, business, and engineering, PMs make wireframes and low fidelity prototypes almost every release. High fidelity prototypes to test the experience with users (and arrive at design solutions that work better) are made mostly by design team, but PMs conduct and measure the interviews with the designers to inform design changes out of them.
Pacemaker: control the speed the team works at (coordination)
PMs work daily with engineering, QA and analysts to implement release items. Sprints (software development cycles) are held (mostly bi-weekly) from inception through implementation to identify and mitigate bottlenecks, balance business needs with technical constraints and maximize business benefit with providing great customer experience. A short digestible update summing features completed in the previous week and work planned for the current sprint with anticipated risks and roadblocks is sent to the team for their reference. On alternate days, standups (scrums) are held to gauge progress, diffuse any blockers and discuss changes in specs with design and business teams as needed. Any open questions or concerns from the scrum are logged on JIRA or scribbled in team-chat to be resolved later in the day. Once a spec is written, it’s shared with tech followed by a spec walkthrough — then tech takes time and validates the requirements — thereupon spec is changed and finalized. They keep everyone on the same page and also build trust in the team with active listening (caring about what they say), empathy and credibility. PMs have clarity of stance (a firm declared position) at all times on all issues but are willing to change immediately if new information indicates otherwise. This ‘strong views but loosely held’ approach maintains clarity and doesn’t let momentum slow down due to any lack of clarity across the team. Lastly, PMs have fun with the team and keep it light by sharing funny incidences that happen across the team, bringing doughnuts during night-outs, etc.
PMs regularly meet stakeholders from business, finance and support teams to identify their pain points and explore product improvements. These teams often demand features they’ve seen in competing products or what customers ask for. While most of their requests are due to lack of clarity, some are important discoveries. To resolve these, root cause analysis with the 5 whys technique is done to define the problem at its core and then get a hint of best possible solutions that need to be tested with prototypes whether they solve the problem.
The initial groundwork for every product is:
- Finding a basic value proposition (MVP) for customers w.r.t. customer need, company capabilities and competition
- Specifying goals for the product, initiatives to achieve them, targets/milestones/metrics to reach after discussing with business stakeholders and then with tech and design
- Measure success/fail of the first cut once launched and then chart the way for product success over time
For running products PMs plan every week, because any current strategy is always falling apart (sounds good doesn’t work) due to complex interdependence among factors which are discovered in product discovery and usability experiments. When you build something only then can you know how users react. Thus, a key part of planning every week is running experiments and shaping the core product documents (PRD and Roadmap). PMs analyze usage data and work with customers and key teams to gather new business requirements and write functional specs that are part of core documents. The PRD exacts what components are required to fulfill product goals in detail and the product roadmap details strategy and prioritization of features — i.e. which features go first and which ones are queued based on value, risk, and complexity of implementation. It’s a fairly large backlog and needs to be prioritized every week. Product Roadmap is a running doc of the company’s product strategy and forces a timeline on all initiatives. In line with product and release roadmap, PMs coordinate all activities, communicate to business teams and customers what to expect, ensure launch checklist and work with marketing to force the GTM strategy.
PMs also devise and maintain go to market (GTM) plan which describes all marketing and promotional leg work required to reach customers and distribute the product to the wider audience. It keeps in mind that not all user groups can be satisfied all together, and with every launch identifies target demographic (with user personas) addresses core value proposition (with user stories) for target user segment (supported by collaterals, etc.), factors of differentiation from competition (USPs) and alignment with brand position of the company and its overall product strategy.
PMs also (infrequently) do competition analyses, pricing and profitability analyses to gain market share and budgeting and effort estimation for new initiatives.
Of skills and style
Every day, PMs write documents and make decisions on tiny details to big ideas involving tech, design, and business — in this order of frequency and mostly reverse order of significance. Although they always chase business outcomes and not the output of tech or design teams, they can’t NOT know tech and view their products as a black box which functions magically because engineers are talented. It removes them from discussions about trade-offs, technical possibilities, and state of tech advancement of the product. Similarly, to test products with users and arrive at effortless and intuitive products, they must deeply understand human behaviour and UX principles. Only when they understand the whole picture can they appreciate the work tech and design teams do and hence build a sincere understanding with them. Every PM, therefore, must understand business, design, and tech — in that order.
To stand-in for management and keep their goodwill, a PM must be exceptional at summarising meetings in 1–2 lines to answer ‘where are we’ questions effectively in person as well as by honest, concise documents sent on time to stakeholders. While there are many skills to help a PM, effective communication is the single skill no PM can survive without. This one skill of being extremely articulate, honest and disciplined must be practiced and improved with feedback from management.
Product discovery skills
To know if the product is working or what’s lacking, PMs must be skilled at discovery interviews (user testing), collecting feedback from major sources and what metrics to measure depending on their industry. Facts are outside the building — PMs must be comfortable going out of office regularly to bring in market data — like the king who roamed as a civilian to check on his kingdom’s welfare. Surveys are a great tool to gather lot of data with little effort, just if they:
- have simple, clear and NOT leading questions
- source email/phone number to get in touch
- are not too long
Prototyping — building quick wireframes and mockups is at the heart of getting to better UX. To assess users’ motivations, behaviours, concerns and selling/impact points, understanding of design principles and human behavioural psychology is needed. Knowledge of what the best products in the world do and how they do it can help build a great taste. A sense of bad UX — dark patterns, infinite scrolling, popups, image carousels, etc. is a good filter. To brief users in experiments and to help them in general, PMs must understand users’ context, POV, and use familiar (their) language.
To lead without authority, PMs tap into incentives/interests of everyone in the product team so that the team knows they’re the means to them getting their interests. Helping everyone in the team grow builds healthy relationships at every node. To grow the feeling of belonging in the team, growth path of team members should be set s.t. they achieve n+1 (next level) performance at the earliest. PMs manage conflicting interests between teams, so insight into teammates’ lives and commitment levels matters. People like to be led by leaders who see them as individuals, rather than means to an end. Fear and doubt are useless emotions for PMs — they must rely on teammates => trust the squad to do their jobs well to harness its power.
To get respect in the team, PMs must exhibit a desire to chase higher, long term rewards by taking greater risks and embracing bigger changes. This is key to everyone in the team getting more. Thinking small is a self-fulfilling prophecy. Incremental change is just adjusting for inflation. Additionally, PMs should uphold the product vision and hold a high moral ground so the team intrinsically looks up to them. Lastly, PMs must have great judgement and strong instincts that are right, a lot. This is built by a habit of taking multiple perspectives to disconfirm their own beliefs.
PMs understand their unique value add and play their position. In Star Trek reference, PMs need to think like Spock and lead like Kirk. Spock keeps a low profile, is disciplined, calculative and thinks in pros/cons. Kirk is fast, speaks up, leads meetings with his heart, takes tough calls with confidence, defends people — you get the picture. The image of the PM in the team should be OPEN, HONEST and TRANSPARENT.
PMs must be extremely capable communicators across all levels and disciplines, and clear presenters, too. Their ability to interact with, present to and distill feedback from stakeholders of varying backgrounds should ensure everyone is evenly filled in and have absolute clarity on what’s going on. No one should be left in the dark or need to set a meeting with you. When faced with ‘where are we’ question, they should be able to rattle out progress quickly in 1–2 lines. Good PMs modulate their part to the team’s convenience:
- Go pitch mode with a concise finished document (like a keynote presentation) with the leadership team
- Detailed spreadsheets with calculations in strategy discussions with business teams
- Balsamiq/Adobe XD prototypes inside the product team (designers and developers)
- For cross-functional collaborations, trim long documents (like PRD, Roadmap, etc.) to product briefs containing hypothesis and strategy (requirements, plan, and costs)
PMs often need to negotiate and should know principles like mirroring their tone and body language to the other side’s, lose the battle to win the war, take time against a hasty decision and use Socratic questioning to open up options. If the other side folds too quick — it could be because you didn’t ask for enough or they have a plan to minimize costs (ears up).
Among the product team, active listening is key to build empathy. Everyone in the team should be able to disagree and yet commit wholly once a decision is taken without any impact on team cohesion. Socratic questioning is a good way to establish the truth of things. A PM should earn the team’s trust by:
- Treating the inner circle like family with long term personal relationships
- Establishing credibility with a firm understanding of the product, users and problem space (market)
- Upholding a clear vision, belief in the end goal and a high ethical bar
- Holding his beliefs strong — i.e. always having a clear stance — but at the same time willing to change immediately if new evidence suggests so
- Having fun. Bringing doughnuts in night-outs. Making them laugh — I generally do this by passing on anything funny that happens across the team to keep it real and light.
PMs are made for speed. This translates to quick decisions. Many actions are reversible and do not require too much study — calculated risks must be taken. PMs exercise judgement and never slow down team momentum. If a decision is complex, set aside time and resolve it then. Product strategy is adaptive and changing plans are okay — don’t be a stickler. Move Fast.
Some red flags to watch for:
- Never step on toes of tech, design or business teams or you’ll be alienated right away. This will be a fatal blow you might never recover from. Never let this happen. Trust your teams to be the best in their areas. Don’t try to trump them.
- Arguments when you have no data, evidence or key intuition about user needs. Intuitions are mostly shared or at least felt by everyone. Rethink if you’re the only one feeling something.
- Inflated sense of purpose and pressure leading to a personal ego. Humility goes a long way in product teams.
First, PMs must immensely care and be accountable for what they build with a deep sense of responsibility for what is shipped out into the world under their name. Problems should not happen once the product is out there.
A good PM, from his experience in product design, has a great taste/instinct in products. He understands what the best products in the world do and how and often reads the opinion of leading product experts. To ensure correct decisions are taken, PMs must understand the big picture of the product and its business, and should be able to rate the importance of things from an overall perspective. Since the real targets where true returns lie are always in the future, they must build foresight by making 3, 5, 10-year plans and revisit them from time to time.
PMs have a strong understanding of the underlying technology and architecture on which the product runs from a CS degree or other technical foundations. PMs understand the value chain of the company and how strategy levers like price, selection, availability and speed, user experience, customer support, convenience, discovery, content (like reviews), speed of fulfillment, brand recognition, personalization, etc should be optimized to gain over competition.
To devise and iterate on strategy, PMs must be good with frameworks like business models, SWOT analysis, Porters 5 forces, etc. and governing dynamics of success in their industry. They must understand the profitability and all possible pricing models of the business better than everyone in the company. They must understand all costs incurred or likely to be incurred and be able to estimate/budget projects flawlessly. They should know how to conduct market research — build customer personas, talk to customers and to-be customers to gather requirements and insights, and analyze competition in the market. They should be curious and take actions to explore new possibilities that can add to product success over time.
While building a product strategy, customers are more important than competition. PMs obsess over customers and work backwards to the strategy to earn and keep the customer’s trust. As the product strengthens, they simplify the way things are done by inventing or bringing in innovative systems. PMs are frugal and always looking to accomplish more with less. There are no points for increasing headcount or burning money. They keep auditing usage data at multiple levels and often delve into detail when metrics don’t meet strategy narratives. Delivering results is part of planning — Good PMs rise to the occasion and focus on key inputs to get them right in time.
Product strategy is based on data gained by experiments. Strong analytical and quantitative skills, attention to detail and the ability to use data and metrics to validate assumptions are key to get started. Then, PMs must hone structured thinking to solve design problems. They should have a system design mindset to think calmly through context, assumptions, use cases and build all scenarios to which a problem extends before thinking of solutions. Key aspects of system design like availability, speed, security, concurrency, costs, etc. must be thought in all scenarios.
Prioritization is another key skill in planning. PMs should be able to manage multiple projects and responsibilities. They must know what they can sacrifice, calculate outcomes and ruthlessly prioritize, with the accountability of results. When they prioritize, they make their stance clear to everyone. PMs should be good at release planning and execution.
PMs are the most organized lot in the team. They prepare well for meetings => ask right questions, drill in the right spot and make sure meeting objectives are met. They think deeply about the meeting objective and ask questions throughout the meeting to steer towards set objectives. They keep a range of minimum to maximum expectation from the meeting and try to get as much as possible before getting out.
PMs are good at writing. They have good copywriting skills and document writing skills (PRD, Roadmap, etc.). They also understand marketing (specially digital marketing). PMs read as much as they can to stay current and be the storehouse of ideas in product planning. They often think and read about scaling to realize the company’s vision.
Organizing and optimization Skills
PMs must keep score and deeply understand industry base rates to optimize upon. This means to set up robust tracking on product use, manage and observe multiple systems, set up careful metrics and reports and finally, the discipline to go through the numbers every day. With time this renders a finger-tippiness with data and ability to weave insightful stories from data without any help.
PMs need to work on a lot of internal and third-party tools. Some tools they need to be familiar with are:
- Spreadsheets (Excel, MySQL datasets, Google spreadsheet), note taking apps (Evernote, Confluence, Docs), prioritisation frameworks like Eisenhower matrix
- Task management systems like JIRA, ASANA
- Wireframing and prototyping tools like Balsamiq, Adobe XD, Marvel app, Sketch
- Survey tools like SurveyMonkey, Twitter Polls, Google Forms, etc.
- Customer communication tools like Intercom
- Personalization and notification tools like Clevertap, Webengage, Evergage, etc.
- Roadmap, strategy documentation tools like Prodpad
*Lastly, any successful PM must know how to give a great product demo.