Field notes by Hovhannes

A backlog is not a build plan

Mon, 08 Jun 2026 00:00:00 GMT

Most backlogs begin as a sensible place to avoid losing ideas. Then customer requests, bugs, experiments, technical debt, and half-formed features collect in the same list. The list gets longer, but the next decision does not get easier.

The backlog is inventory, not direction

A backlog answers “what might matter?” A build plan has to answer a harder question: “what are we willing to finish now, and what are we deliberately leaving untouched?” Treating those as the same thing creates three familiar problems.

The oldest item looks important because it has survived for months.
The most detailed item looks ready because someone already wrote acceptance criteria.
The loudest request jumps to the top even when it points away from the product’s main promise.

None of those signals proves that the work belongs in the next build. Age measures waiting. Detail measures preparation. Volume measures attention. A plan needs evidence of value, a clear dependency boundary, and enough capacity to complete the outcome.

Decision gate / Keep the idea inventory broad, but let only a few connected pieces enter the active plan.

If everything in the backlog is a candidate for this week, the backlog is quietly making the decision for you.

A build plan needs five explicit parts

1. One promised outcome 🎯

Name the change the user should be able to experience when the work is done. “Improve onboarding” is a theme. “A new user can reach a useful first result without help” is an outcome you can test — the same kind of promise a good MVP is built to protect.

2. Evidence for acting now 🔍

Use something stronger than general enthusiasm: repeated support friction, a broken completion path, an observed workaround, failed activation, or a risky assumption that blocks the next decision.

3. A dependency boundary 🧩

Write down which data, states, interfaces, emails, analytics, permissions, and operational steps the change touches. This is how a three-day card stops becoming an invisible three-week project.

4. Honest capacity ⏳

Plan with the time that remains after support, maintenance, interruptions, and review. Capacity is not the number of empty hours on a calendar. It is the amount of focused work the system can actually absorb.

5. A stop rule 🛑

Define what “done enough to learn” means before building. Otherwise polish keeps expanding until the next important question is delayed again.

Planning rule

Commit to an outcome and a boundary, not a pile of individually reasonable tickets.

The tickets are implementation detail. The complete result is the commitment.

Filter before you estimate

Estimation asks how long an item may take. Selection asks whether the item belongs in the active plan at all. I use the second question first.

Question	A strong answer sounds like
Which user outcome changes?	One observable result for one current user group.
Why now?	Fresh evidence, a blocked decision, or a current product risk.
What must ship together?	The smallest connected set that leaves no broken bridge.
What stays out?	Named adjacent work that is deliberately deferred.
How will we know?	A specific behavior, test, metric, or reviewed artifact.
What does this unlock?	The next product decision, not merely the next feature.

If an item has no strong “why now,” return it to inventory. If it cannot name what ships with it, map the dependencies. If it cannot name what stays out, the boundary is not ready.

Turn the outcome into one believable week

Imagine a founder building a product clarity tool. The backlog includes team workspaces, PDF export, templates, progress charts, a better empty state, and a guided first plan. The current evidence says new users understand the promise but freeze on the blank first screen.

A focused weekly plan

Outcome: a new user completes and understands a first plan without outside help.
Active work: one prefilled example, a shorter input path, clear review states, and completion analytics.
Outside the boundary: team roles, export customization, template browsing, and dashboard charts.
Acceptance evidence: five observed first runs and a reviewed event trail from start to completion.

The deferred ideas may still be valuable. They simply do not answer the current question. Keeping them outside the plan protects enough time to finish the complete first-use loop and watch what users actually do.

Believable capacity / Evidence, selected work, and available attention must converge on the same outcome.

Keep the backlog and the plan as two artifacts

The simplest fix is not a better status column. It is separating possibility from commitment.

Let the backlog stay broad.Store ideas, requests, risks, observations, and open questions without pretending they are scheduled.
Keep the active plan small.Include only work tied to the current outcome, boundary, and acceptance evidence.
Move evidence with the idea.When an item leaves the backlog, bring its source, assumptions, and dependencies into the plan.
Return unfinished ideas honestly.If the outcome changes, put unrelated work back into inventory instead of carrying it forward by inertia.
Review the decision weekly.Ask whether the evidence is still fresh and whether the active work still forms one complete result.

A backlog is useful because it remembers. A plan is useful because it excludes. Product progress gets clearer when each artifact is allowed to do its own job.

When an AI agent should stop and ask

Sat, 18 Apr 2026 00:00:00 GMT

An agent that asks about every detail is exhausting. An agent that never asks is dangerous. The goal is not more or less autonomy. It is a visible boundary between implementation choices and product decisions.

“Use your best judgement” is not a boundary

That instruction sounds empowering, but it gives the agent no way to distinguish a reversible code choice from a decision about billing, permissions, or user data.

The model may be capable of proposing an answer. That does not mean it has the authority or missing context to choose it.

Imagine a request to hide cancelled subscriptions from the dashboard. The interface change is easy. Whether those records should disappear from invoices, exports, support tools, and retention reports is a product and compliance decision. A confident implementation cannot replace that missing authority.

Confidence is not evidence that the decision belongs to the agent.

Divide the work into three zones

01
Continue. ▶️
Local, reversible implementation choices that follow an existing pattern and contract.
02
Verify. 🔍
Choices that can be resolved by checking the schema, tests, documentation, or current interface.
03
Ask. 🛑
Choices that change product meaning, public behaviour, security, cost, or irreversible state.

This keeps the agent moving through ordinary work while protecting the moments where guessing is expensive.

The zones should be written in terms of consequences, not file types. Editing CSS may still require an answer if the change hides a legal disclosure. Updating a database can be safe when it is a reversible local fixture. Risk comes from what the action means, not where the code lives.

Five signals that should stop the build

Decision zones / Keep ordinary implementation moving, verify discoverable facts, and stop where authority changes.

The public contract is unclear.The change affects an API, integration, URL, or behaviour other people may rely on.
The action is hard to reverse.Data deletion, migrations, access changes, and external writes need explicit direction.
Two sources disagree.Code, docs, tests, and product language do not describe the same behaviour.
Security changes meaning.The task alters who can see, create, edit, or delete something.
The user outcome is ambiguous.Several implementations are valid, but each creates a different product.

One signal is enough to pause the affected branch, not necessarily the whole task. The agent can still finish safe discovery, identify the exact contract, run read-only checks, and leave the repository in a clean state. A good stop preserves momentum without crossing the boundary.

A good escalation brings the decision closer

“What should I do?” gives the whole problem back to the human. A useful escalation explains the discovery, the options, and the consequence of each.

Useful escalation / Bring the evidence, realistic options, and a safe checkpoint to the human decision.

DiscoveryWhat did the agent find that was not covered by the task?

ImpactWhich contracts, users, or data could be affected?

OptionsWhich two or three realistic paths are available?

RecommendationWhich path best fits the current evidence, and why?

Safe stateWhat has been completed without crossing the decision boundary?

A concrete question is easier to answer: “The API stores \`draft\`, while the interface now says \`exploring\`. I can change only the label with no migration, or rename the stored value and update exports. The first option preserves every public contract. Should I keep the stored value?”

That question exposes the real choice, offers a recommendation, and gives the human enough information to answer without reopening the whole investigation.

Make the answer easy to resume from

After the human chooses, the decision should become durable context. Record it in the relevant document, test, contract, or build log before implementation continues.

Otherwise the next agent will reach the same fork with the same missing information.

A useful checkpoint records four things: the decision, the evidence behind it, the parts of the system it affects, and the next safe action. It should also name what was deliberately left unchanged. That prevents a narrow approval from being interpreted as permission to redesign the surrounding product.

When work resumes, the agent should restate the chosen boundary, recheck any state that may have changed, and continue from the saved checkpoint. The pause is complete only when the implementation and its acceptance evidence agree with the human decision.

Checkpoint rule

A resolved escalation is not finished until the product has a place where that decision can be found again.

What my dog taught me about building consistently

Thu, 02 Apr 2026 00:00:00 GMT

When you work alone, there is no team rhythm to borrow. No stand-up starts the day. No colleague tells you that a decision has been open for too long. It is easy to alternate between overworking and losing the thread completely.

The hard part is returning to the work

I used to think consistency meant producing the same amount every day. That is impossible when one day is product strategy, the next is debugging, and the next disappears into customer calls.

The useful definition is simpler: can I return to the work without spending half the day reconstructing what I was doing?

That changes what a routine is for. It does not have to guarantee a perfect output. It only has to make starting familiar and leave enough context that tomorrow’s version of me can enter the work without a long negotiation.

I keep the anchor stable and let the effort vary. The same desk, the same short planning note, and roughly the same stopping boundary can support a long build session or twenty careful minutes. The repeatable part is the return, not the volume.

A good routine protects the return, not the streak.

The walk creates a clean break

My husky does not care whether the deployment worked. At roughly the same time, we go outside. 🐕 That boundary stops me from dragging one frustrating task through the rest of the day.

Walking also changes the kind of thinking available. I stop staring at the implementation and start noticing the decision underneath it. Quite often, the problem is not the code I was fighting. It is a product choice I had not made clearly.

The walk works because it is ordinary. I do not need to earn it by finishing the task, and I do not treat it as another optimization technique. It is simply a reliable change of context. That is often enough for the noise of the last hour to settle.

Reliable boundary / The daily walk changes the context even when the work refuses to cooperate.

A small loop keeps the day honest

Before I begin, I choose an outcome small enough to recognise when it is complete. “Work on onboarding” invites endless motion. “A new user can save the first decision and recover from an invalid input” gives the day a finish line.

Easy restart / Finish with one clear outcome, one open decision, and a visible first move for tomorrow.

01
Name one outcome. 🎯
Write the one thing that should be more true by the end of the work block.
02
Work until the next decision. ✂️
Do not invent extra scope just because there is time left.
03
Leave a restart note. 📝
Record what changed, what is open, and the first useful action for tomorrow.
04
Step away properly. 🚶
A real break makes returning easier than half-working all evening.

The restart note is the smallest part and the most valuable. I write the current state, the unresolved question, and the first action that would produce evidence. That note removes the need to trust memory after sleep, interruptions, or an unexpectedly busy morning.

Reduce the scope, keep the connection

Some days will not support deep work. On those days I shrink the loop instead of pretending I can force a perfect session.

Review one open decision.Clarity still moves the product forward even when code does not.
Fix one small source of friction.A better name, note, or test can make tomorrow easier.
Write down the blockage.An explicit obstacle is less expensive than a vague feeling of being stuck.

The point is not to protect a productivity score. It is to keep a live connection with the product.

On a bad day, the minimum version may be reading yesterday’s note and making one decision explicit. That still reduces the cost of tomorrow. Consistency becomes resilient when the routine has a smaller mode instead of an all-or-nothing rule.

The five questions I use each week

ProgressWhat became clearer or more useful this week?

DragWhich task kept returning without a decision?

EvidenceWhat did a real user, test, or build teach me?

ScopeWhat can leave the plan without hurting the main outcome?

RestartWhat is the first meaningful move for Monday?

This is not a complicated operating system. That is why it survives busy weeks. Focus, build, leave a clear trail, and come back.

I end the review by removing one obligation that no longer serves the main outcome. A useful weekly reset should create space, not turn unfinished work into a larger pile of guilt.

See what breaks before you build

Tue, 10 Mar 2026 00:00:00 GMT

“Add an archive button to projects” sounds contained. One button, one field, done. Then archived projects keep appearing in search, count toward billing limits, trigger reminders, and leak into exports. The small ticket was never really small.

The gap between a clear task and a clear product

An AI coding agent can inspect code, follow instructions, and run tests. What it cannot inspect is a decision that only exists in your head. If the prompt describes the new UI and nothing around it, the agent has to fill in the gaps.

That is how a change becomes locally correct and wrong everywhere else. The button renders. The endpoint returns 200. The test passes. “Recent work” still shows archived projects.

An agent can only protect the product decisions it can see.

OpenAI and Anthropic both make the same practical point in their guidance: a capable model is not enough. Agents need clear instructions, the right tools, boundaries, and a way to check the result. Speed does not replace product knowledge. It makes missing knowledge more expensive.

Give the agent the context that changes the answer

01
User outcome 🎯
Who needs the change, what situation triggers it, and what should become easier or possible?
02
State transition 🔄
What state exists before the action, what state exists after it, and can the action be reversed?
03
Source of truth 📍
Which model, service, document, or API owns the meaning of this concept?
04
Dependency map 🕸️
Which contracts, consumers, flows, permissions, and operational processes rely on the current behavior?
05
Invariants and guardrails 🛡️
Which conditions must remain true, including security, privacy, billing, and data-integrity rules?
06
Acceptance evidence ✅
Which observable scenarios prove the user outcome works and adjacent behavior remains intact?

This does not need to become a giant specification. A short brief that names the real contracts is more useful than five pages describing how the screen should look.

A small change can create a large failure cascade

Suppose you ask an agent to rename the plan status “Draft” to “Exploring.” A text replacement is obviously risky, but even a careful enum migration may be too much.

Failure cascade / One local change can ripple through every contract that depends on its meaning.

Product languageLabels, help text, onboarding

Data contractEnum, validation, migration

BehaviorFilters, permissions, automation

ConsumersAPI, analytics, exports, emails

The safest answer might be to change the label and keep the stored value. Or the change might require a migration and a versioned API. Code search cannot choose between those options because the answer depends on product intent.

Search the whole repository, yes, but remember what it cannot show: customer expectations, support routines, analytics definitions, integrations, and promises already made in public.

Run a dependency review before implementation

The review has to be short enough that you will actually do it. This is the version I use:

Boundary review / Inspect the connected layers and preserve a safe pause before implementation begins.

1. Write the change as a state transition.
Describe what becomes true after the change, not only which component will be edited.
2. Inventory the touchpoints.
Map schema, API, application state, UI, authentication, analytics, notifications, documentation, and external consumers.
3. Trace contracts in both directions.
Identify what the changed element depends on and what depends on it.
4. Mark risk and reversibility.
Separate read-only from write actions, local from public contracts, and reversible from destructive transitions.
5. Define synchronized changes.
List the files, services, types, migrations, tests, and communication that must land together.
6. Trace failure boundaries.
Cover the main path, permissions, partial failure, stale data, retries, cancellation, and rollback.

Stop condition

Pause when the agent finds an undocumented public contract, an irreversible migration, or a security decision that was never agreed.

A compact product-context packet for an AI agent

Before handing over a change that touches several parts of the product, fill in this small packet. It is deliberately shorter than a requirements document and more useful than a bare ticket.

OutcomeWhat user progress should this change create?

Current behaviorWhat happens now, including known constraints and workarounds?

Target transitionWhat changes, for whom, and under which conditions?

Non-goalsWhich nearby capabilities are deliberately outside scope?

Source of truthWhere is the concept defined and who owns each contract?

DependenciesSchema → API → state → UI → auth → analytics → communication.

InvariantsWhat must remain true for security, data integrity, billing, and trust?

Acceptance scenariosWhich user-visible examples prove the change and its boundaries?

Escalation rulesWhich discoveries require a pause instead of an assumption?

Link to real schemas, interfaces, and source files when you can. Give the agent evidence it can check. Do not copy implementation details into the brief when the code already says them better.

Redefine “done” for agentic development

A pull request is not done because the requested component exists. It is done when the user action, stored state, permissions, and visible result all agree.

The user outcome works.The primary scenario is verified in the real interface, not inferred from code.
Every contract agrees.Schema, API, types, state, UI, and documentation use the same meaning.
Permissions are enforced server-side.Hidden controls are not treated as authorization.
Failure is designed.Partial success, retries, cancellation, and recovery have explicit behavior.
Adjacent flows remain correct.Regression checks cover the consumers identified in the dependency review.
Unknowns are visible.Assumptions, manual operations, and deferred risks are documented for the next decision.

AI agents let us make more changes in less time. That only helps if those changes keep moving the same product forward. The real advantage is not more code. It is a product model clear enough to keep fast work pointed in one direction.

Primary sources behind this note

Build logs beat perfect roadmaps

Fri, 06 Mar 2026 00:00:00 GMT

Roadmaps are useful until they become theatre. A tidy sequence can make uncertain work look settled, so we keep polishing the sequence instead of updating it with what the build is teaching us.

The roadmap forgets how a decision was made

A card moves from “planned” to “done,” but the useful context disappears: the assumption that failed, the shortcut that became permanent, the user reaction that changed the scope.

Three weeks later, you see the final decision without the path that produced it. That makes old ideas look newly attractive and settled questions easy to reopen.

A polished roadmap also compresses uncertainty. Two items can look equally settled even when one is backed by user evidence and the other is still a founder’s guess. A build log preserves that difference, so the next decision starts from the evidence you actually have.

The roadmap says where you want to go. The log explains why the route changed.

Log decisions, not activity

A useful build log is not a diary of every commit. It captures the pieces of work that should influence the next product decision.

Decision trail / Capture the change, the evidence, and the open question while the work is still fresh.

What changed?Name the user-visible or system-level difference, not the files edited.
Why now?Link the change to a problem, risk, or piece of evidence.
What surprised you?Record the assumption that did not survive contact with the build.
What remains open?Leave the next decision visible instead of burying it in a task list.

The distinction between an event and a decision matters. “Deployed search” is an event. “Kept exact matching because fuzzy results hid the user’s own project names” is context that can guide the next iteration.

The five-minute build-log template

Shipped 🚀What can a user or the system do now that it could not do before?

Decision ✅Which choice did this work settle?

Evidence 🔍Which test, conversation, or observation supports that choice?

Debt ⚠️Which shortcut or limitation must remain visible?

Next ➡️What is the next useful decision, not merely the next task?

If an entry takes more than five minutes, the format is probably asking for too much. The log has to survive the busiest week.

For example, a useful entry might say that onboarding now accepts an imported brief, that three test files exposed inconsistent headings, and that automatic cleanup was deliberately postponed. That is enough to explain the current state without recreating the entire work session.

Let the log edit the roadmap

Once a week, I compare the last few entries with the plan. This is where the roadmap earns the right to change.

Weekly review / Let repeated evidence reshape the plan instead of protecting an outdated sequence.

Remove work whose assumption failed.
Do not preserve scope just because it once looked sensible.
Promote repeated friction.
A problem that appears in several entries deserves attention.
Expose permanent shortcuts.
Manual work is fine until everyone silently assumes it is automated.
Rewrite the next milestone.
Use what you now know, not what the old roadmap predicted.

I also look for repetition. One awkward workaround may be acceptable. The same workaround appearing in four entries is evidence that the product is asking for a real solution. Frequency turns isolated frustration into a prioritisation signal.

A build log gives AI agents a better past

Code tells an agent what exists. A roadmap tells it what might exist. The build log explains why the current product ended up this way.

That context is especially useful when a new task appears to contradict an earlier choice. The agent can surface the conflict instead of confidently undoing a decision it could not see.

The log should still be selective. Give the agent entries connected to the current contract, plus the newest decision that supersedes them. A complete archive without relevance creates a different problem: more context, less signal.

Useful handoff

Give the agent the relevant log entries, current contracts, and the decision it is allowed to make. Keep the rest out.

MVP first: what actually deserves to ship

Mon, 23 Feb 2026 00:00:00 GMT

“Minimum viable product” often gets interpreted as a preview of the full roadmap. A little onboarding, a little dashboard, a little automation. The result has plenty of surface area but no moment where the user can say, “That solved it.”

Start with the smallest complete loop

A useful MVP takes one specific person from a problem they recognise to a result they care about. The path can be narrow. You can handle some work manually. The interface can offer very few choices. The important part is that the loop closes.

Complete loop / A narrow path can still take the user from a real problem to a visible result.

MVP definition

The smallest product that delivers the core outcome and gives you real evidence about the next decision.

Both halves matter. The user needs value now, and the founder needs to learn from what happens. A prototype can test whether an idea makes sense. An MVP has to work for someone who does not care that you call it an experiment. Y Combinator makes the same practical point: customers experience an MVP as a product.

Read Y Combinator’s Practical Design: MVP

The four layers of a complete MVP

1. A precise promise 🎯

Name the person, the situation, and the progress they should make. “Plan a product” leaves too much room. “Turn a scattered idea into a first build plan” gives you something you can protect.

2. A clear trigger ⚡

Why would someone open the product today? Maybe the roadmap is blank, an AI handoff failed, or the MVP keeps growing. Without a real starting moment, onboarding becomes a tour of features nobody asked to see.

3. One core action sequence 🔁

Keep only the steps that collect essential context, make a real decision, or produce the result. Remove a step and check what changes. If the answer is “not much,” it does not belong in the core path.

4. An observable result 👁️

The user should be able to point to what changed. A saved document is not automatically an outcome. A build plan that makes tomorrow’s decision easier is.

The complete loop

Trigger → “I do not know what belongs in v1.”

Core action → Clarify audience, problem, value, and dependencies.

Result → A coherent plan the founder can review and build from.

Decide what ships with evidence, not anxiety

Cutting a feature can feel like lowering the ambition. It is usually the opposite: you are choosing which promise to take seriously first.

Ship now when absence…	Move later when the feature…
Breaks the core outcome	Adds convenience after the outcome
Prevents a key assumption from being tested	Optimizes behavior that is not yet proven
Creates unacceptable trust or safety risk	Automates a manageable manual step
Makes the primary path impossible to understand	Serves a secondary persona or rare path
Blocks the founder from observing useful evidence	Improves scale before demand exists

“Later” needs a trigger, not a hopeful date. Add collaboration when active users keep sharing exported plans. Automate recommendations when manual reviews start repeating the same pattern. Build templates when setup time is clearly the thing holding people back.

Minimum does not mean careless

Small scope is not permission to be careless. The MVP can do one thing, but that one thing still has to feel safe and dependable.

Quality floor / Small scope still needs a dependable base for trust, access, and recovery.

Protect user data.Authentication, authorization, backups, and deletion rules are not decorative polish.
Handle the main failure states.Empty, loading, invalid, interrupted, and retry states belong to the core path.
Make the promise understandable.Users should know what will happen before they commit time or data.
Meet the accessibility baseline.Keyboard access, focus, labels, contrast, and responsive layout are part of product quality.
Observe the loop.Capture where users start, hesitate, complete, abandon, and ask for help.

A good shortcut saves implementation work without quietly making the user pay for it. A manual review can be smart. Losing someone’s work because saving was postponed is not.

Applying the model to Product Clarity

I have a long list for Product Clarity: research synthesis, different planning views, collaboration, agents, analytics, integrations, and impact analysis. Shipping a weak version of each would only delay the useful part.

The first complete outcome is much narrower:

01
Capture the product context.
Audience, problem, desired outcome, constraints, and current assumptions.
02
Shape the smallest valuable release.
Separate the core path from convenience, scale, and speculative scope.
03
Connect the plan.
Map features, pages, flows, data, and dependencies into one understandable system.
04
Make the next decision visible.
Show what to build, what to cut, and what will be affected by change.

If a founder completes that loop and makes a better build decision, the MVP has done its job. The next feature should fix friction I can see inside that loop, not a future problem I have invented.

A 60-minute MVP scope session

10 minutes: Write the promise.
For one user, in one situation, define one meaningful outcome.
15 minutes: Draw the happy path.
Start at the trigger and stop when the user can see the result.
10 minutes: Mark the quality floor.
Add the trust, safety, failure, and accessibility requirements the path needs.
15 minutes: Remove or defer.
Challenge every remaining item with the ship-now/later test.
10 minutes: Define evidence.
Decide what completion, failure, confusion, and repeated demand will look like.

Finish with one sentence you are willing to defend: “This release works when this user reaches this outcome, and we learn this.” If you need several audiences and outcomes to complete the sentence, the scope is still doing too much.

Why more features create less clarity

Tue, 10 Feb 2026 00:00:00 GMT

Adding a feature feels productive because the roadmap gets fuller. Then the homepage needs another sentence, onboarding needs another branch, and the product takes longer to explain. That is usually the first sign that the scope has stopped serving the idea.

The real problem is not “too many features”

Size is not the real problem. A large product can feel obvious when its parts work toward the same result. A tiny product can feel scattered when each feature points in a different direction. I use three questions to tell the difference:

Who is this product for right now?
What meaningful progress can that person make with it?
Why does each part need to exist for that progress to happen?

If those answers are fuzzy, roadmap debates turn into taste. Every suggestion sounds reasonable, so nothing has a clear reason to be first.

A feature earns its place when it makes the main promise easier to keep for the person you are building for now.

Every feature creates work outside the screen

1. The decision surface 🧭

Before anyone writes code, you still need to decide where the feature lives, who gets it, what the default should be, and what happens when the user changes their mind. The card on the roadmap hides all of that.

2. The dependency surface 🕸️

Features rarely stay in one component. Add team workspaces and you have also changed permissions, billing, invitations, ownership, deletion, and support. The visible part may be a button. The actual change is a web.

3. The communication surface 💬

Someone has to explain the feature on the website, reveal it at the right moment in the interface, and answer questions when it behaves unexpectedly. If you cannot say why it exists in one plain sentence, users will feel that confusion too.

Hidden surface area / Every new feature adds decisions, dependencies, and communication beyond its visible screen.

Working model

More scope × more connections = more ways to get the product wrong.

Not a formula, just a useful warning: the eighth feature usually carries more baggage than the first.

Use a feature filter before a priority score

A score can rank ideas, but it cannot tell you whether they belong in the same product. I filter for fit first and worry about priority second.

Question	Evidence to look for
Which user problem does it solve?	A repeated, specific obstacle, not a broad desire.
Which outcome does it improve?	A visible change in speed, confidence, quality, or completion.
At what moment is it needed?	A defined step in the core user journey.
What breaks if it is absent?	The core promise fails, or a key assumption cannot be tested.
What does it depend on?	Known data, states, permissions, flows, and operational work.
What can it replace?	An existing step, workaround, or lower-value feature.

Vague answers mean the feature is not ready. Keep the problem, drop the proposed solution for now, and look for better evidence. A neat roadmap card is not evidence.

A practical example: the “complete” onboarding

Imagine a solo founder building a planning tool. Before launch, onboarding grows to include Google sign-in, invites, templates, a tour, profile settings, sample projects, and a progress dashboard.

None of those ideas is silly. Together they distract from the only question worth answering first: can someone turn a rough product idea into a plan they would actually use?

Protect the complete loop

Describe the audience and the problem.
Choose the smallest valuable outcome.
Generate a connected first plan.
Review what to build, cut, or clarify next.

If that loop works with email login and a blank page, the product already has a reason to exist. Templates can make it faster later. Teams can open a new market later. Neither should postpone the first honest test.

Cut scope without losing the product

Bad scope cuts whatever looks easiest until the deadline fits. Good scope keeps the user’s outcome intact and finds a simpler way to deliver it.

Protected outcome / Keep one complete path active and move unrelated scope outside the first release.

Cut breadth before continuity.Serve one user and one main path completely instead of many users partially.
Keep the problem; release the solution.Record the evidence behind an idea so a rejected implementation does not erase a real need.
Prefer reversible decisions.Manual operations and simple defaults are often safer than premature automation.
Name the cost of “later.”Deferred work needs a trigger for reconsideration, not an imaginary date.
Review connections, not only cards.A small-looking feature with five dependencies may be the largest item on the board.

The goal is not to stay small forever. It is to build something whose parts make sense together. Once the main promise is clear, the product starts telling you which feature should come next.