I’ve been building a few small services as part of a personal AI operating system where I want AI agents to be first-class users.

And that immediately raised an architectural question for me.

Should I build a standard API and expose it to agents through the Model Context Protocol (MCP)? Or should the fact that agents will use the product influence how the product itself is designed?

At first, these two approaches can look very similar.

If a service already exposes an API, adding an MCP server on top of it can make selected operations available to an agent.

The agent can discover tools, retrieve information, perform actions, and interact with functionality that previously required a human or a custom integration.

The product becomes accessible to agents.

But I’m increasingly convinced that this is different from designing the product for them.

Accessibility alone can create enormous value

This distinction doesn’t make adding MCP to an existing API less valuable.

There are countless existing services with mature APIs and years of accumulated functionality, but no interface designed for agents. And a well-designed MCP server can make selected capabilities from those APIs discoverable and usable by agents.

The underlying product doesn’t become agent-first, and it doesn’t need to.

Making an existing product accessible to agents is already a significant improvement. And in many cases, redesigning the product around agents would probably be unnecessary.

If the existing API represents the domain well and the operations exposed through MCP give an agent what it needs to accomplish its goals, an MCP layer may be exactly the right architecture.

MCP-enabled and agent-first describe different kinds of value. One extends the reach of an existing product; the other can influence how the product itself is designed.

Existing APIs often expose operations

Traditional APIs are often shaped by the systems and interfaces around them.

They expose resources and operations: retrieve a document, create a comment, update a status, search a collection.

There is nothing inherently wrong with this model. In many cases, exposing the same operations through MCP may be exactly what is needed.

But an agent approaching the system has a slightly different problem.

It needs to understand not only which operations exist, but how they relate to what it is trying to accomplish.

What can I do here? What context do I need? What are the boundaries? What will happen if I perform this action? When should I ask for confirmation?

That is where access to operations can stop being enough.

March as a concrete case

March is the publishing runway service I built to plan with AI without turning the plan into a commitment.

Its API can expose months, available slots, intentional gaps, planned pieces, their states, and links to the documents behind them. An MCP server can make those operations available to an agent.

But the job I care about is not simply retrieving or updating a content item. I want an agent to inspect the runway, question the sequence, surface gaps or inconsistencies, and propose changes without treating every empty slot as work that must be filled.

That requires more than knowing which endpoint changes a status.

The agent needs to understand that a gap can be intentional, that document maturity and publication planning belong to different services, and that a proposal is not permission to change the plan.

The March case does not show that the domain model had to be rebuilt around agents. It supports a narrower claim: MCP can expose the operations, but it does not decide which context, authority boundaries, or confirmation rules make those operations safe and useful. Those decisions still have to be designed deliberately, whether they live in the API, the MCP tool contract, or both.

March still has an API, and MCP still exposes its operations. What changes when I design for agents is the attention given to that operating contract, not necessarily the architecture underneath it.

API-first, MCP-enabled, and agent-first

This is the distinction I currently find most useful.

A product can be API-first: its important capabilities are available programmatically, often before they appear in a UI.

It can also be MCP-enabled: selected capabilities can be discovered and used by agents through MCP.

And it can be agent-first: capabilities, context, permissions, and workflows have been designed considering agents as first-class consumers of the product.

These aren’t maturity levels, and I don’t think every product should try to move from one to the next. They solve different problems.

A mature product with a good API may get enormous value from becoming MCP-enabled without redesigning the underlying product.

But a new product expected to be used primarily by agents may have reasons to make different decisions much earlier.

The question changes when agents are there from the beginning

When agents are expected to be a primary way a system is used, I find a different question more useful:

If an agent had been one of the intended users from the beginning, would I have designed these capabilities the same way?

For March, that question changed what the agent needs to know before an operation and where human judgment remains explicit. The current case does not prove that the product needed a different domain model. It shows that adding the protocol did not answer those design questions.

A summary reads clearly. A proposal has a sensible structure. A product requirement includes scope, acceptance criteria, and open questions. A technical plan uses the right vocabulary and explains the architecture with confidence.

The result may genuinely be useful but its presentation can mature faster than the reasoning behind it.

And that changes the review.

Polished work changes the reviewer’s posture

A rough draft makes some of its uncertainty visible. Missing sections, awkward transitions, and unresolved questions signal that the work is still being formed. The natural response is to challenge it, add context, and ask what is missing.

A polished draft feels closer to approval and completion. And there’s a risk that reviewers move from examining the reasoning to checking the wording, filling small gaps, or confirming that the structure looks reasonable.

Roughness is not evidence of honesty, and polish is not evidence of weak thinking. But polish removes some of the friction that used to make people slow down.

The result is work that looks coherent at a glance and might be easier to trust. So it becomes easier to review the document in front of us than to investigate the decision underneath it.

What a polished draft can hide

A product requirement can describe a solution clearly while relying on weak evidence about the customer problem.

An implementation plan may name the right components but say little about failure modes, migration constraints, or operational ownership.

A customer summary can be accurate sentence by sentence and still compress the disagreement or uncertainty that would change the priority.

Making these documents clearer helps the discussion but it does not resolve what is missing.

A deeper review needs to ask where the evidence ends, which decision has already been embedded in the framing, and what has been excluded or treated as somebody else’s problem. It also needs someone who can take responsibility for the trade-off being approved.

These questions matter without AI too. But AI raises the stakes because it can create a convincing bridge before anyone has examined the gap underneath it.

Seven comments did not create seven insights

I encountered a smaller version of this while reviewing this note in August.

Several reviewer profiles stopped at almost the same passage. They all saw the same weakness: the article said that fluent output changes review behavior, but did not explain clearly enough what a stronger review should examine.

And they were right.

But seven similar comments did not give me seven different insights. Repeating that review needed stronger verification and clearer boundaries still left the editorial decision unresolved.

I had to consolidate those reactions and decide what the article was missing. That led to a more useful distinction between surface quality, evidence, hidden decisions, boundaries, and ownership.

Review output can suffer from the same problem as generated content. It can be fluent, reasonable, and repetitive without moving the decision forward.

My take-away: the number of comments is not evidence of depth.

A working reviewer still needs calibration

I recently helped a software company introduce an AI reviewer into its merge-request workflow.

The technical loop worked. During the tests, the reviewer placed comments on the relevant lines and proposed changes that could be applied directly.

That was not enough to make the review useful.

The initial prompt was generic. Some comments created noise, while repository-specific rules and failure modes still had to be made explicit. The team needed to observe false positives, notice what the reviewer missed, and refine the instructions against real changes.

A comment arriving in the correct place is not evidence that it deserves attention.

This is the same distinction at a different scale. Generating a plausible review is relatively easy. Calibrating that review so it changes the right decisions requires context, feedback, and ownership over time.

Public evidence points to the same calibration problem

This is not only a property of one internal implementation.

GitHub’s documentation for Copilot code review says that the reviewer is not guaranteed to find every problem, may make mistakes, and should be supplemented with human review. The same documentation recommends repository-level instructions and context to improve the usefulness of its comments.

A July 2026 study by Lin et al., “Is Agentic Code Review Helpful?”, examined 31,073 agentic review and developer-feedback pairs across 239 public repositories using CodeRabbit. Developers rejected 56.3% of the reviewed suggestions. The reported reasons included false positives, redundant or out-of-scope comments, and mismatch with developer intent or repository practices.

That result belongs to one product and an open-source dataset, so it should not be treated as a universal rejection rate for AI review. It does reinforce the narrower point: producing a plausible comment is not the same as earning a place in the team’s review process.

Review should follow the consequence

Not every AI-assisted output needs an investigation.

An early outline, a private summary, or an exploratory comparison may only need a quick check. Other artifacts create commitments or dependencies. A requirement shapes what a team builds. A customer summary can change a priority. An architecture proposal may constrain future changes.

The prose should not decide how deeply these artifacts are reviewed. The cost of being wrong is a better signal.

For consequential work, I would want at least four things to remain visible:

• the source material behind the output;

• the difference between assumptions and verified facts;

• the important exclusions and boundaries;

• the person responsible for approving the consequences.

This is why “human in the loop” often feels insufficient. A person can be present and still perform little more than a final glance.

What matters is whether that person has the context and authority required by the decision, and whether the review is designed to use them.

Contribution and review now separate more clearly

This extends the distinction I explored in AI accelerates contribution, not mastery.

AI makes it possible to retrieve context, form a proposal, and express it clearly much earlier. That is valuable.

It also means reviewers increasingly encounter work that looks mature before the contributor has built a complete mental model of the system.

A useful contribution, a well-presented artifact, and reasoning that deserves to be trusted often arrive in the same package. They are still different things.

Review has to preserve that distinction.

A less comfortable review

Clearer proposals, summaries, and plans can make collaboration much better. I do not think the answer is to distrust polished work or deliberately make it rough.

But a polished draft should still be allowed to feel unfinished where the evidence is incomplete or the decision remains uncertain.

That may mean exposing assumptions instead of smoothing them into prose. It may mean leaving a question open, asking for the source, or naming the person who has to accept the trade-off.

I am still working out how much structure is enough without turning every review into bureaucracy. Different work deserves different levels of scrutiny.

But I no longer want the finish of the output to make that decision for me.

We tend to describe these situations as missing information but often the information is there. It is simply not where the process expects to find it.

Once people stop trusting the official view, a private checklist usually appears somewhere: someone keeps a parallel document up to date or meetings are required to fill the remaining gaps. And the shared process becomes a little less reliable each time.

A newsletter by Luca Rossi, drawing on a conversation with Antonia Scheidel, separates information that already exists somewhere from information that still lives only in people’s heads. Rossi’s practical advice was to connect what is already recorded and ask people only for what is still in their heads.

I found that I needed one more category because systems now produce their own reading of the information they collect.

The due date may be a recorded fact. So calling the item urgent is something the system concluded.

When the alert is wrong but the data is right

I ran into this while building Friday, a small system that connects several services without owning their work and decides what may deserve my attention.

August stores my documents and review decisions. Friday reads them and chooses what to show me.

At one point Friday kept presenting a document as requiring action after I had rejected it in August.

The evidence was real. A failed review was associated with the document. Friday was treating that history as work I still intended to continue.

I considered adding a rule for rejected documents. It would have removed the alert, but every similar mistake would eventually need its own exception.

Instead, I added a general dismiss action for anything Friday surfaces.

Dismissing an alert does not touch the document or its review history in August: it simply records that I no longer find Friday’s interpretation useful.

I wanted Friday to remember the dismissal without gaining permission to rewrite the service it had read from. Otherwise I would either lose the review history or find myself filtering the same noise again tomorrow.

The architectural pattern Revert to Source follows a related principle. Information should remain attributable to where it originated. Friday adds a wrinkle because its signal has a lifecycle of its own.

Connecting existing facts can remove a lot of copying. Judgment is still needed when a system ranks work or raises an alert.

When Friday makes a suggestion I want to see enough of its reasoning to challenge it. And if the suggestion is wrong I need to correct the suggestion or the rule that produced it. The source should change only when the source itself is wrong.

Moving facts between tools is work I want to remove. Letting Friday’s interpretation quietly become another fact would create a different problem.

I now look at where each correction lands. Dismissing an item should make Friday quieter and leave August untouched. If the document changes too, Friday has crossed a boundary it was never meant to own.

When work is spread across different tools, I can usually find every open item myself. The expensive part is repeatedly scanning those systems, comparing their state, and deciding what deserves attention first.

An attention layer should take that first pass. It should collect the available signals, reduce them to a short list, and explain why those items appear now. The benefit is not discovering something I could never have found. It is letting me begin with the closest or most important decisions instead of reconstructing the whole landscape each time.

That makes omission part of the product. A system that shows everything has transferred information, but it has not reduced the work of deciding.

A shortlist is already a decision

Prioritization cannot be treated as neutral presentation.

Every slot given to one item makes another item less visible. A useful attention layer therefore needs an opinion about urgency, proximity, and consequence. It also needs limits. Otherwise weaker signals gradually fill the available space and the shortlist becomes another inbox.

Those choices must remain inspectable. For each item, I should be able to understand why it appeared, what may happen if I ignore it, and where the underlying state comes from.

I do not need the system to make the final decision. I need it to perform enough of the first reading that my judgment starts from a smaller, better-organized set of options.

The Morning Bridge as a test

Two private services currently feed Friday: March holds my publishing plan, while August holds documents and their review state.

Friday’s first live synchronization read 22 entities from March and 23 documents from August. The Morning Bridge showed four signals: two publishing-runway items and two documents with unresolved review work.

The reduction from 45 records to four signals proved that the adapters, links, and initial suppression rules worked. It did not prove that the ranking was right, but it created a small enough surface for me to evaluate it.

Friday shows no more than seven items on the Bridge. Seven is not a magic number. It simply makes it harder to fill the page with weaker signals.

Completed work belongs in the Timeline. Integration health belongs in status. A document assigned to a future month can remain quiet if nothing needs to happen yet. Empty space does not need to be filled.

Correct information can still be noise

Friday has already produced a useful negative example.

It surfaced a failed-review signal from August for a document I had demoted to source material. August really reported the failure, so the signal was not invented. But I no longer intended to advance that document.

I dismissed the item.

Friday remembered the dismissal without changing the document in August. The failed review still exists in the system that owns it; it simply no longer occupies my attention queue.

This matters because filtering stale data is not enough. Current, source-backed information can still be noise when it no longer relates to work I intend to continue. An attention layer needs a way to learn that distinction without rewriting the source.

The benefit I am looking for

I would probably notice the things Friday shows me anyway.

The useful change is that I no longer have to give every signal the same initial attention. Friday can examine the state across services, bring the nearer or more important items forward, and leave the rest where it belongs.

The quality of the Morning Bridge will depend on whether its priorities continue to make sense, its omissions remain recoverable, and its explanations are good enough to challenge. A quiet Bridge could mean that nothing needs me. It could also mean that Friday missed something.

Trust will have to come from comparing its shortlist with the source systems over time.

I do not need Friday to know something I could never know. I need it to make the first pass well enough that I can concentrate on what deserves me now.

The other half is deciding who owns each fact, which system is allowed to change it, and what should happen when the sources disagree.

A convenient shared view can become dangerous. A status may be current in one source and stale in another. A coordinating layer may infer a conclusion that neither source actually owns. If it can also write, ambiguity can quietly turn into an unauthorized decision.

Coordination therefore needs a narrow contract. The shared layer can compare state, explain disagreement, and propose where attention should go. The underlying facts remain with the systems that produced them, while uncertainty stays visible until something with the right authority resolves it.

This separation also leaves an escape route. If the coordinating layer disappears, the original work remains usable. If an integration fails, its last observation becomes suspect rather than becoming truth by default.

The goal is coordination without creating a shadow system that every other tool must eventually obey.

In this setup, Friday currently observes two private services I use for editorial work: March holds my publishing plan, while August holds documents and their review state. Friday applies explicit rules to surface what may deserve my attention.

It can centralize attention without becoming the canonical home for the document or the plan. Its view must be rebuildable, each source must remain independently usable, and ambiguity must not silently become permission to write.

The combined view is not the source

Suppose a note has a target month in March and an unresolved review in August. Friday can turn those facts into a signal: the publication window is approaching, but the document still needs attention.

The signal is Friday’s. The facts are not.

If the document changes, August remains authoritative. If the target month changes, March remains authoritative. Friday can rebuild its view from both sources instead of becoming the canonical home for either.

Different signals require different responses

Friday has started producing several kinds of signals from the same underlying services.

It can raise the priority of developing an article based on its position in the runway and the work still required. When the source state changes, Friday can reconsider that priority.

It can notice that an article has a place in March while its document is still a draft in August. This may be a normal stage of the work rather than an inconsistency, but it becomes relevant as the publication window approaches.

A document can also appear complete while still waiting for a decision about whether it is ready. Friday can surface that decision without making it for me.

These situations may look similar in a queue, but they do not authorize the same action. One requires development, another may only need monitoring, and another must stop at human judgment.

Sometimes the correct integration does nothing

One of the first live reconciliation cycles compared nine uniquely linked March–August records.

It changed nothing.

That was the correct result. The records were consistent, no publication window was open, and Friday had no authorized reason to touch either service.

The useful behavior was not writing. It was recognizing when no write was justified and leaving evidence of that decision.

When a signal does become work, Friday can prepare a bounded handoff for Codex. The work happens in the appropriate service or workspace; Friday retains the trigger and result.

Attention without lock-in

I can continue using March and August directly through their interfaces, or through AI clients such as Codex using their MCP tools. I can revise a document in August or change the runway in March without routing the action through Friday.

When the integrations are healthy, Friday observes those changes and refreshes its view. When one is not, the underlying source remains available and the stale observation can be treated as a problem rather than silently becoming truth.

This is the most practical test of the ownership boundary: coordination has not made the underlying services unsafe to use on their own.

The first real disagreement

While reviewing another note, I marked it ready in August. March still described the same note as drafting.

Friday had already observed August’s new editorial state, but its March integration was offline after a contract mismatch. It therefore continued to hold March’s last observed state and showed a high-priority readiness risk instead of presenting the two systems as synchronized.

From Friday alone, I could not tell whether the document still needed work or the planning state was stale. I opened August and confirmed that the document had the ready tag, no draft tag, and no unresolved review work. I then checked March and confirmed that its item had not changed.

That distinction determined the next step. The document did not need another editorial pass. The propagation between services needed attention. Friday had identified the condition, but it did not have enough current authority and evidence to repair it by inference.

This also exposed the maintenance cost I can already see. Independent services keep their responsibilities clear, but their interfaces and state mappings have to remain compatible. A changed contract can leave one observation current and another stale. The coordination layer must preserve that uncertainty, explain where each fact came from, and stop short of turning a partial view into an automatic write.

Integration without erasure

The practical test is simple: if Friday disappeared tomorrow, could I still understand and use the work in March and August?

So far, yes. The harder test is whether Friday can keep earning trust when the sources disagree, an integration fails, and doing nothing is no longer the whole answer.

Sometimes I drive it manually: I choose an issue, start the agent, follow the work, review the pull request, run manual or visual checks, and merge it.

Other work runs on a schedule at night. The agent can implement a prepared issue, respond to CI failures, and leave a pull request for me to review in the morning. I no longer need to be present while the code is being written.

Both modes use the same conventional boundaries. main is protected. Work starts from a descriptive issue, gets its own branch, and reaches the stable codebase through a pull request. CI runs the repository’s tests. AGENTS.md explains the project, commands, constraints, and stop conditions.

This already gives the agent substantial ability without giving it control over the stable state. But the workflow is still paced by transitions that I manage: deciding what may start, recognizing when a run is blocked, and preparing the next piece of work.

The next step I am preparing is automation at the repository level.

Autonomy depends on the decision

In this workflow, autonomy means allowing the system to advance from an approved issue to a reviewable result without my supervision. It does not mean delegating every decision.

The system may select eligible work, implement it, and verify the result. Whether that result may enter main remains a separate decision.

I want the system to continue through a small queue of approved work without requiring me to supervise every transition. An orchestrator should claim an eligible issue, create an isolated workspace, start the agent, track retries, and leave a legible result: ready for review, blocked, safe to retry, or waiting for a decision.

OpenAI’s Symphony specification uses an issue tracker as the control plane for a similar workflow. It combines isolated workspaces, bounded concurrency, explicit retries, and handoff states such as Human Review.

That model matters because unattended development is not the same as leaving an agent alone. A useful system must know what it may start, why it stopped, and when authority returns to a person.

Discovery should not become authorization

Implementation often reveals adjacent work: a missing test, a nearby bug, a useful refactoring, or a larger opportunity outside the issue.

I want agents to preserve those discoveries without expanding the current task or creating their own mandate.

An agent may create a linked issue containing the evidence, likely impact, risks, and possible acceptance criteria. That issue must remain mechanically ineligible for unattended execution until I approve it.

This separates discovery from commitment. It also limits the effect of mistakes, stale assumptions, or untrusted instructions inside issues and comments. Being present in the tracker cannot be enough to make work executable.

Instructions need executable support

AGENTS.md is useful because it places expectations close to the code, but prose is still interpreted.

A recurring review correction may first become a clearer instruction. If it is important and mechanically checkable, it should later become a lint, test, branch rule, smoke test, or inspectable preview.

OpenAI’s account of harness engineering describes this progression from written expectations toward structural tests and environments agents can inspect. GitHub rulesets provide another layer by requiring pull requests and status checks and restricting changes to protected branches.

Since publishing that Friday note, I have started extracting these rules into a private repository and integrating them into Friday. The repository is intended to make issue eligibility, scope, discovery, verification, escalation, and merge authority reusable across projects.

This is work in progress, not a proven system. The integration exists, but I have not yet tested the complete unattended cycle enough to treat the contract as settled.

The merge remains a separate experiment

For now, I review and merge every pull request.

I am curious about agentic merge, but I do not see it as the automatic destination of this work. Generating a change and authorizing it are different responsibilities. GitHub applies the same conservative boundary to its cloud coding agent, which cannot approve or merge its own pull requests.

I may experiment with automatic merge for narrow, mechanically recognizable changes with comprehensive checks, limited diffs, and straightforward rollback. Dependencies, permissions, workflows, data, infrastructure, and product behavior would remain outside that experiment.

The boundary should move because repeated evidence shows that a class of work is contained, not because models have become more capable in general.

Making judgment reusable

The most valuable result of a review may not be the merged code. It may be an improvement to the system that handles the next issue.

A repeated correction can become an instruction. An ignored instruction can become a test. A recurring manual check can become a preview or smoke test. A blocked run can reveal missing context or a missing stop condition.

My role does not disappear. It shifts toward approving intent, examining exceptions, judging product choices, and improving the environment in which agents work.

The next experiment is not to remove the human gate. It is to make everything before that gate more continuous, observable, and capable of stopping for the right reasons.

Then I built August and March.

Friday is my second attempt at the original ambition. It began when those two useful services created a new problem between them.

The problem was not asking

August knew the state of my documents and reviews. March knew the publishing plan.

Both exposed MCP tools, so I could ask an agent to inspect them together. Once I knew the question, active orchestration was already quite simple. Codex could collect the relevant context without making me copy information from one screen to another.

I was still responsible for noticing that there was a question to ask.

March could show an article in a publication slot while August still had an open thread on the draft. Neither service was wrong. They were answering different questions.

To understand what deserved attention, I still had to look at both, reconstruct the situation, and decide what mattered next.

That was the missing job.

I did not need another way to ask my tools for information. I needed a signal before the question: something that could notice a relevant change, explain why it mattered, and bring me to the right place.

That was my trigger to start building Friday.

The same ambition had a different starting point

Jarvis had started from the center. I imagined a general orchestration system and kept adding decisions, action items, context, and agents before any recurring work had earned that structure.

August and March developed in the opposite direction. Each began with work I was already doing and a problem I could recognize without explaining the future platform around it.

They also changed how I thought about the technical boundary.

Markdown had made the first direction especially tempting. AI agents eat Markdown for breakfast, and I am comfortable working with it too. But an artifact that an AI can read is not automatically a reliable operational contract.

August and March could now expose their state and supported operations without asking a consumer to interpret private folders. That mattered because I no longer had to begin by inventing every concept and owning every workflow.

The useful pieces already existed. The new question was whether something smaller could coordinate them.

This is what made the second attempt feel different. I was not rebuilding Jarvis because the original feature list had become more achievable. I was returning to the ambition because a concrete job had finally appeared.

One job before the platform

Friday begins with one question: what deserves my attention now?

That is intentionally smaller than “build my personal AI operating system.” It gives me something I can observe and disagree with. A signal can be useful, irrelevant, late, or simply wrong. Those outcomes are more informative than a long list of capabilities waiting for a reason to exist.

It also gives me a reason to resist the fun part.

Once several services can be queried by AI, it is easy to imagine connecting everything. The more useful constraint is to test one connection at a time, starting with August and March.

I do not know the answer yet.

The next experiment is about integration: can Friday connect services without owning their work?

After that comes attention: can the Morning Bridge be useful because of what it leaves out?

I have not earned either answer yet. For now, they are promises to test, not conclusions.

Jarvis started as a platform looking for its first job. Friday starts with a job and has to earn the platform around it.

For now, that is enough to keep building and tinkering.

Then I had a different problem.

I could see the state of one document, but not the shape of the work around it.

Which pieces were close to ready? Which ones still needed development? Was I putting effort into material for a distant month while an earlier part of the plan remained empty? Had an idea earned a place in the publishing sequence, or was I turning it into a commitment too early?

I wanted a clear view of the months ahead.

I did not want a content calendar telling me to feed the machine.

That tension became March.

A plan is not a promise

I want to publish with some continuity.

I also do not want my personal site to become a production target.

When I use a traditional content calendar, every visible date can start to feel like a commitment. Empty space begins to look like failure. A perfectly filled calendar can become a very tidy way to produce work I do not believe in.

March treats the plan differently.

It gives me a runway: a view of what may be published over the coming months and the state of each piece.

Something can be only an idea. It can be in development, ready, or already published. A planned month gives the work context without granting permission to publish it.

The distinction is simple, but it protects the quality of the work from the appearance of the plan.

The document and the plan have different jobs

August knows the document.

It contains the current text, the versions, the review, and the questions that still need an answer.

March knows where that work may fit.

A planned item can point back to its document in August, but the two services do not need to become the same application.

That keeps two questions separate:

• Is the document ready?

• Does it have a place in the publishing plan?

The answers do not always move together.

A document may be ready while its planned month is still far away. Another may occupy the next available slot while still requiring substantial work. An early idea may be valuable without deserving a publication commitment yet.

Seeing those differences helps me decide what deserves attention without asking either tool to make the editorial decision for me.

March is a dashboard, not the planner

March does not decide what I should publish.

It exposes the state of the runway clearly enough that I can plan with AI.

In fact, March exposes an interface for AI agents through MCP, a protocol that gives them access to specific tools and data exposed by the service. Today, I can ask ChatGPT, Claude, or another agent to inspect the months, available publishing slots, intentional gaps, planned pieces, and links back to August.

An agent can surface a gap, compare possible sequences, or propose moving an item earlier or later.

I make the planning decision.

I may know that two topics are too similar to publish close together. I may want to leave space for something that has not happened yet. A draft may need time even when moving it forward would make the runway look healthier.

March keeps the facts visible. I can use AI to question the arrangement and explore alternatives, but the priorities and final decision remain mine.

The shared state remains visible, so neither I nor the AI has to reconstruct the plan from memory. That does not make March self-maintaining: the plan remains useful only if decisions and changes return to it.

Changing the plan can begin as a conversation

Before March, changing direction meant mentally rebuilding the sequence or maintaining another document that would become stale.

Now an agent and I can inspect the same runway, discuss what changed, and arrive at a different arrangement. Once I decide, the agent can update March, and the next conversation starts from that new state.

The useful part is not that AI rearranges a calendar for me. It is that the planning conversation no longer disappears when the chat ends.

That matters because the plan should respond to the work.

An article may take longer than expected. A new idea may become more relevant. A planned piece may stop feeling worth publishing. Something ready may remain deliberately parked.

Changing the plan is part of keeping it honest.

Empty space is part of the game

An empty slot is not an instruction to create something quickly.

It tells me that a part of the future runway is thin. I may develop an existing idea, do more research, change the expected cadence, or leave the space empty.

A filled slot also carries information. It gives a piece a possible place and may bring it into focus before work planned further away.

March makes both states visible without deciding what happens next.

There is also a light game-like quality to it.

The months form a runway. Progress is visible. Moving a piece toward readiness feels satisfying, and watching the plan take shape makes me more likely to return to it.

I like that.

It can also become a trap. If I start creating articles because March looks hungry, I have rebuilt the content machine with a nicer dashboard.

Empty space has to remain a valid state. The game should make progress visible, not manufacture pressure to publish.

August helped me collaborate with AI on the work itself. March gives that work a possible place in the plan.

The test is whether I can still look at an empty month and leave it alone.

I needed a way to keep working on a document with AI without rebuilding the context in every conversation.

AI models were already useful. I could paste a draft into a conversation and ask for a different structure, a critical reading, a clearer paragraph, or questions I had not considered.

The frustrating part was everything around the answer.

I had to copy the document into the conversation, copy useful suggestions back into my editor, decide which changes I had already applied, and remember which questions were still unresolved. If I started another session, I had to reconstruct the state again.

The AI could help with the text. But we did not have a comfortable place to continue the work together.

The missing part was continuity

A document rarely improves in one pass.

One review may reveal a weak argument. Another may challenge an assumption. A suggestion can be useful without being correct. A question can remain open because I do not yet have the evidence or because I have not decided what I think.

A chat is good at producing the next response, but it is less good at showing the state of the collaboration around the document.

Which version are we discussing? Which suggestion did I accept? Which one did I reject? Is a question still open because I missed it, or because it genuinely needs more work?

I was spending too much time carrying those answers between the AI, the conversation, and the document.

That work was not intellectually difficult, but it was constant.

I started building a private, local workspace around that friction. I called it August.

I did not want the AI to write instead of me

The objective was never to put a document into a machine and receive a finished and polished version.

I wanted the AI to participate in the work without quietly becoming the author.

That means it can propose a rewrite, point out a contradiction, ask for evidence, or show me how a reader may interpret a passage.

But it is still me who decides what the document is trying to say.

I provide the experiences, opinions, constraints, and examples. I can reject a suggestion even when it sounds better. I can leave a question unresolved rather than accepting the most plausible answer the model can generate.

AI is very good at making a draft look complete. It can smooth over a missing argument or invent a convincing bridge between two ideas. The result may read better while representing my thinking less honestly.

A useful review may improve a paragraph. It may also leave an honest gap visible until I know what belongs there.

August became my review workspace

Document collaboration, comments, suggestions, and version history are established patterns. My professional experience around document products has also shaped how I think about review, permissions, and ownership.

August is not a claim to have invented those ideas. It is my private, local implementation of a narrower workflow: continuing document review with AI while keeping the state of the work and the final decisions under my control.

I built it around the way I wanted to work, and I keep improving it as that work changes.

The document remains easy to read and edit. Around it, August keeps the parts that are otherwise scattered across conversations and editors:

• versions of the document;

• comments attached to the relevant passage;

• proposed changes that I can accept or reject;

• questions that remain open;

• the current state of the review.

I do not need to explain the whole history every time. An agent can work from the current document and its visible review state. Its feedback returns to the same place instead of becoming another block of text I have to reconcile by hand.

I can inspect what changed and decide what to keep.

Review does not belong to one model

Once the review state lives with the document, I am not limited to the model or interface I happen to have open.

Because August is part of my private system, I added a dedicated MCP interface for the agents I use. MCP gives them access to a limited set of tools and data exposed by August.

Agents such as ChatGPT or Claude can read the current document and its review state, then return comments or proposed changes to the same workspace. I do not need to give them a pasted copy or reconstruct the previous session.

I also use specialized reviewer profiles that run locally. Each profile is a reusable set of review instructions, not a separate model.

Some are deliberately general: an editor looks at the writing, while a reader looks for the points where the argument becomes difficult to follow. Others use a more specific perspective, such as a developer, a founder, or my future self.

I do not treat these profiles as a panel that votes on the correct version. They are different ways to put pressure on the same draft. A developer may notice that an architectural claim is vague. A founder may question why the problem matters. My future self may ask whether the document will still make sense after the current implementation changes.

Their feedback still arrives as comments and suggestions. I can compare conflicting readings, accept a precise change, reject an elegant one, or leave the question open.

The useful part is not having more reviewers. More feedback also creates more filtering work. August helps when it keeps that work visible and lets different reviewers contribute without losing the document’s history or my responsibility for the result.

The first job was content I wanted to publish

The first job I gave August was deliberately narrow: documents and content I might publish as an article, a longer note, or something that had not found its final format yet.

The job already existed. I was writing, asking AI for feedback, and losing time moving the work between tools.

August did not need to invent a new habit. It made an existing one less fragmented.

This article went through the same process. Feedback from AI helped me recognize that the story needed a different center, while I remained in control of the rewrite.

The scope expanded after the job was clear

I now also use August to develop early ideas and support planning work.

A rough note may accumulate questions and research before becoming a PRD whose assumptions need pressure-testing, a strategy document with unclear trade-offs, or something that has not found its final form yet.

The format changes, but the job remains recognizable: a piece of thinking needs continuity, AI can help explore it, and I need to see what still requires my judgment.

August expanded because that pattern repeated, not because it started as the home for every kind of knowledge work.

Smaller was the important decision

Jarvis began with the shape of a large system and then looked for jobs to place inside it.

August did not invent a new kind of document review. It gave established review patterns a smaller job inside my own system: helping me continue a piece of thinking with AI instead of carrying its state through copy and paste.

That was the important difference from Jarvis. I had a specific job, a friction I could observe, and a way to tell whether my implementation was helping.

August can grow, and it already has. But each addition still has to answer the same question: does it help me continue a piece of thinking with AI without losing its state or my ownership of the result?

That question is the boundary Jarvis did not have: if an addition does not help me continue a real piece of work, it does not belong in August.

Not necessarily the voice, the holograms, or a system running an Iron Man suit—although that would still be so cool, and I still aim for it. What interested me most was having an intelligence that knew what I was working on, kept track of the moving pieces, and could help without needing the whole situation explained again every time.

The ambition came before the job

When AI agents started appearing everywhere, that old idea suddenly felt achievable.

My social feeds filled up with personal assistants, autonomous teams, and operating systems run by agents. Like many others, I was inspired, and probably a little greedy. I wanted the assistant, the agents, and the orchestration all at once.

So I started building my Jarvis as a general personal orchestration system.

The feature list kept growing because almost everything seemed to fit the idea. That was exciting for a while. It also made it difficult to tell what the system was actually for.

A system with no first job

Jarvis did have a center. I wanted it to be focused on decisions and action items.

What did I need to do? What was still undecided? What had already been decided?

Those seemed like sensible things for a personal system to remember. I had chosen the objects before I knew which recurring work they were supposed to support.

I wanted a system for decisions and action items, but I could not answer the practical question: decisions and action items for what? I assumed the context would not matter. It did.

In retrospect, those concepts could have been useful inside the workflows that eventually became August and March. Both deal with work that has a state, unresolved decisions, and clear next actions.

Putting them together inside Jarvis still did not give me a reason to use it for anything repeatedly. The system made sense on paper, but it was not helping me with work I was actually doing. So I left it.

I got further when I started from work already in front of me.

The useful turn was smaller

I wanted to maintain my personal site without turning it into a content machine—if you’re reading this, that’s where you are now. I wanted help developing and reviewing drafts while keeping my own judgment in the loop. I wanted different perspectives during review, control over changes, and the ability to decide what the next version should become.

I also wanted a simple view of the months ahead, so I could see whether I had enough material in progress and where my attention was needed.

That work led to smaller services with actual jobs.

August helps me develop and review notes while keeping unresolved questions visible. March gives me a view of what I may publish and what still needs attention, without deciding that something is ready.

This note is one example. It had a place in the plan while the draft was still being reviewed and revised.

Codex helps me move between these tools and the rest of my work. None of them decides what matters or publishes for me.

The intelligence is not one application

What I have now does not live in one application. August remembers the document and its review state. March remembers the plan. Models can work across both, and I still bring the ideas and make the decisions.

It is a more modest setup than the universal assistant I first imagined. I use it.

Maybe this is how Jarvis starts

I stopped trying to build Jarvis as the first product. I have not stopped wanting it.

Today, I have a few small services that help with work I genuinely care about, and an AI collaboration layer that helps me work across them.

I do not know whether these pieces will eventually become something I would call Jarvis. For now, I am keeping the parts I actually use. That is already more than I could say about the first version.

Sometimes people ask me what they should study before moving into Product Management.

There are definitely many resources on the topic.

Books. Frameworks. Discovery techniques. Roadmaps. Prioritization. Those are all useful. But looking back, I do not think those were the things that made the biggest difference in my own transition. The bigger shift happened earlier, inside the work I was already doing.

I started my career as a software engineer back when I worked at U-Hopper. Over time, I found myself spending more time talking to customers, coordinating work, helping my teammates understand problems, and discussing priorities. In part, I liked it, and in part, it was necessary.

The title changed later, but the transition had already started. I only understood that later.

Product thinking starts with different questions

The biggest change was not learning new tools. I was becoming interested in different parts of the work.

What changed was where my attention went.

Over time, I realized I wasn’t spending less time thinking about implementation. I was spending more time thinking about the decisions that happen before implementation begins.

What problem are we actually solving? Why now? What makes this worth doing? What happens if we decide to wait? What are we choosing not to do instead?

The implementation still mattered. I still enjoyed it. But I was becoming just as interested in the decisions that shaped what should be implemented in the first place.

Those questions slowly changed the way I looked at engineering work. Not because implementation became less interesting. But because understanding why a decision was being made became just as interesting as understanding how to implement it.

Communication becomes part of the job

Another thing that changed was communication. And I’m not talking about presentations or product updates.

As an engineer, I was used to explaining how something worked or why a certain implementation made sense. Over time, the communication became different. It was more about making sure people were looking at the same problem, with the same constraints in mind.

That meant collecting information, connecting discussions that were happening separately, and making trade-offs explicit before the team moved too far into the solution.

It was not communication around the work. It was part of the work itself.

Product judgment develops before product ownership

One misconception about Product Management is that judgment comes with the role. But I think the opposite is often true.

One of the best ways to build product judgment is simply by talking to people already making product decisions. Not to learn the answers. To understand how they think.

What mattered was not only asking better questions, but observing how experienced product people answered them.

How they separated real requirements from preferences. How they weighed customer urgency against long-term product direction. How they decided when a trade-off was acceptable, and when waiting was the better choice.

Those questions can be explored from almost any role.

Engineers, designers, customer success, support, and sales all encounter them every day.

The title simply gives someone more responsibility for answering them consistently.

The title often arrives last

Becoming a Product Manager didn’t feel like switching careers. It felt more like formalizing a way of thinking that had already been developing for years.

Looking back, I don’t think the change started when I got the title.

It started when I became as interested in why a decision was being made as in how the solution would eventually be built.

I have seen the same pattern in Product Managers I’ve worked with and respect.

They did not suddenly become curious when they got the role. The curiosity was already there.

AI is changing something important in how teams work with information. It is becoming easier to access context without knowing exactly where everything lives.

People can now ask questions that used to require manual investigation:

• what changed recently in a workflow

• which systems are involved in a problem

• what customers are saying about a feature

• what recently changed in a specific area

and get useful answers much faster than before.

That changes the cost of exploration. But it does not automatically change the quality of understanding.

Two people can have access to the same dashboards, the same customer feedback, and the same documents, and still walk away with very different interpretations of what matters.

One person sees a signal worth reshaping the roadmap around. Another sees temporary pressure that should not influence long-term direction.

The disagreement is no longer necessarily about access to information. It becomes a disagreement about interpretation.

More information is not always better context

This matters because easier access can also expand the conversation too much.

There is a difference between information relevant to the problem space and simply more information.

Additional perspectives and discussion points can feel useful because they expand the conversation.

But if they do not directly contribute to the original problem definition or the goal of the initiative, they can also become a distraction.

As more loosely related concerns enter the discussion, the problem space itself expands.

And once the problem space expands too much, finding a solution to the original problem becomes significantly harder.

This does not mean different perspectives should be ignored. But it does mean that not every signal should carry the same weight within a specific decision context.

Part of product work is maintaining clarity around the actual problem being solved, the constraints that matter, and the goal the team is optimizing for.

Otherwise discussions slowly drift from solving a specific problem to debating every adjacent concern that could possibly matter.

Better access does not remove disagreement

Better access to information improves discussions in many situations because important facts become easier to retrieve.

But many product discussions were never only about access to facts.

They were also about priorities, trade-offs, interpretation, risk tolerance, and deciding which parts of the context should carry the most weight.

When information was harder to access, missing context was an obvious explanation for disagreement. I wrote about this in most product disagreements come from missing information.

Now teams can have much richer context available and still disagree.

Not because someone is uninformed. But because understanding is not produced by access alone.

Understanding depends on how people connect signals, frame the problem, evaluate constraints, and judge consequences.

This is one reason why structured customer research matters so much.

It does not eliminate interpretation. But it reduces ambiguity and improves the quality of the discussion.

Retrieval becomes cheaper, prioritization becomes harder

There is another shift.

In many situations, agreeing on a possible solution becomes easier than agreeing on when the solution should actually be prioritized.

The proposal itself is often no longer the hardest part. The harder discussion becomes deciding what matters most, comparing competing priorities, evaluating opportunity cost, and understanding where this sits relative to every other request, escalation, opportunity, and strategic initiative already competing for attention.

This is also why AI-assisted contribution can create false confidence.

People can contribute much earlier because context becomes easier to query. But as I wrote in AI accelerates contribution, not mastery, contributing earlier is not the same as understanding the system more deeply.

Earlier contribution does not necessarily mean deeper understanding, stronger prioritization judgment, or shared interpretation of the trade-offs involved.

Better access to context helps.

But shared context is not shared understanding.

Traditionally, becoming productive in a new environment required time.

People needed to understand where information lived, how systems were structured, which teams owned what, and why certain decisions had been made in the past.

Before contributing meaningfully, they first needed to build a mental model of the system.

AI changes this dynamic significantly.

Today, it is possible to start exploring and contributing much earlier. Instead of manually navigating documentation, repositories, dashboards or internal tools, people can describe what they are trying to understand and do, and let AI help retrieve and connect the relevant information.

People no longer need to know exactly where information lives before starting the analysis.

In practice, this can compress weeks or months of ramp-up into days.

Accessing context becomes easier

There are topics and questions that can now be explored conversationally, and much faster than before.

• Which customers are most affected by this problem?

• What changed recently around this workflow?

• How is this feature actually being used?

• What systems and APIs are involved in this process?

As a result, contribution happens earlier.

People can investigate problems, analyze systems, propose solutions and sometimes even implement changes before fully understanding all the underlying details.

The difference compared to a few years ago is hard to ignore.

Contribution is not mastery

But contribution and mastery are not the same thing.

Mastery still requires understanding:

• system boundaries

• historical trade-offs

• operational constraints

• second-order effects

• why certain decisions exist in the first place

AI helps navigate complexity. It does not remove complexity itself.

The illusion of understanding

This new way of accessing information and addressing complexity creates an interesting tension.

Organizations may start expecting faster onboarding and earlier impact because meaningful contribution becomes visible much sooner.

But early contribution can also create the illusion of understanding.

Access to information becomes easier. Building accurate mental models remains difficult.

This is similar to what happens when temporary solutions become permanent. Lower friction makes action easier, but it does not remove the long-term consequences of acting on partial understanding.

A new distinction that matters

As AI reduces the friction of interacting with systems, distinguishing between being productive and deeply understanding the system may become increasingly important.

AI is making the gap between contribution and understanding much more visible than before.

Temporary solutions are often the right choice.

They usually emerge when speed becomes more important than completeness.

This can happen under business pressure, when a specific customer request needs to be addressed quickly. It can also happen when the product lacks certain capabilities, and a workaround is introduced instead of addressing the limitation directly. In other cases, it takes the form of quick integrations or shortcuts between systems, created to move forward without investing in a more robust solution.

Temporary solutions are also commonly used to test or validate ideas that are not yet proven. Building something quickly allows teams to gather feedback and understand whether a direction is worth pursuing.

And sometimes, they are simply necessary. Fixing a bug, resolving an incident, or unblocking a customer often requires acting quickly rather than perfectly. This often happens under pressure, when urgency is perceived before it is fully understood.

In all these situations, speed matters. And that is exactly why they are so easy to accept.

But what all these cases have in common is that they optimise for the short term.

And short-term optimisations often turn into long-term constraints.

When temporary becomes permanent

Problems start when temporary solutions are adopted.

If a prototype starts being used by customers, it becomes much harder to change or replace. What was meant to be a quick experiment turns into something people rely on.

And at that point, the cost of removing or reworking it increases significantly.

The same happens with quick fixes for urgent issues. A workaround that solves a problem in the short term can remain in place much longer than expected.

And once something is in production, it becomes part of the system.

The point of no return

There is usually a moment when a temporary solution becomes difficult to undo.

It might be when:

• Customers start depending on it.

• Other parts of the system integrate with it.

• Replacing it requires significantly more effort than keeping it.

After that point, the “temporary” nature of the solution is mostly theoretical.

The illusion of progress

Temporary solutions can create the impression that progress has been made.

The problem appears solved. The feature seems delivered.

But in reality, what has been built might not be designed to evolve, scale, or integrate properly with the rest of the product.

This is especially evident in areas like AI, where rapid experimentation is common, and customer expectations remain unclear. It is often difficult to understand how a solution will be used in practice, and early implementations can easily become something they were never meant to be.

A hidden trade-off

Choosing a temporary solution is always a trade-off.

It trades speed for future flexibility. It trades immediate relief for long-term complexity. This connects closely to how product decisions are mostly trade-offs.

In many cases, it is the right decision. But it should also be a conscious one.

What looks like a quick fix is often a decision that will shape the product for a long time.

Managing temporary solutions

Temporary solutions are therefore not the problem.

Their uncontrolled adoption is.

When building something temporary, it is important to:

• Limit its exposure.

• Be careful with its adoption.

• Make its limitations explicit and clear from the very beginning.

Otherwise, what started as a way to learn and fix quickly can turn into a constraint that slows down future work.

Closing

Temporary solutions become permanent when they are allowed to spread.

Once they are used, relied upon, and integrated, they are not temporary anymore.

They simply become part of the product, together with their limitations.

Urgency can come from different directions.

From customers, especially when a request is framed as a deal breaker. From sales or business pressure tied to specific opportunities. From leadership, where priorities shift quickly, and expectations follow.

And sometimes, it comes from the system itself, when something is broken or not working as expected.

Not all of these signals have the same weight, even if they often sound equally urgent.

The biggest mistake teams make is allowing stress and pressure to reach engineers before any real decision has been made.

When a request is framed as urgent, it creates immediate uncertainty. Should we stop what we are doing? Do we need to change priorities right away?

Focus is lost, and the discussion becomes driven by pressure instead of clarity.

This often happens when information is shared too early, or when stakeholders bypass product and engineering leadership and go directly to teams. When urgency comes from higher up, it immediately influences the conversation because few people are comfortable pushing back.

When urgency is not real

Some of the strongest urgency signals come from high-value customers.

A request is framed as a deal breaker and: if we don’t act, they will leave.

High-value customers raising urgent requests are not the problem. Their needs are often real and important.

The challenge is how those requests are interpreted and translated into product decisions.

To avoid creating pressure to react quickly, it is worth asking a few simple questions.

• Would this still feel urgent if it came from a different customer?

• How many other customers would benefit from it?

• Is this improving the product, or solving a single use case?

In those moments, what looks like an urgent request is often a trade-off decision in disguise. And in many cases, reacting quickly leads to building something very specific for one customer.

That is not a product improvement. That is closer to what consultants or integrators would build.

I have seen requests that looked urgent not being addressed simply because other priorities were more important. Months later, nothing happened. The customer was still there, and the request was no longer urgent.

Real urgency looks different

Real urgency usually comes from problems.

Something is broken. Something is slow. Something prevents customers from using the product.

When this happens, the impact is clear.

• Adoption is affected

• Key metrics move

• Multiple customers are impacted

And when addressed, the value is immediate.

Managing urgency

Not all urgent requests should be treated the same.

Some can be handled quickly using existing support or maintenance capacity.
Others require proper planning and should be scheduled like any other piece of work. In some cases, the right response is to wait rather than act immediately.

Urgency often compresses the time available to think and react. Decisions are made faster, but not necessarily better. And what is gained in speed is often lost in clarity.

When neither is possible, and plans need to change, the disruption should be explicit. The reason behind the decision should be clear and shared with the team. Alignment matters. Without it, there is a risk of losing focus, motivation, and trust.

The role of product and engineering leadership

Product managers and engineering managers are responsible not only for deciding what to do, but also for how and when information reaches the team.

Their role is to filter noise without hiding information.

It is not the same to say:

We might need to do this quickly.

and:

Here is a new request. Let’s understand if it is something we should address, and when.

The difference is subtle, but the impact on the team is significant.

Choosing not to react

Urgency often pushes teams to act immediately. But not acting is also a decision.

In many cases, waiting allows teams to validate whether a request is truly important. This connects closely to how product decisions are mostly trade-offs, and why waiting can sometimes be the most responsible choice.

Closing

Real urgency comes from clear problems that demand action.

Everything else should be treated as a decision, not as an emergency.

Product discussions often look like debates about the best solution. But in reality, they are usually debates about trade-offs.

Teams weigh different approaches, assess their implications, and select the most acceptable option given the constraints and circumstances. What seems like a debate over the best solution is often about which compromise the team is willing to accept.

The pressure for quick solutions

One of the most common trade-offs appears when dealing with urgent customer requests.

There’s usually a quick solution that meets urgent needs. The demand for speed is intense because customers want results immediately.

At the same time, it is worth questioning how urgent these requests really are. The sense of immediacy around customer needs can easily turn into unnecessary pressure on teams.

In many organisations, the perception of urgency also changes over time. There are periods when customer requests dominate the agenda, and teams feel constant pressure to respond quickly. At other times, attention shifts toward broader strategic initiatives or new technological trends. When this happens, requests that once seemed urgent can quickly move to the background.

Providing a quick solution can remove some of that pressure in the short term. But it comes with a cost.

The cost usually appears later, when the functionality needs to be maintained, extended, or generalised for other customers. Once something is released, customers start treating it as a stable capability of the product. Changing it later becomes much harder, especially if adoption has already started, regardless of any early adopter or beta labels.

Sometimes these shortcuts are acceptable. Sometimes they’re not.

As it always happens, transparency helps in those situations. If everyone understands that the solution is temporary and that additional work will be required later, the trade-off can be managed consciously.

In practice, however, these trade-offs are not always discussed explicitly.

Customers propose solutions

Customer requests rarely come as pure descriptions of a problem. They often come as and include a proposed solution as well.

This is natural. Customers understand their needs very well, but they usually have limited visibility into how a product is built internally.

Part of the work of product and engineering teams is to detach from the proposed solution and go back to the underlying problem. Only then can the team determine whether the suggested approach actually makes sense.

Accepting the customer’s proposed solution might still be the right choice. However, it should be a deliberate decision, made after considering the alternatives.

Different perspectives, different priorities

Trade-offs also exist because different roles evaluate success in different ways.

Engineers often focus on stability and long-term maintainability. Product teams often focus on time to market and delivering value quickly. Business and leadership perspectives add another dimension, focusing on revenue and the needs of the most important customers.

Each role optimises for a different outcome.

When these perspectives meet, disagreements are almost inevitable.

In many cases, these disagreements are not really about the right solution, but about which trade-off a team is willing to accept. I explored this dynamic more in a separate note on managing disagreements.

Strong teams recognise this and actively explore alternative solutions instead of assuming that a single perfect answer exists.

Choosing the trade-off

In my experience, it is rare to encounter a product problem with a single solution that everyone immediately agrees on.

Healthy teams understand that there are always multiple ways forward, none of them perfect. Instead of searching for the ideal solution, they try to understand the implications of each option and decide which compromise is acceptable.

Because, in product work, the real question is rarely about what the perfect solution is.

The real question is which trade-off are we willing to accept?

There was a lot of energy, very few formal processes and not many layers of leadership. Decisions were easy to make. Sometimes they were right, sometimes they were wrong, but they were fast.

If there was data supporting a decision, great. If there wasn’t, and there was still time to try something, the instinct was simple: just build it and see what happens. Discussion and alignment were not major constraints.

Things started to change when I moved to a larger and more structured organization.

Suddenly there were more stakeholders, more teams and more layers of leadership involved in product decisions. Each group had its own perspective, goals and priorities.

In that environment, alignment became much more important.

And disagreements became much more common.

When strategy is too broad

One of the most common sources of disagreement is the absence of a clear strategic direction.

Company strategy is supposed to guide product decisions. But sometimes strategy is written at such a high level that almost anything can fit into it.

I have often found myself looking for the right company-level initiative to attach a piece of work to. When that happens, it is usually a sign that the strategy is too broad.

If everything fits the strategy, then the strategy is not really helping teams make decisions.

In these situations it becomes much harder to reach agreement. Different teams can reasonably interpret the same strategic direction in completely different ways.

Missing customer signals

Another common source of missing information is the absence of strong customer signals.

Customer feedback and real requests should be among the most important inputs for product decisions, especially when combined with a clear strategy.

When those signals are missing, discussions tend to become more speculative.

Product managers and designers are often asked to gather more information: run discovery, talk with customers and try to validate assumptions.

This is where collaboration with customer success and support teams becomes extremely valuable. They often have the closest view of what customers are actually struggling with.

Talking with customers sounds simple, but in practice it can be difficult.

Customers are busy. Reaching them takes time. And sometimes they are focused on problems completely unrelated to the topic you want to discuss.

Interestingly, even the absence of interest can be a signal.

If customers consistently show no interest in discussing a problem, that might be an indicator that the problem is not as important as we initially thought.

When information is incomplete

When important information is missing, product discussions tend to change in nature.

Instead of data and signals guiding the conversation, personal perspectives start to carry more weight.

Ownership of a topic can influence how people interpret the same situation. Technical and non-technical stakeholders may evaluate risks differently. Also, leadership priorities and yearly goals can also shape how decisions are perceived.

In these situations disagreements often become louder, even if everyone involved is acting in good faith.

When information is incomplete, opinions become louder.

Moving forward despite uncertainty

Of course teams cannot wait for perfect information before making decisions.

Sometimes the only way to move forward is through discovery, customer conversations or small experiments that generate new signals.

In other situations the most responsible choice may simply be to wait and observe how the problem evolves.

Product work often happens under uncertainty. The challenge is not eliminating that uncertainty, but understanding when decisions are based on strong signals and when they are based mostly on assumptions.

Recognizing the difference can make product disagreements much easier to navigate.

Product teams often try to resolve uncertainty by pushing forward and building something quickly.

But sometimes the better option is to wait and observe how the situation evolves before committing to a solution.

I had ideas constantly. I wanted to create them, put them out there and see if they actually worked. I wanted to see something real come out of the work we were doing.

At the time I was working in a small company, building products from scratch. Everything was new. Everything felt possible.

Part of that energy came from excitement and the desire to contribute. But part of it was also something else: the fear that simple things might look incomplete to customers.

So the instinct was always the same. Add more. Build more. Improve more.

And often do it before anyone even asked for it.

Over time, and especially after moving to a larger and more structured product organization, I started seeing the other side of that mindset.

Building things that no one really needed.

The cost of building the wrong things

In most companies there is already a long list of things customers are asking for.

There are bugs to fix, improvements to make, features customers are waiting for. And there is never enough time to do all of them.

So why spend months building something no one is asking for?

In most companies, the real problem is not finding things to build.
It’s deciding what not to build.

This is partly a prioritization problem, but it is also a question of respect for the work that engineering teams put into building products.

Engineers should see the impact of what they build. They should see customers using it, benefiting from it, relying on it.

I have seen many teams invest months building large and complex solutions only to later discover that they were too expensive to maintain or simply not used.

Sometimes this happens because product research was not strong enough. But often the reason is simpler.

The world changes.

Requirements change. The domain evolves. Customer needs shift.

And if it takes a year to deliver something, the original assumptions may no longer hold by the time the solution is ready.

The smartest teams understand this and are willing to stop investing in something that no longer makes sense.

Less mature organizations often do the opposite. They stick to an outdated decision and keep investing simply because the decision was already made.

The most expensive product decisions are often the ones we refuse to revisit.

Why waiting is difficult

Despite this, waiting is one of the hardest decisions for product teams.

Technology hype plays a big role. When a new trend appears, everything suddenly feels urgent.

AI is a recent example. In some situations I have seen strong pressure from leadership to explore and plan initiatives that, based on research and customer signals, were not actually a priority.

Sometimes teams also struggle with waiting because they feel the need to show progress.

Building something feels like moving forward. But building something is not always progress. Sometimes it simply means investing time and energy in the wrong direction.

These situations often lead to strong discussions within product teams. Different people see the problem from different angles and the pressure to move forward quickly can amplify disagreements.

This is not unusual. In fact, much of product work is about helping teams navigate these disagreements and still find a way forward.

When waiting is the better decision

Waiting can be the smartest decision in several situations.

• When research and customer conversations show no clear demand for a certain feature.

• When there are other initiatives that are clearly more valuable.

• When the technological landscape is still evolving and there is no clear direction yet.

In these situations rushing into implementation can easily lead to wasted effort.

Waiting allows teams to observe how the landscape evolves, collect better signals and make a more informed decision later.

Waiting requires active attention

Waiting does not mean ignoring the problem.

Product managers still need to monitor signals: customer feedback, product metrics, changes in the market and the evolution of the technology itself.

If the situation changes, the decision should change as well.

Sometimes that means starting something new. Other times it means stopping something that is already in progress.

Stopping work can be painful. Teams invest time and energy in what they build, and shutting something down can feel frustrating.

But continuing to invest in something that no longer makes sense is usually far more damaging.

Clear communication and transparency help teams understand why decisions change and why the focus needs to shift.

For a company to succeed, people need to remain convinced that the work they are doing matters.

Sometimes the right decision is to do nothing

Product teams are often rewarded for shipping things.

But sometimes the most responsible product decision is simply to do nothing. Waiting gives teams time to learn, observe and understand what actually matters.

And in product work, understanding the problem is often more valuable than rushing to solve it.

In theory, prioritization should not be that complicated.

A company should have a strategy that gives direction to the work of product and engineering. When that direction is clear, many decisions become easier. Teams know what they are contributing to and why.

But this is not always the case.

Sometimes the strategy is unclear. Sometimes a new technology or trend suddenly shifts the conversation and everything starts feeling urgent.

When that happens, prioritization becomes harder than it should be. Discussions shift from purpose to opinion.

Internally, teams start questioning why certain initiatives matter more than others. Externally, customers and partners may feel that the product lacks a clear long-term direction.

Without strategy, prioritization often turns into debate instead of decision.

Implementation disagreements are about trade-offs

Disagreements about how something should be built are usually more complex.

From a technical perspective, many things are possible. The real question is how much time, effort and risk a certain approach introduces.

This is where many discussions actually happen. Should we build something quickly and iterate later? Or should we spend more time designing a more robust solution?

Speed often comes at the cost of stability, performance or security. Doing things more carefully often comes at the cost of time.

There is rarely a perfect answer. Most implementation decisions are simply trade-offs.

When data is missing

In many cases disagreements are not really about opinions. They are about missing information.

When good data exists, decisions tend to become clearer. Numbers help remove part of the subjectivity that often fuels debates.

But sometimes the data simply does not exist yet.

Maybe the product is new. Maybe customers have not used a feature yet. Maybe the team is exploring a new area where feedback is still limited.

In those situations there are usually two possible paths.

• One option is to build something small and quick to test an assumption.

• The other option is to wait.

Waiting is often underrated. If customers truly need something that does not exist, they will usually ask for it. That signal alone can be extremely valuable.

Experience and intuition still matter, of course. Looking at how other companies approach similar problems can also provide useful signals. But when information is limited, resisting the urge to overbuild is often a reasonable choice.

In situations like these, teams often feel pressure to move forward anyway and build something just to reduce the uncertainty.

But sometimes the more responsible decision is simply to wait and gather better signals before committing to a solution. I wrote more about this in another note on why waiting is often one of the most underrated product decisions.

Taking a stand without making it personal

One thing I’ve learned over time is that product managers need to take a stand.

If you are responsible for an area, you should have a point of view. That point of view should come after listening to engineers, designers and other stakeholders, but at some point you need to form your own opinion and be ready to defend it.

At the same time, it’s important not to become attached to that opinion.

The goal is not to win an argument. The goal is to build something meaningful and valuable.

For that to happen, disagreements must not become personal.

Assuming good intent from colleagues is essential. Most of the time people are trying to solve the same problem from different angles.

It also helps to remember that work relationships are still human relationships. Understanding the context other people are working in — the pressure they are under, the constraints they face — often makes discussions healthier and more productive.

Conclusion

In the end, product work is not just about deciding what to build. It is about helping teams move forward when smart people disagree.

However, Machine Learning is not for all! There are situations in which it cannot help. Not because it is not the right solution to use, but just because the right conditions for making it work properly are missing. So “When should Machine Learning be used”? The answer is simple and should never be forgotten: “Only when there is enough meaningful data available”.

The training of a Machine Learning model requires access to a big-enough amount of data — and unfortunately, this data is not always easy to get! When available, such data makes sure that the rules necessary for identifying a particular situation do not need to be defined and set by engineers or, more in general, by domain specialists. In fact, it is sufficient for data scientists to correctly set all the parameters of that extremely complicated mathematical formula that — luckily — no one needs to even know.

Yes, the data science work is definitely complex — Harvard is saying that the data scientist is the sexiest job of the 21st Century. But I am getting more and more convinced that the most difficult step to achieve when organising and carrying on a project is actually making sure that prospects and clients truly understand how important data availability is. Data that, let’s not give this for granted, should describe in details the use case we are trying to cover.

An example I often propose is the following: if we are trying to take advantage of Machine Learning for predicting possible malfunctions in a production plant, having a lot of data collected while the process is running smoothly is not going to help much. The model will definitely need data describing the malfunctioning cases — how else is it going to be able to identify and predict such cases?

This is the reason why there are situations in which Machine Learning could — and probably should — be used and others that definitely require the application of an alternative solution.

When not to apply Machine Learning

So here’s when a Machine Learning solution should not be applied:

1. There is no historical data available and it is not possible to collect any new information.

2. There is not enough data available: this should be decided taking into account the experience of data scientists — their gut feelings will most likely be correct.

3. Enough data is available but it is not describing the use case we are covering.

In all such cases, the accuracy offered by the trained model is not going to be acceptable. Actually, the proposed result is probably going to resemble a random choice — definitely not a good solution. The smartest choice would be to apply right away an alternative solution to Machine Learning. It is going to save not only time but also — and especially — money. Software engineers and domain experts should be able to easily come up with everything needed for setting up a rule engine that is going to work well enough.

When Machine Learning makes sense

On the contrary, if there is enough data describing in detail the use case we want to cover, we are in the perfect place to apply Machine Learning. Some patience is going to be required — we may call it also hammering — but, once ready, the solution is for sure going to automatise and greatly simplify everyday work.

Because, yes, the objective of Machine Learning is providing tools able to predict and anticipate issues while supporting decision making. So, if you have the chance, give it a try while remembering and taking into consideration the key importance that data is going to have on the end result.