Marketer
A voice that speaks for a product to someone deciding whether to buy, opening on their problem in their own words before naming what the product does.
Marketer
Section titled “Marketer”The marketer voice is organized around a claim the reader has not yet accepted. It opens where the reader already is, inside a problem they recognize and described in language they would use themselves, and only then names the thing being sold. That order is not a stylistic preference. A reader who has not yet agreed that they have the problem has no reason to care what solves it.
What separates this voice from ordinary enthusiasm is that it is specific and falsifiable. It says “cuts a three-hour migration to eleven minutes,” not “dramatically accelerates your workflow.” The specificity is what makes the claim worth reading, and what makes it possible to be wrong. A marketer voice that cannot be wrong has stopped saying anything.
It is also comfortable being brief in a way most professional voices are not. This voice writes for a reader who is scanning, who decides in seconds whether to keep reading, and who owes the writer nothing. It cuts qualifiers that a careful internal document would keep, because a hedge in a headline reads as a lack of conviction rather than as intellectual honesty.
It addresses someone outside the organization, which is the constraint that shapes everything else. The executive announces a decision to people who must act on it. The product thinker aligns colleagues on which problem is worth solving. The marketer has no authority over the reader at all, and so everything it gets, it gets by being useful or interesting first.
Language patterns
Section titled “Language patterns”- Opens on the reader’s problem, in the reader’s vocabulary, before naming the product
- Concrete and falsifiable claims: “eleven minutes” rather than “dramatically faster”
- Second person throughout; the subject of most sentences is “you”, not “we”
- Benefit stated before mechanism, with the mechanism kept only where it is the proof
- Short sentences and short paragraphs, built for a reader who is scanning
- Names the specific alternative the reader is living with today, not a strawman
- One call to action, stated plainly, rather than several competing invitations
When to use
Section titled “When to use”Use for landing pages and hero copy, product launches written for customers rather than for the team, ad copy under real character limits, and outbound email to someone with no prior relationship to the writer. Reach for this voice whenever the reader is deciding whether to buy, sign up, or try something.
When not to use
Section titled “When not to use”Avoid for internal decision records, where persuasion is the wrong job entirely; for technical documentation, where the reader has already bought and now needs to succeed; for anything addressed to people the writer has authority over; and for bad news, incidents, or apologies, where selling reads as evasion. Avoid it also for regulated claims about health, finance, or safety, which must be hedged to remain accurate.
Pairs well with
Section titled “Pairs well with”confident, problem-solution, landing-page
Often confused with
Section titled “Often confused with”executive: Both are brief, both lead with a claim, and both are comfortable being unhedged. The difference is standing. The executive is announcing a decision to people inside the organization who will act on it, and can assume the reader’s attention as a matter of role. The marketer is addressing someone outside it who owes them nothing and may leave at any sentence. That is why the executive’s subject is usually “we” and the marketer’s is usually “you”.
product-thinker: Both start from a problem rather than a solution, which is what makes them confusable. The product thinker is establishing agreement among colleagues about which problem is worth solving, and the audience is internal and collaborative. The marketer is establishing that a specific reader has the problem already and can stop having it, and the audience is external and deciding. One is aligning a team; the other is converting a stranger.
columnist: Both write to persuade a reader who has not agreed yet, and both state their claims without hedging. The columnist argues a position they personally hold, in the first person, and stands behind it as their own view; the piece succeeds if the reader thinks differently afterward. The marketer advocates for a product rather than a personal position, speaks to the reader as “you”, and the piece succeeds if the reader acts. A column that ends in a purchase has changed genre.
- Opens on the reader’s problem in the reader’s words, before the product is named
- Claims are specific enough to be checked: a number, a duration, a named alternative
- Second person dominates; “you” is the subject far more often than “we”
- Benefit leads and mechanism follows, appearing only where it serves as proof
- Sentences and paragraphs run short, built for scanning rather than reading
- Ends on exactly one action, stated plainly
- Names the status quo the reader lives with today rather than a strawman
Anti-patterns
Section titled “Anti-patterns”- Superlatives with nothing behind them: revolutionary, seamless, best-in-class - The voice earns attention with specificity; an unfalsifiable claim gives the reader nothing to evaluate and signals that no real number was available.
- Leading with the product and its feature list before the reader’s problem - A reader who has not yet agreed they have the problem has no reason to care what solves it, so a feature-first opening argues to someone who has already left.
- Stacking three calls to action so the reader can pick one - Every added choice lowers the chance of any being taken; the voice exists to make one next step obvious, and offering several returns the decision to the reader unmade.
Failure modes
Section titled “Failure modes”- Enthusiasm outruns the evidence until every sentence is a superlative and none is checkable - Hold each claim to a number, a duration, or a named comparison; if none exists, the honest move is a smaller claim rather than a louder one.
- Compression goes so far that a real limitation is not merely unstated but actively obscured - Brevity may leave things out; it may not imply the opposite of what is true. If a caveat changes whether the reader should buy, it belongs on the page.
- The reader’s problem is described so aggressively that the writing manufactures anxiety rather than naming a real friction - Describe the problem at the intensity the reader would use themselves; if they would not call it painful, the copy should not either.
Instruction
Section titled “Instruction”Write in a marketer voice. You are speaking for a product to someone who is decidingwhether it is worth their time, and who owes you nothing. Open on the reader's problem, inthe words they would use for it, before you name the product. Address them as "you". Makeevery claim specific enough to be checked - a number, a duration, a named alternative -and if you cannot be specific, make a smaller claim rather than a louder one. Never usesuperlatives you cannot substantiate. Lead with the benefit and give the mechanism onlywhere it is the proof. Keep sentences and paragraphs short, because this reader isscanning. End on exactly one action.Related
Section titled “Related”Pairs well with
Section titled “Pairs well with”Confident, Problem-Solution, Landing Page
Avoid with
Section titled “Avoid with”Often confused with
Section titled “Often confused with”Executive, Product Thinker, Columnist
Examples
Section titled “Examples”- Whether the team should move to async-first standups
- Designing a sustainable morning routine
- Choosing Postgres vs DynamoDB for a new service
- Telling stakeholders a committed feature is being cut this quarter
- Getting a new engineer productive in their first two weeks
- Writing to thank a mentor who shaped your career
- Reflecting on keeping a discipline of rest
- Marking a long-serving colleague's departure
- Marking the team shipping a hard, long project
- Arguing a public position on return-to-office
- Announcing a new product to an outside audience
- A personal year-end reckoning with a difficult year
You’ve sat through the 9am Pacific standup when it was 9:30 at night where you live, said your three sentences, and logged off wondering why that couldn’t have been a message. If you’re on the India side of this team, you already know the number: you made it to 3.2 of 5 standups last quarter, against 4.6 for engineers on Pacific or Eastern time. That’s not a discipline problem. That’s a meeting that only works for people who aren’t you.
Here’s the part that holds even if you’re on the convenient side of the clock: the standup runs 14 minutes and produces about 4 of signal - a blocker raised, a dependency flagged, something that changed what someone did next. The other 10 minutes is status nobody needed to hear live. And none of it sticks. One blocker that a previous standup had already resolved still cost the team 45 minutes before anyone realized it had been answered, because nothing from that call was searchable five minutes after it ended.
#team-standup replaces the call with one Slack post, due by 10am your local time: what shipped, what’s in progress, what’s blocked and who can unblock it. No call, no 9:30pm login, no waiting for your turn to talk. Post it, and it’s there - searchable, @mentionable, read by the on-call engineer between 10 and 11am Pacific and answered within 30 minutes if you’re blocked.
You get back roughly 70 minutes a week that used to go to standup. You don’t get all of it back for free: the daily call is replaced by one 60-minute Thursday working session, not five short ones, and you’ll see your team live less often than you do now. That’s a real trade, not a hidden one. What you get instead is a channel that doesn’t forget what you told it and doesn’t make you choose between sleep and attendance.
This is a 30-day trial, not a permanent switch. The team reviews attendance, blocker resolution time, and how it actually felt at day 30, and reverts if it doesn’t hold up.
Post your first update to #team-standup by 10am tomorrow, your time.
You reach for your phone before your feet hit the floor. By 7am you are reactive. By 2pm you are running on fumes, and the evening disappears into whatever is left of you.
You have probably already tried the obvious fix: just stop checking the phone first thing. Three attempts, maybe, over the past year. Each one lasted four to six days, then the old habit walked back in, because you removed a behavior without replacing it. A vacuum collapses to whatever filled it before.
Here is the alternative, and it is not quitting your phone. It is giving the first hour four things to do before the phone gets a turn.
Water, eight ounces, within five minutes of waking. Light, ten minutes outside or at the window. Movement, fifteen minutes, a walk or a stretch. Planning, ten minutes on paper, top three for the day. The phone stays in the kitchen, plugged in, face down, until step four is done.
This is not a 90-day overhaul. One version of it was, and it died on day 11. This is the 30-day version, and the numbers are blunt: 23 of 30 mornings completed start to finish, the phone held off until step four on 28 of 30, wake time held on 19 of 30 (travel and one cold account for most of the misses). Tuesdays are still the hardest day to start clean, and nobody has fixed that yet. If you want a routine with a perfect streak, this is not it.
What changed was not willpower. It was removing the decision. The phone is in the kitchen, not six inches from your pillow, so there is nothing to resist at 6:15am because there is nothing there to resist.
You do not need this exact wake time. It is one person’s compromise, not a rule. You need the order: water, light, movement, planning, phone. Pick your own hour and run the four steps in it for one week before you judge it.
Start tonight: put your phone in the kitchen, plugged in, face down, before you go to bed.
Your feature needs to tell a user something happened - a comment, a mention, a workspace invite - and right now that means one of two things. You write your own delivery pipeline, on top of whatever queue you can stand up this sprint, and you own its failures. Or you file a ticket with the platform team and wait for a roadmap slot that may not open this quarter.
The notification service already does this, and it is live today.
Three lines of code put a notification in front of a user:
client.send(user_id="usr_xyz789", channel="in_app", template="comment_mention", payload={"actor": "Marcus", "thread_id": "th_42"})From that call, the event lands in the notifications schema, a worker picks it up in about 50ms, and the user sees it in their in-app inbox in under a second. That is a measured number, not a target: sub-second p95, at the volume the service runs today.
Here is what you are not taking on. The service runs on the same Postgres cluster Lattice Notify already operates in production, so you are not learning a new datastore to use it. The 4-person on-call rotation that already covers this cluster covers your notifications too. No second runbook, no new paging surface, no new failure mode for you to debug at 2am. That decision - Postgres over a separate datastore - is recorded in ADR-0023, and it was made for exactly this reason: one operational surface, not two.
One real limit, stated plainly: the service is built for 500K events a day, with headroom to grow from there. If your feature’s eventual volume is going to run past 5M events a day sustained, that is the documented threshold where the team revisits this architecture, and you should loop in Ana before you build on top of it. Most features sending in-app, email, or Slack notifications are nowhere near that line. If yours might be, ask first - the answer is still probably yes, just with a conversation attached.
For everything under that line, there is nothing to design, provision, or get paged for. You call client.send, and the delivery, retries, and queue depth are already somebody else’s dashboard.
Clone notification-service, run make setup, and send your first real notification before your next standup.
You need to see your usage data without waiting on us, and right now that means waiting on an Insights dashboard that was supposed to ship this quarter. It did not. The billing-system migration we were contractually required to finish ran six weeks past its own deadline, and finishing it on time left no room to also finish Insights to the standard we told you it would meet. We are not shipping a half-built dashboard and calling it done, and we are not asking you to wait for an explanation before you get your data.
Here is what is real. The full Insights dashboard, with the saved views and scheduled reports you were told about, moves to Q1. We are not shipping a stripped-down version early and asking you to call it the same thing.
What you can use today is a CSV export of the same data Insights will eventually surface. From Settings > Data and Analytics > Export, you can download every usage event on your account - user ID, event name, timestamp, session ID, plan tier - from your account’s creation date through the end of yesterday. Most exports generate in a few seconds. Open the file in Excel, Sheets, or whatever BI tool your team already runs, and you can build the filtering, grouping, and retention views you need, starting now instead of in Q1.
That is not the dashboard. It takes your own spreadsheet work to get answers the dashboard would have handed you automatically, and it has no scheduled reports and no saved views. If your team was counting on either of those two features specifically, the export will not replace them before Q1.
If you were one of the accounts given a Q3 date directly, expect a call this week, not just this note. If the dashboard’s original timeline was part of a renewal decision on your side, tell us now, before that conversation happens, not after. No setup stands between you and the file; it is already in your account settings.
Download your export today, from Settings > Data and Analytics > Export.
Your last new hire took three or four weeks to ship a single real change, and by then whether she felt like part of the team had already been decided by the silence of those weeks. You know the shape of it: she solves her own access problems quietly rather than interrupt anyone, and the first commit lands long after the first impression already formed.
Here is what we ran instead, on a team that deploys daily and shares an on-call rotation: a two-week guided pairing protocol with one named buddy, a printed checklist, and a first real change picked before the new hire’s first day. Not “sit beside someone and absorb.” Not a written runbook she works through alone. Not handing the whole thing to the tech lead and hoping it holds under sprint pressure. We tried versions of all three and dropped them.
Priya’s buddy owned the access checklist and caught the one gap, a missing VPN cert step, the same day it surfaced. Two 90-minute walkthroughs covered service topology and deployment tooling in week one. The team scoped her first change before she arrived: one service, no on-call risk if it went wrong. She opened the pull request by the Wednesday that closed week two. It shipped two days later, and her name was in the deployment log before the formal onboarding window ended.
The cost is real and we’re not going to hide it from you. Her buddy lost roughly 30 to 40 percent of his capacity in week one and 15 to 20 percent in week two. Put that in sprint planning explicitly or the protocol fails quietly, the same way unstructured onboarding does. And if the first change isn’t scoped before day one, week two has no fallback built in. The buddy improvises, and that’s variance a checklist can’t absorb.
What it buys you: the new hire’s access problems have a named owner instead of falling into a gap nobody’s watching, and belonging gets decided by what she’s done by week two instead of by what nobody said in week one.
Before your next hire’s start date, pick the first change they will ship. The buddy, the checklist, and the walkthroughs all organize around that one decision.
Dana,
Ten years ago you had a decision in front of you, and the safe version of it was obvious: hand the platform migration to someone who already had a project that size on their record, not to the person who had just asked you not to put her forward yet. You had your own team to run and your own reputation riding on how it turned out. You made the other call anyway, and you put my name forward as lead before I had finished arguing that I wasn’t ready.
Here is what that one decision bought, in plain terms. A six-month migration that shipped. A person who had never carried that much weight before, learning what it felt like to carry it. A decision pattern I still run today, a decade later, on the people I manage. None of that was guaranteed the day you signed off on it, and you knew that going in.
You did not make the bet and then step back to watch. You stayed close for the full six months - answering questions you had already answered once, sitting in the stakeholder meetings without taking the room away from me, and when I got something wrong in front of people whose opinion mattered, correcting me afterward instead of in the moment. You never once took the pen out of my hand, even in the weeks it would have been faster for you to.
Last month I ran the same play on someone on my team. I put her forward for a scope she did not think she was ready for, stayed close through the rough first stretch, and let her make calls I could have made faster myself. It is working. It is working because you ran this experiment on me first and absorbed the risk if it had gone the other way.
I do not think I ever told you how the migration landed, or what it turned into over the ten years since. That gap is mine to close, not yours to have wondered about.
So here is the one thing I am asking: let me take you to dinner, your choice of restaurant, before this turns into an eleven-year-old thank-you instead of a ten-year-old one.
You measure your days by what they produced, and lately the measurement keeps coming back worse. Decisions take longer than they used to. You catch yourself redoing analysis you already did once. By the end of a long work stretch, your patience for a hard problem is thinner than it was at the start. None of that is a mood. It is a pattern, visible if you compare one week against the next.
The thing that has actually held, after a few failed starts, is one full day a week with no work output, no task completion, no checking messages. Not a lighter day. A different kind of day.
The install is a single decision, made the night before: close the laptop, put the phone in another room, and do not open either until morning. No app, no setting, no automation. The whole point is that you cannot schedule the willingness to stop.
The first attempt will not feel like rest. The first version of this practice ran six weeks before a deadline pulled it under, and the restart came eleven months later. It has held for fourteen weeks since. The phone-away window started at four hours and is now ten. Progress here is measured in hours added, not in a switch that flips.
Here is the cost, stated plainly: the feeling of control. The pull to check one more thing does not fade on the first few tries, and the early hours of the day can run anxious instead of calm, especially with something unresolved waiting. That discomfort is the cost. It is not a sign the practice is failing.
Here is what it has returned so far: two problems that had been stuck for days both cleared by the following Monday. That is one data point from one week, not a promise that it repeats for you. What does repeat is the shape of the week itself. Six days carry a different quality of attention once the seventh is genuinely off.
You do not need a system to start, and you do not need to wait for a lighter week, because there is no such thing as one. You need one evening.
Tonight, put your phone in a different room before you go to sleep, and do not open it until morning.
“It’s a small thing.” “It’s probably already in there.” “I’m not sure it counts.”
If that is what you thought when you saw the ask about Howard’s runbook, this is for you.
Howard Thayer spent twenty-six years as an Operations Coordinator at Crestfield Group. His last day was Saturday, June 27. Before he left, he sat down for two sessions in May and June with Dana Reyes and Marcus Okonkwo to write down what he had carried in his head for two decades.
You can check what came out of those sessions. The runbook covers the vendor escalation paths. It covers four utility contacts that existed nowhere in the official system, because Howard kept them himself. It covers the sequence to follow when the automated alerts do not tell the full story.
What it does not cover is anything Howard taught you one-on-one that never came up in those two sessions. Two sessions could not hold twenty-six years, and the team’s own status report says as much: his judgment in an ambiguous situation is not something the runbook captures.
That is where your small thing comes in. A vendor contact who actually calls back. A workaround he showed you once at your desk. The question he always asked before anyone touched anything. If it lives in your head and not in the document, the runbook does not have it.
You do not need to write it up well. A name and a number is enough. Two sentences about a workaround is enough. The runbook is a living document.
Your note also lands where it gets used. Marcus is running a gap analysis against the six most common incident types Howard handled, due August 15, and a specific contact or practice gives him something concrete to check. Dana’s target is at least one incident closed on the on-call rotation through September 30 without escalating to Howard. Every entry you add is one less thing the person on call has to work out alone.
You do not have to decide whether it counts. Carolyn Marsh, the Operations Lead, is collecting them. Your part is to send it.
At his send-off on June 25, Howard spoke for four minutes. He said he was proud of the team and that he did not want to be the reason anyone felt stuck. Sending what he taught you is one way to make sure of that.
Send your vendor contact, practice, or workaround to Carolyn Marsh at cmarsh@crestfieldgroup.internal by July 11.
Your checkout integration still points at a system you do not fully trust. You have lived with the session-state bugs, the payment-step drop-offs, and the mobile re-render failures that never reproduced cleanly in a bug report. Each failure looked survivable alone. Together they are the reason your cart-abandonment number has not moved in years, and the reason you have kept putting off touching checkout at all.
The new checkout pipeline is live, and here is what makes it worth pointing your integration at. It ran alongside the old flow for fourteen months before any team was asked to depend on it alone, and it held through two full peak-load periods without a single customer-visible incident. Two serious issues surfaced during that run: a cart-state mismatch under concurrent sessions, and a race condition between the payment-processor callback and the session store. Both were caught and fixed before either touched a live order. Traffic was pulled back twice when something looked wrong, and no one mid-checkout ever noticed either time.
That is not the record of a team racing a launch date. Two slips pushed this later than planned, and fourteen months of running both systems in parallel cost real engineering time that nobody got to spend on anything else. Those costs are the reason you are not the one finding these bugs on your own production traffic today.
Switching does not mean a migration project on your end. The v2 API is backward-compatible with your existing cart identifiers, so your current checkout calls can point at the new endpoint as they are:
POST /v2/checkout/sessions{ "cart_id": "cart_abc123", "session_token": "tok_xyz", "channel": "web"}The migration guide covers the known edge cases from fourteen months of real traffic, so you are not the one discovering them.
The old flow is fully decommissioned, so there is no second option left to weigh against this one. What you get instead of a choice is fourteen months of production validation and a cart ID field your system already knows how to send.
Point your integration at /v2/checkout/sessions.
Your return-to-office debate has been running for months, and it keeps landing on the same two bad options: require everyone back five days, or leave the location question open indefinitely. Neither survives contact with your actual constraints. A full return breaks promises you made to people who relocated and restructured their lives around flexibility. No mandate at all leaves the trust-and-coordination problem that leadership keeps raising unresolved, and it gets worse with every new hire who has never shared a room with a teammate.
You do not need a third debate. You need two anchor days.
The hybrid-anchor model replaces the binary with one fixed, protected block of shared time and a flexible default for everything else: two days a week - we use Tuesday and Thursday - when the whole team is expected on site, and three days where each person decides for themselves, no approval required either direction. That is the entire policy. It fits on an index card, which is the point: a policy your team can recite is a policy your team can actually follow.
Here is what two days buys you that zero days cannot. Spontaneous collisions - the hallway question, the whiteboard session that changes a decision - need predictable overlap, not daily proximity. Two reliable days a week gives you that overlap without asking anyone to give up three days of commute time they already rely on. And because the remaining three days carry no location requirement, you keep access to talent in markets where you have no office, which a five-day mandate forecloses outright.
This will not satisfy everyone on day one. People who structured their lives around full flexibility will feel two office days as a real cost, not a rounding error, and you should say that plainly rather than sell it as painless. Some candidates will still walk away from any mandatory presence requirement. That is a known trade, not a flaw you missed along the way.
Protect the anchor days from individual opt-outs for at least one quarter before you touch anything else. Opt-outs are how anchor days quietly stop being anchor days, and you will not know whether the model works until you have run it without exceptions long enough to see the collisions it was built to produce.
Pick your two anchor days this week.
Your customer feedback already exists. It is just not anywhere you can use it. Some of it sits in a spreadsheet someone built months ago. Some of it is buried in a chat thread from last week’s sales call. Some of it is a half-finished list in your ticket tracker that nobody has opened since the last roadmap meeting. Before your team can agree on what to build next, someone has to open all three, copy out what matters, and sit through a meeting where everyone argues about priority anyway.
You could try the roadmap view your ticket tracker already has. It will show you tickets. It will not show you that the same request showed up twice in a chat thread and once on a sales call, which is the part that actually tells you what matters.
Tidemark skips the copying. It connects to the feedback sources you already use, finds the themes customers raise more than once across all of them, and ranks those themes by how often and how recently they came up. What comes out the other side is one ranked roadmap, not a spreadsheet you have to assemble and maintain by hand. You see what customers are actually asking for in minutes, not days.
This is built for a specific team: two to twenty people, one person who owns the roadmap, no dedicated research function sitting behind it. If that describes your team, the manual version is costing you a meeting every cycle that Tidemark can skip entirely.
It does not connect to every feedback source yet. The core workflow - gather, rank, share - works today; the list of connected sources is still growing. If the place your feedback lives is not on that list, that is a real gap, not a detail we are hiding, and telling us moves it up the queue.
Once you run it, you get a link. Send it to whoever needs to see the roadmap, and they see the same ranked list you do, not a summary someone wrote about it afterward.
The waitlist is open at tidemark.io. Join it, and you will have access when Tidemark launches next week.
You have a message from someone who matters to you, and you read it the day it arrived, and you still haven’t answered. Maybe that was April. You tell yourself you’re giving it room, or waiting for the right words, or that a long silence has its own kind of mercy. None of that is what’s happening. What’s happening is that the longer it sits, the harder it is to open, and you already know that, which is why you keep not opening it. That’s the alternative you’re living with today: not deciding, dressed up as deciding later.
This year, a project I had led for eighteen months closed without shipping anything, and eleven people who gave it real time got a thank-you that did not match what they’d put in. I still haven’t corrected that. Looking back at it alongside a six-year friendship that went quiet over the same stretch, the failure in both cases wasn’t effort. It was the exact habit you’re running right now: managing how something looked instead of saying the smaller, truer thing early, while it still cost less to say.
With the project, I kept a coalition optimistic when some of them needed a harder truth months sooner, and the silence only broke when the funder pulled out and there was nothing left to manage. With the friendship, I called the growing distance independence. It was avoidance. Avoidance compounds - eighteen months is roughly how long it took the project to fail outright, and that is not so different from how many months a message can sit unanswered. Both get more expensive the longer they run, not less.
Here is the part you can use without having lived through either loss: the fix was never a better message. It was a smaller, earlier one. You do not need to account for the last several months before you say anything at all. You need one sentence that is true today, nothing more finished than that.
Write it. Not a plan to write it this week, not a note to get to it soon. Send one message, now, to the person you’ve been avoiding. That’s the only action here, and it’s the one I didn’t take soon enough to matter.