When Bosses Panic About AI: Turning Their Anxiety into Practical Product Strategies

Feature Overview: AI‑assisted Business Requirement Generation

Users start by entering a high‑level theme (e.g., “design a community group‑buying module”). They then browse an internal asset library containing past project specifications and select a subset of assets they consider valuable references.

Design Philosophy – “Precise Echo”

Respect Choice – A user‑checked asset is treated as an explicit request to incorporate that material.

Ensure Feedback – The language model must read the selected assets deeply, extract their core concepts, and reproduce those concepts faithfully in the generated requirement document.

Value Loop – Every interaction (click, selection, generation) must yield a deterministic, measurable benefit to the user.

This approach deliberately limits the number of assets that can be fed to the model because large‑model context windows (e.g., 8 k‑token limits for GPT‑3.5‑turbo) cannot accommodate arbitrarily many full documents. The trade‑off is a narrower “width” (fewer assets) in exchange for deeper, more reliable incorporation of each asset’s content.

Stakeholder Conflict: Boss’s “Fabrication” Objection

During a design review the product manager presented the Precise Echo logic. The boss (Mr. Ding) interrupted, arguing that if the user selects asset A and the AI simply outputs A, the system is merely stitching content together – a form of “fabrication.” This moral framing dismissed months of user‑scenario analysis, interaction‑path mapping, and technical trade‑off evaluation.

Re‑engineering the Feature – Version 2.0 “Soul Insight”

In response to the boss’s demand for a more “creative” AI, the team altered the data pipeline:

Core Disruption – Instead of feeding the raw selected assets to the model, the system now extracts each asset’s summary , tags , and a distilled representation of its domain soul (high‑level intent and style). These abstractions are concatenated and used as the prompt.

Boss Vision – The AI should “understand” and “create,” not act as a verbatim repeater. The goal is to trigger the model’s generalisation capability so that the output contains insights beyond the literal source material.

Team Translation – The pipeline is analogous to giving a chef a photo of a dish and a flavor description rather than the exact recipe; the model then produces an “innovative dish” that resembles the original but may taste entirely different.

Comparison of V1.0 and V2.0

V1.0 – Precise Echo

Philosophy: Deterministic “what you see is what you get.”

Risk: Limited reference scope may miss broader insights.

User experience: Selections are faithfully reflected, providing reassurance.

V2.0 – Soul Insight

Philosophy: Embrace possibility – “what is understood is what is created.”

Risk: “Choice loss” – user‑selected content can disappear if the abstracted prompt does not capture it.

User experience: Selections act as inspiration sparks; results are surprising and may diverge from the original assets.

Three‑Level Translation Framework

Upward Translation – Convert the boss’s high‑level, often speculative AI vision into concrete, measurable product goals (e.g., define “understand” as extracting summaries, tags, and domain‑soul vectors).

Downward Translation – Turn those product goals into detailed engineering specifications: data‑pre‑processing scripts, prompt templates, token budgeting, and validation tests.

Outward Translation – Communicate to users why their selected assets may not appear verbatim and explain the nature of the “uncertain intelligence” that drives the generative output.

Implementation Walk‑through (V2.0)

Collect user‑selected asset IDs from the UI.

For each asset, run a summarisation micro‑service (e.g., python summarize.py --input asset.json --max-tokens 200) to produce a concise summary .

Extract tags using a keyword‑extraction model (e.g., python tagger.py --text summary.txt --top‑k 5).

Generate a domain‑soul vector by feeding the summary into a sentence‑embedding model (e.g., sentence‑transformers) and storing the resulting embedding.

Compose the final prompt:

You are an experienced product analyst. Based on the following abstracts and tags, write a complete business requirement document for the theme "{user_theme}".

      Summaries:
      {summary_1}
      {summary_2}
      ...

      Tags:
      {tags_1}, {tags_2}, ...

Send the prompt to the LLM (e.g.,

openai.ChatCompletion.create(model="gpt-4", messages=[{"role": "user", "content": prompt}])

) and capture the response.

Post‑process the response to ensure required sections (scope, functional requirements, acceptance criteria) are present; if any are missing, trigger a fallback routine that re‑asks the model with a stricter schema.

Risk Mitigation Strategies

Maintain a “fallback echo” mode that, when the abstracted prompt fails to surface a selected asset, re‑injects the raw asset text for a second generation pass.

Log token usage per request to stay within the model’s context window; if the token budget is exceeded, automatically truncate the least‑relevant summaries based on tag relevance scores.

Provide UI feedback indicating the probability that each selected asset will influence the final output (e.g., a progress bar derived from relevance scores).

Conclusion – The Role of the Product Manager as a Human Prompt Engineer

The experience illustrates that product managers must act as translators across three layers: aligning visionary, often vague, executive AI expectations with concrete product specifications; converting those specifications into precise technical requirements for engineers; and finally, explaining the stochastic nature of generative AI to end‑users. Mastery of prompt design, token budgeting, and risk‑aware fallback mechanisms becomes the core competency, superseding traditional code‑centric responsibilities.