Share

Product Management has changed dramatically over the last 10 years. What was once an amorphous concept (“wear lots of hats”) became the Hot Thing, and then a well-worn position with university certificates and an MBA pipeline.

Every product team I've worked with has been vastly different from the last. While approaches and expectations vary, there are some directional changes affecting all of them. Here's what I've observed from the teams I've worked with and the nearly 50 PMs I interviewed in 2023:

It’s harder to find meaningful problems to solve

As software has eaten everything in sight (and no, the buffet is not actually unlimited), the simple stuff has been taken by a kajillion different SaaS offerings. The tried and true customer discovery techniques have already plucked the ripest, juiciest fruit, leaving little else for the taking. This applies to both startups seeking product market fit and growth stage product teams looking for next opportunities. Despite having an excellent-but-creepy tools like Gong to surface ✨Insights at Scale, going through The Process (e.g. call seven customers, ask the seven why’s, rank the pain points by the framework du jour, build an MVP, run a beta) increasingly looks like pushing paper around. Even worse is roadmap by sort, arranging all the garbage in the backlog by various dimensions.

👉 Don't expect the answers to jump out at you - seek them out with deep curiosity and take bigger swings. Avoid the obvious, first pass solutions that might save a customer some marginal $s or hours in their day to day. Contained experiments and prototypes are still your friend, and you should deploy them against higher risk, transformational opportunities.

Perma-IC

Over the past several years, the idea of the dual track product career gained steam, and senior IC paths were commonly accepted by both PMs and employers. All of a sudden, this trend has bucked: companies see people layers as a costly and bureaucratic, and the management track is vanishing. Executives are increasingly suspicious of product people that don’t get their hands dirty (nor show tangible impact) and get better perceived value from 5 overworked solo PMs than from their expensive, handwaving boss. Added AI anxiety and continuied interest-rate-hangover layoffs have poured gasoline on this trend. I’m not sure it will hold exactly over a longer time span, but one clear trend over the last decade: growth in individual scope is far outpacing that in headcount.

👉 Expect to continue contributing directly for a longer time horizon and actually doing product work. This feels riskier, since there is no clean career path laid out for a cushier future, but is beneficial for your long term development and value. Increasingly, it can also pay quite well without the managerial junk. Recognize that this is a macro effect, and don't let your ego get in the way of your next career phase.

The average product is harder to ship

Navigating regulation and global scale requires more coordination with operations, security, and compliance teams. These are critical in a world run on software, but add to the onus of just getting something shipped. This is another factor in the presence of more veteran ICs. No meaningful projects are simple or risk contained enough for a junior PM’s learning opportunity. This upfront cost of shipping makes low-hanging fruit more elusive and requires more conviction to make the effort worth it. Orgs are easily dissatisfied with slow velocity, and it's a bad look to waste weeks negotiating the minutiae of a negligible improvement.

👉 While the days of moving fast and breaking things are over, the clever, creative PM can still leverage deep, nuanced understanding of the technology and the industry to identify faster paths to impact and learning. This is where the clichéd "thinking like an entrepreneur" is the most powerful thing you can do. You don't need to break the rules, but you need to be hellbent on moving things quickly. And when those things are mountains, find the boulders.

The role and output are as murky as ever

Airbnb got rid of PMs (spoiler: not really), Product and Eng leaders continue to battle for scope and ownership, and cycles are getting faster. There’s less space for the Product Definition and fewer outputs in the form of artifacts. Specs and other documents fall by the wayside when product minded designers and engineers can just start prototyping or shipping immediately after talking a customer. If they do exist, they're shorter and to the point. Increasingly the role of PMs is one of influence and shadow guidance; Something that's amorphous, and better noticed in absentia. This creates anxiety for PMs desperately trying to show their work, often resulting in write-ups and presentations no one cares about. For too long, PMs fell back on only doing this and calling it a day.

👉 Experiment to find the right balance of what your team actually needs to ship impact quicker, have an open mind, and stop doing rote chores. When dealing with higher-ups, it's often the score (number go up), that matters more than the inputs (look how hard I worked on this decision). You might actually find this freeing.

Roles are skewing more specific

As products are getting harder and the minimum stuff is disappearing, PMs need to skew towards domain or specialty expertise. Learning an industry on the fly and ramping as a generalist (something I’ve been adamant about doing repeatedly in my career) seems increasingly like an outlier case. Fewer open roles - and plenty of public company layoffs competing for them - lets companies double down on their perfect mold job description even longer than before. And combined with the Perma-IC and difficulty increase per product, the junior, generalist, and "learn on the fly" roles will remain rarer, until we get into the next economic cycle.

👉 Transferring between domains or specialties is still possible but requires more upfront investment. The best way to make these transitions is still to leverage whatever related experience you’ve got and sell it as a transferable base. But you’ll also need to be laser focused (and persuasive) on opportunities that immediately amplify your background.

Conclusion

It's bound to be a wild next few years for the industry and product management. I expect many of these trends to accelerate: the job will get more hands on, faster, and more difficult. The upside: PMs will have no choice but to increase their leverage, building teams, systems, and tools to do much more with much less, growing and developing impactful resumés as they go. Isn't that the definition of lean product development?

Typically, this is all well and good. But sometimes it leads to brute force thinking. Staring at a brick wall and engineering your way out of it can be more destructive than helpful.

I’m talking about cases when your product simply isn’t clicking. When you keep pivoting towards new segments or new iterations in order to finally deliver on the goal you staked in your spec.

One artifact of this stubborn thinking is the spreadsheet that flawlessly articulates the rational reasons why anyone in your target market should be using your product. This consists of models or calculators that show that your product produces value for the customer (“with us you get 200% ROI guaranteed!”). These can be useful sales materials, but should not be the sole articulation of your product’s value. The product (including landing pages and ads) needs to be able to speak for itself.

Inherent in these models is the belief that if you can just outsmart your (customer, market, business model), you can finally find the hack that makes your product work.

This is an approach well-loved by product geniuses, but it fails to depict the real world your product exists in. It typically comes along with a few flavors of bias:

Sunk costs

We don’t want to give up on something we’ve already built. So we iterate, add new features, and keep building. We don’t want to admit defeat because that would be a failure. This leads to endless iterations or - worse - reverse engineering problems to be solved out of something that you’ve already built for some other reason. This often hides under the guise of targeting a new segment or moving the goal posts.

Hubris

This is classic startup faith: believing that you know your customer’s market so well, that you anticipate all the things they need better than they do. When you are creating something new, you have to educate the market about it and make it a reality. This is critical for 0 -> 1 company building.

But once you are chasing product market fit (or beyond) this is a severe handicap on your thinking. If only our customers weren’t morons they would see that our solution prints money for them! If you face conflict here, you haven’t fully understood your customer. You may realize that the problem they want to solve (e.g. increase marketing ROI, content monetization rates, team productivity) doesn’t begin and end within the narrow scope your product lives in. Or they actually don’t care about the problem as much as you do.

Solutions

When we are laser focused on solutions, we lose sight of the problems they are meant to cure. For many people - particularly those with a technical or curious bent - it’s rewarding to tackle difficult challenges. This will send product teams chasing ever complex, sophisticated solutions. What else do you have to show for your work if not a brilliant solution? And what are you going to do with full engineering team if you could deliver results with a jenky, .csv-driven hack? You would be surprised how many projects are shipped that could have avoided altogether. This isn’t just about user facing features, but entire ML models or capabilities that optimize something that doesn’t actually need to be optimized.

What to do about it

Your products don’t exist entirely in financial models or spreadsheets. They are purchased and used by human beings. (You may get tired of that phrase but I will continue to use it).

Observe your actual users in your app

Product is an experimental process. No user testing or analysis perfectly simulates real life.

Find the heaviest users of your product. What are they doing? What are they trying to do? You will find much better insights here than chasing the ideal user that isn’t using your app.

This also requires that you get some level of adoption. If no one is using your product, start there. If someone is using your product, find out why! Not why you think they should, but why they actually use it. This can lead to surprising cases.

In the super early days, this might cause you to change your product and audience entirely. In more established days, this may inform your menu of features or how you onboard users. For instance, you may find that b2b marketers are using your product far more successfully than d2c ecommerce marketers and make the call to focus on their needs. There are plenty of extreme cases where product people stumbled into gold by identifying active users that had invented their own surprising use cases for the app.

The most helpful spreadsheet isn’t the one that you create, but the one your customers are using to patch together some broken process in your app or your problem space. That’s the one you need to concern yourself with.

If your customers haven’t created a hacky version (even an adhoc or manual process) of whatever your product does, they simply don’t care about it. Full stop.

Figure out what your customers are doing, outside your app

Your product never starts and ends with your product.

If you actually take the time to understand what goes on in their (home) office day to day, you will have a much richer understanding of their needs. You cannot get this level of insight without soaking up the experience of your users and knowing what they do before and after using your product. What other problems do they have? What are all the obstacles that they haven’t even thought to tell you about, because they seem so natural to their environments?

Read the tea leaves

Let go of your hubris and take a hit to your ego.

Resist the urge to model out all your problems. Maybe it’s time you talk to someone.

We like to believe the product genius myth: that products are the invention of a solo mastermind like Steve Jobs or Elon Musk. Product people are supposed to be visionaries. Not only should they have answers to everything, they should have the most sound, first principles-driven, perfect answer to everything. (Bonus points if this answer publicly destroys someone else’s opinion - what a genius!)

Are you a product genius? Let’s see some of the behaviors:

1. Insistent on making the decision; resistant to any alternatives.

2. Spends lots of time alone; presents ideas with the expectation that everyone will unanimously agree with the foolproof logic.

3. Organizes everything to their personal liking, at the cost of everyone else’s productivity (or sanity).

4. Torments candidates in interviews; only chimes in to discussions to outsmart someone else.

5. Defends positions vehemently. Gets flustered three whys? into a discussion.

Spoiler: No one wants to work with this person.

Product is a team game

While there are some brilliant creators and thinkers in the field, this myth hides the fact that products are delivered by teams, by dozens or hundreds of contributors. While product is often the face of the project, they do little of the real work (e.g. writing code, architecting systems, designing interactions). Instead they do all the other boring stuff to make the work simply work.

Let’s say you are effective as a solo decision maker. Once you’re managing multiple product lines or teams, you become a bottleneck and can’t scale. Congrats, your ego has won out and now you make 100% of decisions, but your product suffers. To counter this, you need to think about highest order outcomes and constantly find ways to remove yourself from the process. (Related: Applying Leverage as a Product Manager)

Everybody egos

Even though we may not behave like supergeniuses or egomaniacs, each of us is subject to ego-driven thinking. The ego protects our self-image from anything that might be painful or challenge the status quo. It hates other peoples’ opinions or any derivations from the master plan.

This has subtle effects on your ability to do product, whether you suffer from the obvious signs above or not. The ego often:

1. Blinds you from the important things you could be working on versus the ones that will increase your status.

2. Prevents you from considering great ideas that didn’t come from your own brain.

3. Makes you focus on appearing successful on surface, instead of being successful in the weeds.

4. Leads you to fix other people’s problems (or emergencies) to show them how valuable you are. Why bother with the hard work they don’t see?

5. Makes you avoid conflict or any hard conversations about your precious ideas.

Get uncomfortable

“Dropping the ego” is easier said than done. Changing your thinking is humbling and will take time. Start by reflecting on your own thinking and identifying some approaches for handling these blind spots.

A simple, tactical example: I avoid making any decision on the spot in front of people. I know that I tend to make crappy, fear-driven calls in the moment and only see issues objectively hours or even minutes later. Just hanging up the zoom will let my ego to stop clenching. Pay attention to your own instincts and behaviors and you’ll see these patterns play out.

When you let go of your ego, you’ll realize some important truths:

1. Looking dumb is uncomfortable but necessary. Asking questions everyone else is afraid to is painful now, but prevents disasters later.

2. You don’t really build anything. You are kind of like a coach: you might create gameplan, run practices, but you don’t get to step on the field. You are only successful by making the team successful. That’s quite alright.

3. You don’t get to take credit for anything. It’s a good thing, because it doesn’t last long anyway. Your product’s and team’s ongoing health matter more than one-off hits and praise.

4. You’re more creative as a vessel for ideas than as an imagination machine. Your range of possibilities and inspiration sources will have a step change improvement when you realize you don’t need to be brilliant on your own. Ideas already come from everywhere - you just can’t see most of them.

5. You will win more favor by delivering long term results than by always presenting super tight ideas but failing to ship them.

There are enough product geniuses out there. Drop the shield and get uncomfortable. You’ll see that many obstacles are entirely of your own making.

As product people, we naturally focus on tangible, swipe-able software we create. The product (ux, app, etc.) you manage is only a sliver of the Product (sum of the benefits you’re delivering) your company delivers.

Here’s a good foundation of this concept:

The complexity, context, and difficult stuff is hidden deep underneath the surface. Everything from minute technicalities to big picture strategy gets mixed up in the murky layers below the product. Acclimate yourself to this setting - it’s where you’ll be spending your most important thinking.

When you dive into these waters, a new picture will start to emerge. You’ll start to see your entire company as a set of systems for delivering your Product. It is a product in and of itself.

You’ll see the machinery actually ticking. Some parts may be well-engineered and precise:

Others parts are messy or adhoc. They may actually be “uncharted” until you map them out.

👓 Critical lenses to understanding how your product ticks

Product is a discipline of lenses. You need to see problems from many angles, all the time. To do product IRL, you need a holistic understanding of everything.

Here are some common angles you need to understand your Product from. There are many others based on your unique situation - but here’s a good foundation.

Map out a model (on a whiteboard, mindmap, or post its) for each of these sub-systems. If you find it too complex to fit into one view, create several separate maps.

1. Financial - How does your product actually make money? What are the fixed and variable costs of delivering your product and what drives them? How and when does money flow through the system?

2. Technical - How does the product technically work? Where are the limitations / opportunities? What happens in real-time vs. on a schedule? Even as a non-coder you need to intimately aware of how all the components work.

3. Operational - How does your business actually serve its customers? What does the engagement look like? How does the [cardboard package, white glove service, free stock trading] actually get from A -> B?

4. Distribution - How do customers find out about you? Whether by a direct sales force or app install ads, you need to be intimately aware of this system if not shape it directly.

5. Implementation - What does it look like in practice when a customer uses your product? Where are they, who pays for it, and what does success look like? You can think of this as a broader “experience” including - but extending beyond - the tactile UX.

Once you assemble some of these pictures, you will gain a meta-picture of how they all fit together. But how do tease out this information in the first place?

⛏ Going Deep

Whether you are inheriting a product or working on it for a significant amount of time, there will be an endless history to catch up and stay current on.

You need to piece together snippets of information from multiple sources to construct your own map:

1. Customers - Talk to them! Hang out where they hang out. Don’t just read what other product people are reading, read what you customers are reading.

2. Space / Market - Find super high quality blogs or podcasts from experts that can explain complex topics simply in small chunks. Avoid fluff about funding rounds and press releases.

3. Internal experts - Talk to subject matter experts from all over your company. When you’re new, use you naiveté as an excuse to ask for whiteboard sessions from experts like the CTO, VP of Sales, etc. Develop casual relationships with people that you don’t find yourself working directly with to see new dimensions of what’s happening in different areas.

4. External experts - Find experts elsewhere. Look to twitter, professional groups, and connections in your network to find people to follow and engage with. Remember that while reading or doing your own research are critical - you can often obtain higher density insights faster in a short conversation with an expert who’s seen everything that’s new to you.

5. Take a longer view - Read histories of your industry, whether that’s banking, advertising, retail, software. Dry material springs to life when it makes things your current situation click. Just because products are made and delivered differently (extremely online), doesn’t mean the current industries or business models (and all the challenges that come along with them) have never been seen before. Sometimes they are progressions, other times they are remixes.

🧠 Keep it all in mind

You will now have the context to make fast, nuanced decisions and create alignment. By seeing how it all works together, you can simplify decision-making and focus efforts on true impact drivers.

Once you have an understanding of how your Product ticks, you will also have a pretty good sense of how your Business ticks. The emergent patterns of your culture (who you hire, how people work, how decisions are made) will start to make sense from this context, as will all the product decisions that have been made to date.

This will inform your approach to not only building products, but releasing them successfully within your org. You will learn to see your place within the (possibly chaotic) system of your business. You will see new opportunities to improve the Product in ways that benefit you and your customers and you’ll learn how to partner with or leverage other components get there.

This holistic view will be critical in delivering impact to your Product. Remember that no single piece is disconnected from everything else.

When used effectively, metrics:

• Create accountability

• Clarify objectives

• Provide focus

• Facilitate creativity

When used poorly, metrics:

• Create unnecessary data wrangling work

• Stress and burn people out

• Blind you from other critical work

• Add to your org’s confusion

Using metrics effectively and sanely

Here are some simple approaches to make metrics work for - and not against - you.

For a general intro on product metrics, check out Startup Metrics for Pirates.

Set and (kind of) forget

Metrics provide the pulse of your business and feature teams. They’ll tell you if your efforts are working and highlight changes in your users, product, and business. It’s critical to keep them top of mind, but this often sends PMs off on a disproportionate amount of busy work.

If you find yourself constantly refreshing metrics or running reports you may be too focused on metrics. Think about your personal finances. Unless you are in a severe financial position, there is no reason to check your balances or portfolio on a daily (or worse hourly) basis. It’s much healthier for your habits (and your sanity) to have fixed times to look at standard sets of data, say weekly or monthly. You should treat metrics the same way, even critical business ones.

Instead of constantly pulling you need to rely on pushing, passively consuming metrics at regular intervals. Once you’ve determined the right cadence - based on how frequently you expect them to change - set up automated reports to your inbox and scan them when they come in. This will free you up to focus on actually changing them instead of mindlessly and compulsively checking them. It may feel more like “work” than compulsively checking social media, but it’s the same thing. (I have another topic in mind about over-using analytics tools that I may cover - the same rule applies).

As a prerequisite, take the time to figure out what those metrics are and how they should be structured. Do the work up front to get this in place and don’t fiddle with it too much. Every quarter or year, you’ll find opportunities to improve your reporting. Your company’s goals will shift over time and these periods will be a good time to recalibrate your metrics.

Open access

Metrics provide clarity for everyone: stakeholders, executives, feature teams. To get the full value of this, you need to agree on a foundation set of KPIs and make them widely accessible. My first startup had a daily report, emailed to the entire company that stated all key business KPIs against goals. It looked something like this.

Note: these figures are totally made up, but I remember the structure from sheer repetition. We also had green-red delta figures showing changes in each. These fit an ad-based business so the individual metrics don’t matter - the point is, every company has ~5 key metrics that describe the entire business as a whole and should be known to everyone. For another example, see an old version of Uber’s KPI dashboard.

This made a major impression (no pun intended) on me and I’m constantly surprised that more companies don’t make this a standard practice. When a product person is deep in the data, they forget that other people don’t have their context. Making metrics widely available on push basis, ensures everyone is on the same page. In this example, I can assure you that every single employee knew exactly how the business was performing at any given time and what they needed to do in their role to affect them.

Never make people run their own queries (“the data’s there for anyone who wants it!”) or do their own reporting. Spoon feed it to them.

Not all companies or executives are this transparent with their data, and in some businesses it’s not possible to push sensitive data to hundreds of employees. Directionally, it’s what you should push for. If you can’t implement something like this on a broader level, make sure you and your team have regular, automated access to top line KPIs. They will inform everything you do and help you set your own, downstream KPIs.

Make them simple

Open metrics are only as useful as they are understandable. Use self-explanatory naming conventions and don’t get too clever with business logic. If you have 4 different definitions of a signup or “activation” you are only adding to the confusion. Clarity will help you (when you check something 3 months from now you won’t need to dig into code to remember the logic behind a figure) and everyone else consuming them. I can’t tell you how many meetings I’ve sat in where a PM reported a metric in a 20+ directors meeting and then spent the rest of the meeting clarifying and debating whether that metric was defined the right way to begin with. Avoid this at all costs.

Metrics make everything simple. They boil down all kinds of activities, work across the business, and product launches into business facts. But that doesn’t mean they are as simple as they look.

A lot of PMs struggle to move towards a so-called North Star Metric. This is another item that scores well on take home exercises, but can fall flat in real life. Don’t get me wrong - north star metrics are very powerful, but they aren’t as easy to grasp or act on as it might appear.

Think about Airbnb’s nights booked metric. It’s a perfect encapsulation of their entire business into one tidy package. But how do you and your feature team increase nights booked? Well, you start by unpacking the sub-metrics involved in nights booked. To oversimplify, it’s a function of inventory, demand, and sell-through. You can break this down further:

• Inventory = new hosts acquired, hosts retained, listings added, etc.

• Demand = new guests acquired, guests retained, etc.

• Sell-through = discoverability of relevant stays, availability, pricing optimization, etc.

This waterfall goes on and on. The value of a north star metric is that you can spin up a bunch of independent teams to focus on particular sub-metrics and prioritize their work against them. But you can’t just say “ok, north star metric - any ideas?”. That is paralyzing and hides the complexity of how your business actually ticks.

Similarly, you need to understand the interconnectedness of these metrics. If we increase hosts in one region, does it increase sell-through or decrease it? It depends.

Another example is a marketing funnel. Growth PMs are rightly funnel obsessed and are always looking for ways to optimize each part. But let’s say you make it easier to sign up (ex: add Facebook login) or to pay for your service (ex: add Apple Pay). You may increase new users or checkout rates, but do these customers behave the same way as all the other customers? The usual answer is no. If you increase conversion rates on one part of the funnel, the drop tends to leak elsewhere or into long-term metrics (e.g. LTV, retention). It doesn’t mean these efforts aren’t useful, it just emphasizes that it’s often impossible to change one thing for the better with no other effects.

Once you and your team are used to consuming regular push reports and shipping against them, you’ll get an intuitive grasp for some of these relationships. You’ll realize that you may need to affect a low level metric (or several low level metrics) to boost a higher level one, or that there’s an interplay between work you and other feature teams are doing that needs to be collaborated on, or at least resolved.

Focus on the right stuff

Avoid things that can be measured just because they can be measured. Another personal example would be weight. If you are looking to improve your fitness, you should think about what you really want to change. Is it your energy levels? The way you look? Being healthy for long term longevity? There are an endless number of goals people might want in this category, but often they will just measure their weight because… they can. Some people may need to actually gain weight to meet their goal. So make sure that what you’re tracking is useful and not just available. A common parallel of weight in product work is often efficiency. Sure you can make an internal team (ad ops, support) more efficient - and sometimes you should - but is that the most important thing you can be working on? Maybe, maybe not.

Be metrics-first

Once it’s clear what KPIs your feature team needs to focus on, they will inform the projects you take on. It’s critical that you start with a goal in mind, and then decide the projects. If you have a bunch of random ideas in your backlog that would make great features, you need to figure out which will actually get you to your objectives. The best feature that has no goal in mind may delight some users, but will bring you no closer to that goal. The best way to get your team thinking of great ideas, is to ask the question “what are all the ways could we improve x metric?”. Now you have a constraint on your brainstorming and can put the free-flow of ideas to productive use. In some cases, the best solution may even not be a “product” one you need to build.

Similarly, once you start writing a spec for that project, start with the goal. This should be the first line of every single spec you write. I’ve seen some organizations that start with this and nothing else before the feature team starts developing ideas. That way, every requirement or design that gets added can be judged against “is this really going to get us to that goal?”.

As the feature starts to form, you should also define exactly how you’ll measure it and set a goal against it. This approach will keep you honest throughout the process and avoid uncomfortable conversations after a feature flops. You will be surprised how many high growth companies ship things with 3-4 simultaneous goals and move targets after the fact. Were they successful? No one knows, but you can keep data scientists busy trying for weeks trying to find the answer.

Set goal posts early

Just like with the regular consumption of topline metrics, you’ll get a feel for what metrics can be moved and by how much. In absence of that knowledge, start with something. Do you think 10% of users will pay for this feature? 70%? If the number is too low, it’s probably time to move onto another idea - that’s fine! Putting a line in the sand forces you to think critically about how to reach it and doesn’t let you hide if it doesn’t work. When a feature ships, you should already have a report ready to go.

There’s nothing wrong with failing to meet a goal - it’s part of an iterative process. If you attained 100% of your goals all the time, you aren’t taking enough risks. It’s only when teams continually fail to hit goals that there’s a problem.

Don’t get obsessed

While product people are supposed to be “metrics obsessed” (another one from a real job description), you can’t focus on your metrics 100% of the time. Being hellbent on a single number will give you tunnel vision, and cause you to miss opportunities that don’t perfectly fit into your chase.

You can also spend way too much time thinking about tweaks and optimizations to squeeze features toward that metric. This is another form of myopia that inhibits new directions and ideas that could have an even greater impact than what you’ve already got.

Remember that not everything can be captured by a metric. There is lots of soft stuff like user experience that can’t be measured so easily. All products are used by human beings and there are some fuzzy things that aren’t captured in metrics - think “user love amount” - that can drive long term growth for your product. Leading indicators like engagement can quantify this somewhat, but you should also rely on anecdotal feedback and direct conversations with users to get a sense of whether something is working or not. Combine qualitative and quantitative

Like all tools and competencies, metrics have specific purposes. Use them wisely, and remember they are just one abstraction of the real work you’re doing. They are never enough on their own.

What is the job of doing product? After last week’s intro, it’s time to get into the heart of the matter.

The answer isn’t as obvious as you expect. Newbie tend to struggle bridging the gap between a job description and real life. And veteran PMs easily fall into old routines that keep them from seriously addressing the fundamental question of “what should I spend my time on?”.

Many job descriptions will list out the rituals you’ll need to perform (I’ve pulled these from live job listings):

You understand the motions that Product Managers must go through when bringing a feature from idea to completion, e.g. grooming & prioritizing a backlog, writing product requirements, preparing work for sprint planning, attending the team standup, etc

Other times they say fuzzy things like:

Be the voice of the customer

Create an inspiring product vision

Act as the connective tissue of the organization

None of these points are inaccurate, but they often train PMs to overweight the importance of activities and process. This thinking turns PMs into project managers or scrum masters instead of nimble, entrepreneurial movers and shakers. Those functions are absolutely critical, but often get mistaken for the job itself.

Hey, that wasn’t in the description!

Another danger of sticking to detailed activity descriptions is that they are inevitably incomplete. If you focus solely on the activities you’re asked to perform (e.g. running metrics, writing tickets) you will inherently miss all the important other stuff that will fall through the cracks.

In their first few releases, PMs tend to miss some key steps. These are the responsibilities that you don’t know you have until you’ve screwed them up. Or they arise at the last minute without any prior consideration, creating a fire drill. Here is a short list of commonly skipped steps:

1. Stating clear targets before a project starts.

2. Looping in the marketing team to determine who the audience is, what the value prop is, and how you’ll deliver it to that audience, well before the development is underway. “We have this feature coming out next week” is not a good way to start the go to market conversation. 

3. Setting up pre-defined ways that can report on those goals the second the product launches, and not a week later.

4. QA’ing the crap out of the feature. In addition to the simple test cases, have you actually tried to use the feature the way a new user will? With no backstory on how and why it was designed the way it was?

5. Understanding whether the thing you want to ship - which may be a simple ui tweak - will create new problems, increase support tickets, or challenge your ability to run the business. 

6. Clearing plans with legal, logistics, finance or other key parties. This is critical if you are dealing in the movement of money or physical goods.

A simple purpose

This job is complex. There is always a laundry list of things you need to be doing, including all those bullet points above. But without a cohesive purpose, they tend to result in busyness. Or worse, feeling like you are drowning (busyness without going anywhere). 

One way to understand your scope is to widen and simplify the job description.

Here’s one excerpt I found that actually describes the job:

Whatever it takes to keep your product team shipping and successful

Putting it into practice

Rather than thinking in terms of day to day responsibilities, you can use whatever it takes to increase your team’s ability to execute. Here are some strategies that will get you thinking along these lines and ensure any project’s success:

Create a (simple) plan

List out all the things that you think need to be done to complete the project on day 1. It’s totally fine to keep a list of possible concerns to tick away once you’ve confirmed they aren’t necessary. You may have an item like: confirm whether we need to make changes to our privacy policy to support this. If the answer is “no, we don’t” cross it off and keep going. This is a muscle you’ll build over time and soon you’ll have a mental template (better yet - create a digital one) that you can rely on repeatedly.

Spend at least half your time on rollout

In your plan, prioritize go to market and how you’ll deliver the product to users. This includes marketing strategy, sales education, training, and all the downstream activities that will make the product successful. Remember that the core “product” work (designing and shipping) is only a small sliver of the team’s success.

Communicate constantly

Share project documents with stakeholders while the designers and developers are still exploring their own solutions. Maintain active relationships and conversations with all the people that need to be involved in some way or another. There is no harm in oversharing or having a quick sync where “we’re good, I’m up to speed and can do what you need me to do on time” is the result. You’ll find that there is always something to be clarified and re-clarified as the project starts to breathe.

Prioritize unblocking work

The ratio of PMs to engineers or other team members is very low. In many cases you’ll be more productive simply by clearing the way for work to proceed than in working on non-blocking items. This includes clarifying key vs. edge cases, core user segments, and what needs to be done now vs. later. Set up times and systems to address open questions before getting into your “personal” work.

So who actually does what?

The actual technical work in your project (testing, writing copy, running ad campaigns) needs to be performed by someone. Depending on the size and maturity of your org, you will need to understand whether you need to run these tasks yourself or partner with other resources to get them done. 

On one end of the spectrum: You are a sole PM with no dedicated designers, product marketers, QA testers, ops support, etc. 

On the other end: you have dedicated departments to work with and have these roles embedded in your feature team.

The most common case is somewhere between those two extremes - maybe you have a proper designer but no QA resource. Or you may have a product marketer that works with several feature teams.

Your job is to tie all those pieces together into a cohesive whole. You will need to dive in and out of these different roles and keep the whole thing moving, whether you actually perform the duties or not. A large part of leading a collaborative effort is making all the parts of the clock tick smoothly and in rhythm, even if you are acting as most of those parts. 

When you do have resources available, you’ll need to learn to delegate properly. The first attempt of this usually has a PM assigning a ton of tasks to other groups and then checking in weeks later to see what happened. This is abdication. A more mature approach requires collaboration. You’ll need working syncs with team members to figure out the best way to handle the work, with a two way give and take. A rule of thumb is that you should never expect someone involved in the problem to “go quiet” for a few weeks and suddenly deliver the task in question. The same goes for your work. 

Expanding

To re-state: your role as a product person is everything. While that doesn’t mean you will necessarily do everything, you need to start thinking this way. When people talk about the cross-functional or multi-disciplinary work of product this is what they mean. Once you start envisioning product work holistically, you’ll naturally learn to see things from more angles. It may take time, but each thing you ship will add a new layer of depth to this view.

Roadmap

This post mostly describes the tactical work you’ll need to be doing in product. For younger PMs, this is the core of the job. As you grow in scope and level, you’ll need to focus more on strategy and higher level thinking. We’ll get into those topics in future installments.

Other requested topics I’ll cover in the next few weeks are:

• Setting and using metrics

• Staying organized (my personal favorite)

• Thinking like an owner

Why We’re Here

I’ve been doing product at tech startups for a decade. The companies I’ve worked for span many industries (anything you can add a “tech” suffix to) and have raised nearly $400m in VC funding. I love product and couldn’t imagine doing anything else. Product is the most dynamic, exciting, and entrepreneurial work you can find.

Unfortunately, I’ve seen many bright PMs lose sight of that. Bright-eyed new hires arrive with shining optimism, only to have it beat out of them by the realities of the job. Talented teammates transfer in and promptly sprint away once they get a peek behind the curtain. On the other end, you have grizzled veterans growing more cynical with every planning cycle.

The main reason for this is that we have unreal expectations for the work.

Great Expectations

We’ve been trained through podcasts, conference decks, and business books to believe product work is done in a fantasy, movie-like world. That a genius product person can think hard for a bit, wave their magic wand, and with a [clever a/b test, foolproof strategy framework, brilliantly designed feature], turn an idea into a billion dollars. That one key insight makes everything else run perfectly on auto-pilot.

The stories we’ve heard aren’t false - they just don’t describe what those situations actually looked and felt like in real life. They create unreal expectations that simply can’t be met. They send us out looking for silver bullets that will instantly solve everything and make us look like visionaries. When we can’t find them, we tend to burn out and blame ourselves

Real Life

Building products is a messy, collaborative, and chaotic process. There are human beings, emotions, and egos at play - not to mention dynamic, complex market environments.

It might feel silly to admit it, but we get tricked into thinking that we do product in Fantasy World. This is a wonderful place where:

1. Engineers are exuberant about the new [agile process, ticketing system, design sprint] you’ve installed after reading that [successful company] does it that way.

2. Stakeholders are awed by your immaculate prioritization matrix and everyone agrees on its outputs.

3. You have all the time and data you need to make the perfect decision.

4. Your company has a single, clearly articulated strategy that guarantees success if followed.

5. Roles fit their job descriptions, down to the bullet point.

6. Every feature ships exactly as spec’d, exactly on time, with the exact results you hoped for.

7. Systems work as expected 100% of the time. Especially when the signup or checkout page is involved.

So what’s real life? Well, the exact opposite of Fantasy World. Go ahead and imagine the inverted list if you’d like.

Our Path Forward

So how do we navigate messiness IRL?  That will be our focus. I’ll share techniques and ways of thinking to help you adapt your work to real life.

But there’s one truth that I want to share with you now. This will be the core thesis of the series, and I’ll reiterate it through many topics. If you can accept this, you will be able to make use of all those great books, courses, and stories. You’ll learn to treat them as sources of inspiration, instead of sacred texts to adhere to.

The core premise of Doing Product IRL is simple:

1. Every single product role is unique.

2. Despite #1, there are common fundamentals that will help you succeed in any case.

It may seem shallow, but it’s taken me many years to fully grasp. I’ll explain the nuances and variances of those fundamentals over time - they may not be the ones that readily come to mind.

Lastly, I’d like to set the tone for this series with a comment Obama made about the Presidency at this week’s inauguration:

“This is a unique office, without a clear blueprint for success, so I don’t know that any advice from me will be particularly helpful.”

Don’t worry - I will offer plenty of advice but, more importantly, I’ll focus on giving you what you need to blaze your own trail in your unique case.

✌ 

Graham

Thanks for reading this issue. Have feedback or ideas for future topics? You can always reply directly to this email.

If you’re enjoying this series, please share it with a friend or colleague.

In this series, I’ll be sharing lessons from a decade of building products in high growth startups.

Sign up now so you don’t miss the first issue.

Subscribe now

In the meantime, tell your friends!