There is another version where you build a public track record while you are employed. A newsletter, a talk, a repo, a thread that goes farther than you expected. The compounding is real. So is the risk of doing it badly.

I am nine weeks into writing this newsletter under my real name while employed at a big company. Long enough to have made the small mistakes but short enough that I still remember what they felt like. Here is the playbook I am running.

Why do this at all

Three reasons.

First, leverage. The single hardest thing about senior PM careers is that most of the signal you generate is trapped inside the company. Internal docs, internal reviews, internal decisions. If you leave, most of that evidence does not travel. A public body of work is a portable resume that also makes the internal one better.

Second, thinking. Writing forces the argument to be clean. I have caught more sloppy reasoning in my own head by trying to explain it to strangers than I ever caught in a spec review. The newsletter is a forcing function for a clarity of thought that the day job rewards but rarely demands.

Third, optionality. The market for senior PMs is bifurcating. On one side, people known for a specific point of view. On the other side, people known for a specific title at a specific company. The first group has more doors. Building the first version of yourself while you have the second is cheap insurance.

What the risk actually is

The risk is not that a VP reads your post and gets angry. Most VPs do not read newsletters. The risk is more specific.

• You accidentally publish something that reads as a competitor pitch.

• You describe an internal process in enough detail that a security or PR team asks who authorized the disclosure.

• You take a stance in public that contradicts a stance your team is about to take, and now your team looks incoherent.

• You develop a public voice that is materially more interesting than your internal one, and eventually someone asks why.

Notice that none of these are catastrophic. They are correctable. But they are all easier to prevent than to unwind, which is the whole point of having rules.

The four rules

Rule 1. Write about the craft, not the product.

The safest topics are the ones about how you think, not about what you ship. How I run a spec review. How I decide when to say no. What I look for in a launch. These pieces reveal the operator without revealing the operation. They are also, not coincidentally, the pieces that build authority fastest, because they are the pieces a reader can actually use.

Product specifics are where the trouble starts. Unlaunched features, roadmap intent, internal metrics, customer names, deal shapes. Anything a competitor could use, anything a customer could feel exposed by, anything a lawyer would want to review. That is not the same as “never mention what you work on.” It is fine to say what team you are on. It is fine to say what problem space you think about. It is not fine to describe a decision that has not been made externally yet.

Rule 2. If you would not say it in an all-hands, do not put it in the newsletter.

This is the single rule that has saved me the most. If I would not raise my hand at a company-wide meeting and say the exact sentence, it does not go in the post. Not because all-hands are the ceiling of what is acceptable, but because the audience is the same: employees, customers, partners, and people who wish they were any of the three. Public writing has the same reach with less context.

The rule is not that the newsletter has to be corporate. Mine is not. The rule is that the version of me writing the newsletter has to be recognizable as the same person who shows up at work. If I would not defend a sentence in front of my manager and my team lead in the same room, I do not want it in print.

Rule 3. Publish about the past, not the present.

The riskiest posts are about work you are doing right now. The safest are about work you did months or years ago, at a level of abstraction that a reader can generalize. This is a hard rule to hold because the present is where the good material is. But the present is also where the confidentiality is thickest, the framing is least settled, and the risk of contradicting an as-yet-unannounced position is highest.

The workaround is to lag. I let ideas sit for weeks before I publish them. By the time a post ships, whatever proprietary edge it had is gone or public. What is left is the reasoning, which is the part worth publishing anyway.

Rule 4. The “views are my own” line is not a shield. Behave as if it did not exist.

Every senior PM who publishes under their real name uses some version of the disclaimer. It is polite. It is professional. It is not, functionally, protection. If a post causes a problem at work, the disclaimer will not save the conversation. It will just make the conversation slightly shorter.

The right posture is to write posts you would defend without the disclaimer. The disclaimer stays because it is a norm, not because it is doing work.

The mechanics I actually use

A few concrete practices, in case they are useful.

• A four-eyes rule for anything ambiguous. If I am not sure whether a paragraph crosses a line, I ask a peer I trust to read it before it ships. Not to get a formal approval. Just to check whether the read from outside my head matches the read from inside it.

• A “delete this sentence” test. Before I hit publish, I look at the piece and ask which single sentence would cost the most if it were quoted back to me in an unfriendly context. Then I ask whether that sentence is doing enough work to justify the cost. Usually the answer is no, and it gets cut.

• A weekly cadence, not a daily one. Daily publishing at a big company is a way to eventually publish something you regret. Weekly gives time for the “would I still write this in three days” filter.

• Real name, no anon. Anonymous accounts feel safer and are actually riskier. The moment you are outed, every piece of the archive gets re-read in a hostile frame. Publishing under your real name from day one forces the discipline the anon account lets you skip.

What I have not done

I want to be honest about the moves I am deliberately not making, because a playbook without omissions is not a playbook.

• I have not filed an Outside Activities Approval. My current writing is analysis and opinion, not paid work or consulting, and my read is that it does not require one. If the writing ever generates income, or if I take on paid speaking, that changes and I file first.

• I have not built an audience play around the company brand. I do not want the newsletter to succeed because of where I work. If it does, the audience is not really mine.

• I have not done a launch post about my current team or product. Some day I might. It would be a specific choice, cleared through the right internal channels, not a default.

Why this matters more than it used to

Ten years ago, a senior PM at a big company could be visible or invisible, and the market would treat both roughly the same at hiring time. That is not the market anymore. The bar for “senior IC PM at a top-tier company” has enough people at it that the differentiation is starting to happen outside the company, not inside. That does not mean everyone needs to be public. It does mean that the option value of being public is going up.

The playbook above is not the only way to do this. It is the way I am doing it. If you are in a similar spot, I hope some of it is useful. If you are not, and you are thinking about starting, my suggestion is to write the first three pieces in a private doc before you publish anything, so you can see whether the voice holds up when nothing is at stake.

That is the piece for this week. Next week: the PM job description in eighteen months, and what I think will actually be on it.

If this was useful

Forward it to a senior PM who is thinking about writing in public. That is the whole distribution engine at this stage.

Luiz

Roadmap reviews are theater when they are done well and interrogation when they are done badly. Neither is where the roadmap actually gets better. The roadmap gets better in the quiet hour before, when somebody with no ego and no political stake in the outcome asks the three questions the room will not ask with the same honesty. That somebody used to be a peer you trusted. Now it can be three prompts.

I own roadmap decisions for employees, customers, partners, and technical communities. The plan touches labs, assessments, content workflows, and the tooling that keeps a large catalog alive. Before any serious review, I now feed the roadmap into three separate model sessions with three different system prompts. Each one plays an adversarial lens. Together they give me the pre-mortem the room will not.

Here is the drill.

Why three lenses, not ten

You could invent ten personas. Do not. Every lens you add dilutes the signal and burns your own reading time. Three lenses is the smallest number that covers the three trade-offs a roadmap has to survive.

• Cost defensibility. Is every eng-month on this plan buying something a rational finance leader would fund again next year.

• Customer value. Does the plan solve the problem the person actually using the platform would name if you asked them.

• Competitive exposure. Does the plan leave a door open that a serious competitor would walk through.

If a roadmap item cannot survive at least two of the three, it is a candidate to cut, defer, or reshape. If it fails all three, you are keeping it for internal reasons that deserve to be named out loud.

Lens 1, the skeptical CFO

The point is not to model a real CFO. The point is to force yourself to answer, in plain language, why the money is well spent.

The system prompt I use:

You are a skeptical CFO reviewing a product roadmap. You are not
hostile, but you have seen too many plans that spent engineering
months on work that did not defensibly move revenue, retention,
cost, or risk within four quarters. Your job in this review is:

1. For each roadmap item, ask the single sharpest question you
   would ask if you had to defend this line in the annual
   planning cycle.
2. Flag any item where the mechanism from work to business
   outcome is more than two steps long, or depends on an
   assumption the PM has not stated.
3. Group items into: clear defensible spend, defensible with
   caveats, and unclear. Do not soften “unclear.”
4. Ignore emotional framing. If a phrase reads like advocacy
   (”critical,” “must-have,” “foundational”), replace it with
   a neutral description of what the work does.

Output: the three groups above, plus your one sharpest question
per item, plus a short section titled “the two items I would
cut first and why.”

What this catches, in my experience, is the item that survived last planning because everybody was tired, the item that describes a capability instead of an outcome, and the “foundational work” that never traces back to a metric anyone tracks. It also catches the two items I quietly know are weak but was hoping the room would let slide.

What it misses: political context. A CFO model does not know that item four exists because a partner made a commitment two quarters ago, or that item seven is the price of keeping a senior engineer engaged. That context is your job to add on top.

Lens 2, the frustrated customer

Not any customer. The one who is on the platform right now, using the thing, and who would give you the ninety-second version of what is broken if you cornered them at a conference.

The system prompt:

You are a senior technical practitioner who uses this platform
weekly. You are frustrated but constructive. You do not care
about the roadmap themes or the strategic narrative. You care
about the moments that make you sigh, close the tab, or send
a Teams message asking somebody else to fix it.

Your job:

1. Read the roadmap. For each item, say in one sentence what
   friction, failure, or unmet need it resolves for a user
   like you. If it does not resolve one, say so plainly.
2. Then, ignore the roadmap and list the five things about
   the platform that make you sigh, in order of severity.
3. Cross-reference: which of your five sighs does the
   roadmap address, and which does it not.
4. Do not be polite about the gap. Do not invent problems
   that are not in the reference material provided.

Output: the per-item resolution, the five-sigh list, and the
gap analysis. End with the one thing you would ship first if
you were the PM.

What this catches: the plan that is full of interesting projects and empty of the boring five things that would make the platform noticeably less annoying. Every roadmap I have ever run has at least one of these. The lens does not invent the sighs. It surfaces the sighs implicit in the material you gave it (support themes, feedback tickets, past release notes if you paste them in).

What it misses: the customer model does not know what is technically feasible in the window. Some of the five sighs are hard problems that will take three quarters, and the roadmap is honest about that. Read the gap as a prompt, not a verdict.

Lens 3, the hostile competitor

The point is not paranoia. The point is to look at your own plan the way someone who wanted to displace you would.

The system prompt:

You are a product strategist at a serious competitor. You do
not have unlimited resources, you have to pick your fights.
You just got a copy of this roadmap. You have thirty minutes
to write an internal memo for your team titled “where they
are leaving the door open.”

Your job:

1. Identify the two or three areas where the roadmap is
   silent, thin, or scheduled far enough out that a fast
   mover could ship first.
2. Identify any strategic assumption in the plan that, if
   wrong, breaks the plan. Name the assumption in one
   sentence.
3. Pick the one wedge you would build if you wanted to peel
   off their most valuable segment in the next twelve months,
   based only on what this roadmap shows and does not show.
4. Be specific. “They are weak on AI” is not useful. Name
   the surface, the workflow, or the segment.

Output: the three-point memo above. End with the single
sentence you would put at the top of the memo for your CEO.

What this catches: the silences. Roadmap conversations spend most of their time on what is in the plan. This lens spends all of its time on what is not, and where the silence is dangerous. The best output I have gotten from this prompt was a three-sentence description of a workflow we had deprioritized because it was hard, which a competitor could ship as a hero feature.

What it misses: the model has no idea what is on your competitors’ actual roadmaps. It is not competitive intelligence. It is a pre-mortem for the plan you are about to defend, run by someone assigned to poke it.

What the three lenses do together

Any one of them can be dismissed. All three at once, on the same roadmap, in the same afternoon, is uncomfortable in a way that is useful.

I read the three outputs in order (CFO, customer, competitor), highlight anything two of them flag independently, and mark those items for hard conversation. Convergence is the signal. If the CFO thinks item four is weak, the customer does not see themselves in it, and the competitor sees it as a place they would attack, the item does not go into the review as-is. It either gets reshaped, deferred, or cut, and the cut gets named honestly in the room.

The residual is what you defend. The items every lens can articulate a reason for. Those are the items you can walk into the review already knowing how you will answer the hardest question in the room, because a version of it has already been asked.

Where this workflow is wrong

Three honest limits, so you do not over-trust the output.

• It cannot see culture. The plan carries commitments to specific people, teams, and partners that a model cannot read. Item seven exists because a senior engineer wants to build it and losing them costs more than the item saves. That is a real reason. Just make sure it is the reason, and that you have named it.

• It cannot see sequence dependencies. A model reading a roadmap as a flat list can call item three low-value on its own without seeing that item three unblocks item nine, which is the biggest bet on the plan. Bring your own dependency map to the reading.

• It can invent confidence. The output looks decisive. The confidence is a stylistic artifact of the model, not evidence. Treat every “the two items I would cut first” as a prompt for a real conversation, not a verdict.

Nothing in this workflow makes the roadmap smarter on its own. What it does is force you to answer three questions before the room does. It surfaces the items you were hoping nobody would ask about. It names the silences. It gives you a chance to reshape the plan while you can still reshape it cheaply, in a text file, at a desk, instead of expensively, in a review, in front of an audience.

The chart is not the decision. The plan is not the decision. The decision is what you can still defend after somebody who is not on the team, does not owe you anything, and does not care about your quarter, has poked at it. That used to require three people. Now it takes three prompts and a quiet hour.

See you next Tuesday (sorry, busy day yesterday and I'm late).

Luiz

If you run this on your own roadmap this week, I want to hear which of the three lenses was the most uncomfortable, and what it flagged. Reply or drop it in the comments.

Views are my own and do not represent Microsoft.

Every PM I know has shipped a change based on a test that did not actually prove what they thought it proved. I have done it. I have watched a team celebrate a two percent lift that vanished the next quarter. I have sat in a review where a variant got killed because the presenter could not answer one question about sample size. I have approved something based on a test that peeked five times before it ended, which meant the “significant” result had roughly the same evidentiary weight as a coin flip.

I run experiments on a platform used by Microsoft employees, customers, partners, and technical communities. A lot of what we ship touches labs, assessments, content workflows, and the tooling that keeps a large catalog alive. The traffic is real, the stakes are real, and the temptation to declare victory on a clean chart is real. This is the field guide I wish somebody had given me at early levels. Five things a senior PM should be able to explain in a launch review without opening a stats textbook.

1. What you are actually buying when you run a test

The reason to run an experiment is not to prove your idea works. It is to rule out the alternative explanations for why the number moved.

Say you are running a test on a labs discovery page. You change the layout on Tuesday, and by Friday, lab starts are up three percent. You want to say the new layout caused the lift. You cannot. You just changed the layout the same week a partner ran a big skilling push, the same week a competing platform had an outage, and the same week a top acquisition surface shifted its mix. Any of those could be the story. Correlation is easy to see. Causation is the thing you have to earn.

An A/B test earns causation by holding everything else equal. Randomize users into two groups, show one the new layout and the other the old one, run both at the same time to the same audience. Now the partner push, the outage, the acquisition shift, all of it hits both groups equally. If the treatment group starts more labs, the treatment is the most defensible explanation left standing.

That is the whole product. Everything else in this issue is about the ways that machine breaks. Three risks show up most often. Confounders: something other than your change is correlated with the treatment (you shipped the flow to one region first, so you tested geography, not the flow). Selection bias: users in each bucket are not comparable (you let people opt in, so you tested motivation, not the feature). Bad randomization: the assignment logic is broken in a way you did not check.

If you cannot name which of these three risks your test is protecting against, you are not running an experiment. You are running a slower rollout with a chart on top.

2. Hypothesis, metric, guardrail. In that order.

Before the code goes anywhere near the assignment logic, write three lines. Hypothesis: if we change X, we expect Y will move in direction Z, because of mechanism M. Primary metric: the single number that decides the test. One. Not three. Guardrails: the numbers that must not get worse for the launch to be a good idea even if the primary moves.

The guardrails are where the discipline slips. Say you are testing a change to an AI-assisted authoring step in a content workflow. Your primary metric is “time to draft ready.” It drops thirty percent. Wonderful. Meanwhile the downstream editorial rework rate quietly climbs, because the drafts you shipped faster were half-baked. You did not win. You moved a problem downstream.

Pick the primary metric that most tightly matches the causal claim. If the mechanism is “reduce friction at the first-lab-start step,” measure lab starts, not total learning hours. Total hours are downstream of a hundred things you are not testing. Choose a metric that a competent teammate could not argue moved for the wrong reason. That is the whole game.

3. The statistics you cannot skip

You do not need to be a statistician. You do need to explain four ideas without hedging.

P-value. The chance you would see a result at least this large if the treatment did nothing. A p-value of 0.03 means “if the feature had zero effect, we would still see a lift this big about three times in a hundred.” That is not “there is a three percent chance the feature does not work.” Never say that in a review.

Statistical significance. A pre-committed threshold, usually 0.05. It is a convention, not a physical law. You choose it in advance. You do not shop for a threshold that makes your result significant after the fact.

Statistical power. The probability the test detects a real effect if one is there. Standard target is 80 percent. If the test only has a 40 percent chance of detecting a real two percent lift, and the result comes back “not significant,” you learned nothing. The absence of evidence was baked in before you started.

Sample size. A function of the smallest effect you would care about (the minimum detectable effect, MDE), the baseline variance of your metric, and the power you want. Run the calculation before the test. If the required duration is longer than your patience, negotiate the MDE up or pick a less noisy metric. Do not shorten the test to fit the calendar.

4. Multiple variants, multiple metrics

The moment a test has more than one variant, or you look at more than one metric, the p-value stops meaning what you think it means. Run twenty independent tests where nothing is happening, and about one will come back significant at p=0.05 anyway. If you A/B/C/D test four variants of a lab landing page and pick the winner by “which one is significant,” you have quietly increased the odds of a false positive.

The fixes are boring and they work. Reduce the number of comparisons. Correct the alpha before you start (Bonferroni: divide alpha by the number of tests, so four comparisons means 0.0125, not 0.05). Split primary and secondary metrics: primary decides, secondaries teach, do not promote a secondary because it looked good.

If the team pushes back that this is too conservative, ask “if we make the wrong call on this test, what is the cost.” Small UI tweak with a cheap rollback: be aggressive. Change to how a large catalog is scored, ranked, or surfaced to millions of learners: be conservative. Match the rigor to the reversibility of the decision, and to how many people it touches.

5. The four mistakes that make tests unreliable

These are the ones I have watched hurt real launches. Learn to name them and refuse to sign off when they are present.

Peeking. You look at the p-value every day and stop the test as soon as it crosses 0.05. This inflates the false positive rate dramatically. The p-value is only valid at the sample size you committed to. Pre-commit to a sample size or a duration, and only read the result there. If you must monitor, use a sequential testing method designed for it.

Sample Ratio Mismatch (SRM). You expected a fifty-fifty split. You got fifty-two, forty-eight. This sounds close. It is not. If the assignment mechanism is broken, whatever caused the imbalance is very likely correlated with the outcome, and every downstream number is contaminated. Check SRM before you look at the result. If the split is off by more than random chance would predict, throw the test out and fix the pipeline. This bites hardest on platforms with complex assignment logic (bot filters, region gates, feature entitlements), because there are so many places the split can quietly break.

Novelty and primacy. Users click on the new thing because it is new, and the effect decays. Or existing users resist the change, and the treatment stabilizes later. Both bias the result. Run long enough for the effect to stabilize (usually more than two weeks on established products), and look at the trend inside the window, not just the final average.

Interference. The behavior of users in the treatment group affects users in the control group. On a shared platform this is everywhere: a discovery ranking change where treated users’ behavior reshapes the ranking that control users then see, a workflow where treated and control authors share a review queue, a capacity-constrained resource like lab environments where both groups draw from the same pool. Fix it with cluster-based randomization (whole tenants, regions, or catalog areas get one variant), switchback tests, or by treating the measured effect as a lower bound. Do not pretend interference does not exist because it is inconvenient.

Sidebar: what I now do differently

The list I would tape to a monitor if I could.

• Write the hypothesis, primary metric, and guardrails before the ticket goes to engineering. Not after.

• Run the sample size calculation. If the required duration is unrealistic, negotiate the MDE or the metric, not the duration.

• Check the split ratio on day one and day three. If SRM is present, stop, fix, rerun.

• Do not peek. Read the result once, at the pre-committed sample size or date.

• If there are more than two variants, correct the alpha before you start.

• Pair every primary metric with a guardrail. A launch that moves the primary while wrecking a guardrail is not a launch, it is a bill coming due next quarter.

• For long-running features, plan a holdout group that stays on control for at least a month post-launch. Novelty effects show themselves there.

• Ask “what would falsify this result” before signing off. If the answer is nothing, the test was not designed to decide anything.

The senior PM job on experimentation is not to run the math. Your data science partner runs the math. The job is to make sure the test is designed to answer the question you actually care about, and to refuse to draw a conclusion the test cannot support.

Most launch reviews I have been in do not fail on the analysis. They fail on the setup. The chart is not the decision. The chart is the argument. And the argument is only as good as the machine that produced it.

See you next Tuesday.

Luiz

If you run experiments on a platform, or you are the PM who has to defend the result in a launch review, I want to hear which of these five mistakes bit you hardest. Reply or drop it in the comments.

Views are my own and do not represent Microsoft.

The team lead read it, pushed back on two things, agreed with the framing, and we made a call by Thursday. If I had opened a blank doc that Monday morning, we would have been debating scope on Friday and I would still be alone in a tab called competitors-draft-final-v2.docx.

This is the workflow I actually use. It is not a demo. It is what I do when I need a competitive read fast, and it violates most of what I would have told a Senior PM two years ago.

Why the model is wrong in useful ways

The wrongness is predictable. That is the whole trick. The model is going to be wrong about the same categories of thing every time, in the same directions, and once you know the pattern you can edit around it faster than you could have started from scratch.

Here is what it gets wrong, reliably:

Recency. The model does not know what shipped last quarter. It writes about competitor features as if the last major release was eighteen months ago, because for its training that is true. Fine. I know what shipped last quarter. I fix that in the edit pass, and the model has done the tedious part of laying out the frame.

Pricing and packaging. Nearly always wrong, usually in the direction of “simpler than it is.” Real pricing has weird tier boundaries, seat minimums, and enterprise carve-outs that the model averages into something clean. I fix that too. But the model was right that pricing belongs in the comparison, and it drafted the row for me.

Differentiation claims. The model believes marketing copy. It says two products differentiate on things that are actually parity features both sides have shipped. This one is the highest-value catch, because it is exactly the trap a junior PM would fall into reading the same press releases. When I strike through the model’s differentiation line and write the real one, I have learned something about the market, not just corrected an error.

The recommendation. The model writes a milquetoast recommendation. “Focus on the mid-market segment where our differentiation is strongest.” No opinion, no risk, nothing anyone would push back on. That is a mirror of every meeting where nobody wants to be wrong on record. I replace it with the actual bet, which is usually narrower and more uncomfortable.

Four categories of wrong. All predictable. All faster to edit than to write from zero.

What it gets right, that a blank page never does

The frame. That is the whole gift. Deciding which dimensions to compare on is the hard part of a competitive analysis. Should we compare on price, or on time-to-value, or on integration depth, or on brand strength, or on ecosystem, or on all five, and if all five, which two matter for the decision this is supposed to unblock. That decision is what makes the artifact useful or useless.

The model picks a reasonable frame from the average of every competitive analysis it has ever seen. That is roughly as good as I would pick on a slow morning, and I get it in ninety seconds instead of an hour. When the frame is right, I keep it. When it is not, editing the frame is still faster than picking one from scratch, because I now have a concrete thing to react to.

Reacting to a wrong frame is faster than choosing a right one from nothing. That is the whole engine.

The workflow, end to end

I write three prompts and run them one after the other. Total time before I start editing is about four minutes. The prompts are in the sidebar.

First prompt writes the analysis. I do not touch anything yet. I read it once, top to bottom, without a pen, and I ask myself whether the frame is defensible. If yes, keep. If no, throw the whole thing out and rewrite the first prompt with a tighter frame. This is the only real decision point.

Second prompt asks the model to argue against its own analysis. This is where the differentiation errors surface. The model, prompted to be adversarial, will name the two things it just claimed as differentiation and point out they are parity. This costs me nothing and saves the meeting.

Third prompt asks for the strongest counter-recommendation, in one paragraph, from the perspective of a competitor’s PM reading our analysis. That paragraph is usually where I find the real risk we were about to walk into.

Then I edit. Twenty minutes, maybe thirty. Recency fixes, pricing fixes, differentiation corrections, and the recommendation gets replaced with the one I would have written on hour four if I had started from a blank page. I ship the doc. It has a note at the top that says “drafted with a model, edited by Luiz, errors mine.” That note is not decoration. It is the reason I sleep at night.

Sidebar: the three prompts

Generic versions. Swap in the real product, market, and vendors before you run.

Prompt 1, the draft. “Write a one-page competitive analysis of {product} against {competitors}. Compare on {two or three dimensions I care about most}. End with a one-paragraph recommendation for the {audience, e.g. VP of Product} on where to invest next quarter. Assume the reader has ten minutes.”

Prompt 2, the self-attack. “You just wrote this analysis. Now argue against it. Name the three claims that are weakest, the assumption most likely to be wrong, and the differentiation lines that are actually parity features both sides have shipped. Be specific.”

Prompt 3, the counter-move. “Write one paragraph from the perspective of a Principal PM at {main competitor} who has just read our analysis. What is the counter-move they would take to weaken our recommendation? Be aggressive.”

Why this is not lazy

The critique of this workflow, the one I used to make, is that you are outsourcing the thinking. You are not. You are outsourcing the drafting and keeping the thinking. Deciding whether the frame is defensible, catching the differentiation errors, replacing the milquetoast recommendation with a real bet, and owning the doc in the room, that is the entire job. The model does the typing. You do the calling.

A PM who ships a model draft unedited is lazy. A PM who spends four hours writing the same draft the model would have produced in ninety seconds, and then ships it with the same errors because they never had time to run the self-attack pass, is also lazy. They just look busier while doing it.

The bet I am making, one issue at a time here, is that the second kind of laziness is more common and less visible than the first, and it is the one costing careers right now.

What to try this week

Pick a competitive analysis you owe someone and have not started. Run the three prompts. Do not edit the first output. Read it once, decide if the frame holds. If yes, run the second and third prompts, edit for twenty minutes, and ship it with a note at the top saying it was model-drafted and human-edited. Watch what the reviewer pushes back on. That is your signal for what to fix in the prompt next time.

If the frame did not hold on the first pass, you learned something too. Rewriting Prompt 1 with a tighter frame is the highest-leverage move a PM can practice right now, because it is the same skill as convening a good meeting or writing a good problem definition. It is the skill of picking the right question.

See you next Tuesday.

Luiz

If you run this and it lands, or it flops in a way you did not expect, I want to hear about it. Reply or drop it in the comments. The best answers usually show up there.

Views are my own and do not represent Microsoft.

Most Senior PMs prepare for the wrong thing. They ask for more surface area. They volunteer for the cross-team initiative. They rewrite their brag doc to sound bigger. Then they get told they are close, and six months later the feedback is some version of “we need you to be more strategic,” a phrase that means nothing and everything, and they stall.

Here is what the jump actually is.

The scope story is a lagging indicator

Yes, Principal PMs usually own bigger surface area. That is true and uninteresting. Scope gets handed to you after you have proven you can operate at the next level, not before. If you are waiting for bigger scope so you can prove you deserve promotion, you are running the loop backwards.

Promoters are looking for a different mode of operating on whatever scope you already have. Same product area, same team, same quarter. Different behavior in the seams. What they watch for is: what do you do when the problem is not defined yet.

The four things that actually change

1. You are handed a mess, not a brief. At Senior PM, your intake looks like a request. A partner needs a thing. A GM wants a decision. A segment is missing a feature. The problem has shape. Your job is to sharpen it and ship. At Principal, your intake is a shrug and a hallway sentence. “Something is off with retention in the enterprise tier, can you look at it.” That is the whole assignment. Six weeks later somebody expects a defensible problem statement, a shortlist of what to do, a recommendation, and evidence you talked to the ten people whose buy-in you need without being asked to.

2. Your first artifact is a problem definition, not a spec. Senior PMs write specs. Principal PMs write the doc that comes before the spec. The one-pager that says: here is what we think is happening, here is what we are choosing not to work on, here is the one bet, here is what would have to be true for it to be wrong. That is the artifact that gets you promoted, and almost nobody practices it.

3. Your stakeholder work becomes convening, not aligning. Alignment is what you do when the direction exists and you need people rowing the same way. Convening is what you do when the direction does not exist yet, and you have to get the right five people in a room, ask a good question, and let the direction come out of the conversation. Alignment is project management dressed up. Convening is picking the right question and sitting with the silence after you ask it.

4. Your calibration for “done” changes. At Senior PM, “done” is the feature is live, the metric moved, the launch review closed clean. At Principal, “done” is often that a decision got made and stuck. Sometimes the decision is “we are not going to work on this.” Sometimes there is no shipped artifact at all. That took me the longest to internalize. I was counting outputs when I should have been counting decisions I had unblocked.

Why “be more strategic” is such useless feedback

“Strategic” is what people say when they can feel the gap but cannot name it. What they actually mean is one of three things. You keep executing well-formed problems cleanly, when they wanted you spending that time on a badly-formed one nobody else was picking up. Your recommendations arrive with tradeoffs already collapsed, so leadership never gets to make a choice, they just approve one. Or you are optimizing inside a frame somebody else drew, when the promotion depends on you drawing the frame.

None of those are about doing more. All are about operating earlier in the funnel, when the shape of the work is still being decided.

Sidebar: three questions I ask before I accept an assignment

I ask myself these silently when someone hands me work. If I cannot answer them, I ask the person who gave it to me. That conversation, more than any other habit change, is what moved me.

1. “What is the actual decision this is meant to unblock?” Not the deliverable. The decision. If nobody can name it, the work is not ready to start, and my first job is to help name it.

2. “Who has to buy this for it to be real?” Not who will review it. Who has to be quietly on board before it lands, or it dies on contact with the room. I want their names before I write anything.

3. “What would have to be true for us to walk away entirely?” If I cannot answer that, I do not understand the problem yet.

What to practice before you have the title

You do not need the promo to start operating this way. Doing it before the title is often the fastest way to get it. Three things worth trying on the scope you already own.

Pick one messy area everyone complains about and nobody owns. Write the two-page problem definition for it. Not a spec. A problem definition. Send it to two people whose judgment you trust and ask them where you are wrong. The document matters less than the fact that you produced one nobody asked for.

Next time a request arrives well-shaped, resist the urge to accept it as-is. Ask the requester what decision it is meant to unblock, and what they would do if you told them the request as written would not work. Half the time the real problem is one layer up, and you just found it.

Kill one project on your own plate. Write the one-paragraph rationale, share it, and take the small hit. Principal PMs kill things. Senior PMs finish them. That muscle is one of the hardest to build, because the performance system around you is calibrated to reward completion.

The uncomfortable part

The reason this is not a scope conversation is that it is a tolerance conversation. How much ambiguity can you sit inside without flinching, without pattern-matching too early, without asking your manager to just tell you what they want. The people who make the jump are not smarter. They are comfortable being uncertain in public for longer.

That is trainable. Nobody trains for it because it does not feel like training. It feels like being bad at your job for a few weeks while the shape of the problem comes into focus.

See you next Tuesday.

Luiz

If you are prepping for this jump right now, or made it recently and the feedback loop was different from what you expected, I want to hear about it. Reply or drop it in the comments. The best answers usually show up there.

Views are my own and do not represent Microsoft.

For years, the middle of that week was the worst part of the job. Not the calls. The synthesis. Twenty pages of notes, four transcripts, my own memory decaying by the hour, and a blank doc titled “what did we hear this week.”

That middle part is now mostly a model. But not entirely, and the “not entirely” is the whole point of this piece.

The workflow, end to end

Here is what I actually do. No theory. The order matters.

1. Record everything, one place. Every call gets the Teams recording plus the transcript export. Partner calls, instructor calls, learner panels, internal stakeholder calls with the content-developer team. One folder per week, named by the ISO date. If it is not recorded, for me it did not happen, because I will not trust my memory of a 55 minute conversation on Thursday when I sit down to write on Friday.

2. Clean the transcript, once. Before any model touches it, I open the transcript and do two things by hand. I fix the speaker labels (Teams still confuses two people with similar names), and I delete the first 90 seconds of small talk. Both take about a minute. Both matter, because a model reading a transcript that says “Speaker 2” 40 times will confuse the partner and the learner, and a model reading two minutes of weather chat will pick up “delay” and “frustrated” from a sentence about traffic and quote it back at me as a customer signal.

3. Run the synthesis prompt, per call. Not per week. Per call. Batching four calls into one prompt sounds efficient and produces mush. One call at a time, same prompt, structured output. This is the workhorse:

You are helping a Senior PM synthesize a single stakeholder call.
The PM owns labs and interactivity experiences strategy for Microsoft Global Skilling. The person on the call is a [role: content
developer / partner / learner / instructor]. Their relationship to
the product is [one sentence].

Read the transcript below and return exactly four sections.

1. Verbatim quotes worth keeping (max 5). Speaker attribution and
   a rough timestamp if visible. No paraphrasing. If nothing meets
   the bar, return fewer than 5. Do not pad.

2. Decisions or asks the person made of me, explicit or implied.
   For each, mark E (explicit, they said it) or I (implied, I am
   inferring). If implied, quote the line you inferred it from.

3. Contradictions. Places where this person said something that
   conflicts with something else they said in the same call, or
   with a claim I flagged in the input notes.

4. What I did not ask that I should have. One or two questions,
   maximum. Base them on threads the person opened and I did not pull.

Rules. No summary paragraph. No executive summary. No “key
takeaways.” No emojis. If a section is empty, write “None” and stop.

Transcript:
[paste]

My input notes (optional, may be empty):
[paste or leave blank]

Four sections, structured, no summary. The lack of a summary is deliberate. A summary is where the model launders vagueness back into your week. I want the raw material, not a briefing.

4. Cross-call pass, at the end. Once every call for the week has its four-section output, I paste all of them into one document and run a second, much smaller prompt.

Below are per-call synthesis outputs from [N] calls this week.
Roles: [list].

Return only two things.

A. Signals repeated by two or more people, in different calls,
   in different words. For each, cite which calls. Do not list
   signals that only one person raised.

B. Signals raised by exactly one person that I should still take
   seriously, and one sentence on why. Cap at three.

Do not summarize. Do not recommend actions.

That is the last thing a model does for me. What comes out is a short list. Usually five to eight lines total.

The part I still do by hand

The five minutes at the end.

I take the short list from step 4, and I write the one-page synthesis for my PM lead by hand. Not because the model cannot write it. It can. It writes it beautifully. That is the problem.

The one-page synthesis is where I decide what to argue for. Which two signals move a lab priority for next quarter. Which one signal, even if only one person raised it, is the one I am going to spend political capital on. Which contradiction I am going to name in front of the senior director, knowing it will make somebody defensive. That is the work. Not the writing. The load-bearing choices inside the writing.

If I let a model do it, three things happen, and I have tested all three. It flattens the strongest signal into the middle of a balanced list. It softens the contradiction into “an area to explore.” And it removes my name from the decision, because the sentences read like a briefing from nobody. My PM lead is very good at his job. He reads that draft and asks me, politely, what I think. And I have to redo it anyway, slower, because now I have to argue with a version of my own opinion that a model wrote.

So I stopped. The model does the extraction, the structuring, the pattern matching across calls. I do the sentence that says “we should prioritize the lab refresh over the content-developer onboarding, and here is why.” That sentence has a name attached to it. Mine.

The rule I use: if the sentence would be different depending on who wrote it, a human writes it. If the sentence would be the same regardless of author (a quote, a count, a structural note), a model writes it.

Sidebar: three prompt patterns I stopped using

1. “Summarize this call in three bullet points.” The compression is where the signal dies. Three bullets always come back generic, always in the same shape, always missing the one thing that actually moved. I ask for verbatim quotes instead, and I do the compression myself.

2. “What are the key takeaways?” Every model has a house style for takeaways, and it is not mine. “Key takeaways” is also the phrase most likely to trigger the model to invent a fifth bullet because four looks weak. I ask for signals with citations, not takeaways.

3. “Act as a product manager and...” Role prompts sound clever and produce worse output. The model does not become a PM. It becomes a generic idea of a PM, which is exactly the voice you do not want in your synthesis. I tell it what the reader is and what to return, not who to pretend to be.

Why this order

One call at a time before any cross-call pass, because you cannot detect a pattern from calls the model has already blurred together. Per-call output first, then cross-call. The extra 10 minutes at the front saves the whole exercise from producing the kind of synthesis where every week sounds the same.

No summary sections in any prompt, because a summary is a place where the model quietly interpolates. I want the four sections raw, and I want to be the one who decides what they add up to.

Verbatim quotes with attribution, always. When I take a claim into a room on Monday, I want to be able to point at the sentence and the speaker. “The lab partner said this at minute 34” is a very different argument from “customers are frustrated.”

The whole workflow takes me about 40 minutes on a four-call week, most of which is the five minutes at the end, done four times, on the sentences that matter.

What to steal

If you take one thing from this, take the per-call versus cross-call separation. Almost every synthesis prompt I see PMs share online batches everything into one call. It looks efficient. It produces a briefing that reads well and says nothing.

The rest is variations. Different tool, different transcript source, different stakeholder types. The structure holds.

The five minutes at the end holds too. That part is not a workflow problem. It is a job description.

See you next Tuesday.

Luiz

What does your team’s customer-call synthesis look like right now, and where do you still refuse to hand the work to a model? I read every reply, and the best answers usually show up in the comments.

Views are my own and do not represent Microsoft.

Not “what is your mitigation plan.” Not “what would you cut.” The simpler question. What happens. To whom. When.

He had a 14-page spec. It was well written. It had a problem statement, a user journey, a success metric, three acceptance criteria, and a risks section. On paper, it was a good spec. In the room, it fell apart in one question, because the spec described a feature and did not describe a commitment.

A spec is not a document. A spec is a set of statements someone will be held to. If nobody can be held to any of the sentences in your spec, you did not write a spec. You wrote a wishlist with a table of contents.

The three sentences that actually matter

Take any spec you have ever written. Underline the sentences that meet all three of these tests.

One. The sentence names a thing that will either be true or not true by a specific date. Not “we will improve,” not “customers will feel.” True or not true. Date attached.

Two. There is a way to check whether the sentence turned out to be true, without asking the author. A number, a log line, a test result, a customer message. Something that survives your absence from the room.

Three. If the sentence turns out to be wrong, a named person carries it. Not “the team.” Not “product.” A person, who can point at the sentence, and say “I said that, I was wrong, here is what I got wrong.”

Sentences that pass all three are the spec. Sentences that pass two are context. Sentences that pass fewer than two are decoration. The mistake senior PMs make is treating the whole document as though it were the spec, when in fact the spec is the four or five sentences inside it that pass the test.

Why this got sharper this year

Ambiguity in a spec used to be free. If you wrote “we will improve the onboarding experience,” the sentence just sat there, harmless, next to the sentences that did real work. A reviewer might frown, ask for a metric, or let it slide.

Ambiguity is no longer free. When a model is drafting the spec, or the plan under the spec, or the code under the plan, every ambiguous sentence gets filled in by something that does not know what you meant. The model will pick a metric. It will pick a threshold. It will pick a definition of “improved.” It will pick confidently. And the artifact will look coherent, because models are very good at making incoherent inputs look coherent on the surface.

What used to be a soft sentence that a smart reviewer would catch is now a hard commitment that a machine made on your behalf. You just did not sign it. You just did not read the part where you signed it.

The cost of not writing a real spec used to be a slow launch. The cost now is a shipped product built on assumptions you never made, that you cannot defend when they show up in production.

The test I run before I approve anything

Before I sign off on a spec, mine or someone else’s, I do one thing. I read the doc top to bottom with a pen, and next to each substantive sentence I write one of three letters.

C for commitment. I would defend this in front of a room in six months.

A for assumption. I believe this today, and it might not hold. It needs a check, a date, and a name.

D for decoration. It reads well, it says nothing.

Any spec I approve has to have more C than A, and zero D. Not fewer D. Zero. If a sentence is decoration, it either becomes a commitment, becomes an assumption with a check, or it comes out.

The test takes about 20 minutes for a 10-page spec. It is the most useful 20 minutes I spend in a week.

What to do with this before Friday

Pull one spec you own. It can be a draft, a shipped one, or one you inherited. Read it with the three letters in your hand.

Count the C sentences. If you have fewer than five, you do not have a spec. You have a document. Rewrite the top five candidates into commitments, with dates and checks and a name.

Then send the spec to the one person on your team who is most likely to disagree with the load-bearing sentence, and ask them to try to disprove it. If they cannot, the sentence is stronger. If they can, you just saved yourself the launch review where somebody else does it for you, with more people in the room.

A spec is not what you wrote. A spec is what you are willing to be wrong about, in public, with your name on it.

Ship one this week.

See you next Tuesday.

Luiz

Views are my own and do not represent Microsoft.

The one-pager. The PRD. The market analysis. The competitive teardown. The launch brief. The post-mortem. The roadmap. The status update. The exec summary. The Teams message that took 40 minutes to write because it had to land right.

For 20 years, the people who could produce that stack on demand, and produce it well, were the people who got promoted. The artifact was the job. If the spec was sharp, the launch tended to be sharp. If the post-mortem was honest, the next launch tended to be less broken. The artifact was both the work and the receipt that the work happened.

That model is collapsing. Most of these documents are about to get cheap. A few are not.

Here is my read on which is which, and why the difference matters more than the trend.

What is actually happening

The cheap version of the story is that AI “writes the docs for you.” The more accurate version is that AI removes the cost of a respectable first draft. The price of a passable spec, a passable competitive analysis, a passable launch brief, has dropped to near zero for anyone who can write a coherent prompt.

That sounds like a productivity story. It is not. It is a redistribution story. The work that used to live inside the artifact (the thinking that happened while the PM was writing the spec) now has to happen somewhere else, or it does not happen at all. And the place it has to happen is the PM’s head, before and after the model runs.

So the right question is not “which artifacts survive.” It is “where does the thinking move when the artifact gets cheap.”

The artifacts that collapse

These are the ones a model now produces faster than I can, at a quality level that is good enough to ship internally with a half hour of editing.

The competitive teardown. A model reads ten competitor pages, three analyst reports, two community threads, and produces a respectable two-pager. The PM job becomes choosing what is wrong in the draft and what is missing, not generating the draft. The artifact stays, the labor inside it changes shape.

The status update. The weekly “here is where we are” doc, the all-hands slide, the partner update, the monthly stakeholder note. These are aggregation work. Models aggregate. The PM who used to spend Friday afternoon assembling status now spends 20 minutes editing what the model assembled. The artifact survives. The Friday afternoon does not.

The market analysis. The 30-page deck that took two weeks and an analyst is now a 90-minute exercise. The deeper version (the one that includes a real point of view about where the market is going) is harder, and the model does not do it well. So the deck collapses and the conviction is what is left, written shorter and signed by a named person who will own being wrong about it.

What these three have in common is that they were always synthesis work. The PM was the human glue between sources. The glue is now mostly machine. The work that remains is editorial: what is true, what is missing, what does not pass the smell test, what is worth defending.

The artifacts that stay human

These are the ones I have tried to delegate to a model and watched fail in ways that mattered.

The spec, but only the part you would defend in court. Models write very good first drafts of specs. They write a usable user flow, a credible set of edge cases, a reasonable success metric. What they do not write is the line that says “we are choosing this trade-off and rejecting this other one, and here is why we will defend it in three months when it is unpopular.” That line is where the spec stops being a document and becomes a commitment. A model does not have skin. It does not get held to the decision. The part of the spec that gets shipped to a real customer and stays your call is exactly the part that stays human.

You can let the model draft the rest. You cannot let the model draft that line. If you do, you will not be able to defend it, because you will not actually know why you chose it.

The post-mortem about the launch that flopped. Models write fine post-mortems for launches that worked. The retrospective on a success is a recitation, and recitations are easy. The post-mortem about the launch that broke is hard because the honest version requires saying out loud what you did wrong, what you saw and did not say, who you avoided pushing back on, what assumption you were holding that turned out to be a fantasy. A model cannot do that work. It does not have the context, and it does not have the standing. The post-mortem on the flop is one of the most valuable documents a PM produces in a year, and it is exactly the one that does not compress.

The pattern: artifacts that require a named person to take a position on something they could be wrong about do not collapse. They are the ones that get more valuable as everything else gets cheaper, because a clear position with a name on it becomes the scarce thing.

The one I am still not sure about

The roadmap.

I have watched models produce roadmaps that are 80 percent right and 20 percent wishful in a way that is hard to detect. A roadmap is a sequence of bets, and a model that does not face consequences for the bets cannot tell you which bet is real and which one is the comfortable one. So the artifact looks plausible and is quietly wrong.

On the other hand, the roadmap is the artifact that most senior PMs spend the most time rewriting, because it changes every two weeks anyway. So the cheap-first-draft model is genuinely useful here, even if you cannot trust the draft.

I think the roadmap is going to split into two artifacts. The plausible-sequence document, which a model produces and a PM edits in 30 minutes. And the “here is the bet we are making and what we are willing to be wrong about” document, which is one page, signed by a person, and updated when the bet changes. The first one is the schedule. The second one is the spine.

If you are still writing both into one document, the cheap part is going to drag the expensive part down with it.

What this means for the week

If you are a senior PM right now, the play is not “use AI for everything you write.” The play is to figure out, for each artifact on your stack, which of these three buckets it lives in. Then ship the cheap ones cheaply, and protect the expensive ones from being mistaken for cheap.

The mistake I keep seeing senior PMs make is using the same workflow on both. They either AI-draft the spec and ship it without sharpening the load-bearing line, which leaves them exposed in three months. Or they hand-write the status update like it is 2022, which is fine for them and disrespectful of the time of everyone who reads it.

The artifact stack is not collapsing uniformly. It is collapsing where it was always thin, and getting heavier where it was always load-bearing.

The PM job in 2027 is going to be the same job it was in 2007, with most of the in-between work taken away. You will write less. You will defend more.

See you next Tuesday.

Luiz

Views are my own and do not represent Microsoft.

That is the day job. It is good work and I am staying.

This newsletter is something else.

What changed

The work is changing under all of us. AI did not lower the bar for product management. It moved the bar. The old question was “can you produce the artifact.” The new question is “can you tell me which parts you do not trust.”

I see this from a vantage that is a little strange. I do not just ship product. I help define what “competent” looks like for the people who will be hired into product, security, and platform roles next year. When the curriculum changes, the bar changes. When the bar changes, the work changes. The feedback loop between what I do and what the industry asks of PMs is short and direct.

So I have a point of view forming, every week, about what stays human in PM work and what does not. About which workflows survive the model, which ones get cheaper, and which ones quietly disappear.

I have been keeping those notes private for a while. I am going to start writing them down for real.

Who this is for

Senior product managers, roughly 8 to 15 years in tech, sitting inside big tech or a serious scaleup. You run real surface area. You ship to real customers. You have opinions about Azure DevOps or GitHub. You feel the AI shift is rewriting what “good PM” means and you are tired of the firehose.

If you are looking for a primer on what a PRD is, this is not for you. If you are looking for the next “10 ways to leverage AI in product,” also not for you. There is a lot of that already and most of it is bad.

If you are a senior PM trying to figure out which parts of the job stay yours and which parts get reshaped, this is the conversation.

What you will get

• One essay every Tuesday at 6:30 AM Central Time. Same day, same time, no skip weeks. Cadence is the whole game.

• PM craft. Specs, prioritization, stakeholder management, IC leadership at the senior level, post-mortems, launch reviews. The artifacts and the meetings and the decisions.

• AI for PMs. Tooling, workflows, prompt patterns specifically for PM work. Not “use ChatGPT to brainstorm.” Things like: the prompt I run before every spec review, the diff between a draft you trust and a draft you cannot, what happens to discovery when the model already read the customer interviews.

• Careers. Level transitions at L62 to L65, building authority while staying employed, the IC versus manager fork, comp patterns, when to leave.

• Industry takes when they earn the post. When a launch or a re-org or a model release actually moves something, you will get my read within 48 hours. No takes on takes.

What you will not get

• Anything Microsoft-internal. No roadmaps, no headcount, no internal slides, no comp specifics from the day job. Views here are mine and not Microsoft’s.

• Listicles. If a post is “7 things you must know about,” I did not write it.

• Fake humility, fake excitement, or AI-marketing voice. No “unlock,” no “supercharge,” no “let us unpack.” If a sentence sounds like it could open a SaaS landing page, it does not ship.

• Hot takes on politics, religion, or culture wars. There are other places for those and other writers who do it better.

Why a newsletter and not just LinkedIn

LinkedIn is rented. The algorithm decides what gets seen. Your “followers” are an audience the platform owns. A newsletter is mine. You subscribed, you decided, and your inbox is one of the last places on the internet where attention is still consensual.

LinkedIn still gets posts from me. Different cadence, same body of work. If you are here, you have the canonical version.

Why now

Two reasons.

One. The AI shift in product is moving fast enough that one year of silent observation is a year of useful notes I should have written down. The notes are more useful in public than in a private OneNote vault, both to me and to anyone reading.

Two. I have been hiding behind the artifacts of my job for 22 years. The certification cuts. The lab specs. The content. They were always “the team’s” output, never mine in any named way. I am at a point in my career where the thinking is mine, and the thinking is worth signing.

That is what this newsletter is. The work, with my name on it.

Practical things

• Cadence: Tuesday 6:30 AM Central Time, every week.

• Format: One essay, roughly 800 to 1500 words. Sometimes shorter. Rarely longer.

• Cost: Free. If a paid tier shows up later, free subscribers keep getting the weekly essay. Paid would be additive, never gated.

• Replying: Hit reply on any issue. It goes to hi@macedonotes.com and I read every one.

One thing before you go

If you read this and thought of another senior PM who would actually use it, forward this issue to them. That is how this thing grows, one trusted recommendation at a time. There is no growth hack here. There is no referral program. There is just the work, and people you trust telling other people you trust.

Thanks for being here on issue one.

See you next Tuesday.

Luiz

Views are my own and do not represent Microsoft.