"Is This Technically Possible?" Is a Question That Should Take Minutes, Not a Week.

Tuesday, 2pm: a PM Slacks the engineering channel — "Can we add bulk export for enterprise customers?" Thursday morning, planning starts without an answer. Friday they get one: "It's possible but complex." Monday planning they try again, still without enough detail to scope it. Six days after the question, the PM has what they needed to write a ticket.

This is not a communication failure. The engineer answered as soon as they had time. The PM asked clearly. The delay was structural: answering the question required rebuilding system context from scratch, and the engineer had three other things in progress. The question had to wait its turn.

Feasibility questions are not expensive because they are hard. They are expensive because every single one requires an engineer to stop what they are doing, rebuild the relevant system context in their head, investigate the answer, and then translate it into something a non-technical PM can plan with. That process takes an hour of engineering time and three to five days of calendar time — for a question that often has a knowable answer in under two minutes if the system model is already loaded.

The anatomy of a feasibility question

A feasibility question sounds like a simple yes or no: "Can we do this?" But answering it correctly requires understanding several things simultaneously: what the system currently does, what would need to change, what other parts of the system those changes would touch, and whether existing patterns make the change easier or harder than it looks from the outside.

"Can we add bulk export for enterprise accounts?" sounds like a product question. From an engineering perspective it is four questions: Does the reporting service support bulk operations? Does the permission model have an enterprise entitlement for this? How does multi-tenancy affect file generation and storage? Is there an async processing infrastructure or does this need to be built? Each of those sub-questions has an answer buried somewhere in the codebase. Assembling those answers takes time — not because the engineer does not know their system, but because no one person holds all of it in their head at once.

The investigation is usually forty-five minutes to an hour. Translating the findings into something a PM can plan with takes another fifteen. The calendar delay — waiting for the engineer to have a quiet window, waiting for the follow-up response, waiting for the clarification question to be seen — adds days on top of the actual work time. The question that took thirty seconds to ask costs four to six days in total elapsed time before it produces usable planning information.

A single "is this possible?" question — the full journey:

  Tuesday 2:12 PM
    PM posts in #product-eng: "Can we add bulk export for enterprise accounts?"
    (The question takes 30 seconds to ask.)

  Tuesday 2:47 PM
    Engineer reads the message during a context switch.
    Mental note: need to look at reporting service, data access layer,
      customer permission model, multi-tenancy setup.
    Cannot answer now — mid-implementation on a different feature.
    Cost so far: ~4 minutes of engineer attention, zero answer.

  Wednesday 10:30 AM
    Engineer picks it up during a quiet window.
    Opens ReportingService, DataAccessLayer, CustomerEntitlements, TenantConfig.
    45 minutes of investigation.
    Finds: bulk export is technically possible but requires:
      - a new async job queue entry (reporting service does not handle bulk synchronously)
      - per-tenant storage quotas to be checked before triggering
      - enterprise entitlement flag that does not currently exist in CustomerEntitlements
    Engineer writes back: "It's possible but complex — probably 2 weeks with the queue work."

  Wednesday 11:15 AM
    PM receives the answer. "Possible but complex" is not enough to plan with.
    Asks: "What does 'complex' mean — is it the storage piece or the queue piece?"
    Engineer is back in focus work. Does not see the message until Thursday.

  Thursday 9:00 AM — sprint planning
    PM presents bulk export as a candidate feature.
    Team asks: how scoped is this? PM says "2 weeks, possibly, still getting details."
    Feature is deprioritized pending clarification.
    PM follows up with engineer after standup.

  Friday 4:30 PM
    Engineer gives a fuller breakdown.
    PM now has enough to write a ticket — six days after asking the question.

The interrupt cost: why every "is this possible?" consumes more than it appears

The obvious cost is the engineer's investigation time. But the interrupt cost is larger. When an engineer stops mid-implementation to answer a feasibility question, they lose the mental context they were holding. Rebuilding that context — getting back to the state where they were making progress on the thing they were doing — takes fifteen to thirty minutes after every interruption. The feasibility question that consumed forty-five minutes of active investigation actually consumed sixty to ninety minutes of engineering capacity once context switching is included.

Engineering takes longer than expected partly because of this accumulated interrupt overhead — the sum of feasibility questions, Slack check-ins, and planning questions that each seem small but collectively consume multiple hours of focused work time per sprint. A team of five engineers fielding three feasibility questions per sprint loses six to ten engineer-hours per sprint to interrupts that, individually, no one would characterize as a problem.

The PM's cost is less visible but equally real. A blocked feasibility question means a blocked planning decision. The PM cannot write the ticket until they know whether the thing is possible and roughly how complex. They cannot prioritize it in the sprint until they have that answer. Every day the answer is delayed is a day the planning decision is deferred. At sprint planning, the feature either gets proposed without enough information — generating discussion and uncertainty in the meeting itself — or it gets pulled from the sprint entirely and pushed to the next cycle.

At scale: what 3–4 feasibility questions per sprint actually costs

Three to four feasibility questions per sprint sounds like a normal volume for a 10-person product team. It probably is. The question is what those questions cost when you account for the full cycle — investigation time, context switching, PM planning delay, and the downstream effect on sprint throughput.

The real cost of feasibility questions at scale:

  Per-question cost:
    Engineer context switch + investigation:         45 min
    PM waiting time (blocked from planning):         3–4 days
    Follow-up round trip (clarification):            +1 day
    Total elapsed time per question:                 4–5 business days
    Engineering time consumed per question:          ~1 hour

  Per sprint (10-person product team, 2-week sprints):
    Average feasibility questions per sprint:        3–4
    Engineering hours consumed (interrupts only):    3–4 hours
    Hours of PM planning time blocked:               10–15 hours
    Features deprioritized due to unknown feasibility: 1–2 per sprint

  Per year:
    Sprints per year:                                26
    Total engineering interrupt hours:               78–104 hours
    Equivalent: 2–2.5 engineer weeks per year
      spent answering feasibility questions
      that a queryable system model could answer in minutes.

  This does not count:
    - The features that were never proposed because the PM assumed they were too hard
    - The features that were scoped wrong because the PM got a partial answer
    - The sprint planning sessions that started without the information they needed

Two to two and a half engineer weeks per year spent answering feasibility questions is not a crisis. It is a slow drain — the kind of overhead that is invisible in any single sprint but accumulates into a measurable velocity gap over a year. Add the planning cycles that ran with incomplete information and produced mis-scoped tickets, and the cost is higher still.

The deeper cost is in what does not get asked. PMs learn, over time, which questions will get a fast answer and which will sit in the queue for days. They learn to route around the bottleneck — either waiting until they have a reason to talk to an engineer anyway, or making planning decisions without the feasibility check they know they need. Features get proposed as simpler than they are because the PM did not want to delay planning for a week. Scope gets underestimated because the full system impact was never investigated. These are the invisible costs of a feasibility bottleneck — the questions that were never asked, and the decisions that were made without them.

Why Slack and email do not fix this

The instinct is to route feasibility questions more efficiently: use a dedicated channel, set response SLAs, establish a rotation of who answers product questions. These interventions reduce the friction at the edges without touching the core problem.

The core problem is not routing. It is that every feasibility question requires an engineer to do active investigation work. No matter how quickly the message gets to the right person, the investigation still has to happen. The SLA does not make the context switch cheaper. The dedicated channel does not make the codebase easier to query. The rotation does not change the fact that the person answering the question has to stop what they are doing and spend an hour on it.

Async communication makes the delay more predictable but does not reduce it. A PM who knows they will get an answer in forty-eight hours instead of whenever the engineer has time is in a marginally better position. They are still waiting two days for information that does not need to take two days. The planning cycle is still blocked. The sprint is still starting without complete information.

What self-serve feasibility checking looks like with a managed agent runtime

Non-technical teams need a way to answer their own system questions before escalating to engineering — not because engineers should not be involved in planning, but because the preliminary feasibility check should not require pulling an engineer out of focused work. The investigation that takes an engineer an hour because they have to rebuild context from scratch should take a PM two minutes when the context is already loaded and the system model is already queryable.

This is what a managed agent runtime provides. Kognita keeps a live, semantic index of your codebase — not a snapshot, not documentation, the actual indexed representation of how the system works, updated as the code changes. When a PM asks a feasibility question, they are not asking a general-purpose AI to guess. They are querying a system that already has the codebase loaded and can answer directly from the source.

What Kognita returns when a PM asks about bulk export feasibility:

  Query: "Is it possible to add bulk export for enterprise accounts?"

  Kognita response:
    ReportingService: currently handles single-report generation synchronously.
      Bulk export would require async processing — no existing job queue in this service.
      AsyncJobQueue exists in NotificationService and could be extended, or a new
      queue entry could be added to ReportingService directly.

    Data access: DataAccessLayer.fetchReportData() supports pagination but not
      bulk cursor-based iteration. Bulk export of large datasets would need a
      streaming or chunked query approach.

    Permissions: CustomerEntitlements has no 'bulk_export' flag.
      Enterprise entitlements are currently defined in: entitlements.config.ts.
      Adding a new entitlement requires updating that file + the billing plan mappings.

    Multi-tenancy: TenantConfig enforces per-tenant storage limits.
      Bulk export files would count against tenant storage quota.
      StorageQuotaService.checkBeforeWrite() would need to be called before job creation.

    Estimated scope: async queue work + entitlement flag + storage check + streaming query.
    Existing patterns for async jobs are in NotificationService — reusable.

  Time to answer: under 2 minutes.
  Engineering time consumed: zero.
  PM can now write a scoped ticket and present it at Monday planning.

The answer is not generic. It is specific to the actual architecture — the real services, the real permission model, the real async infrastructure or lack of it. A PM reading that response has what they need to write a scoped ticket, estimate rough complexity, and identify the questions worth bringing to engineering. What was a four-day wait with a partial answer at the end is now a two-minute self-serve query with a complete answer.

"Managed" is the operative word. Nothing runs on individual laptops. There are no per-developer API keys to manage or Claude subscriptions to provision. The team connects to Kognita once and the whole organization — PMs, POs, scrum masters, founders, ops leads — gets access to the same queryable system model. When a new PM joins, they do not need to spend three weeks building system intuition through engineering conversations. They have the system available to query from day one.

Final take

The six-day wait for "it's possible but complex" is not a people problem. The PM asked reasonably. The engineer answered when they could. The delay was the system working exactly as designed — every feasibility question routed through the one person who has system context, who has to rebuild that context from scratch every time, who has ten other things they are also supposed to be doing.

Feasibility questions should take minutes because the information that answers them is already in the codebase. The only missing piece is a queryable interface between the people who ask the questions and the system that holds the answers. At three to four questions per sprint, eliminating that bottleneck recovers two to three hours of engineering time and unblocks the planning cycle before it starts. Over a year, that is a measurable change in how much gets planned accurately and how much gets shipped on schedule.