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.