Other than dust bunnies and hairballs, no product is made in a vacuum. Product success takes a herd, but we must first align the sheep.

Many product decisions can go in circles, which is frustrating and demoralizing for anyone involved. The uncertainty leads to wasted time and inaction because stakeholders aren’t rowing in the same direction. There’s an alignment problem.

A great product manager knows how to shepherd their stakeholders to align on a clear decision.

The Good Shepherd

Misalignment happens when people have opposing viewpoints on a topic. These differing perspectives could be simple misunderstandings—people wanting the same thing but using different words—or fundamental objections. Regardless of the source of the misalignment or whether there’s misalignment at all, people want to be part of the decision-making process.

I use a six-part framework to drive stakeholder alignment: Shepherding.

1. Externalization

2. Stakeholder Mapping

3. Individual Alignment

4. Group Alignment

5. Signoff

6. Immortalization

Before elaborating on the six stages, let’s unpack the ethos of shepherding. The spirit is to drive what’s best for the business, not to satisfy our career goals, some executive’s agenda, or political maneuvering.

We must believe that teams are strongest as a unit—a dispersed herd of sheep moving in scattered directions will accomplish nothing. A shepherd does not force sheep to do anything but seeks to get them moving in one direction that supports their interests.

We must respect the individual’s intelligence. In the knowledge sector, influence—not control—is essential. We must bring people along for the journey to ensure they feel seen and heard in the decision-making process.

Shepherding takes significant time and effort (often 3-4 weeks), so we must only invest in one-way door decisions that impact multiple areas of the business: launching or deprecating critical features, major system upgrades, or new policies and programs.

Step 1: Externalization

The first step of shepherding is to externalize the idea into an artifact, such as slides or a document. I prefer a document because putting ideas into writing helps sharpen thinking and provides adequate detail for stakeholders to review offline. Slides are easier to create, but they’re insufficient to convey ideas without a verbal presentation.

A culture of writing—materializing ideas into prose—helps others assess a proposal objectively and read it asynchronously. Most importantly, a written artifact ensures the idea prevails over personalities and prevents the loudest voice from domineering the group.

Aim to keep it under two pages and place supporting data and materials in an appendix.

Step 2: Stakeholder Mapping

Determine the stakeholders that need alignment. Most product decisions will include other product managers, executive leaders, and functional representatives from engineering, customer support, sales, marketing, and operations. Catalog these stakeholders at the bottom of the proposal document. Most decisions will involve 3-4 stakeholders at minimum, to a dozen at maximum.

Ensure to list individual contributors most impacted day-to-day by the decision’s outcome. Leaders will look to them for guidance when they ultimately sign off on the proposal.

Step 3: Individual Alignment

With the written proposal and stakeholder map in hand, seek individual feedback. I recommend meeting with each functional group separately but no more than 2-3 at a time to keep the discussion focused and intimate. Seek their feedback, listen to their concerns, and aim to address their objections in edits to the document.

In these discussions, it’s essential not to get defensive but to seek understanding. Press the individuals to offer solutions to problems they present—even if these ideas are not implemented, voicing them can unravel concerns that aren’t valid.

Step 4: Group Alignment

After meeting with everyone individually and incorporating their feedback to bolster our argument, arrange a group review. Share the document in the invite 3-5 days before the meeting and instruct everyone to pre-read and leave comments. We can then begin the group review with the comments to keep the conversation focused, as it’s easy for people to derail these meetings with tangential topics.

The good news is that everyone should be mostly aligned by this meeting. The group session may feel like a formality, but that’s good. Like a wedding, the group review is a public endorsement that everyone present supports the decision being made. They may disagree with it but respect it nonetheless since they were consulted on the topic.

Step 5: Signoff

After the group review, add a signoff table at the bottom of the body content before the appendices. I recommend three columns: the signer’s role, name, and signoff date. To “sign off,” the stakeholder should type the date beside their role and name.

Getting signoffs will require tactical shepherding. After the review meeting, send a follow-up email thanking stakeholders for their participation and requesting they sign by a specific date. I recommend a deadline of 2-3 days away.

Some people will sign off promptly, but others will need chasing. Don’t let the discomfort of pestering people prevent their signoff. If people haven’t signed within two days of the first request, prod them with individual messages. Another tactic is to reply to the original email. Keep pending signers on the To: line, move all other stakeholders to CC, thank those who have signed, and gently request others to do so.

Step 6: Immortalization

After everyone has signed, rejoice, for we have made a complex, business-impacting decision across multiple functions! To immortalize the decision, send a final announcement to all stakeholders confirming the outcome. Thank them for the feedback, ideas, and support. Emphasize that it was a group effort and that they should feel like co-owners.

It was no small task, but we have shepherded the herd to greener pastures.

Action Items

Create a list of stakeholders to align with for a future product decision. Refer to this list next time you advocate for change.

When a new person joins the team, people love to welcome their “fresh eyes” that can “spot the nonsensical things we’ve grown blind to.” People quickly discount their earned wisdom by casting experience as a burden. Although the new joiner may appreciate this welcome, I’ve yet to see the pithy sentiment come true.

Don’t get me wrong: every team needs fresh minds and diversity of tenure to ensure workers don’t get stuck in a rut. However, new product managers could benefit from getting to know the lay of the land before they push for change. Unexamined product decisions can destroy a business.

The One-Way Door

Product decisions are two-way or one-way doors. Most decisions are two-way—you can step through the door and back out with minimal consequences. Changing the format of a team meeting is easily reversible. Running an experiment is low stakes: if it fails, return to business as usual or launch a new one. PMs shouldn’t waste time on two-way doors and bias for action over deliberation.

One-way doors are tough to change once decided. A one-way door requires a lot of thought, research, and debate to be successful—such as infrastructure choices or multi-year business plans. PMs should bias for thoughtfulness over action when the stakes are high.

Sometimes, the rationale for past decisions may be uncertain, like legacy software dependencies. In these scenarios, people may refuse to touch them or adopt the risk-seeking mindset of “turn it off and see who screams.” Neither approach is wise—the former is too passive, and the latter hyperactive. Instead, we must approach unknowns with the methodical opening of a one-way door.

Chesterton’s Fence

Philosopher and apologist G.K. Chesterton described a thoughtful approach to policy reform in his 1929 book, The Thing. Chesterton’s principle advised against reform until decision-makers understood the rationale that created the present state. Put simply: If a fence exists, there’s likely a reason for it.

All sorts of “fences” abound in software. Technology rapidly changes, new frameworks emerge, and people switch roles, so the knowledge of critical legacy systems gets lost in the shuffle. The product may seem littered with unintuitive features when a new person joins the team.

While it’s tempting to strip away counterintuition, restraint is essential. According to Chesterton, we should not remove a fence until we know why it exists in the first place. A guillotined head can’t be glued back on.

A new product manager should remain humble when beginning a new role. It’s tempting to scoff at the “ridiculousness” of an incumbent feature, but until we learn about its history, we can’t know if the feature is ridiculous.

Learn why past product decisions were made by talking to several functions and stakeholders—especially those with years of tenure.

Second-Order Consequences

We approach a fence. After asking around and conducting internal research, we understand that it kept cattle from running onto a busy road. Given this rationale, we can respect and appreciate the prior decision, but we believe it’s now vestigial. We must step over it every day, and it’s hard to mow around, so long grass grows along it, and neighbors complain that it looks unkempt.

Since a highway was built, the road now experiences little traffic, and fewer cows live on the property now than years ago. So, we want to rip down the fence.

Learning history is the first step in removing Chesterton’s fence, but it’s insufficient. Destroying a fence may have second-order consequences.

Last summer, I helped a friend remodel his basement. He wanted to knock down a wall to create a more open floor plan, but as we removed drywall, we discovered a support beam directly beneath his kitchen’s refrigerator. Thankfully, we lowered the sledgehammers, or I might not be writing this.

Second-order consequences are what happens when we remove that support beam. Yes, we’ll achieve our first-order objective of an open floorplan, but we might experience a second-order consequence of an open ceiling.

To deprecate part of a product, we need to consider the long-term effects of that decision.

Imagine you want to increase the daily active users of a marketplace app. Removing CAPTCHA from login could simplify the sign-in experience and increase user engagement. But, when the service becomes flooded with bot traffic, the quality erodes, legitimate users lose trust, and they stop using it altogether, sabotaging the initiative’s very purpose.

A strong product is built with intention and careful decision-making.

Action Items

Research a seemingly nonsensical part of your product. Document the decisions that led to it in a wiki.

Bats aren’t blind. Paradoxically, their vision is better than most humans, but since they operate in the low light of caves and at nightfall, they rely on echolocation to enhance their vision. The auditory feedback enables them to hunt, navigate, and survive. Knowledge workers need similar feedback to validate how they interact in the workplace. Without personal performance feedback, a product manager can live a delusional existence.

Yet, delivering feedback is uncomfortable—whether to one’s reports, peers, or boss. The discomfort of giving feedback—worrying that it will be taken the wrong way and fray the relationship—causes us to avoid criticism altogether. But the price of not delivering feedback is akin to stripping a bat of its echolocation abilities and letting it haphazardly slap against stalactites and starve.

A product manager is a leader, and a leader does not turn away from discomfort. We can consider a few frameworks to overcome the anxiety around delivering feedback. Like any framework, the three below serve as training wheels to help us navigate uncertain terrain.

Fearless Feedback

The Apple Store Genius Bar was a revolutionary customer support experience when it launched in 2001. Tech-savvy “geniuses” helped customers use and troubleshoot the products in the store. Their approachable, friendly demeanors ensured a customer didn’t feel “stupid” for struggling with a device. They exhibited high ownership of problems—aiming to deliver a solution in one trip instead of the standard support tactic of passing the buck.

In the Apple Store’s “secret” employee training manual was a simple operating model for employee performance reviews: Fearless Feedback. This model had two dimensions of feedback: polarity and specificity. On the polarity axis, feedback could either be positive or negative. On the specificity axis, feedback could be either general or specific.

General feedback is net-neutral at best. General positive is well-intentioned and harmless—“You’re doing a good job!”—but ultimately worthless, as it doesn’t tell the person how they did a good job.

General negative feedback is mean and harmful—“You’re doing terrible work!”—and should never be used, as nothing productive comes from this flavor of feedback.

Specific feedback, however, is essential. Employees are encouraged to deliver timely feedback that targets tangible behavior. “Awesome job helping that lady troubleshoot her iPad’s Wi-Fi issue! I noticed you validated her frustration with connectivity and taught her practical tips to ensure she can self-help next time she joins a new network.” Specific feedback like this helps the employee feel seen and learn what actions were effective so they can repeat them in the future.

The same is true of specific negative feedback. “I noticed your recent interaction with the iPad lady was tense. I could tell she was already frustrated when she walked in the door, but telling her to Google the answer wasn’t a productive suggestion since she had come to you for help. Next time, please validate her concern and teach her how to check Wi-Fi settings.” This feedback is constructive as it highlights the poor performance and recommends appropriate behavior.

Deliver specific feedback.

Continue and Consider

General Electric (GE) was renowned for developing leaders for decades, and I was fortunate to spend my early career there. Leadership excellence was imbued throughout the company culture, and performance development was no exception. GE believed that feedback should be action-oriented, so they introduced a simple framework that made it easy for everyone to provide. It involved two words:

• Continue = behaviors that are working and one should keep doing

• Consider = behaviors that are not working and could be stopped or changed

This simple reframing of positive to continue and negative to consider relieved the concepts of their incumbent connotations, inviting employee participation. The framing requires the specificity of Fearless Feedback without the polarity definitions that incite anxiety.

Additionally, the feedback tool was open year-round—instead of once annually—and allowed 360-degree sharing—peer-to-peer, manager-to-report, and report-to-manager—so a broader and more representative sample of feedback on individuals’ performance occurred.

Make feedback action-oriented.

Losada Ratio

Even with specific and well-framed feedback, the right balance of affirmative and constructive feedback can be challenging. Psychologist Marcial Losada sought to discover the optimal ratio in his research at the University of Michigan in 1999. The study initially stated that 2.9 positives for every one negative feedback (2.9:1) was ideal for optimal individual performance. However, peers later revoked the statistical approach, and additional research concluded that 5.6 positives per one negative feedback (5.6:1) was the ideal ratio to maximize human labor output.

Put in such clinical terms, this approach to feedback giving can feel inhumane. But we shouldn’t dismiss this research because it has a human-centric finding: Asymmetric feedback matters. People must stay motivated and encouraged, so a bias toward positive feedback suits both the individual and the business. The specific number doesn’t matter much (3, 5, or 6 positives per negative), but we should aim to share more positive feedback than negative for the well-being of coworkers.

Aim to give five positives for every negative feedback. In other words, five continues for every consider.

If a bat hits a wall with every other flap of their wings, they’ll get hurt and give up flying altogether. Bats need positive feedback to thrive, and humans are no different.

The best feedback is specific, action-oriented, and asymmetrically balanced to five continues for every consider.

Action Item

Give one continue and one consider to a coworker this week. We all know somebody who needs it.

Funerals occur postmortem—after death—and serve to reconnect family and friends. But they’re tragic in their timing; we wait for death to bring us together. Why not coalesce the living, manage affairs, and make peace before we pass?

Like funerals, project retrospectives (postmortems) are essential for a growth-minded team, but they come too late in the project lifecycle. Instead, product managers can host a premortem.

Philosophically, product launches are more like birth than death. Internal teams are pregnant with a product, feeding it time and resources until they birth it into production. Within this metaphor, a project prenatal might seem more fitting, but therein lies the problem: birth mostly has positive connotations. While optimism is essential to build anything, excessive optimism around a launch will guarantee failure.

Premortems are cross-functional sessions that encourage teams to anticipate problems arising after a release. Product managers invite team members to imagine how a product can fail and work backward to mitigate those issues. Most importantly, a premortem creates a shared vocabulary around failure points.

The essence of a premortem involves three animals:

1. Tigers

2. Paper Tigers

3. Elephants

Let’s explore each.

Tigers

Tigers are deadly to the product, potentially disastrous issues leading to inevitable failure. Think of broken capabilities—incompatible browser issues, login errors, corrupted data, significant latency spikes, and uptime challenges. These are true positives. Stakeholders will likely agree on these issues and won’t require much discussion in the premortem session.

Paper Tigers

Paper tigers seem deadly to the product, but they likely aren’t. Think of things with capability gaps that don’t matter for the use case, like mobile responsiveness for a desktop or missing SEO keywords for an internal tool. These are false positives. Some stakeholders will see these as tigers, so thoughtful and objective discussion is required to decide whether an issue is real or “paper.”

Elephants

The metaphorical “elephants in the room” are issues that should be concerning, but nobody is speaking about them. Think about the secondary aspects of a product—logging, monitoring, alerting, intentional or unintentional platform abuse, security vulnerabilities, and bias factors. These issues are false negatives, items we’d surely miss without the proactive reflection of a premortem. Paranoia is our friend for identifying such elephants. Cross-functional representation is crucial for covering all dimensions of a product launch.

Hosting a Premortem

Schedule a one-hour block a few weeks before launch. Invite a diverse group, ideally no fewer than six and no more than ten, and include reps from functions like engineering, analytics, customer support, sales, design, marketing, or operations.

Structure the session as follows:

1. Initiate for 5 minutes. Quickly visualize the state of the product one month after launch. Express that the product (or feature or version bump or policy) is failing miserably.

2. Brainstorm for 10 minutes. Instruct the team to imagine issues and list as many as they can. Use a shared whiteboard or collaborative document to collate all potential problems in one place. As they write on digital sticky notes or bullet points, move similar items near each other.

3. Vote for 10 minutes. Finish clumping similar items and ask the team to quietly cast three “votes” on the most severe threats.

4. Discuss for 30 minutes. Introduce the concept of tigers, paper tigers, and elephants. Then, review the top-voted threats. Encourage participants to discuss and assign each to an animal. Most threats debated will be tigers or paper tigers, so ask the group if any less-voted issues could be elephants.

5. Assign for 5 minutes. Decide on the top five threats. List each as an action item, assign owners, and set target dates to address each.

Memento mori. Premortems express a stoic overtone, a willingness to think about failure today so you can enjoy a fruitful launch tomorrow.

Action Items

You’ll probably release something in the coming months—a feature, an internal update, a policy. Host a premortem with your team to anticipate problems before the launch.

Product managers can be myopic about building. I gravitate toward development because the creation process is enjoyable; making a vision come to life feels productive and satisfying. But over-indexing on building is a fool’s errand if customers don’t use and enjoy the product.

Google invented a framework for user-centric design that broadly applies to any product. Five dimensions, aptly acronymized as HEART, measure customer love:

• H for Happiness

• E for Engagement

• A for Adoption

• R for Retention

• T for Task Success

Each metric will shape how one builds, markets, sells, and supports a product or feature. External or internal solutions can leverage this framework; some metrics will be more critical for a given initiative. A product manager should consider each during product design, as the dimensions will require a degree of interactivity and built-in analytics to measure effectively.

I will present them logically rather than ordering them to satisfy an acronym.

Adoption

Adoption is concerned with gaining new users to a product or feature. A product is worthless without users, so adoption is a critical step. Consider this a sales and marketing problem—how can you acquire customers?

Depending on the product or feature, we could measure adoption based on new signups, accounts created, purchases made, or the percentage of the population that upgraded to a new version.

Let’s consider the Product Field Guide email newsletter: the number of subscribers is a decent measure of adoption.

Task Success

Task Success is an objective measure of product effectiveness. Think of this as an engineering problem—does the thing work as expected?

At the most basic, we might measure the error rate of users or how efficiently they accomplish their goals. Does the feature reduce the user’s cycle time to complete a process? Were they able to create a profile, upload a photo, process a payment, or submit a form?

For a newsletter, we could measure delivery rate—how often a sent message arrives in an inbox without going to spam. We might also consider the signup flow and how many clicks it takes for a prospective reader to subscribe.

Engagement

Engagement is the degree of user interaction with the product. This is where the magic happens—the telling indicator of a feature falling or flying. Think of this as a product design problem. Customers will engage if we have product-market fit and add value.

We might measure the number of visits over time (i.e., per hour, day, or week), the number of tasks completed, the time spent in-app, or the frequency of clicks/taps/hovers on certain portions of the experience. Aim to assess the level of user involvement.

For a newsletter, engagement could be the number of email opens and click rates. We might look at how many comments we receive on a post or how often individual users open a message.

Retention

Retention is how often existing users return to the product. A working solution or healthy acquisition rate isn’t enough if customers don’t use the product consistently. Consider this an account management problem—how can we continue adding value to users over time?

There are two parallel paths to measure retention—finance and usage. Financial measures like renewal rate, churn, and recurring revenue indicate that the product keeps providing value or customers wouldn’t continue to pay for it. But usage metrics—like active users over time—are often better assessments of product efficacy.

For a newsletter, unsubscribes (churn) or open rate over time can represent subscriber retention.

Happiness

Happiness is concerned with user sentiment. This is squishy territory, as customer attitudes around a product are difficult to quantify. Whereas the other dimensions are measured passively—like clickstream logging or financial reports—happiness is often collected actively through surveys.

Typical metrics include customer satisfaction (CSAT) or net promoter score (NPS), calculated by aggregating user ratings. Natural language processing can systematically parse free-text fields like user reviews or comments to gauge user sentiment. While this data is precious to receive, it’s costly to collect—regarding employee and customer time—so we should consider it carefully.

For a newsletter, the number of post likes or a qualitative assessment of comments can measure user happiness.

Simple polls are also a great way to gauge reader satisfaction 😉

Action Items

Pick a feature you own. Then, select one metric from each of the five categories to start tracking.

The Greek sphinx challenged people to confusing riddles and ate them when they answered wrong. In much the same way, artificial intelligence algorithms can behave in confusing, non-deterministic manners. Chances are that AI impacts your business, but it’s easy to get caught in the hype without understanding if AI is helping achieve your product’s goals. Don’t get lured into the sphinx’s trap without deciphering its riddles.

Product managers can use a statistical matrix to define success for AI projects.

From Deterministic to Probabilistic

A decade before generative AI became mainstream, machine learning was (and still is) used for predictive modeling. Like generative AI, ML algorithms can feel like a black box—we feed them inputs, and they provide us with outputs. This isn’t inherently a problem, as we can use and measure algorithms without knowing their inner workings. Consider a basic calculator. Even if we can’t solve 123 x 456 in our heads, we can trust the algorithm’s result to be the same every time because the algorithm is deterministic.

In other words, deterministic means that a set of inputs always returns the same outputs. Probabilistic means that a set of inputs does not always return the same outputs.

Ironically, the inexactitude of AI algorithms is their primary feature. We live in a complex and uncertain world, and our most critical problems don’t have straightforward solutions. Product management is the art of solving problems in nebulous environments, and the confusion matrix is our tool to measure AI’s effectiveness at solving these problems.

The Confusion Matrix

Given a dataset with true/false labels of predicted and actual values, you can measure the effectiveness of a classification algorithm with a confusion matrix. It’s a simple two-by-two grid with four classifications:

• True Positive (TP) = correct about a condition’s presence

• True Negative (TN) = correct about a condition’s absence

• False Positive (FP) = incorrect about a condition’s presence

• False Negative (FN) = incorrect about a condition’s absence

Adding context to the labels can make a confusion matrix less confusing. Consider a screening test for an emerging virus that makes people speak in riddles, SPHINX-24:

• TP = detected SPHINX-24

• TN = no SPHINX-24

• FP = false alarm for SPHINX-24

• FN = did not detect SPHINX-24

Contextualizing the accuracy of an AI algorithm in layman’s terms can ground it, making its results accessible to people regardless of background. A product manager can create specific metrics with these four values, depending on their goals.

Confusion Metrics

We could set goals around the four values directly. Any algorithm should aim to reduce false positives and negatives, but different use cases may prioritize one.

If trying to reduce the spread of a novel virus, decreasing the number of false negatives is a meaningful goal. If a person is incorrectly flagged as having the virus (a false positive), they must quarantine for a week. While disruptive to their routine, a healthy person quarantining is better than an unhealthy person spreading an unknown virus to dozens of others.

In email spam detection, reducing the number of false positives is a better goal. If a person receives a spammy email (a false negative), they can simply delete it. But if a spam filter incorrectly stops a critical email—such as a tax document—a person could incidentally break the law. Letting a few spams through the filter is preferable to blocking legitimate messages.

Other use cases could require a balance. In fraud detection, businesses need to strike a balance between loss prevention (reducing false negatives) and customer friction (reducing false positives), so metrics like F1 score or area under the curve (AUC) could help optimize between two goals. Although complicated to calculate, these metrics emerge from the four values in the confusion matrix.

Even if a product manager must rely on a data scientist to calculate AUC, understanding the confusion matrix sets the foundational knowledge required to set sound product objectives.

Action Items

With this knowledge of measuring the predictive power of a model, take a six-question quiz to assess your understanding of AI.

Product managers don’t move mountains. They neither pick the mountain to move nor move the mountain that’s picked. Their roles are necessarily smaller than that. A PM is rarely in the first round of hiring for an early-stage startup and is only staffed once a company knows its mission.

Suppose an ambitious company wants to move Mount Rainier from Washington to Florida. This enterprise is the company’s purpose for existence and will give it direction for decades. Product managers carry the mission of deconstructing Mount Rainier boulder by boulder and relocating it to Miami.

An essential skill for product managers is problem decomposition: going from boulders to stones to pebbles.

Boulders

Boulders are initiatives that ultimately align with the company's mission. In our silly example, an initiative to transport one boulder of Mount Rainier to Florida will be 100% strategic. Leaders at the VP or director level decide which boulder to move by evaluating the initiative's impact and its high-level cost. Like a new product launch, boulders can take multiple quarters to move and involve several teams.

The ripple effects of boulder decisions are enormous. If dropped into a body of water, a boulder will create waves—great for surfers but potentially disastrous to homes near the beach. As such, decisions on which boulders to select need careful review and critical examination.

“Great is the enemy of the good” doesn’t apply here. If there isn’t a strong initiative, the job transforms into finding the right one. The focus of boulder-level decisions is on impact and strategic direction. Product VPs and directors are accountable, whereas individual contributors are consulted and eventually responsible for moving the chosen boulder.

Stones

Stones are deconstructed boulders, epic-level projects that support an initiative. Product managers spend most of their time here, as they are accountable for selecting and executing the stones to work on. As such, conversations at the stone level are about 50% strategic and 50% tactical.

Specs and designs are needed for stones because various teams must align on the priority of the given features. Stones could include the required infrastructure, the implementation of the feature itself, and the monitoring and alerting needed to support post-release. Each stone should take about a month (i.e., two to three sprints) to complete.

At the stone level, PMs focus on ROI to ensure the effort justifies the value and that all stone requirements tie back to its associated boulder. Capacity-first planning can help prevent scope creep.

Pebbles

Pebbles are deconstructed stones, story-level efforts that support an epic. They are 100% tactical and related to the specific details of execution. The product manager should spend minimal time on overhead for these work items and avoid force-fitting requirements into dumb templates. Instead, PMs should write clear, specific, measurable acceptance criteria and let engineering own the how.

PMs should be involved and aware of each pebble to verify that it builds toward the desired stone, but too much involvement is usually an antipattern. Engineers may grind a pebble into even smaller tasks, like sand. PMs should not play with the sand because they must focus on throughput and holding teams accountable to a high say-do ratio.

Dynamite or a Pickaxe?

Although I mapped boulders to initiatives, stones to epics, and pebbles to stories, this metaphor is not tightly coupled to one decomposition. Based on a PM’s level or the company dynamics, a boulder could be an epic and a pebble a task. The mapping doesn’t matter, but thinking about boulders, stones, and pebbles can help frame discussions and identify problems.

A boulder-level discussion is needed if a team is confused about the why of a project or doesn’t buy the stated value of an initiative. In other words, where should we place the dynamite? There’s no point in discussing pebble-level details if stakeholders don’t buy into the goals. Conversely, arguing about edge cases wastes time in a strategy discussion, as that’s a pebble conversation. Dynamite isn’t needed to extract a pebble, but a pickaxe is.

Product managers don’t move mountains, but they break mountains in the boulders, stones, and pebbles that make them moveable.

Action Items

Decompose one of your 2024 objectives into boulders, stones, and pebbles.

I’ve never seen an empty backlog. Every product team is overflowing with ideas and possibilities, and it’s up to the product manager to determine which is worthy of a pull request. Prioritization is essential for selecting what activities will be best for the product, customers, and the business.

Yet, prioritization can be crippling if performed haphazardly. Methodical thinking ensures that prioritization is objective, transparent, and rational, and thankfully, several frameworks exist to support this process.

The Moscow Method

A simple framework is the Moscow Method—stylized MoSCoW—a four-tier categorization that’s easy to understand, mitigates risk, and can swiftly align stakeholders. While more sophisticated frameworks can better serve specific use cases, MoSCoW is the most versatile starting point.

The funky name is a glorified acronym for its four prioritization tiers: Must, Could, Should, and Would.

Moscow’s simplicity is both its biggest strength and greatest setback. While flexible and intuitive, it can generate too many high priorities and harbor bias if mismanaged. That said, Moscow’s benefits far outweigh its issues when understood for what it is. Moscow is an axe, not a scalpel.

When confronted with a disordered backlog or meandering list of requirements, you’d do right with Moscow. On the epic level, you can use Moscow to prioritize a list of projects, high-level product capabilities, and primary features. On the story level, Moscow can help you order a list of specific requirements and acceptance criteria.

Step 1: Define

To make Moscow effective, your team and stakeholders must get translucently clear on definitions.

Must = If not done, the product is a failure

These are mandatory and non-negotiable. Common examples include core product capabilities, such as mitigating security vulnerabilities. To determine if something is a Must, ask: Will the product work without this? You might get different answers from different stakeholders, so here’s a follow-up question: Is there a simpler way to accomplish this?

Should = Important but less urgent

The feature may have a stop-gap solution, although its completion would add significant value. Common examples include performance improvements, minor bug fixes, and new functionality. Every Should ought to have a clear metric attached so the value is objective. Ask: What quantified value does this create?

Could = Desirable but not necessary

The feature may have a slight negative impact if not done, but won’t leave much value on the table either. Only include these if time and resources permit. Common examples include user experience improvements and features that improve customer satisfaction, like dashboarding. Ask: Does this impact the core offering?

Would = not a priority

You would do it if you had unlimited time and resources, but since that’s never the case, you won’t be doing these features. Avoiding Woulds prevents scope creep. Ask: Could we justify doing this in the next six months?

Document these definitions where all your stakeholders can refer to them. Use simple terms relevant to your product. i.e., Must = XYZ cannot function without it.

Step 2: Triangulate

With your terms articulated, approach various stakeholders with your backlog. I recommend doing smaller reviews with each functional team separately to keep the discussions focused and the context consistent. At a minimum, meet with three groups:

• Technical: The scientists and engineers who will research and develop.

• Market-Facing: The salespeople and client success managers who will sell and support.

• Business: The other product managers and leaders who will assess other product initiatives and the company’s broader strategy.

Walk each group through the backlog and rate each item. Then, triangulate ratings across the groups to create a unified rating. Triangulation is difficult because you must balance operational items, short-term business needs, and long-term strategic moves. Engineering may want to clear a tech debt that reduces pager noise. Sales may wish for a specific feature to close an upcoming deal. Product may want a capability that will strategically drive the adoption of a new offering.

Weigh these needs against each other to arrive at a unified list. There are many philosophies on how to weigh competing needs, but use your judgment for the first pass. Again, think axe, not scalpel.

Step 3: Stack

Once you have a rated list, refine it to craft the appropriate distribution of each category. Ideally, stack your list into a pyramid structure.

In a list of twenty items:

• 1-2 can be Must

• 3-5 can be Should

• 5-10 can be Could

• Any remaining items can be Would.

The team cannot understand what’s most critical for success if there are more than 1 or 2 items marked “Must.” If you have more than three, get recursive and rank the first-round Musts using Moscow. Which is the most Must of the Musts?

From here, the rest of the pyramid can build itself.

Once you stacked your pyramid, socialize the backlog with your stakeholders to set expectations for upcoming deliverables. Even if folks aren’t happy with the result, they’ll appreciate the clarity you created.

Action Items

Define Must, Should, Could, and Would for your product. Document these in a wiki and use them the next time you’re in a prioritization discussion.

Big projects fail all the time. The failure may not be apparent—no one gets fired, and no public criticism emerges—but that’s typical of a product failure: Nothing happens.

We like to blame budget for failures. Corporate slashed expenses! We’re in a hiring freeze! Our resources weren’t approved! All companies are cost-constrained, yet budget remains a scapegoat for a lack of execution. While there are many ways to fail at execution, poor planning is the root. No plan is perfect—it may be too rigid, too detailed, or too high-level—but plans have more surface area for failure the larger they get because they’re increasingly divorced from reality.

A good product manager remains ambitious while creating pragmatic plans, and one approach they employ is capacity-first planning.

Capacity-First

The usual plan emerges from a grand vision. Teams imagine the future, outline a waterfall of activities, and then plead for funding to make their PowerPoint slide a reality. Even if the ever-elusive budget comes, it’s never enough, so they haphazardly cut scope, resulting in a convoluted chimera of a product.

Our eyes are bigger than our story points.

Capacity-first planning flips the narrative. Instead of begging for resources, we start with the time and resources available (i.e., half an engineer’s time and a summer intern) and accept them as fixed constraints. We can only modify the scope if we can’t increase time or resources. And that unlocks creative freedom.

A Common Language for Capacity

Capacity is a function of time and resources, where “resources” are the people capable of executing the work, and “time” is their available working hours.

Let’s develop a common language around capacity by defining “story points.” The Scrum Bible decrees that story points are a team’s understanding of complexity and should not reflect time. While complexity-based points can be a useful abstraction, it’s more practical to start with a de-scrummified and easy-to-measure concept: hours.

In an eight-hour workday, an engineer will spend a few hours on meetings and administrative tasks, like email. After factoring in breaks and lunch, one would be hard-pressed to achieve more than five hours of work. With your team, agree on a realistic number of daily working hours and equate that to one story point.

5 hours = 1 working day = 1 story point

To estimate capacity for an iteration, start with the number of workdays and multiply by the people on your team. If you have two and a half full-time engineers and a two-week sprint equals ten working days, you’d have a 25-point capacity.

2.5 people x 10 working days = 25 points

You can easily tweak this to reflect the nuances of your iteration. If an engineer plans a vacation for three days this sprint, only count seven points for her in the capacity.

The Appetite Razor

37signals—the company behind software like Basecamp—operates its projects based on “appetite.” They discuss how much capacity they’re willing to invest into the idea before starting work. An appetite of three weeks creates an incredibly different set of conditions than an idea worth three days.

When you have a firm grasp of capacity, you can have appetite-based conversations with engineering. You can negotiate what scope is critical and efficiently align the goals of a project. Expressing appetite can prevent overbuilding by making incremental progress without constructing unnecessary infrastructure.

Capacity-first planning is not an excuse to cut corners. An expression of appetite should encompass all work needed to accomplish the project—design, development, deployment, documentation, etc. But sometimes, a promising idea is infested with unknowns and is too risky to stomach, so your appetite shrinks. When you have a small appetite, consider a timeboxed spike to do a feasibility analysis or prototype the idea. Whereas the output of a standard project is working code, the output of a spike is information.

Whatever your appetite, if the team doesn’t have the capacity, you’ll need to cut scope. This humanist approach avoids burnout and fosters better morale, as team members needn’t overperform to produce miracles. A respected team is a reliable team and a reliable team consistently executes. Some argue that execution is less important than strategy, but they’re debating a false dichotomy because execution is the strategy. And capacity-first planning creates a culture of execution.

Action Items

Pick a project in your backlog.

Reflect on how much capacity you’re willing to invest in it.

Ask an engineer what amount of scope is feasible, given your appetite.

Junk Drawer

I launched the Product Field Guide Website to house these articles, related ideas, and other resources about product management. Check it out, and let me know what you think. I appreciate all feedback!

Leave a comment

Share Product Field Guide

Any product initiative requires a clear vision. Vision, by its very definition, suggests a view of the future, and the more tangible and specific that future is, the more precise the vision becomes. Working backwards is a proven method to define the vision for a product.

Working backwards embodies Covey’s quote. The process starts with the customer and the problem, then steps through the roadmap to make it happen. It’s simple, and that’s the point: Working backwards shaves away the confusion and dead ends that come with working forwards to provide a straightforward path to the result.

Working Backwards

Here are the main steps of working backwards:

1. Start with the customer. Identify the customer and their problem with a fictional press release.

2. Deeply evaluate the opportunity. Review the press release and details with peers and leadership to decide whether the idea is worth pursuing.

3. Define the solution. Drill into the details to architect the solution and align stakeholders.

4. Build the roadmap. Define the major milestones and epic-level work items.

5. Execute the tasks. Create the detailed backlog tasks and begin executing.

Press Release

Amazon is famous for working backwards. Since 2004, each of their product launches has followed this approach because they systematized the process with PR/FAQs. A PR/FAQ is a fictional press release for the product and an accompanying list of frequently asked questions to explain the steps to make it happen. This method came from humble beginnings (not some academic theory), as the details emerged in a simple Quora answer.

Let’s focus on the PR of PR/FAQ by discussing how to write an internal memo that mirrors an external press release.

This press release is not a spec. It should not contain any technical jargon, “geek speak,” or acronyms. It should be one page long, written in prose (not bullet points), using paragraphs of 3-4 sentences in digestible language. The first draft does not need to be perfect—most go through 5-10 rounds of feedback and revision to get it right.

Focus on the customer outcome and summarize the goals concisely and non-technically. The clarity of this document will remain a north star during development.

Template

Here’s a simple press release template:

[Title]
[Subtitle]
[Location] / [Date] - [Introduction]
[Problem]
[Solution]
[How it Works]
[Customer Quote]
[Call to Action]

Each component of a press release contributes to the product’s vision. The subtitle provides a pithy explanation of the benefit, the date establishes when to work backward, and the quote anticipates how the customer will react.

Here’s guidance for crafting each component:

• Title. Name the product so that the customer will understand.

• Subtitle. Provide a one-sentence summary of the market and the main benefit.

• Location & Date. The date sets the target, and the location specifies the company headquarters.

• Introduction. Spend a sentence or two summarizing the value. Don’t bury the lede; some readers won’t scan beyond this.

• Problem. Articulate the customer and their challenge, ideally using qualitative and quantitative reasoning.

• Solution. Explain what will address the customer’s problem in layman’s terms.

• How it Works. Briefly describe how the solution works and how customers will receive the benefit.

• Customer Quote. Make up a quote from a target customer, using appropriate language to express how they’re happy with the outcome.

• Call to Action. Provide the next steps (i.e., read more at [URL], sign up at [URL], try the beta at [URL].)

Appropriate Use

You can write a fictional press release for many initiatives, even internal ones—such as a new policy, process, or tool. Tweak the customer quote to reflect an internal user and change the location to a work site.

However, don’t force-fit a press release for a project that doesn’t solve a customer problem. The ease of writing a press release is a proxy for product-market fit, so if the concept of a press release isn’t making sense, it’s an indicator that the project isn’t solving a real problem.

Even if you write a compelling press release, don’t be surprised if your initiative doesn’t move forward. Most ideas won’t get funded because a company has limited resources and must discern which initiatives to pursue. That said, a press release can give your idea a fighting chance because it’s centered on a timeless fundamental: serving customers.

Work backwards by asking, “How does this benefit the customer?”

Action Items

Pick one project you’ll work on in 2024 and outline a fictional press release.

If you’ve already written a press release, share it in the comments!

Leave a comment

Measuring product success is tricky. Chasing profit, user satisfaction, or efficiency are likely insufficient success indicators because a myopic focus on metrics can lead us astray. Yet, not tracking performance metrics is also inadequate. A good product manager will track several performance indicators for their company, projects, teams, and themselves, so defining meaningful metrics is critical. Like swans, meaningful metrics come in pairs: A baseline and a target.

A baseline is a starting point—where you’re at today.

A target is a future point—where you’d like to be.

You cannot have a meaningful metric without these two numbers.

To define key performance indicators for a product, measure the difference between the baseline and the target so you’re not chasing a solo swan. Establishing a baseline is a prerequisite to setting a target.

Baseline

The baseline is essential because it necessitates two things:

1. Knowing what to measure

2. Having a firm grasp of reality

Knowing what to measure is no small task because pursuing the wrong metric can create perverse incentives. Venomous cobras were a public health crisis in Colonial India, so the British government offered a bounty for every dead cobra. Rather than decrease, the cobra population grew because people bred them for bounty money. The Cobra Effect occurs when the wrong metric—or even the right metric in the wrong context—is applied.

When measuring product performance, your first job is to select the right metric. In general, establishing metrics should follow the desired business outcome, but here are a handful of useful metrics to consider:

• For an app in the consumer space: daily active users (DAU), cost per install (CPI), and lifetime value (LTV).

• For a B2B SaaS product: customer acquisition cost (CAC), retention rate, and monthly recurring revenue (MRR).

• For an internal product: error rate, user cycle time, and net promoter score (NPS).

Once you’ve selected the metric(s) you wish to track, establish a firm grasp of reality. This grounded perspective is the foundation for data-driven decisions, such as setting your target metric. To grasp reality, you must benchmark.

Benchmark

Benchmarking is the act of establishing your baseline. First, understand what data will help you create the baseline metric and how to capture said data. If you’re looking at DAU, you’ll need an analytics solution to show how often unique users return to the product. To understand NPS, you’ll need a user survey to source initial results.

When defining your benchmarking goals, consider the collection mechanism and the reporting frequency. Figure out how often you’ll need to receive and review this data. DAU would require daily updates, while MRR or CAC could occur monthly.

After collecting for a reasonable time (30 days is a good rule of thumb, but this varies by metric) and the collection mechanism has proved reliable, assess the mean and median of the benchmarked data to set your baseline.

After defining your baseline, you can set the target.

Target

Ironically, setting the target metric becomes more philosophical than data-driven. While the essence of the baseline metric is to form a firm grasp of reality, the target metric should inspire action. With that goal in mind, two schools of thought arise: The Realist and The Mystic.

The Realist sets attainable targets that are feasible to attain.

The Mystic sets idealistic targets that are almost impossible to attain.

The Realist believes that feasible targets inspire action because one can visualize success and define a rational path to get there. Imagine a business with $2M MRR (baseline) that wants to achieve $2.5M MRR (target) by year-end. This goal may be feasible if the company has a product-market fit, a decent sales funnel, and stable operations.

The Mystic believes that a high target metric can manifest the necessary behavior—inspiring teams to rise to the occasion and get creative. Imagine a business with $2M MRR (baseline) that wants to achieve $10M MRR (target) by year’s end. Even with product-market fit, a decent sales funnel, and stable operations, this goal could be impossible since it hinges on 5x growth in a year. Setting a target like this is aspirational, and that comes with risk. People might view it as absurd, ignore it as a vanity metric, and not invest the effort to make it happen. Or people could over-index on it at the cost of recreating the Cobra Effect.

As a rule of thumb, product managers are pragmatists, so we should bias toward The Realist mentality: set feasible target metrics informed by well-established baselines.

After accruing measurable wins and earning more ownership, we could unlock the gumption to set more Mystical targets.

Takeaways

To set up your success metrics for success:

1. You need a baseline (where you are) and a target (where you want to be).

2. If you don’t know your baseline, set up a collection mechanism to benchmark.

3. After establishing a baseline, set a feasible target metric informed by reality.

Action Items

This week, evaluate your product’s performance metrics. For each metric, ask yourself:

1. Is my baseline accurate?

2. Is my target feasible?

If you don’t have a baseline metric, what do you need to start benchmarking?

Leave a comment

A new role is exciting, scary, intriguing, confusing, fun, and overwhelming, especially at a new company that feels like a distant planet where everyone’s speaking Acronymish.

In an ideal world, you’ll have a clear 30-60-90 plan that defines success and some low-hanging fruit to pluck along the way. Often, this is incomplete at best.

I’ve started new roles nine times in my product career, and my most effective onboarding occurred when I learned by doing. So, here are 30 actions to earn quick wins and accelerate learning in your first 30 days of a new product role.

Note: The list is numbered for ease of reference and is not exhaustive nor prescriptive—it’s a grab-bag for getting started.

1. Take meeting minutes. In team meetings, volunteer as scribe and share notes afterward. Notetaking will help you better digest the material, and you’ll do the team a small favor—adding value and demonstrating humility.

2. Meet customers. Ask to shadow a product-related call with an account manager or participate in a discovery call with a designer.

3. Create new hire training. Make it easier for the next person who joins the team.

4. Use the product. Get the proper permissions and use the product! Even if the product is an internal system or has no user interface (like an API), use it a few times and get a sense of how it works.

5. Make a list of product issues. As you use the product, log your onboarding challenges and questions about features. These will help you understand gaps in your knowledge and could inspire product improvements later.

6. Review user feedback. Ask team members for user-reported feedback—these might be in a system like Jira or (more likely) some clunky spreadsheet. Read each one manually and label them.

7. Get the latest slide template. Ask a marketer for the most recent slide template that follows company brand guidelines. While it may seem trivial, your future presentations will demonstrate best practices and reduce the surface area for nitpicking.

8. Perform a competitive analysis. Do some light market research to see what the competitive landscape looks like. Put these learnings into a few slides and share them with your team.

9. Understand how you’re measured. Meet with your manager and ask what OKRs, KPIs, or goals they have for the year and how you can help.

10. Create or improve the product dashboard. Ask where you can see product performance metrics (i.e., latency, uptime, active users, revenue, sales pipeline, churn, customer acquisition cost). Help aggregate the most important ones into a simple view.

11. Meet everyone on the team. Schedule a short 1:1 with each person to learn what they do and their challenges. Ask relevant questions about the product to round out your knowledge—i.e., ask a marketer about positioning or an engineer about the architecture.

12. Schedule recurring 1:1s. For people you’ll regularly collaborate with (i.e., the engineering lead and your manager), schedule a meeting at a cadence they recommend.

13. Perform QA testing. Ask to help test a new feature before launch. Ask for the most tedious test cases to take the load off the team and go deep with the product.

14. Make a pull request. Ask engineers if there’s any simple coding work you can take off their hands (i.e., running test scripts, performing routine data ingestion) so you can get comfortable with the tech stack and DevOps process.

15. Schedule 30, 60, and 90-day reviews with your manager. Set up 30-minute check-ins every 30 days to get honest feedback on your performance. Take the feedback seriously.

16. Memorize the org chart. Review reporting structures to understand how work flows through the organization.

17. Create or update product FAQs. Based on your learnings, compile short and simple FAQs and share them with the team so they don’t need to repeat themselves when others have similar questions.

18. Query logs. If your product has plaintext search logs or usage statistics, ask for SQL read access to the relevant databases so you can perform exploratory data analysis. Put your query templates on a wiki page and share your findings with the team.

19. Update the wiki. As you read the documentation and discover outdated information in your talks with team members, update the wiki. If the content doesn’t exist (i.e., how to query search logs), create it.

20. Update system diagrams. When you review architecture diagrams with an engineer, and they say, “That’s outdated; it works like this now,” update the diagrams to match.

21. Offer to write status reports. For a project status report, ask if you can facilitate writing and sending the email. Ensure the sender list is up-to-date and all the content remains relevant.

22. Do the grunt work. Offer to do any busy work for your team (i.e., data entry or document formatting). Be clear that this is a one-time favor and not your new job.

23. Collect bookmarks and acronyms. Keep a running file of valuable links and acronyms. Add this to your new hire training and share it with the team as a common resource.

24. Assist your stakeholders. Understand the key internal stakeholders of your product—a representative in sales, a vocal account manager, and a product leader are a good start—and make a good impression by listening to their needs and earning them a quick win (i.e., updated FAQs, a better product dashboard, a clear status report).

25. Ingest what your customers ingest. Figure out what your customers engage with—are there industry reports they read, podcasts they listen to, or online forums they chat in? Find these and subscribe.

26. Honor the history. Ask a tenured employee about the history of the company and its products. Learn how it came to its current state, what challenges and successes it had in the past, and how the users/customers have changed.

27. Tighten up acceptance criteria. Look at some tickets your team is working on and ask if any requirements are unclear. Update them with the right level of detail.

28. Learn to send praise. Many companies have an HR tool to send a public “thanks” to coworkers. Do this for someone who was especially helpful in your onboarding.

29. Clean the backlog. Review it with a teammate to close outdated items, combine related ideas, and add light prioritization.

30. Reserve judgment. Many processes won’t make sense, but try to learn why they exist, and don’t assert your opinion too strongly in the first month. Nobody likes a Scrum Zealot.

This post was inspired by Jackie Bavaro’s tweet about your first 90 days.

Action Items

Whether new or seasoned, your role could benefit from at least some of these ideas. Pick one idea to action by Friday.

Let me know how it goes!

Leave a comment

A CEO I worked for set the tone within his first week. He joined in November, right before the Thanksgiving holiday, and learned that the annual sales kickoff was scheduled for February. That was too late, as the sales team would be directionless for the first month of the new year. So, he requested the kickoff to occur in December. Two months of planning compressed into two weeks. The slide decks weren’t pretty, the swag didn’t arrive on time, and the presentations weren’t polished, but the kickoff happened before year-end. And the sales team gained an extra month to hit their targets.

With that first kickoff, the CEO coined the idiom pull it to the left in the company vernacular, creating a culture of speed that separated us from competitors and led us to dominate our niche.

Pull it to the Left

Picture a Gantt chart depicting a project’s timeline, where the delivery date is somewhere to the far right of the chart. “Pulling it to the left” means moving that delivery date forward. Move faster, increase the urgency, and bring the target closer to the present. Instead of February 15^th, could we do January 1^st?

Shortening the timeline can up the tempo, as urgency creates clarity and offers opportunities for practical creativity. To meet a condensed timeline, teams can improve clunky processes, drop low-value requirements, and sculpt more efficient working hours. A faster delivery necessitates cutting scope, but not at the cost of quality. Pulling to the left believes in iteration—in making forward progress while acknowledging that a first attempt will be imperfect. Future iterations can address those imperfections, but nothing can be improved if it doesn’t exist in the first place.

Speed Matters

Speed matters in business. Environments and conditions change, and opportunities will expire, so we should act on them. Sitting on a new feature is a travesty when someone could benefit from it today.

People and organizations tend to procrastinate and default to a leisurely pace, so opting for speed is a strong differentiator—both on the personal, team, and company levels. Moving a to-do item from tomorrow to today, replying to a client in a day instead of a week, and bringing an MVP to market this quarter instead of next quarter are all ways speed differentiates.

Product managers are responsible for delivering value to their customers, so bias for action is a critical trait. Other teams will strive for perfection—design, engineering, analytics, ops—but a product person should get off localhost and shorten the time to value.

Bias for Action

When ideating for this newsletter in December, I created a mile-long project plan. The plan gave me confidence but felt like a two-ton elephant dangling over me. I needed a website! An X account! A marketing plan! A logo! The excitement around Product Field Guide morphed into overwhelm and stress, so I resigned to launching in March. I would use the two months to configure the above, validate some ideas, and do all the “proper” product management things like creating a persona, mapping out their user journey, and understanding the total addressable market.

Then I heard the CEO yelling, “Pull it to the left!”

They say you should be embarrassed by your first launch. If you’re not embarrassed, you waited too long, and I was too comfortable with my March timeline.

Instead of two months, how could I deliver value this week? I didn’t need a perfect logo or a website—Substack was sufficient for collecting subscribers and sending mail. And what better way to set the tone for my new venture than launching on Monday, January 1^st!

In the words of Reid Hoffman:

Action Items

Pull something to the left this week:

• Is your strategy doc due in February? Finish is this week.

• Did an annoying to-do item carry over from last year? Do it today.

• Are you holding off sending an important email? Reply now.

Happy New Year, and see you next Monday!

Subscribe now