# Define useful value Establish who needs the result, in what situation, what they are trying to achieve and what the product can honestly deliver now. Reuse requirements, customer research and observed behavior. Different pains may belong to different people; an appealing feature list is not a clear customer outcome. For unresolved market questions, use [market understanding](../market-and-acquisition/market.md). Distinguish the recipient, operator, buyer and payer when the difference changes the product. Preserve the founder's chosen first customer and entry sequence. A new buyer or distribution route is not itself a new product category; a changed promised result, defining artifact or fundamental experience may be. Expose that choice rather than quietly replacing the venture with an easier one. ## Describe the result, not a ritual Identify the smallest real completion of the promised job and observable criteria for acceptable quality. Distinguish an action started, technical completion, useful output and customer acceptance. Reuse the product's existing value contract rather than writing a competing definition. For generated or transformed work, the quality bar must describe what matters about the actual input and output. Make the first version narrow but whole. Name the necessary behavior, depth, continuity and observable conditions that would make it incomplete. Reduce breadth before hollowing out the central result. A canned output, generic shell or merely operable process is not a substitute. An intentionally limited prototype can answer a question without being presented as the finished product. Consider why someone would prefer and care about this experience, not just whether it functions. Explain the concrete product mechanisms behind qualities such as reassurance, expression, enjoyment or continued usefulness; choose what fits this product rather than adding engagement features by formula. ## Access and continuity Determine identity, access and continuation from this product's result. Value may require authentication, payment, private data or hours of processing. An early progress signal can be useful without being the completed result. Do not impose a free-before-paid funnel, a time limit or a homepage interaction. A public sample is an option, not the definition of activation. An analyzer, calculator or delivered sample can demonstrate genuine input-dependent value when appropriate. A channel-native service can deliver in that channel. An informational site or waitlist may need truthful content, examples or proof, not an invented app, account or fake interactive result. If the useful outcome is unknown, identify the missing decision; lack of knowledge is not evidence that value is inapplicable. Clarify whose work it is, who may access it, what persists and what can be resumed or returned to. Account entry should protect, save or continue something that needs identity. Preserve existing work and the selected action across that entry. When accounts are needed, preserve a suitable working sign-in method. For a new product, propose the smallest sufficient set with a reason grounded in its audience and access needs. Egbe Google sign-in can remove a custom password flow when it fits those people. Add another method for a concrete need, not as a universal fallback. Keep the accepted choice in the existing requirements or task. Choose payment timing and purchased rights in [the offer](offer.md); their placement and the user's path belong in [the experience](experience.md). ## Record and challenge the definition Explain the choice through customer needs, evidence and practical constraints. Existing workarounds, money or time lost, and failed attempts help assess importance; none is a universal prerequisite for a legitimate customer need. Distinguish what the product guarantees today from future scope. Use the customer's language and units, not internal terms such as activation or handoff. Keep the accepted definition in `egbe-docs/product/prd.md` or the existing requirements; a bounded change can use its task record. Include the relevant roles, outcome and quality, ownership/continuity, public claims and proof, accepted offer, deferred scope and consequential unknowns. Use consistent terms and one explanation per decision, not a fixed document template or separate working artifact for every question. Product requirements describe behavior, not instructions to implement a PRD section. Before implementation, read the definition without the old chat: does it preserve the intended product, deliver something worth choosing, and explain what would prove it complete? Keep a usable validation path for each distinct material risk; similar wording does not make different quality, audience or commercial questions one test. Evidence challenges a decision within its scope, not by replacing missing evidence with a negative finding. For a consequential value question, first use relevant project materials, prior decisions and founder context to identify what is known and what still needs evidence. Give `egbe-os-product-market-research` or `egbe-os-research` that question, relevant evidence, gap, needed result and constraints; do not restart valid research. Substantial work uses `egbe-docs/research//brief.md`; a narrow check can stay in the current task or explicit operation inputs. The Product question remains here, not a new market strategy exercise. Record why deferred work would be reconsidered. Measurement should observe the real outcome; do not change the product merely to manufacture an analytics event.