michaelheap.com

In the spotlight

2026-02-26T14:58:41Z

I've spent most of my career on the periphery. Building the tools, documentation and platforms that make it possible to build the product that customers pay for. I remember fighting tooth and nail for headcount. Lobbying to get some time on the company all-hands to make sure people know that we exist. Being worried that when cuts inevitably come, the teams I work with would be first on the chopping block.

Now, I'm in the spotlight. I'm the product leader for the product that makes the majority of our revenue. I fought so long to be in the spotlight, and now that I'm here I'm struggling to bear its weight.

The weight of the spotlight

Working on a revenue-generating product is often treated as a privilege. The work is visible. Impact is easier to point to. Success maps cleanly to business outcomes.

But that visibility comes with scrutiny.

Every decision is observed, evaluated, and challenged - by leadership, sales, marketing, finance, customer success, and often customers themselves. The closer your work is to revenue, the more people feel entitled to an opinion about it.

I thought I'd spend my time adding new capabilities to the product, but I've learned that in the spotlight you don't ship features. You defend them.

Revenue = Restrictions

The closer your work is to the revenue, the less freedom you have on your own destiny. With so many people's careers relying on your product (internally, and within your customers) you're subject to a large list of constraints:

Features promised to sign a deal
Existing customer expectations
Revenue targets from the business

As you try to deliver all of these, you also need to maintain stability for your existing customers. You can't break anything, ever. Experimentation becomes expensive. Reversibility matters more than elegance.

You're walking down a narrow corridor under a bright light, stepping carefully do you don't touch the wall on either side. As you walk, people are shouting their opinions on pricing, roadmap priorities and market positioning.

And you can't ignore those opinions. Each statement is framed as risk. If we don't ship feature X, customer Y will churn. If we charge $10,000, we'll lose the deal. We need to shift messaging to CIOs to capture that budget.

System breakdown

Over time, everything grinds to a halt.

People ship the safe thing, not the impactful thing
Timelines are extended so that we can "underpromise and overdeliver"
People optimize for defensibility rather than learning

This isn't your team doing the wrong things. They're reacting to the risk in the system with a rational response. No-one wants to be associated with a loss of revenue due to a bet they made. So we keep doing the safe things.

The trade-off

When I think back to my time on auxiliary teams, there was no spotlight. We'd occasionally get feedback from a customer, but overall our destiny was our own. We could make the big bets, but when they were successful no-one really understood just how impactful the work was.

For auxiliary teams, success looks like nothing breaking, and no-one complaining. They keep the lights on all while longing for the spotlight themselves, not realising that there's a cost to pay.

Revenue teams trade autonomy for visibility.
Auxiliary teams trade visibility for autonomy.

Neither is easier. They just fail in different directions.

Learning to carry the light

I don't think the answer is to work in the shadows. Revenue work is what pays the bills, and the scrutiny exists for real reasons. It's rational for people to protect it.

But the cost of that protection is often invisible: slower learning, narrower ambition, and teams that mistake defensibility for good judgment. When everything is framed as existential risk, we stop asking what’s worth building and start asking what’s hardest to argue against.

The work, I’m learning, isn’t just product strategy. It’s systems design. Creating space where teams can make bets without being crushed by hindsight. Separating real risk from imagined risk. Absorbing pressure so it doesn’t flatten everyone else.

That's the role of a leader. To make space. To bring clarity. To be the filter that brings signal to the noise.

The spotlight isn’t going away. But maybe it doesn’t have to blind us.

Choose your losses

2026-02-18T17:13:44Z

Strategy is choosing what you’ll be bad at.

I’ve been revisiting Michael Porter’s work on strategy, and the point that's stuck with me is this: trying to be “the best” is usually a trap. “Best” often means you’re competing on the same dimensions as everyone else. The same benchmarks, same dashboards, same playbook. You can lead for a while, but the moment everyone copies what works, yesterday’s advantage becomes today’s expectation.

If you want to avoid the race to the bottom, don't try and compete on doing the same things as everyone else, but better. Do the things that you're uniquely positioned to do that are hard to copy for your competitors.

Stop Confusing “Better” With “Different”

Companies often confuse differentiation with excellence. Maybe you have more features, or higher quality, or better customer support. Those are differentiators, but guess what:

Your competitors are building those features right now
You're only one bad bug away from reputational damage
Your best support staff will leave (potentially for your competitors)

The things that we say make us different are mostly operational effectiveness rather than strategic differentiation.

Strategic differentiation is the thing that's hard to copy. It's a set of choices that reinforce each other to build an advantage. Copying a single choice that you've made doesn't help the copier. They'd have to copy the whole system (and accept the trade-offs that you've made along the way).

This is how you differentiate yourself from the market.

The uncomfortable part is you have to name what you’re not going to optimize.

If you can’t say what you choose to be bad at, you don’t have a strategy, you have ambition.

Choose Your Customer

Let's build a sample use case to really drive the point home. There has been a proliferation of observability tools over the last couple of years. Thanks to open standards (thanks, OpenTelemetry!) it feels like a new competitor has popped up every other week and the cost of switching is lower than it's ever been. Competing on better pricing or a nicer UI is a dead end.

Many of the tools out there position real-time data processing as a benefit. The event happens, and less than 5 seconds later you can see it in your dashboard. Your system can do it in 3 seconds, so you're the market leader for those looking for speed.

Eventually though, someone else will do it in 2.5 seconds. Then 2, then 1. Suddenly your advantage is gone.

Instead of competing on the same metric that everyone uses, what if you explored other use cases:

These tools have 30-day retention -> We'll provide 365-day retention at the same granularity (targeting compliance) -> Storage and retrieval of the data takes up to 10 minutes
Sending so much data across the internet is expensive -> Our product can't show realtime, fine-grained data, but we have an agent that runs daily and reduces data egress costs by 90% (targeting FinOps teams) -> Additional deployment complexity for customers
We pride ourselves on performance -> We're slightly slower to ingest, but we guarantee exactly once ingestion (targeting regulated industries) -> Our sales team finds it hard to demo

Each of these use cases forces architecture, pricing and go-to market decisions. They are hard to imitate, and hard to undo. If sales asks for realtime dashboards, the strategy answer isn’t ‘maybe later.’ It’s ‘no’ unless we’re willing to unwind the system that makes our advantage.

If you're successful, your competitors will try to copy you without having the correct foundations. They built an architecture around ingestion speed and are trying to pivot to long-term retention with the wrong technologies, and the wrong team.

It's important to emphasize that these are trade-offs. If the market values speed over retention, you don’t get to “pivot” to instant ingestion without undoing the choices that made you different. You can't do everything and be differentiated.

Build a Stack, Not a Skill

Most career advice is generic. "Be a great communicator". "Always deliver on time". When I'm reviewing applications as a hiring manager, I've seen all of the generic traits by the fifth or sixth application.

Instead of saying the same as everyone else, build a specific combination of traits that sets you apart.

To build your stack of traits, choose one item from each of these categories:

Domain / context (where you have unusual understanding)
Examples: platforms, regulated industries, developer workflows, migrations, pricing, enterprise buying, support realities.
Craft (how you work)
Examples: writing, systems thinking, facilitation, debugging, prototyping, negotiation, research.
Leverage (how it spreads)
Examples: internal enablement, templates, docs, workshops, tooling, a repeatable process, a network.

Your uniqueness usually lives in the combination, not a single skill.

Example: “Deep platform context + crisp writing + enablement templates”
becomes: someone who makes complex platform decisions simple and repeatable across teams.

As mentioned earlier, there are trade-offs each time you make a decision. Name the trade-off you're willing to make consistently:

I'll lose five small deals to save one large deal
I care more about getting to what’s true than about everyone agreeing
I prioritise iteration speed over upfront certainty
We optimise for consistency, not autonomy
I aim to understand 25% of Product, Engineering and Marketing rather than 80% of Product

Personally, I am the person you call when something is on fire, because I can rapidly gain context from both a technical and business perspective. To enable this, I will happily be mediocre at long-horizon planning and stakeholder consensus-building.

The Pattern Shows Up Everywhere

Being unique is a strategy that works in every industry.

IKEA optimise for low prices and immediate availability, at the expense of service through flat-pack, self-assembly, and “good enough” furniture.

FedEx optimise for reliable, on-time delivery rather than aiming to be the cheapest option.

Nespresso optimise for convenient premium-at-home coffee, at the expense of a closed pod ecosystem and a higher cost per cup.

That's how you build an advantage, not by competing in a race where the prize is eventually becoming everyone’s baseline. Strategy is choosing what you’ll refuse to be great at - and then living with that refusal long enough that it becomes your advantage.

Never leave on a no

2026-02-13T03:52:05Z

One of the biggest mistakes I see new managers make is how they manage disagreement with their boss.

They do one of two things:

They nod along, but disagree quietly and disengage
They keep arguing until they run out of time and the meeting ends awkwardly, with no real decision

Both options leave their boss frustrated.

Something that's worked well for me is that I never leave a conversation on a no.

It doesn't mean we always agree. It means that we're aligned on what the next steps are.

Disagreeing behind closed doors

I believe that it's everyone's responsibility to challenge bad ideas. You should challenge ideas when:

You have information that the person you're talking to doesn't
You're accountable for the outcome
You believe a decision will materially harm your team, customers or business

How you challenge is important. Shouting in a meeting room with 15 other people won't get you anywhere. Instead, argue with your boss in private where there is space to listen and to be heard.

Know when to stop

There's a difference between advocacy and infinite debate. Knowing when to stop pushing and start aligning is a skill.

Early in a discussion you can push hard:

Ask clarifying questions
Share concrete risks
Offer alternatives, not just objections

But at some point, you'll feel a shift in the conversation. You start getting repeated answers. The trade-offs have been heard. The decision has been made.

The most senior person in the room decides when the argument is over. Your job is to notice.

Missing that moment once is forgivable. Missing it repeatedly gets you labeled “difficult,” regardless of the quality of your ideas.

Disagreement is a tool for improving decisions, and once the decision is made your job changes.

What “never leave on a no” actually means

Before the meeting ends, alignment has to be explicit.

You should be able to say one of these - and mean it:

“I disagree, but I understand the decision and I’ll execute it.”
“I still have concerns, but given the trade-offs, this is the direction we’re taking.”
“Let’s try this for X weeks and revisit with data.”

A clean disagreement that ends in commitment builds trust. A fuzzy disagreement that lingers destroys it.

From your boss’s perspective, there are few things more dangerous than a manager who:

Appears aligned in the meeting
Signals doubt afterward
Executes half-heartedly

If you can’t commit, say so in the room. Don’t carry a private veto.

It's easy to paint leadership as the bad guys.

"This wasn't my call"
"I don't agree, but..."
"Leadership wants us to..."

It feels like solidarity, but it teaches your team that alignment is optional.

Your team works for you, not leadership, and they need to know what they need to do be successful in your business.

What was the decision?
Why did we decide this?
What does success look like?

You don't have to say that you're fully behind the idea, but you do need to communicate that this is the direction.

“There were other options, and we discussed them. This is the direction we’re taking, and here’s how we’ll make it successful.”

If you can't stand behind the decision at all, you need to get back in a room with your boss and talk until you can.

Your real job

Your job isn’t to win arguments.
It’s to reduce uncertainty.

Argue fiercely when it matters.
Notice when the argument is over.
And never walk out of the room without a clear answer to one question:

“What are we doing next?”

Update the AUR from GitHub Actions

2026-02-05T13:45:31Z

I maintain trello-cli, which is also published to the Arch User Repository (AUR).

Each time the package is published, I needed to update the PKGBUILD with a new version and sha512sum. I'm no longer an Arch user (I miss it, but MacOS works so much better for my current role) and so I don't have makepkg readily available.

I had an idea that updating the PKGBUILD could be done with GitHub Actions:

Updating an AUR package for a node based tool could be automated using GitHub Actions.
Each time a release is tagged, the pkgver and sha512sums fields in the PKGBUILD need updating, and the repo needs pushing to the https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD
The sha512sum needs to be calculated from the published NPM package, so we'd need to wait until the version is available, download it from the registry and then calculate the checksum.

Here's how I did it:

Generate an SSH keypair:

bash
ssh-keygen -t ed25519 -f ~/.ssh/aur -C "GH AUR - your-email@example.com"

Add the public key to your AUR account:
- Go to https://aur.archlinux.org → My Account → SSH Public Keys
- Paste contents of ~/.ssh/aur.pub
Add the private key as a GitHub secret:
- Go to your repo → Settings → Secrets and variables → Actions
- Create secret named AUR_SSH_PRIVATE_KEY
- Paste contents of ~/.ssh/aur

Then create a GitHub Actions workflow that you can run. You can't add it to your npm release workflow as there is a delay between publishing and it appearing in the API.

There's some tricky runuser logic required when updating .SRCINFO as you can't run makepkg as root:

yaml
name: Update AUR Package
on:
  workflow_dispatch:
  schedule:
    - cron: "0 0 * * 0" # Weekly on Sunday at midnight UTC
jobs:
  update-aur:
    runs-on: ubuntu-latest
    container:
      image: archlinux:base-devel
    steps:
      - name: Install dependencies
        run: pacman -Sy --noconfirm jq openssh git
      - name: Get latest npm version
        id: npm
        run: |
          VERSION=$(curl -s https://registry.npmjs.org/trello-cli/latest | jq -r '.version')
          echo "version=$VERSION" >> $GITHUB_OUTPUT
      - name: Download tarball and get sha512sum
        id: checksum
        run: |
          curl -sLO "https://registry.npmjs.org/trello-cli/-/trello-cli-$.tgz"
          SHA512=$(sha512sum trello-cli-$.tgz | cut -d' ' -f1)
          echo "sha512=$SHA512" >> $GITHUB_OUTPUT
      - name: Setup SSH for AUR
        run: |
          mkdir -p ~/.ssh
          echo "$" > ~/.ssh/aur
          chmod 600 ~/.ssh/aur
      - name: Clone AUR repo
        env:
          GIT_SSH_COMMAND: "ssh -i ~/.ssh/aur -o IdentitiesOnly=yes -o StrictHostKeyChecking=no"
        run: git clone ssh://aur@aur.archlinux.org/trello-cli.git aur-repo
      - name: Check if update needed
        id: check
        working-directory: aur-repo
        run: |
          CURRENT=$(grep '^pkgver=' PKGBUILD | cut -d= -f2)
          if [ "$CURRENT" = "$" ]; then
            echo "Already up-to-date (version $CURRENT)"
            echo "skip=true" >> $GITHUB_OUTPUT
          else
            echo "Update available: $CURRENT -> $"
            echo "skip=false" >> $GITHUB_OUTPUT
          fi
      - name: Update PKGBUILD
        if: steps.check.outputs.skip != 'true'
        working-directory: aur-repo
        run: |
          sed -i "s/^pkgver=.*/pkgver=${{ steps.npm.outputs.version }}/" PKGBUILD
          sed -i "s/^pkgrel=.*/pkgrel=1/" PKGBUILD
          sed -i "s/^sha512sums=.*/sha512sums=('${{ steps.checksum.outputs.sha512 }}')/" PKGBUILD
      - name: Update .SRCINFO
        if: steps.check.outputs.skip != 'true'
        working-directory: aur-repo
        run: |
          useradd -m builder
          mkdir -p /home/builder/build
          cp -a . /home/builder/build
          chown -R builder:builder /home/builder/build
          runuser -u builder -- bash -lc 'cd /home/builder/build && makepkg --printsrcinfo > .SRCINFO'
          cp /home/builder/build/.SRCINFO ./.SRCINFO
      - name: Commit and push
        if: steps.check.outputs.skip != 'true'
        working-directory: aur-repo
        env:
          GIT_SSH_COMMAND: "ssh -i ~/.ssh/aur -o IdentitiesOnly=yes -o StrictHostKeyChecking=no"
        run: |
          git config user.name "Michael Heap"
          git config user.email "m@michaelheap.com"
          git add PKGBUILD .SRCINFO
          git commit -m "Update to version $"
          git push

Now you have a workflow that will update your PKGBUILD automatically once per week, or whenever you trigger the action manually.

Yes, if…

2026-02-04T20:25:58Z

People love hearing “yes.”

In a meeting, it sounds like momentum. In Slack, it reads as alignment. On a roadmap, it feels like progress.

It's also the first step towards disappointment. "Yes" is a contract - a commitment to deliver something. If you say "yes" to everything, you start paying for it with late nights, dropped balls and a creeping resentment that's hard to admit because you chose to say yes.

Every “yes” goes on an invisible ledger. Time, attention, credibility. All quietly debited, rarely reconciled. Eventually you will go bankrupt and disappoint someone. The only question is whether you disappoint them when they ask, or later when your lack of delivery has a much higher cost.

The two types of "yes"

We say “yes” for many reasons. In personal relationships, it can strengthen bonds and make others feel valued. In professional settings, saying “yes” can signal teamwork, ambition, and a commitment to shared goals. However, saying “yes” can also be driven by fear. A fear of disappointing others, a fear of missing out, or a fear of conflict.

No matter why we say yes, the expectation to be agreeable leads to us committing to way more than we can ever hope to achieve. You say yes to avoid disappointing someone, only to disappoint them at the worst possible time: after you've agreed, they've told other people about their idea and half of the org is excited.

So, how do you keep the momentum that "yes" brings without overcommitting yourself? By using "Yes, if."

"Yes, If" is a trade

“Yes” pretends there is no conversation. It hides the cost and defers the pain.

“No” without context shuts the conversation down before anything useful is learned.

“Yes, if” is the conversation.

“Yes, if” makes the cost visible. It takes the invisible tax you were about to pay and puts it on the table where everyone can see it. Not as a complaint. Not as drama. As accounting.

“Yes, if you can wait until Thursday after the report goes out.”
“Yes, if we agree this replaces the other thing I’m doing.”
“Yes, if you do the first draft and I’ll review.”
“Yes, if we can fund the work and assign an owner.”

Most frustration at work doesn’t come from disagreement. It comes from ambiguity.

Applying this in real life

A good “Yes, if” is just good bookkeeping. It names which account you’re drawing from.

Time: “Yes, if it can wait until Thursday.”
Priority: “Yes, if Bob agrees this outranks the report.”
Ownership: “Yes, if you draft it and I’ll review.”
Scope: “Yes, if we do a 1-page version, not a full report.”
Resourcing: “Yes, if we fund it / staff it.”

Most org pain comes from pretending those currencies are infinite. By explicitly naming them and negotiating with the requester you can be collaborative without overcommitting.

Price the work

“Yes, if” is about maintaining balance. It’s about making sure the work you agree to aligns with your time, energy, and priorities.

Next time someone asks you for something, name the trade-offs. Make the constraint explicit. Price the work. See if they still want it.

If that trade kills the request, it wasn’t a priority. It was just an idea looking for someone else to carry the cost.

“Yes, if” is about maintaining balance. It's about making sure that projects align with your time, energy, and priorities. It fosters collaboration without compromising your well-being. Next time you’re faced with a request, remember: you don’t have to say “yes” to everything, but with the right conditions in place, you might just find a way to make it work for everyone.

Delivery and Dopamine

2026-01-28T20:08:57Z

I've built my career around being the person that delivers. Throw me into a messy problem and I'll figure it out and make progress.

My performance reviews praised output. Peers trusted me as the person who “got things done”. The system rewarded shipping, and for a long time I used that as my definition of “doing my job well”. I confused visibility with value, and if I’m being totally honest, I was addicted to being the person that everyone pinged.

Then one day, my career stalled. I just couldn't justify another promotion on output alone. Shipping things feels good in a way that designing systems doesn't. Shipping provided that immediate dopamine hit, but system design doesn't work like that. Feedback is delayed and ambiguous, and honestly, things usually get worse before they get better.

You can justify being a player-coach as a manager, senior manager and in some places, even a director. But at some point you need to accept that the best use of your time is to act as a multiplier for the team that you're supporting.

That's where I failed.

Dopamine vs. Leverage

Execution gives you fast feedback. System design demands patience.

When I say “designing systems,” I don’t mean architecture diagrams. I mean the interfaces that shape how the business operates: who makes decisions, how work gets planned and what happens when things break.

Discipline means letting the system converge on an idea and make decisions without you "helping". It means allowing systems to fail without heroics, enabling the organization to understand the flaws in the system. It means trading that dopamine hit for organizational leverage.

It also means being comfortable with feeling like a failure. Letting projects fail felt irresponsible. Not being hands on felt lazy. And if I'm honest, not getting that dopamine hit felt like withdrawal.

The Relapse

When leaders step back, things slow down. Metrics wobble. People complain.

That's the system revealing itself. Heroics are praised, and organizations choose short-term relief over long-term leverage. So when things got messy, I didn’t choose execution, I relapsed into it. It was the easy choice. The safe choice. It was also the wrong choice.

I fell back into being an IC multiple times. Each time the dopamine hit was even bigger. "Things were really going downhill and you turned it around!" Each time, it was even harder to crawl back out of the routine of shipping and start thinking about the overall system.

In one example, there was a last minute tooling update required for a key customer. So I dove in, made the changes, got the relevant approval and shipped a fix within 24 hours. The customer was happy, the account team was happy, the engineering team appreciated not being interrupted... then less than a week later the exact same thing happened again. Everyone's first instinct was to message me. My save the previous week didn’t fix the problem; it taught the organization the workaround.

The "helping" trap

I told myself I was "just helping".

But “helping” was a trap. It kept me focused on solving the immediate problem instead of asking why this problem kept showing up. It made me the bottleneck instead of fixing the decision boundary. It let me feel needed, and in the process I stole learning from the organization. The team didn’t get stronger; the system didn’t improve; I just became the workaround.

I'm not entirely at fault, though. While I was chasing the next hit I was also operating in an environment that was easy to understand. Do good work, get rewarded. Designing systems is filled with ambiguity and risk. System design is political, cross-functional and uncertain. It's also invisible to your stakeholders (until it fails). Execution is visible, measurable and safe.

Build a System That Ships Without You

Building a sustainable system is thankless work. The feedback loop is slow, and the wins are quiet. You don’t measure it by what you shipped - you measure it by what happens when you’re not there.

A system is getting healthier when:

Recurring fires disappear because you removed root causes instead of treating symptoms.
Decisions happen without you (and they’re good enough. Not perfect. Good enough).
Approval paths are explicit: who decides, what “good” looks like, and how long each step should take.
Leading indicators show up early, so problems surface while they’re still cheap to fix.

If you're looking for a concrete example, we moved approvals from an ad-hoc Slack-based approach with emoji reactions to a weekly forum with named decision owners and SLAs. It felt like more process, but the overall time investment was much lower.

To understand if the system is working, ask yourself "if I take a month off, does the team still make good decisions, ship on time and recover from setbacks?".

(Fun fact! This is one of the reasons I quit my last job. I took 3 months off when my baby was born and when I got back to work it was as though I'd been there the whole time. They no longer needed me, and it was time to go and build systems somewhere else.)

The organization trained me

The org rewarded heroics, and I cashed the checks. Repeatedly.

In many cases a leader is doing what the organization expects of them. It's not that they can't let go of execution, it's that no-one tells them that they should. So we keep delivering, getting that dopamine hit and feeling effective.

Until organizations realize that leadership is about designing systems that enable the work, rather than doing it, they'll keep celebrating productivity and wondering why nothing scales.

We have to fix the incentives. Evaluate leaders based on team throughput and decision quality, not individual output. Celebrate recurring fires that no longer happen. Put “eliminated dependencies” and “decisions made without me” into performance reviews. Heroic saves should result in a postmortem and a system fix, not a medal.

If heroics are the path to praise, leaders will keep relapsing (even when they know better). If you keep rewarding people for being the system rather than building the system you won’t get leaders.

You’ll get bottlenecks with better titles.

Fix the inputs, not the outputs

2026-01-21T09:58:37Z

A friend of mine is a design leader at a company with a couple of thousand people. We were recently chatting about the amount of time she was spending reviewing her team's work. It wasn't because the work was bad, but because she had no idea if the design met the needs of the project. She was spending hours trying to reverse-engineer the requirements from the final design.

The reviews didn't feel good for the individual designers either. Their manager was coming in at the end of a project and scrutinizing every little decision without the full context of what the requirements were. As it turned out, the designers also didn't have the full context - they knew how it started, but not how the requirements evolved over time. That information lived somewhere between the manager, the designers, and the project lead, with no clear source of truth.

My friend works in a design team, but I've seen this play out in a variety of settings. Engineers without clear product requirements. DevRel teams without clear metrics. Salespeople without a solid ideal customer profile. Anytime someone's required to fill in the blanks themselves, there's a high chance that it will lead to frustration for everyone involved.

Garbage In, Garbage Out

Every output is an echo of its inputs. If the team doesn't know what "good" looks like from the start, they have to make decisions that they're not informed enough to make. Sometimes it works out, but more often than not it results in conflict.

The person reviewing the output feels that something is "off", while the team is blindsided by feedback that could have been provided as a requirement early, before the work was done.

Good requirements aren't about more documentation - they're about building a shared understanding of what you're trying to achieve.

What problem are we solving?
What does success look like?
What constraints do we have?

By aligning on the answer to these questions early, you make it easy to evaluate the work objectively. Did it solve the problem within the constraints expressed? Yes? Excellent work! Let's ship it.

A Stitch in Time

"But we don't have time to do such rigorous alignment work! They need this delivered yesterday!" I hear you, I understand, and respectfully, I disagree.

You're already spending this time, and more, at the end of the project "catching problems" with the implementation. It feels productive to catch the issues, but doing it after the work is complete is both expensive and demoralizing for the team.

Aligning on the inputs takes time, but it takes less time than trying to reconstruct requirements from an output. It takes less time than redoing the work because someone made a decision they didn't have enough context to make. Investing the time up front pays off in the long run. A stitch in time saves nine.

In order to improve for good, you need to solve problems at the systems level. Fix the inputs and the outputs will fix themselves. - James Clear, Atomic Habits

How to Fix the Inputs

Fixing the inputs isn't hard, but it does take some concerted effort. At your next project kickoff, try asking the initial framing questions:

What problem are we solving?
What does success look like?
What constraints do we have?

Take the answers provided and write them down in a location that can be linked to from the work you do. This provides the base for your requirements doc.

Over time, you'll build up a list of additional questions that are specific to your org, for example:

Is this intended for new users or for experienced users?
Are they likely to interact on a small screen, or will they always be on a laptop-sized screen?
There's a lot of data being processed here. Are users expecting a result within a second, a minute or an hour?

Of course, not every requirement can be known in advance. Discovery happens through iteration and exploration. You learn what users really need, what's technically feasible, and what trade-offs actually matter by trying things out.

That's normal. The problem isn't that requirements evolve, it's that the written requirements are rarely updated as the real world requirements change. The initial assumptions are treated as the "requirements" even as reality shifts. This is even worse than having no requirements at all, as the final output is then evaluated against incorrect assumptions.

When requirements change, don't delete the old requirements. Instead, append to the document and make a note of the date. Then add a "current requirements" section to the top that is a synthesis of everything you know from the initial definition and the updated requirements. This is your evaluation criteria once the project is ready for review.

The Real Definition of "Done"

Everyone has a different definition of "done" depending on their context and point of view. When teams say a project is "done", they mean that the solution is ready for review. In reality, the work is only done when everyone is aligned that this is the best possible outcome given the constraints.

Before calling something complete, review everyone's understanding of the problem and the proposed solution. Ask "Do we still agree on what good looks like? Are the inputs still valid?"

When inputs are solid, reviews become easier. Feedback stops becoming a surprise attack and becomes a shared evaluation against a known goal. Teams spend less time justifying their decisions and more time improving the product. "Done" stops meaning "I hope this is what you wanted" and starts meaning "we all understand why this is the best solution given the trade-offs".

So the next time you're tempted to try and reverse engineer what was required from the final output (and inevitably provide misguided feedback), pause and think about what led you to this point.

Don't fix the output.

Fix the input.

When Asking is Easy (and Answering Isn't)

2026-01-14T08:34:05Z

It's 4pm on a Thursday, and I'm patting myself on the back that I've managed to align multiple teams on a tricky project. The requirements document has been reviewed and approved by everyone involved, and I'm excited to see what's been scoped come to life.

I'm about to sign off for the day when someone from our SaaS team pinged me: "Hey, quick question. What would it take to make this multi-tenant?". It's as though the walls come crashing down around me. It's not a quick question at all - it's one that takes deep technical, historical, and organizational knowledge to unpack.

I sigh as I make another cup of tea and settle in to write an essay of a response, trying to balance the need for details without it appearing as though I'm trying to overwhelm them with complex explanations.

Questions like this aren't malicious. They're often great questions, asked in good faith. But they reveal something important about effort - it's much easier to ask questions than to answer them.

Asymmetric Questions

An asymmetric question is one where the effort to ask is trivial compared to the effort to answer.

This asymmetry isn't inherently bad. I'd choose to work with a curious team over a disinterested team every time given a choice. But when left unchecked, these questions can lead to a high emotional load for those receiving them.

I've been the person receiving the questions, and my responses have ranged from "Why are they asking questions that they definitely won't understand the answer to?" (which was an unkind categorization on my behalf) to "This sucks. Weeks of alignment undone by a single question. Maybe I can pretend I didn't see it?" to "This is a good question. I should have covered this in the first place. It's going to take time, but it's worthwhile".

Lack of knowledge is often the driver of asymmetric questions. The person asking is often missing the context required to realize how much effort it will take to answer what appears to be a simple question.

In general, the more senior or cross-functional your audience, the higher the likelihood is of one of them asking an asymmetric question. This isn't malicious - their curiosity spans domains that they're not totally familiar with.

Asymmetric questions can be valuable, but they can also be distracting. If the system that the asker is operating in rewards visibility, you're going to get spontaneous questions that don't add much. They don't care as much about the answer as they do about being seen to contribute. Over time, this erodes focus and encourages reactive rather than strategic work.

Managing the Imbalance

Asymmetric questions aren't malicious. They're born from curiosity, but left unchecked they can command a lot of time. It takes 30 seconds to ask a question, and 30 minutes to answer it.

My rule of thumb for asymmetric questions is to spend twice as long answering a question as it took to ask it. If they spent a minute asking a question, I'll give it two minutes of thought then respond (usually to ask clarifying questions of my own). The asker's response might take 5 minutes to write, and so I'll take 10 minutes to respond.

If a question takes one minute to write and will take twenty minutes to respond to, schedule a call. That's a good sign that there's something missing from either the asker's knowledge, or from your proposal itself.

The goal isn't to stop people asking questions. It's to right-size your response.

Navigating Asymmetric Questions

The first step to navigating asymmetric questions successfully is to get past the resentment stage as quickly as possible. Even being aware of the knowledge asymmetry, I still have an initial burst of resentment every time someone asks "why don't we do X?".

The impact that their question has on the project, and on me as an individual, is huge. But I need to separate intent from impact. People don't generally ask asymmetric questions without a reason.

Once you're past the initial resentment, you can engage with the asker in good faith. Many people see a question and feel like they have to answer it immediately, and in depth. This usually isn't the case.

Exploring or Deciding

Questions on proposals are either exploring or deciding.

If someone is exploring an idea e.g. "Did we consider internationalizing the docs?" then you can respond with a similar level of depth. You could say "We did, but the return on investment for both time and cost wasn't there. I'm happy to dig in more if you like."

If the same question is phrased slightly differently, they're looking for a decision: "Why aren't we internationalizing the docs?". My personal instinct here is to write a 10 paragraph response in the comments section of a Google doc, but that's the wrong approach. Instead, propose a follow-up with the correct audience: "That's a good question. A full answer will take some time to put together. Can we chat next week with a few others that were involved in the decision?"

Clarify and Redirect

If the question is open-ended, don't try to answer every potential question. Here's one question that I had recently:

Why don't we provide a hosted version of {Dependency X}?

Instead of diving in, I asked a clarifying question to narrow the scope: "There a couple of reasons. Are you asking about technical, cost or market reasons?". The author came back with "market" and I explained that a hosted version would be well received by the market, but the technical implications (single tenant dependency) meant that the cost of providing a service (COGS) was too high for it to be a viable option for us.

Asking questions turns what sounds like a demand into a conversation. Either the asker wants to really dig in and you can have a fruitful conversation, or (as I've experienced many times) they just don't respond at all and you can forget about the question entirely.

Answer with Intention

Asymmetric questions are inevitable in collaborative work, especially as scope and seniority increases. By clarifying the questions and matching your effort to their intent you can keep projects moving without letting "one quick question" derail weeks of progress.

Visibility is Velocity

2026-01-07T11:29:57Z

Once upon a time, I worked with a Product Manager, Bob. Bob's team worked with incoming data pipelines, and transformed and augmented a variety of disparate data sources in to a consistent data model. It was a tough job, as you didn't actually know what data you were going to receive from our providers until it arrived.

Bob’s team also had a reputation for being slow. On average, onboarding a new data source took about three months. When the work shipped, though, it was excellent: reliable, well-instrumented, and easy to maintain.

But when they shipped, they didn't get any accolades. The team heard "Finally! Why did it take so long?". Worse, they heard "I wish you'd have warned us - we haven't implemented the new data source in the billing system". So not only did the project feel late, the business couldn’t even use what had been delivered.

A few months later, Bob was no longer with the company. The feedback was that he “wasn’t compatible with how the business needed to operate.” We hired Alice as his replacement.

The perceived change was immediate. Alice shipped something in her first two weeks. People were impressed. It didn’t even seem plausible that Bob’s team could ship anything in two weeks, let alone within two weeks of a new PM starting.

But Alice didn’t actually make the team faster. New data sources still took three months to fully integrate. The work was the same. The complexity was the same. What changed was that progress became visible.

And suddenly, everyone believed the team had become fast.

The Dangers of Silence

Humans hate ambiguity. When there’s no signal, people invent their own story.

Bob's lack of updates created its own narrative: the work had stalled, or it wasn’t a priority. The project lost momentum. Other teams postponed their related work. Leaders delayed decisions tied to the project. Everyone just kind of "forgot" about the ongoing work.

The lack of communication usually comes from a good place:

“I didn’t want to distract people until I had something solid.”

But updates aren't a distraction. Surprises are. And surprises are expensive for everyone.

Each and every time I've found myself surprising an executive, I've ended up on calls where they're trying to figure out what's going on. Those calls take a lot of time.

We need to re-establish context for those that aren't deep in the project, then explain what's happening and why. The conversation inevitably turns to re-litigation of a decision that was already made.

Before you know it, the engineering team is frustrated that we're revisiting old decisions and the execs are frustrated that things are taking even longer. Surprises don't serve anyone.

The Power of Updates

Sending regular updates doesn't make you go any faster - in fact, it slows you down slightly as writing the updates takes time. You don't want them to be a torrent of useless information ("We added 14 new tests and added support for the FlubJam"). Instead, focus on what's useful ("We added tests to ensure that URL mapping works consistently, and integrated FlubJam so that the billing team can get started with their work").

These small, regular updates build trust and predictability for your audience. They know what's happening, and that the project is still on track. And if there is something that isn't quite right, these regular updates allows people to raise concerns, build alignment and course correct while the cost of doing so is cheap.

How to Ship Incrementally

Let's go back to Bob and Alice. Alice didn’t deliver results any faster. She just made progress visible.

Instead of waiting for everything to be solid, she shared updates like these:

Week 2: Great news! We've connected to the third party system. Here's a video of us ingesting a piece of data (no mapping, no augmentation)
Week 4: We've figured out what data is available. Here's a link to our proposed data mapping, and a demo video with the mapping added
Week 6: The pipeline is running well, and we've managed to add some augmentations. Here's a video of URL extraction from text working. Look how it augments the data with the page title from the URL
Week 8: Slow progress this week. We realised that the data isn't guaranteed to arrive in order, so it turns out that we were missing some data. We're reworking our pipeline to use the deduplication service so that we don't have to rely on timestamps. I'm still optimistic that we'll be done next month
Week 10: All solved! I've shared the data size/volume information with the billing team so that they can load it into the rate card system. We're working on additional test cases to give us confidence that we haven't missed anything.
Week 12: Tada! The project is done. Here's a list of sample configurations and test cases that we run. Thank you for all the feedback along the way.

We still couldn't ship the new data source to customers until week 12, but all of the stakeholders were clear what was happening every step of the way.

Compare that to Bob's updates:

Week 12: The integration is complete. Here’s the final implementation - let me know if you have feedback.

The engineering team did the same work on the same timeline, but the leadership team had a very different perception.

Alice wasn’t seen as faster because she did more. She was seen as faster because progress showed up continuously. Risks were surfaced early, course corrections happened when needed, and no one was surprised at the end.

Your updates don’t need to be long. Fifteen minutes to produce. Two minutes to consume. That's all it takes.

Bulk unsubscribe in Gmail

2026-01-06T10:23:42Z

Back in 2021 I added an idea to /ideas that would scan my email inbox and provide a single page containing unsubscribe links that have been scraped from emails. Here was the proposal:

A UI that reads all emails in a folder and shows all emails with an unsubscribe link.
Provide a way to group by sender / subject / unsubscribe URL
I'd like to be able to choose which folder this runs in (minimum Inbox + Trash, but ideally any folder/label)

Today I learned that Google have built this themselves. In your inbox, click on More in the sidebar and then choose Manage subscriptions. You'll see a screen that shows you email volume from each sender and allows you to unsubscribe with a single click.

Now, I need to go and unsubscribe from all of these Kickstarter platform emails that I always delete without reading...