Product Manager Operations and Responsibilities
The Product Manager role can vary greatly. I recently developed the practice for my company. After compiling a comprehensive package of process documents, templates, and role descriptions, I wanted to add a brief high-level outline of the major activities, that if done well, would provide a high likelihood of success. Here is that list of activities and operations that handle by Product Manager.
The Problem and Thought Leadership:
The Product Manager must understand the problem statement. What is this product trying to solve and for whom? The Product Manager should continually evaluate the solution against these inputs and focus on prioritizing what brings the most business value.
The big picture:
Once a solution has been chosen, prior to the engineering engagement, the Product Manager should map the full scope of work. It should be defined with enough rigor and detail that the engineers can create DB models and the product architecture. This will keep the work focused and uncover a roadmap of decisions, dependencies, and integration points to be worked out to develop Product Management.
The little picture:
With a strong solution scope, the Product Manager should start at the top of the priority list and work their way down adding complete clarity and definition to each feature.
The Product Manager should stay in front of the engineers so by the time they get to a feature, they can develop it without any ambiguity or lingering requirements questions.
Always be unblocking. The content in the two previous bullets will naturally uncover blockers. Product Managers must quickly locate the source of the block and reach out immediately as needed to the appropriate persons. If the current approach isn’t doable, the Product Manager will determine what are the alternate options and choose the best path forward.
Product Managers should always be aware of the current and projected budget. In agile, the scope and roadmaps are ever-evolving based on stakeholder feedback and the effects on a budget should be kept in sight.
The product manager role is tough and comes with stress, high expectations, and moments of self-doubt. Coordinating the balance between a plethora of teams and managing the sky-high expectations of leadership is no small task.
But harnessing the knowledge and expertise of your engineering team, fellow Product Managers, and mentors can smooth out the rough edges and pump up the probability of success. Rely on the team, believe in your own abilities, and trust the process.
Innovation is a term that penetrated the business and technology lexicon ages ago and still billed as the only way to stay relevant in the information age. New product entering the market? Innovative. Software update? Innovative.
Slight refresh of a couple UI components? Innovative. When everything is labeled as being innovative, nothing really is.
Businesses forget that as they’re managing and developing in-house innovation hubs
, other companies are doing the same. Absolute progress continues to move forward, but relative positioning stays exactly the same. The tech industry’s own version of the Red Queen’s race. To compete in today’s markets, we need to chase disruptive innovation.
The goal is to build products that become so deeply entrenched in our psyche and daily ability to function that we couldn’t have imagined life before without it. To do this, we need a strategy. In this blog, we’ll examine ways to put together product documents, develop strategic plans, and touch on other considerations a product manager needs to be aware of in the scope of their project.
A Product Manager is tasked with creating a tech product that produces a solution to a problem that currently exists. If you view your product as a black box that magically functions because your engineers are talented, it removes you from a discussion about tradeoffs, technical capabilities, and the state of tech advancement.
Just as important as the tech itself, the user experience and design of the product needs to be distinctive. Why is Uber so successful when taxis were readily available to the masses? Because it enabled the user to call a car, set a destination, and pay for the service in an effortless and intuitive way.
The design is rapidly shifting from being a brief afterthought in the product timeline to placing itself at the forefront of product success, so learning how to test the experience with users and crafting a plan for designing solutions that work as intended should be part of the core ethos of every product manager.
Great Product Managers have foresight into the future that isn’t immediately clear to the rest of the world. Everyone can spot current market trends and tell you “what’s hot” this year, but what about the next three, five, or ten years?
Putting together a complete roadmap, requirements document, and business strategy is mandatory for any Product Manager, so we’ll dig into the best practices for drafting up these artifacts as the blog naturally progresses.
“Congratulations! On behalf of FutureTech Labs, we are delighted to confirm your offer to join our team as a Product Manager. We look forward to hearing your decision soon…”.
After months of heads-down study, carefully honing your craft in dimly lit coffee shops or co-working spaces, and guzzling five-hour energy drinks, you’ve finally secured a role at the company of your dreams.
After a brief orientation period, you receive your top-of-the-line, fully loaded MacBook on your first day at work, with a shiny employee badge with the title “product manager” superimposed over a less-than-flattering headshot taken of yourself weeks prior.
You feel energized, proud, and ready to execute on your Steve Jobs-style vision to elevate the organization to heights it has never seen. In your first 100 days, you focus on setting up one-on-ones with engineering and design teams, introducing yourself to leadership and executive management, and drafting up a strategy for the next year and beyond.
Six months later, the dream suddenly becomes a nightmare. Your enthusiasm aa nd false sense of pride will transform into a vicious cycle of feeling defeated, stressed, and frustrated by the lack of movement. The initial product roadmap you developed was detailed down to a T, but the engineering team hasn’t bought into your goals, and you’ve failed to make any significant progress. Leadership is pissed, and your confidence is at an all-time low.
If the picture I’m painting seems bleak and hopeless, then I’ve done my job of alerting you early as to what happens when you don’t follow the guiding principles of product management. If you walk away with anything from this blog, I want you to remember the five basic principles that could make or break your introductory role in product management. From the day you sign on the dotted line of the employment contract, your presence is instrumental in the success of the team.
Often, capable Product Managers fail early because they don’t recognize the core principles of their field, and misinterpret the expectations leadership has set for them. Let’s dive into the five cardinal rules of product management and break them down in understandable terms.
Accept them as dogma early, and you’re immediately in a headspace that prepares you to tackle any issue, technical or political, that presents itself in the work environment you’re thrust into.
Kill your ego
A product manager has an enormous amount of responsibility, sometimes more so than other roles within an organization. However, the inflated sense of purpose and pressure can lead to negative consequences, including feeding directly into a personal sense of ego.
A product manager that views himself/herself on a pedestal when compared to his or her peers is losing sight of the goal of building an incredible product.
A raging god-complex isn’t the least bit productive, and humbling yourself from time to time can foster the growth of a cooperative, collaborative environment.
You’re not the expert
As much as the Product Manager is the “CEO of the product,” it doesn’t issue you carte blanche authority over every layer of the product, both architecturally and design-wise. If a conversation arises around the tech stack that should be used, loop in the tech lead / CTO. For tasks involving user experience flow design or UI frame mockups, bring in the designer.
Trust your teams to be experts in their particular area, and argue back only if you have data, evidence, or intuition about a user’s needs to support your claim. Stepping on the toes of the engineering, design, or business team is the quickest path to alienating yourself, so understand your unique value-add to the team and play your position.
The only exception to this rule exists in startup land if a company isn’t able to hire a dedicated tech lead, designer, or business strategist, so the Product Manager (with relevant background experience) plays more than one role simultaneously.
The tech industry moves at light speed and waits for no one. A fresh hire Product Manager may be overwhelmed with the number of decisions that need their green light and can fall victim to analysis paralysis if too much time is dedicated to overthinking simple choices. If you’re writing five-paragraph essays for emails that only require a one sentence approval, you’re wasting time for both people across the wire.
Whether you’re supporting your decisions with blind intuition, empirical data, or team buy-in, the Product Manager has to take the reins and exercise good judgment to keep the chains moving. Don’t slow down the timeline bickering over minor details.
Find a method to understand the order in which decisions need to be made. Insignificant tasks (e.g., wording on the landing page, stock image selection) can be deferred, whereas strongly linked action items need immediate attention to prevent a sequence of events from being delayed.
For complex decisions, set up a dedicated time to mull over the details and come to a conclusion. Time is a luxury you cannot afford to waste as a Product Manager, so learn to consider the opportunity cost of each hour you spend on the clock.
Become comfortable with ambiguity
If there’s one word that perfectly encapsulates the standard product manager experience, it’s ambiguity. A Product Manager’s personal task plan is rarely ever set in stone, and you must embrace the feeling of being lost in the water. It’s OK to be uncomfortable, restless, and anxious.
A lot can change over the course of a product development Management timeline, especially if you’re dealing with multi-year projects, so learn to adapt early and remain flexible enough in strategy and mentality to deal with unexpected curve balls that will be thrown at you over time.
An average Product Manager looks to his or her manager to ask what needs to be done; a great Product Manager decides what needs to be done and looks to his or her superior to request the resources needed to execute.
Ask the right questions
Time is a non-renewable resource, and people don’t enjoy wasting it, especially in a work setting. If you’re in a meeting, user research interview, or client feedback session, it’s imperative that the questions you ask are clear, concise, and generate useful insight that can be looped back into product development Management planning at a later stage.
Asking an effective question is comparable to drilling for oil; if you do your research, prepare, and drill in the right spot, your yield will be high and effort will have paid off.
If you follow a strategy in which thoughts are disorganized and you start breaking ground in random places, you’re likely to waste time and walk away feeling distressed (with a bunch of empty holes on the ground).
Think deeply about the objective beforehand, and understand that the “right” question posed to another individual can make or break the interaction from a product value perspective.
The End-to-End Product Journey
Being aware of the traditional SDLC concept is useful for a product manager, but the linear nature of the phases don’t lend themselves well to describing iterative software development Management (covered in a later blog).
Instead, we’ll step through an unstructured set of principles to keep in mind when going from product inception to polished end result that is consistent with the way products are developed at top-tier startups and tech firms.
Step 1: Ideation
Believe it or not, the idea is the simplest part of this entire journey. How many people do you know that utter the following phrase from time to time “I had the idea for [insert innovative product here] first. I should have followed through”
Before Uber existed, TaxiMagic and Hailo did the exact same thing. Instacart and AmazonFresh had a predecessor called Webvan that raised close to $400 million but went bankrupt trying to do the same thing. The idea is just 1% of the equation; it doesn’t go anywhere without a ton of strategy, luck, focused decision-making, legwork, and clear execution that comes after it.
That said, if the core idea isn’t to sound, it dooms the product (or startup) from the onset. An “Uber for Nachos” is a ridiculously dumb service, and there’s no amount of execution or capital in the world that can make it a success. When brainstorming new products to build, ask yourself the following questions:
Is it useful?
Does the world need this product?
Does this product exist in the market already?
If it exists, can we launch a version which is a 10x improvement?
Is it feasible in terms of cost, time, and resources?
Does it solve an existing problem?
Why hasn’t the problem been solved already?
Everything you build should serve a purpose and alleviate the problem a user (consumer or enterprise) is facing. Otherwise, the product will end up quickly forgotten in the software graveyard shortly after launch.
Once you have an idea, put it down on paper by creating a PRD. We’ll go through a PRD and how to create one in detail during the product strategy blog, but in essence, it’s a document that describes the product, all of the features & requirements, and key details (timelines, risks, and so on).
Start it off with a mission statement or core objective, follow up with the internals of the product, and finish with how you plan to execute on the vision. If the PRD is less than ten pages, it may not be thorough enough, so add as much detail as you can so all of the obvious questions anyone can ask are answered.
Step 3: Assemble the right team
Technical talent is underrated. Regardless of the salaries, you see on Glassdoor or the fancy perks you hear about, people still treat engineers as an expendable resource. I can’t tell you how many times I’ve been to a tech mixer and hopeful entrepreneurs go around asking for free labor in exchange for 5 percent of their company, which is nothing more than an idea.
When assembling a team, align incentives. Everyone wants something at the end of the day: money, recognition, prestige, equity, and so on. If you’re a solo founder, find team members who are just as passionate about building something from the ground up.
If you’re a product manager at a major organization, round up members who want to start a new business line and eject themselves from a team that incrementally moves the needle each year.
Tips for team dynamics
Never prioritize talent over ego. No matter how skilled, ego will ruin the flow of the entire team.
Establish credibility. People will be drawn to your team if they feel like you’re the right one to steer the ship.
Be fair. Give credit where credit is due, and don’t overinflate your contribution.
Have a diverse mix of skills, backgrounds, and viewpoints.
Establish ground rules, set up one-on-one, and allow room for team members to air their thoughts and concerns on a monthly basis.
Step 4: Create a Minimum Viable Product (MVP)
The software isn’t cheap to build if you’re working with a team of experienced developers. Costs can easily cross over the million-dollar threshold if it’s a technically complex product, so finding cheap ways to confirm that users want the product before investing all the chips at once is a smart thing to do.
That’s where MVPs come in. An MVP is a proof-of-concept first version of the product that doesn’t contain every feature on the wish list but has enough functionality to be usable.
For example, if you’re building a massively multiplayer video game, build just one world first and test with users before developing the others. Or, if you’re building a robot that delivers toothbrushes and toiletries to customers in a hotel, have one of your team members dress up in a convincing robot costume and have them deliver the item to the user.
This may sound like a joke, but Star Wars has been using a human being to play R2-D2 instead of a mechanical robot, and Kenny Baker has done a pretty convincing job so far of making you believe it’s a real robot, right?
The user doesn’t know what’s missing and what’s been done intentionally. Using a bit of smoke and mirrors is okay if it prevents you from moving forward with a product nobody will use. In this phase, collect feedback from the user on the MVP, and note any changes, suggestions, or pain points that are immediately recognized.
Step 5: Establish a product-market fit
Product-market fit, according to Marc Andreessen, means “being in a good market with a product that can satisfy that market.” In other words, find a market that’s sizeable enough to be interesting, then find the right product to disrupt the market. The easiest way to establish product-market fit is to rely on traditional metrics of success (revenue, user base, engagement, etc.), but what if you have a product that is still in the early stages?
Instead of using indicators or metrics that only come once the product is already successful, you can get creative with your approach.
Enterprise: for internal products, use a newsletter or group alias to drum up interest.
Communicate the value proposition, then collect emails for follow up.
Startup: create visual media and spin up a campaign on a crowdfunding website.
If you can get orders before the product is fleshed out in the form of pre-orders, you’ll prove there’s a market for it.
The key takeaway from all of this is “don’t solve problems that don’t exist.”
Step 6: Don’t discount design
The design is a major driver of cash flow, but it’s often an afterthought in Product Management environments. UX / UI designers are an additional expense to a team, and costs are cut in the design department to focus more on pumping out functionality. To illustrate the importance of design, let’s look at Hotel Tonight.
As profiled in Fast Co. Design, Hotel Tonight was able to drive revenues up more than 10 percent by changing a simple confirmation logo.
10 percent! Users were accidentally blogging non-refundable hotel rooms because their finger would slip and hit submit, and this resulted in a high cost to Hotel Tonight since they had to process a wave of customer service requests to correct the mistake on the side of the user.
To remedy this, they decided to change to a checkout flow that involved the user tracing their finger over Hotel Tonight’s iconic bed logo. In this design, there is no possible way a user can accidentally blog a room, and it saved the Hotel Tonight time and customer service resources. Not to mention a sizeable annual revenue bump. The design is critical; treat it as such.
Step 7: Source feedback
The voice of the customer is always available to you in the form of feedback, but it’s a challenge to find the right way to capture it. As a product manager, you have to ask the right questions to mine the valuable info that can be fed back into the product. Surveys are a quick and dirty way to cast a wide net, but context is missed since you can’t ask follow-up questions in real time.
Interviews are better, but they require a time tradeoff. Find the correct balance that works for you, and use the feedback to continue meeting the user’s needs. Problems and objectives can change over time, and becoming comfortable with the product at a fixed stage in its lifecycle is not a mindset that will lead to longevity.
Sample Q’s for the user
What problem does this product solve?
Do you use any other products along with this one to accomplish the same task?
What can be improved? What is the product missing in your opinion?
What would cause you to stop using the product?
Is the product easy to use?
What are the key strengths of the product?
Would you recommend the product to others? Why or why not?
Step 8: Obsess over metrics
Track everything. Collect every shred of data that passes through your systems, then recognize the patterns that’ll lead to useful insights. A ton of users can tell you directly that they love your product, but if your monthly active user count is low, then the data tells a different story.
Use the numbers from logs and analytics tools to corroborate the stories told by users in surveys or vocal feedback sessions. If there’s misalignment, then you’ve found the disconnect that needs further investigation.
Step 9: Win or Learn
After the end of all the steps, the product can still fail. You could develop an MVP and drum up support, only to be crushed when the final version is out on the market. Factors out of your control can cause the product to slip, but how you react and learn from the experience is completely within your control.
If mistakes were made along the way, find ways to self-correct and adjust. If bad team members were chosen, make a mental note and promise never to repeat the same mistake. Everyone will have a bad product or two in their career. Whenever this is the case, spot the holes in the previous game plan and come back with the lessons next time around.
Analytics are everything
In the information age we’re currently occupying, data is king. Machine learning-enabled startups and products are being touted as the silver bullet to combat tough problems, and companies are investing heavily in data analysts and scientists.
The hype around learning from patterns in data is at an all-time high, and organizations want to cash in on the gold rush as soon as possible.
Putting aside the mania surrounding big data, the longstanding principle of “if you can’t measure it, you can’t improve it” still applies to every software product that is user-facing. User actions, behaviors, and patterns of thinking can be captured using a variety of techniques, and the data can tell us things about the product at a scale that aren’t immediately obvious when testing with a limited user set.
In addition, the data we choose to collect and analyze gives us a set of targets to shoot for. A mobile application may track one-time downloads as the key metric, whereas an enterprise application could focus on subscription retention or churn as a guiding data point.
A product manager routinely needs to communicate progress and product success to an audience of stakeholders, and a combination of carefully selected metrics and data points can be the best way to describe the current state of affairs. Data analytics serves to provide insights, rank the user’s flow of attention, and help Product Managers make better business decisions.
Analytics vs. Metrics
Before we start talking about the types of metrics to collect and the analytical tools to use, we need to define the two terms to solidify our understanding of the distinction.
A metric is a unit of measurement that tracks one point of data.
Analytics are the output of the process of transforming raw data (metrics) into actionable and strategic business insights. In other words, using the metrics you’ve collected to answer previously unanswered questions.
Analytics and metrics work hand-in-hand: first, we come up with the right metrics to track, then zoom out and examine the relationships between the collected data.
Selecting metrics for measurement
There is no “one magic metric” that every Product Manager needs to flag for collection. Collect too little data, and you run the risk of missing patterns that lie below the tip of the iceberg. Collect too much data, and you could lose time parsing through all the information (especially if the repository is sizeable in nature). At a high level, we can hypothesize the general questions we want to answer through our metrics:
Do users like the product?
What causes users to stop using the product?
How do users find out about the product?
What features do users love? Hate?
Are users able to navigate through our product with ease?
What drives revenue in our product?
What can be improved?
Once this is set, huddle with the team and management to think through the success criteria. Is it to maximize revenue? Grow the user base exponentially? Sunset (remove) features that aren’t well performing or frequently used?
Brainstorming will align goals, and you can form the metrics around the main product objectives. Metrics that guide key decision makers are called key performance indicators (KPIs). Companies will tie KPIs to financial, business, and other success criteria, and setting a mix of realistic and stretch goals for the KPI goals keeps the team focused and efficient.
Types of metrics
Metrics indicate success or failure in whatever you’re measuring, but without categorizing them properly, you could end up mixing one type of metric with another, leading to messy final insights and scrambled reports.
To cover all of the bases when choosing trackable metrics, answer the following questions in the six categories as you put together a data analytics strategy: financial, business, product, process, people, and user. Use the categories and questions to frame the thinking when making the conscious decision on what to track versus what to ignore.
How much money are we currently making?
What are the revenue goals for the next year? Next 5-10 years?
What are the biggest financial risks for our company? Industry?
What is our annual growth rate?
What is our projected market share?
How will we handle competitors?
What partnerships can we strike with industry players?
What acquisitions can we make?
What problem are we solving?
Do people care about the product?
Do they naturally recommend the product to their friends and colleagues?
What features are unused?
Does the product perform well?
Are we effectively following a framework or process for development Management?
What are the primary concerns around our current processes?
Do we document enough?
Are we using the right software tools?
Are people happy in the organization?
Do employees feel satisfied by the work they’re doing?
What’s the best way to reward high-performers and vice versa?
How do we incentivize the team
Who is our target demographic?
What will cause users to stop using our product?
What will users pay for the product?
How closely do we examine direct user feedback?
Metrics that matter
In the search to find the perfect mix of metrics to harvest, there are a baseline set of data points that need to be mentioned. Every product will not find the following list of metrics relevant, but in general, they’ll come up over and over again in product discussions throughout a Product Manager’s career, and knowing the meaning behind the name and/or acronym is handy.
The number or percentage of users that complete a desirable action or goal (e.g., clicking on a banner ad or subscribing to a monthly service).
The percentage of users who leave the website or app after the first page or opening interaction.
The percentage of users who leave or stop using a product or service within a specific timeframe. Also referred to as the attrition rate.
The percentage increase of a unit of measure (users, revenue, etc.) over a period of time.
Customer lifetime value (CLV)
The amount of revenue expected from a single user through the lifetime of their engagement with the product or service.
Monthly recurring revenue (MRR)
Measurable and predictable revenue per month calculated by multiplying the number of users with the amount paid per month.
Daily / Monthly active users (DAUs / MAUs)
A number of unique users who actively engage with the product or service on a daily or monthly basis.
Average revenue per user (ARPU)
Total revenue divided by the number of total users.
Customer acquisition cost (CAC)
The cost of acquiring a customer (marketing and promotions) divided by the number of customers acquired during a period of time.
Customer satisfaction (CSAT)
A percentage or numerical representation of the user’s level of happiness or satisfaction with customer service interaction
Drilling Deep with Google Analytics
Google Analytics is a robust analytics engine developed to help websites maximize advertising return on investment (ROI) and track detailed behavioral metrics.
A grouping of high-level metrics is shown (Users, Revenue, Conversion rate, Sessions) along with sections to go deeper in the left-hand navigation pane. Google Analytics splits the reports into four sections: Audience, Acquisition, Behavior, and Conversions. Since the tool collects so much information at once, the subsections are helpful when honing in on related slices of the analytical data set.
For a product manager, the behavior flow is a critical view to develop familiarity with. It tracks the number of users who touch the landing page and shows a raw user count for each set of possible interactions that users could follow in the product. This report can identify areas with high rates of exit, and confirm if the product is intuitive enough to guide users from start to finish without hand-holding.
Experiment with the Google Analytics dashboard and make a note of the sections of data that suit a particular product’s industry, type, technology stack, and use case. Then, create a set of reports that return only the set of numbers you need to make informed decisions. Everything else can be treated as random noise.
Google Analytics: Advantages
Here are the advantages of Google Analytics:
Powerful: loads of functions and reporting capabilities integrated into the platform.
Easy setup: simply inserting a snippet of code gets the tool up and running.
Free (for the basic tier): no cost to low-traffic products and/or services.
Cross-platform: records analytics on the web, mobile, and other devices.
Customizable: flexibility of the tool allows for the product manager to create product-specific reports and data captures.
Documentation & training: the community for GA is vast, and tons of tutorials exist for learning the ins-and-outs of the platform.
Common across the industry: almost all companies in advertising, e-commerce, and marketing use Google Analytics (or are aware of the tool). Knowing and understanding the platform is a transferable skill no matter where your career takes you.
Think about requirements
After pain points are considered, the stage is set for requirements collection. The final outcome needs to be an exhaustive list of mission-critical features all playing a distinct role in producing the best possible product in the end.
For example, if this a toaster for blind users, using visual cues are not the optimal way to describe the state that the product is in, so we can explore other ways like the use of auditory feedback or tactile feedback through the use of braille characters, universal symbols, and so on.
Create a list of everything that will contribute to the final design, and keep the user’s needs at the top of mind when jotting them down. Just remember that a massive laundry list of every single feature or function is not the right way to go; this doesn’t show creativity or strategic thinking. Instead, focus on the innovative new goals you anticipate the user accomplishing with your requirements baked into the final output.
Understand the market
After the requirements have been defined and finalized, the next step is to understand the market. At this stage of the game, you need to ask yourself questions along the following lines:
What is the total market size for this product?
How would I raise awareness of this product’s existence?
How would I source feedback on the quality of this product and how well it satisfies user needs?
How would I price this product?
What are the metrics for success?
Quite often, back-of-the-envelope calculations can be made to size a market in a rough and dirty way based on limited information. Let’s walk through a sample estimation question together.
Arrive at a solution
After considering the markets and end users of the product, you’ll arrive at a final solution for the conceptual design. To maximize the accuracy of your solution, keep the following in mind:
Focus on clarity
There is no correct answer for an open-ended product design question; only your answer. Back it up using your own perspective, and stand by the decision you made. In real life, new product innovation will follow a similar process of research, design, and iteration, and flexible thinking is absolutely necessary to come up with a reasonable solution.
Pressure test your solution
In a work environment, your product roadmap and vision will constantly be called into question and attacked. As the leader, it’s your job to not only put the team at ease but ensure them that you’ve thought through all of the areas of concern.
In the toaster prompt, most people immediately think of toasters as they exist today, and marginally improve in one way or another. But what if you proposed an entirely new solution? The “job-to-be-done” is toasting pieces of bread, so why do we automatically assume the current technology satisfies this requirement in the most optimal way?
Coming up with brand new, untested solutions can be refreshing, and provides evidence of creative thinking. Thousands of items from the past haven’t been improved upon for centuries (check out Bill Gates’ condom challenge), so reset your thinking and disregard the norms set beforehand.
Users, including yourself, are generally lazy and impatient. We don’t like to wait for pages to load, hate long sign-up flows, and despise the idea of a shipping window that exceeds seven days. Our attention is currency, and companies are doing everything they can to keep us coming back to their products.
Every point of frustration, every ounce of friction, and every moment that makes you say “I must be dumb…I can’t figure this out” is all contributing to the user experience of the product you’re interacting with. To better explain the idea of user experience, let’s walk through the process of attending a football game.
Browse tickets, purchase a seat, then print on paper and bring to the venue. Once you get there, stand at the security gate, pick up concessions, and walk to your assigned seat. At each interaction point in this user journey, elements of the event chain can make or break the experience. Ticketing agency website running slow?
Leave and go elsewhere. Only expensive seats left? Oh well. Security line taking forever? What a waste of time.
User Experience (UX) vs. User Interface (UI) design
Simply put, the user experience is the ease of use and enjoyability of using a product, whereas user interface design is concerned with the look and aesthetics. For example, the simplicity of putting headphones in your ear that automatically connect to Bluetooth as soon as it senses your ear is UX, and a glossy, colorful body to an app or website falls in the realm of user interface design.
User experience is criminally underrated, partially because it is still misunderstood. A near-perfect user interface doesn’t automatically aid the user in reaching an end goal state without UX considerations that are baked into the design process. Factoring in time for UX research and paying close attention to end-user interactions can debunk assumptions made about whether a user does X or Y when they have your product in their hands.
UX principles to live by Considering the following five principles:
Don’t make the user think:
A momentary pause confused look, or a full stop in engaging with the product are clear signs that something is wrong. If users can’t figure out how to use something within a couple seconds, then it’s a product issue.
Trust established design patterns:
Names and logos of products/services are left or center aligned at the top. A hamburger or three bar icon signals a settings drawer. A scroll bar indicates a high-low setting for a component. Years and years of product use has primed us to engrave certain types of imagery into our mental model. Don’t reinvent the wheel and send the user on a wild goose chase for the areas they’re familiar with or expecting in a complete product.
Add moments that matter:
Small UX Easter eggs delight the user and convert them into a walking billboard for your product. Take special care in crafting the experience and remember that user experience is a journey, not a destination. There is no “perfect experience”. Improvement is ongoing.
Hideaway the details:
The user doesn’t care how the metaphorical sausage is made. Hideaway technical details and keep the internal exposure of the product to a minimum, unless it enhances the experience.
Keep it simple, stupid:
Each additional screen or click is a potential dropoff point. The more inputs, the higher the likelihood of the user abandoning the flow.
Blue underlined text
sends an implicit signal that an element is clickable. A progress bar tracks a moving state for completion of a task. An envelope communicates a mail or inbox function. Our interactions with technology and software in the past have developed patterns in our mind that are intuitive and easy to follow.
When designing products, keep track of consistent themes previously used and tap into them. Using help text is necessary when explaining complex actions, but proper visual affordance cues can clear up chatter on the digital canvas and present a cleaner look. Symbolism is a core part of UX, and affordance helps translate concepts and ideas from the physical space to software.
Three upward curved lines to represent Wi-Fi
Magnifying glass for “Search”
A country flag for localization
Grey out elements to indicate inactivity or disabled features
Red text or icons for incorrect inputs or “Danger” signs
UX Research Techniques
Let’s go through some useful research techniques.
A persona represents an average user of the soon-to-be-developed product. It can range from brand-obsessed individuals to elderly folk who have special considerations. Developing a diverse range of personas help understand the unique needs of each end user, and puts the team in a space to put themselves in lives of the people they don’t have time to interact with.
A persona can have as much or as little detail as the team needs, but the exercise is crucial to understanding motivations, behaviors, and concerns each profile will inherently have.
To further inquire into the daily habits of your potential user base, pursuing a diary study can yield higher-fidelity results. A diary study involves recruiting a random, representative sample of key user personas, and asking them to record their day-to-day routine in blocks of time.
At the conclusion of the study (or during regular checkpoints), the diaries are collected and examined to pool feedback into the product pipeline.
If time is of the essence, and the Product Manager requires a larger pool of participant responses, conducting surveys can be a worthwhile use of time and resources. Craft a set of open, clear questions and deploy to hundreds or thousands of people at a time. Using a service such as Amazon Mechanical Turk can widen the number of responses for pennies on the dollar.
Tips for developing targeted questions
Decide whether to use open-ended questions (fill in the blank, paragraph responses) or multiple choice. The results will vary based on which method is agreed upon.
Source email address or phone numbers for additional follow up (with consent). You will want to speak with a small group who provide unusual or interesting answers to the questions posed.
Simplify the question set and use language that is universally understood.
Avoid bias and loaded questions. Swinging the user in one direction as they’re thinking through a response taints the entire exercise.
Don’t ask too many questions. The response quality and rate drop as the question base grows.
Additional UX research and information gathering methods
As we’re only covering fundamentals, we won’t have time to go over every single method of UX research. As a follow-up activity, I urge you to delve into the techniques below and find the right mix for your projects.
You may find surveys ineffective, but usability testing highly effective for your purposes. Experiment, learn and try again until you have a tried-and-true system.
Bad UX examples
using greyed out or hard to click “X” or “Close” buttons. Hiding functionality is frustrating and if the user wants to leave, they will. Keep everything in plain sight.
a continuous scroll on a web or mobile product can exude polish and slickness, but it’s an abysmal experience for finding content hidden deep in view. If you have content that spans multiple refreshes, it’s better to think up a new model for display to the end user.
Liberal use of pop-up content:
Pop-ups are slowly phasing their way out, but certain companies still use them to punch you in the face with ads or marketing content. The conversion uptick is not worth the friction, regardless of how subtle it is.
Use of an image carousel is fun, but as with search results, people only pay attention to the first or second frame that is displayed. If you have content that requires user attention, a carousel isn’t the ideal option of framing.
Identify your own in the software products you use, and think up ways in which the bad UX decision can be substituted to clear the path for user success while increasing conversion, engagement, or another desired metric for the organization.
The Good, The Bad, and The Unusable
If you haven’t had the pleasure of reading “The Design of Everyday Things” by Don Norman, stop what you’re doing, fire up your Amazon account, and go purchase it. If you’re turned off at the thought of adding yet another blog to your growing reading list, the visual learners should check out Tony Fadell’s TED talk titled “The first secret of design is…noticing”.
Why all of the recommendations? Because I want you to care about how your product looks, feels, and operates. Plenty of times throughout your Product Manager career, you’ll be tasked with building a product that is unsexy and bland at the surface.
It could be an HR application, internal developer portal, or proof-of-concept scheduler, but you’ll approach it with the enthusiasm of a college student taking the SATs. After all, you have to take a couple of losses early in your career so you can work on flying cars, artificially intelligent robots, and other cooler projects later on, right? Wrong.
A Product Manager can take any mundane software offering and turn it into a product that delights the end user. Workday (an HR application) is a friendly, bright platform that takes the guesswork out of payroll and employee/benefits information.
Salesforce (a customer relationship management platform) innovated by taking a space crowded with monolithic platforms and moved the practice of managing client contacts into the cloud.
Countless examples exist of applications that maneuvered a boring space and found a way to differentiate themselves, creating a billion-dollar company in the process.
The end user is highly impressionable when new products hit the market, and your job is to identify the latest trends, forecast a user’s needs, and cater to them in the simplest, most straightforward fashion. In this blog, I’ll walk you through a handful of good, bad, and unusable products, both in the realm of technology and elsewhere.
I want you to pay attention to the small points of friction, areas of improvement, moments of delight, and overall user experience the product is meant to deliver to the customer. Interweave form and function into an intuitive and functionally sound product, and the user’s hearts will be won forever (or at least until the next big thing comes along).
All the technical and design skill in the world won’t save you as a product manager if you’re lacking the number one skill required to succeed in the role: leadership. If you enter a team, establish yourself in your new role, and nominate yourself as the go-to resource for managing the development Management of a new product, you NEED to understand the “soft skills” that come into play when managing conflicting sets of interests.
Strip away the titles, meetings, and day-to-day tasks, and you’re left with a group of regular human beings who are coordinating their time on this earth around a common goal. Engineer A may be in the middle of selling his house, Designer B may have been passed up on a promotion twice, and Marketer C may be going through a divorce.
Although all of this could seem like personal issues that should be abstracted away from a person’s ability to perform at work, they matter.
If you’ve done research around hiring at enterprises, you’ll see a bit of literature around the “layover test.” This states that if you have two candidates who meet a baseline level of skill required for a position, you should choose the one you’d want to grab a drink or coffee with during an airport layover from destination A to B.
As simple as it sounds, people like being around people they like. More importantly, they want to work with people who see them as an individual instead of a means to an end.
Tips to lead effectively
A good leader knows when to keep their ears open and their mouths shut. Being attentive and responsive tells people that you care about what they have to say.
Understanding one another fosters trust and realizing that human beings don’t exist to check off tasks at work goes a long way. If someone is going through a rough patch or dealing with difficult circumstances, step back, put yourself in their shoes, and act based on the holistic view of the situation.
Understand the user, market, product, and problem space. Even if you lack the technical or design chops, a firm understanding of the industry landscape is enough to add value.
Don’t pull rank to push a point forward. Use data and rational insights to break down ideas that aren’t feasible instead of brute forcing your viewpoint on the team.
Follow a “yes, and…” approach by extending thoughts previously suggested by team members and flexing them to reflect your ideas. Directly criticizing and shutting down team members disrupts the creative flow and adds tension to team dynamics.
Set a positive example:
Carry yourself with a sense of purpose, establish a high moral and ethical bar, and praise team members and peers who exceed expectations.
Rally around a vision and a clear set of goals:
Believe in the end goal so passionately that the team has no choice but to align themselves with you.
Establish strong views, but keep them loosely held:
Keep a firm position at all times in regard to approved decisions, but be willing to change at a moment’s notice if new information that counters the original hypothesis emerges.
Learn to communicate ideas
We all know the saying: “communication is key.” Key to a good relationship, personal satisfaction, and life success. In product management, the same sentiment still holds true. People want to know what is going on with a project, and knowing the “right” way to communicate to an audience can set the stage for you to shine as a product manager.
When it comes to matters of relaying information and translating complex thoughts through speech, the Product Manager’s approach will change based on which of three stakeholders they’re interacting with: team members, upper management, and users.
Communication: Upper Management
Managers, executives, and board members have no interest in a verbal essay of the product development Management gameplan; they only want to know that things are on track and on budget.
When communicating upstream, keep in mind that they don’t have visibility into the day-to-day, so the Product Manager’s goal is to select the major themes of the past week/month/year and find a medium to communicate this in the most effective way.
A poor sense of communication can cast a black mark on a Product Manager and prevent them from being at the table for important conversations, so practice speaking to leadership and ask for feedback after the session for the sake of continuous improvement.
Keep it concise:
Executives and senior managers are busy people. Cover the major points, and leave enough room for clarifying questions. Anticipate the value they’re looking to extract from the conversation, and tailor your presentation to fit this objective.
Send emails, pings, or Slack messages to constantly engage members of leadership when appropriate. If you fall off their radar, it can be hard to build the relationship later down the line.
Avoid general answers:
For one-on-ones with line managers or directors, don’t answer with “everything is fine” or “I’m fine” every time. Don’t be afraid to bring points of concern to their attention, and never hold back when things are falling apart (or when things are successful!).
Focus on business value:
Saying “feature X, Y, and Z have been implemented” isn’t useful to an individual in leadership. Instead, hone in on why it’s important for pushing the business forward and adding value.
For example, “Feature X will allow us to track the number of users who convert based on the ads we’re deploying, allowing us to allocate marketing spend more effectively” is a solid way to signal that the feature has been marked done, and the resulting value-adding effect of deploying it to the customer.
Press releases, help center documentation, newsletters, and media announcements are all examples of ways the company will need to communicate offerings to the customer.
The product manager will directly or indirectly touch each form of user communication and frame the correct tone and language to connect with the target audience.
A game manufacturer will want to use engaging, explosive language to promote a new first-person shooter, whereas a B2B enterprise startup needs to invoke a sense of professionalism and credibility with their communication strategy.
Understand the audience: Align yourself with the user’s point of view. Use language that is familiar and easy to comprehend.
Simplify: Don’t overcomplicate for the sake of sounding professional (except in rare cases). Stick to tried and true methods, but never speak down to the user or insult their intelligence.
Personalize the message: Users don’t want to feel like they are one of a million others in a calculated batch. Targeted outreach with a personal touch can go a long way to leaving a lasting, positive impression.
Study indirect channels of feedback: Internet forums, comments, and other ancillary channels of user engagement are a gold mine for tapping into the voice of the user and capturing their raw, unfiltered response to the product or service.
Communication: Team Members
Open. Honest. Transparent. When delivering news to the team and communicating progress, it’s imperative that everyone is evenly filled in. Team members should not feel out of the loop or feel like they need to set up meetings with the product manager just to stay updated on what’s going on.
To kickstart a Product Manager’s communication model, the following set of channels in the figure below can be leveraged to make sure knowledge distribution is widespread and nobody is left in the dark.
Treat the inner circle like family: Whatever the Product Manager knows, the team knows. Be liberal about disseminating information, and the team’s trust will be won sooner than later (or never).
Create an open atmosphere: Debate, discuss and encourage discourse in a safe, collaborative space.
Don’t play the blame game: Mistakes and wrong calls are a given in the Product Management workstream, and pointing out individual slip-ups isn’t productive. Focus on the lessons learned, and don’t dwell on failure by singling out members who made an incorrect decision.
Establish a lasting personal relationship: Eat lunch, go bowling, or grab a beer with team members. It’s much, much harder to work with people you only know on a superficial level.
The Art of Negotiation
I recently went to a car dealership to purchase a new vehicle. A mix of excitement and nervousness rushing through my body on this monumental day, I stepped inside the building with an idea of the estimated trade-in value I hoped to receive for my current vehicle. After viewing the car I wanted, I sat down at the negotiation table and shot across my trade-in offer.
The dealer representative paused, said “I’ll speak to my manager” and went upstairs, and came down a few minutes later. He agreed to my dollar amount without countering. Ecstatic and surprised, I happily continued with the process and purchased my new vehicle. In retrospect, it’s clear to me now that I lost the negotiation.
Negotiations are never easy. If the other side folds immediately, it’s because you didn’t ask for enough or they have a game plan in place to mitigate the expected loss on their end.
The same is true with software and Product Management. A product manager will often be in the business of making tradeoffs and convincing people to do things they aren’t necessarily thrilled about.
To soften the headache of negotiation, the Product Manager can use a set of tried and true conventions to sway the verbal tug-of-war in their favor.
Mimic the movements of the other person, repeat their ideas back to them before framing your own opinion, and match their mood and cadence.
Listening to your inner EQ:
Observe visual cues (e.g., is the person in a hurry? Are they constantly checking their watch?), pick up on microexpressions, and get a sense of their immediate reaction to statements you make. If the conversation is not progressing in a positive direction, be able to adapt on the fly to avoid damaging the negotiation.
Avoid haste decision-making:
Do not commit (or overcommit) to anything based on just one discussion. Let the points stand, and give everyone time to sleep on it. Often times, if the other party is willing to immediately accept a path that leaves them with the short end of the deal, that should be a red flag signaling to you that time is needed to think through all possible exit scenarios.
Lose the battle to win the war:
Aggressively pursuing a win in each debate will land you in hot water and mark you with a toxic reputation. Find strategic moments to give in and accept a less favorable outcome to position yourself for a pivotal win in a future negotiation.
Chase cooperative agreement:
Win-win scenarios do exist. If option A and B are being negotiated, but a third option C naturally emerges which is beneficial for both parties without as much compromise from either end, then it should float to the top of the list of acceptable outcomes.
Personal Product Management
In the chase to develop timeless products, paying close attention to personal growth is imperative to climbing the ranks and adding more responsibility to your plate as your career grows. The quickest way to maximize learning potential and level up fast is to use the resources directly around you.
Seek out 2–3 senior managers/executives within the organization who can guide your career. Studying their path and understanding their trials and tribulations effectively prevents you from hitting the roadblocks that they’ve bumped into in the past.
Use internal tools and shared community resources to create a culture that nurtures and develops product talent within the company. Share best practices, artifacts, and tips to help each other reach a state of collective product excellence.
Positive feedback is great for self-confidence, but negative feedback is where the gold lies. Ask teammates and colleagues to provide detailed feedback from both ends without restraint, and put together a plan to flip your weaknesses into strengths.
A product manager level 1 should strive to perform at a Product Manager level 2 standard, and a Product Manager level 2 should constantly work at a Product Manager level 3 baseline, and so on. Never settle on performing at par with the current state job expectations; aim higher and set a trajectory that exceeds the bar.
Budgeting & Estimation
When the CEO is putting together a budget proposal for the year or new Product Management is scheduled to kick off, the recurring question that comes up is “how much do we need for product and engineering?” For a new Product Manager, it can be daunting and overwhelming to come up with a solid figure.
When assigning dollar figures to a proposal, keep in mind the following expenses:
Software licenses (task management tools, source control, project management platforms, etc.)
Hosting (cloud and bare metal servers)
EquiProduct Management (computers and hardware)
Third-party development Management
Miscellaneous (travel, food, hotels)
development Management operations (penetration testing, moving from development Management to production, etc.)
Once an initial estimate is calculated, run it by the engineering managers, other product managers, and anyone else who has experience in this space. Everyone will have opinions, but if you reach a state where the estimates are all within an acceptable range, then you have your rough number.
Dealing with vendors can either be a headache or pleasure depending on who, what and how much. At some point in your product career, you’ll have to either rely on a full-time dedicated vendor team to understand your creative vision or supplement an internal workforce with outside talent to pick up tasks that the main team doesn’t have the time to execute.
When sourcing a third-party vendor, you will come across tons of developing Product Management shops (domestic and international) that want to bid for your budget. Finding a trusted vendor and establishing a long-term relationship is what every product manager hopes for, but in any case, it’s wise to remember a handful of guidelines when hiring contractors.
Double check the SOW (Statement of Work): The SOW details what needs to be delivered, as well as the expenses associated with final handoff. Run the SOW by the legal team and ensure that your organization is protected in the event of unsuccessful completion. The SOW is the trusted handshake between two parties, so make sure everything about the project is included in this document.
Fixed vs. variable cost: Some projects will be a fixed fee, others will vary based on time committed. Be sure not to assume that a variable price contract can’t go significantly above the agreed upon rate (hint: it can).
Agile vs. waterfall: If the development Management team is using agile methodologies for software development Managers, it can be tough to set an end date to the project. Don’t make recommendations to management that ties the team to a fixed month and day. Add buffer in the timeline and keep estimates to a 2– 3-month window to be safe.
Controlling scope: The SOW doesn’t list every feature and design requirement, so it’s essential to sit down with the vendor and use the PRD as a blueprint. Understand that scope will change throughout the project, and features can be added/dropped based on velocity and other considerations.
Product Requirements Document (PRD)
Writing a comprehensive, detailed PRD is a task that separates the good Product Managers from the high performers. The product requirements document is a manifest of all the features, requirements, and considerations identified before kicking off formal development Management. It communicates what a product should do, and the assumptions made prior to a deeper analysis performed at later stages.
A proper PRD contains the following pieces of information:
Header / Authorship: Title and names of all the authors (usually the product manager with contributors)
Project Objectives / Goals: Purpose of the project, and the goals needed to be met once development Management is over.
Scope: Describes the product, and specifically mentions the out-of-scope requirements left for another version.
High-Level Description: Short description of background/context, product information, and industry landscape.
Stakeholders: All of the non-team members with a vested interest in project execution and success.
Project Team: Lists titles, roles, and responsibilities of each member in the product development Management team.
Product Overview: A longer, detailed view of the product discussing the key outcomes and features of this release.
Functional Requirements: Requirements that describe what the product should do (e.g., the system sends an automatic email confirmation when a user is added)
Non-functional Requirements: Requirements that describe how the product behaves (e.g., the product should have an uptime of 99.99%).
Proposed Tech Stack: Runs through the software stack and the rationale behind chosen technologies.
Timelines / Milestones: Estimated time window to completion along with pivotal milestones.
Assumptions: Describes conditions which are thought to be true upon the start of development Management.
Risks / Constraints: Any and all risks that can throw the scope, budget, or timeline out of whack with mitigation plans for each. Also, constraints that limit development Management are included in this section.
Future development Management: Plans for the next version of the product and deferred feature sets.
Open Questions: Unanswered queries that need to be clarified or closed out.
The roadmap is the living, breathing representation of the company’s product strategy. It communicates the now, next, and future development Management plans, and tracks the state of live products and their development Management paths. A roadmap can be represented as a thorough document, or mapped in a tool like ProdPad or Aha!
Here are the product roadmap goals:
Measure progress against KPIs and trackable metrics
Provide view on every product in the portfolio in one centralized place
Secure buy-in from leadership and related stakeholders
Tie product success to business goals
Provide visibility for the internal teams to understand where the products are headed
Rally around a unifying mission statement, and use this to direct decision-making
Fear is a useless emotion in product management. The analysis, decision-making, and research conducted before the product steps into development Management should give the Product Manager enough confidence to jump into the unknown without being held back by fear or doubt.
If the team senses that the Product Manager is unsure about the product path, it can cause a domino effect that can hurt morale and team motivation. If the road chosen returns nothing, go back and pick a new path.
Don’t ask permission, just ask forgiveness
Corporate bureaucracy and red tape can hinder your ability to innovate. On one hand, rules are put in place to protect you and the company. Sending unencrypted emails containing sensitive information to vendors and skirting the process designed to secure data to save time is a bad idea.
But, there are grey areas where calls need to be made, and you don’t have time to pull together every single point of approval. Exercise good judgment, but bend the rules where necessary.
Don’t always rely on “best practices”
Best practices were put in place based on observations from history. If 100 projects all used one method and 95 percent of them succeeded, the process is documented and branded as a best practice for all teams to follow. Often times, there are “better practices” waiting to be discovered.
In essence, a best practice is just a baseline; it’s what everyone else is doing. As the timescale changes from year to year, the same recommendations won’t work. Find new ways to improve on the status quo, and refresh the thinking each year so you’re not relying on outdated models of thought.
Embrace exponential thinking
Human beings are bad exponential thinkers and predictors. If we’re asked to predict the next 20, 50, or 100 years of technological development Management, we’d be terribly inaccurate once the time has come and passed. This handicap restricts us from seeing things how they will be instead of focused just on how they are.
The next century will be defined by those that can make calculated bets on emerging technologies that will outlast the hype. Train yourself to accept and anticipate radical change, and find a way to put yourself at the bleeding edge so your job isn’t on the chopping block as a direct result of exponential tech growth.
Dealing with failure
Failure is not an end state; it’s a minor road bump along the path to success. I’ve never known a product manager who had a perfect record when it came to product deployments, so don’t set unreasonable expectations for yourself. If a launch or decision ends up producing results you’re unhappy with, go back to the drawing board and start over.
Being frustrated in the aftermath of a bad call isn’t productive, but using the learnings to influence the next iteration may lead to a home run the second time around.
Never underestimate the power of luck
Success is not 100 percent attributed to skill and hard work. Luck can be the factor that makes or breaks a product, and doing everything you can to maximize the amount of luck that falls on your side is a wise decision.
For example, if a cybersecurity startup is entering the market, a string of hacks that pop up at once can be a golden opportunity to reach out to the companies affected and negotiate a contract to provide products or services. Capitalize on acts of God or dumb luck moments, because you will need a lucky break every once in a while to provide relief and dissolve pressure from the team.
20 Questions and Answers for a product manager
How do I hire a product manager?
Carefully. Pulling people from related roles like technical program manager or finding strategic thinkers from areas like consulting can be the best bet if your organization hasn’t formalized internal requirements for a product role. Since the role is still relatively new, there is no prescribed way to hire strong Product Managers. Talk to leaders in the community, source their advice, and above all, tease out critical thinking ability in the list of candidates you interview.
What if the organization I join doesn’t understand the product role?
A common issue. Companies, especially non-tech firms, will either convert a “project manager” into a product manager to capitalize on the buzz surrounding the role or will hire a product manager and stick them with marketing and customer service responsibilities without any direct pull on engineering or the product being built.
If you’re outside of the organization, ask questions during the interview and be sure the role involves touching the core product. If you’re inside the organization, approach the top-line management leader and set time on the calendar to discuss expectations for a Product Manager role and provide your two cents.
Often times, leadership is willing to make changes because they’re under the assumption that nothing is wrong. Be a voice for the product, and build a product culture that you’d be proud of, piece by piece.
What if I have a limited budget for product development Management and engineering?
A tight budget is not necessarily a bad thing if you’re tasked with producing an MVP. The scope for an MVP is limited, and non-critical features can be stripped away since it will be used as a proof-of-concept to test the market. However, if you’re building a V2 and beyond the product, it can be difficult to push ahead without adequate resources. Going with cheaper development Management is an option, but it can come with a quality tradeoff.
The best move forward is to communicate the final deliverable with a $ budget to leadership so they are well aware of what is realistic and show them a mock or improved version of the product that can be built with the $$$ budget. It could be a useful tactic to convince them to allocate more funds, or it can just set expectations accordingly if you deliver a subpar product with the resources you were given.
What if I’m not respected?
Find a way to earn it. People are motivated by incentives, and those who don’t respect you feel that way because of something you did or didn’t do, so think of ways you can attract others by helping them help themselves. Pull people into a meeting, ask them for advice, or send them documents for review. Small moves that make peers feel included and showing them that their opinions are valued can go a long way.
What can I start doing today to flex my product management muscles?
Create a product in your free time. Put together a business plan, go-to-market strategy, mock PRD, mock roadmap, and use Balsamiq or Sketch to put together wireframes.
If you have the resources, find engineers who can build it and manage the development Management journey. Or go online and donate your product management skills for free to build experience and a portfolio of pro-bono projects. The best way of learning is doing, so get involved.
Is an MBA required to be a product manager?
No. An MBA can help solidify the business fundamentals, but it can’t immediately make you product-ready. Utilizing 2 years on a full-time program can be valuable to some, but others will be better off in the workforce for two years. If you can work full-time and get a part-time MBA, even better.
What are the growth opportunities for a product manager?
There is no glass ceiling for a product manager. Sundar Pichai (Google) and Marissa Mayer (Yahoo) are examples of product managers turned CEOs, so there’s no limit to how high you can go. Find an organization that has a clear promotion path, be impactful, and the rest will take care of itself. Join a startup as Product Manager #1 or an established company as Product Manager #1000?
This is a tough one and depends entirely on the person making the decision. I’ve boiled down a handful of pros and cons to each below.
Startup Product Manager #1
Control over the entire product portfolio; single point of responsibility for strategy
Lower base salary, but a high equity stake
The wider scope of responsibilities beyond product due to the size of the company (marketing, customer service, picking up takeout, etc.)
Limited resources and funds
Is it detrimental to my career to join a product team at a non-tech company?
Absolutely not. Every company will have a technology function, and non-tech companies are ripe for disruption. If taxi companies embraced innovation a long time ago, Uber would never have been launched and yellow cabs would have a stronghold on the transportation market.
I’ve heard Product Managers work 80-100 hour weeks. How do I avoid this?
False. Hours of work does not equal productivity. Every additional hour you dedicate beyond a reasonable threshold has diminishing returns, and positions you for burnout.
A healthy 40–60 hour work week is achievable, and it’s all about keeping track of priorities. Finish the urgent tasks first, say no to people to avoid over-promising, and treat your mental and physical health with the same level of care as your career.
What is the best way to rebound from failure as a Product Manager?
Rebounding from a Product Manager failure is like rebounding from any other. One must be able to be introspective without ego. If there is enough self-awareness to locate failure points, one can outline the mitigation plan, make the appropriate process updates, and start again. It isn’t about the product manager. It is about the product.
How would you go about hiring product managers on your team? Any specific skills that you’d look for?
In hiring Product Managers, I look for the following skills:
Diligence – If the Product Manager doesn’t know the tiny details, who does?
The sense of urgency – Product Managers set the mood and the pace of the project. There shouldn’t be stress--it’s a fun role(!)--but they should operate with velocity.
Lack of ego – This will help make the environment transparent and the faster Product Managers can admit mistakes, the faster they can course-correct.
Multi-tasker – In a project environment, problems don’t come up in an orderly fashion. Product Managers must be able to juggle and disseminate new information, prioritize, and lead the team through the evolving roadmap. Project needs are what set the work and schedule.
Good Instincts - Everyone can be trained to be a better manager but there are those who have better managerial instincts. While knowledge of a given field is extremely valuable, I’ve found more success with those who have the right instincts about what to focus on and what questions to ask.
Without intimate knowledge of the product, those with better instincts can still know where to obtain the necessary information and still make the right decisions for the product.
What misconception do people generally have about the product manager role?
I think the “CEO of the product” description of product management can lead people to believe that the role is fully autonomous and that they will get to make all the decisions. This isn’t the case.
Effective product managers collaborate, communicate, and influence. They align teams behind a shared vision and strategy and enable that team to make great decisions that are aligned to the goals of the business.
How do you deal with failure as a Product Manager?
The default state of any product is a failure. As a product manager, you need to create a path to success and remove the roadblocks that block that path. This doesn’t guarantee success, of course, and when you eventually fail, you need to look back and understand the factors that caused the failure.
Was it poor product-market fit or poor execution (or both)? Could more resources have solved the execution failure? Was the product too early or too late to the market? Was the niche too small or the competition too intense?
Understand the reasons your product failed (and remember, the product failed, not you!). Do a post-mortem of what, if anything, you could have done differently to change the outcome and either share it with your team or keep it to yourself depending on the culture and temperament of your organization.
Once you’ve internalized what happened and what you could have done differently, take a break and move on to your next project. A good Product Manager has a long list of projects they want to actualize.
What is one thing that Product Managers can do immediately that will improve the way they build world-class products?
Go visit some customers and once you’re done, go visit more. As I love to say to my students at Carnegie Mellon, ‘the facts are outside the building’. It’s so tempting to get trapped behind your email and attending those “critical” internal status meetings. However, world-class products are LOVED by their customers and it’s so important to talk to them to make sure your product is getting that love.
What advice do you have for a nontechnical founder who wants to raise money and build a tech startup?
First and foremost, you need to recruit a technical co-founder. Keep in mind that technical leaders have a lot of options at this point. When you ask them to join you, they aren’t going to simply build what you have in mind without any input or questions. You need to convince them of your vision and specifically that you’ve done the hard work of talking to customers to validate elements of that vision.
If so and it excites them, then you can discuss them investing the most valuable asset they have (their time) into your startup. At that point, it makes much more sense to talk to investors about raising money as the team is such a key element of any early-stage investment thesis.
If you exercise the part of your mind that gives you a competitive advantage over the competition, you distance yourself far away from the rest of the pack. Our approach will be to introduce the three pillars of product management and set the introductory seeds in your mind so they grow over time.
The sharpest Product Managers who I’ve personally had the pleasure of working with have a potent mix of each individual area of study: technical, design, and product/business strategy. This doesn’t mean you need to transform yourself into a rockstar software engineer or UX designer to succeed as a Product Manager, but building awareness of the terminology and raw concepts can go a long way in a conference room.