Make R&D always on and ubiquitous.

What the AI will do

• Builds an R&D tool that keeps collecting useful signals from customers, commercial behavior, industry, competitors, culture and new AI capabilities.
• Brings you product and service ideas at your chosen cadence and supports on-demand brainstorming.
• Builds selected prototypes and has evidence-informed simulated customers try them before comparing which deserve real investment.

What you can provide

• A business area or product territory and whatever source access or rough examples you already have.
• Available customer feedback, sales and experiment records; the AI will find and connect useful sources.

Where you'll take part

• Choose what kinds of opportunities matter and how often ideas should arrive.
• Develop ideas with the AI, select prototypes and decide which deserve real customer testing or investment.

What you'll get

A working R&D intake and brainstorming tool, a first set of developed ideas, tested selected prototypes and a sourced investment comparison. Simulated reactions are separated from actual customer evidence; unattended operation is verified or identified as unfinished.

Activity context

R&D does not have to wait for the next off-site or a team to be released from its day jobs. Customers are asking, complaining, buying and walking away all the time. Competitors move. Culture changes. AI makes something possible that was impractical last month. Turn that stream into a place you can visit whenever you want to think about what to make next.

For the user

Name the business territory. The AI will investigate the available signals and build a recurring idea service and a place to brainstorm. You choose the cadence and which ideas to prototype, then review what the tests suggest.

Guidance for the AI

These are general instructions, not a description of this user's particular AI system, tools, access, or circumstances. Adapt the method to the user's goal and the capabilities you can actually use, while preserving the activity's essential sequence, review points, and intended result.

Start with the activity and the user's context

Read the complete activity and guide the user through it. Use the activity prompt yourself; the user does not need to paste it again. Keep the responsibilities of the user, the AI, and any colleague clear.

Begin with what the user has already supplied. Establish the intended result and resolve missing context through focused questions when needed. Work within the activity's stated scope, permissions, required confirmations, and stopping points, including any deliberate order for introducing information. Make progress with the available information and reasonable, clearly identified assumptions where the activity allows them.

Check the capabilities needed for this work

Inspect relevant available tools, connectors, and data. Use small, relevant, non-destructive checks to establish whether necessary access or a capability actually works. Naming a product does not establish access to it. Let this activity determine what needs checking; do not impose a universal preliminary questionnaire or a full system audit.

When useful access is missing:

• Explain what you cannot reach and how that material would help.
• Investigate practical setup, connection, export, or other access alternatives before asking the user to gather material or troubleshoot.
• If progress depends on access, request only the specific user action or permission needed to enable it or provide the material another way. Continue useful independent work while awaiting the response.
• Offer to walk the user through an export or upload. Welcome files, links, copied text, rough notes, or an interview as supported by your system and the activity, and use the best available route. If the missing access is optional, continue with what is available.

Ask focused questions and respect the answers

Ask questions only when necessary to complete the work well or satisfy the activity's required review points. Build on answers already supplied. Ask one question at a time, or a small group of closely related questions. Wait on work that depends on the answer, and continue useful work that does not. Explain unfamiliar language with examples where helpful.

Confirm answers or decisions you supply on the user's behalf before treating them as the user's final answers or decisions. This does not require separate approval of every sourced finding; follow the activity's specific review requirements.

Keep evidence and independent contributions distinct

Distinguish evidence, inference, and missing information. Check your work against the source material.

Use independent agents when your system actually supports delegation and independent investigation or review would improve the work:

• Give each agent a bounded brief and the context appropriate to its role.
• Keep discovery independent until synthesis where the activity requires it. Preserve any requirement for the user or colleagues to contribute before seeing other explanations.
• Follow the activity's stated fallback and any required confirmation when independent agents or fresh contexts are unavailable. Preserve reviewer isolation where required; describe shared-context or sequential passes accurately.

Produce, check, and revise the result

Do the substantive investigation and production. Carry the activity through to the most complete, usable result within its scope, rather than ending with a plan or handing the main work back to the user. When missing information does not prevent useful work, proceed with clearly identified assumptions where the activity permits them.

Check the result against the activity's completion criteria. At each substantive delivery, state what is complete and any material unfinished work, assumptions, helpful missing information, and remaining uncertainty. Explain how these affect what the user can use, and help the user revise the result.

Preserve the activity's stopping point. Do not turn a rehearsal, investigation, or test-design activity into execution that the user has not authorized.

Your AI prompt

Build an always-available R&D capability for new products and services. Gather useful signals continuously through the sources and cadence we choose, turn them into developed opportunities, support interactive brainstorming, and quickly prototype and evaluate selected ideas. Carry this through a working tool and a complete first cycle.

Learn the business and find the signal streams

Inspect and try available customer email, chats including WhatsApp where accessible, meeting and sales-call transcripts, support complaints and requests, CRM and lost-deal records, purchase and usage data, research notes, prior prototypes and innovation decisions. Search strategy documents and relevant calendars for current priorities, decision owners and planned product reviews. Establish what we sell, who uses and buys it, the result they need, our capabilities and the territory worth investigating.

Look beyond what customers ask for explicitly. Examine what they buy, do not buy, stop buying and how they buy, using actual records and consistent definitions. A missing transaction is not proof of rejection; seek lost-deal reasons or surrounding correspondence. Preserve differences between user enthusiasm, purchasing authority and actual buying behavior. Identify customers and their expressed goals from real interactions, rather than demographic stereotypes.

Add useful external streams: industry and competitor developments, cultural changes relevant to demand, customer news, and new AI capabilities that could alter production, delivery or the offer itself. Use current primary sources for important claims and distinguish an advertised feature or demonstration from performance we have verified. Record original links, dates and the business mechanism that could make each signal useful.

Map accessible sources and coverage. Investigate supported access routes before asking for targeted exports or a user-only connection step. Work from rough notes or a small sample when necessary, marking the resulting ideas as hypotheses with limited evidence. Do not make me curate an innovation packet before you search.

Build a research and brainstorming space

Ask what would make this useful in our working life. The idea service might arrive every morning, every Tuesday, every hour or once a quarter; choose a cadence based on the actual sources and my preference. Support an on-demand conversation as well: I should be able to bring an observation or ask what has become possible since our last discussion.

Propose a manageable initial territory and show example outputs before building around an unresolved preference. Preserve authorization already given. Agree the internal recipients, source scope, cadence, place to keep ideas and what the tool can do automatically. Separate ongoing signal collection from the timing of the human-facing digest so a weekly conversation can use daily observations.

Implement the source intake, durable signal and idea store, refresh process and brainstorming interface using available tools. Keep source identifiers and dates, links from signals to ideas, earlier versions, prototype results and decisions to pursue, park or stop. Detect duplicate signals and remember why an idea was declined while allowing new evidence to reopen it. Verify current official documentation for the actual connections, scheduler and storage chosen.

A recurring chat prompt without a tested trigger is not a running research service. If live connections are unavailable, build and demonstrate the tool on permitted source samples, prepare the missing connection steps and show how a manual refresh works. Deliver the working subset and distinguish it from unattended collection.

Turn observations into developed possibilities

For each cycle, seek meaningful combinations of customer problems, business capabilities and external changes. Explain what changed, whose problem it could solve and why this creates a product or service opportunity now. Generate alternatives that differ in the result delivered, customer, delivery method or economics, rather than ten names for the same feature.

For each promising idea, write a compact brief with:

• Intended customer and buyer, unmet need and current alternative.
• The concrete offer and evidence that inspired it.
• What AI or another change enables.
• Plausible delivery and revenue logic.
• The most important unknown.

Label inferred demand and speculative economics. Link the brief to prior related experiments so the team learns cumulatively.

When useful, assign distinct signal territories to independent discovery agents. Give them source scope, business context, evidence requirements and a bounded output. Keep their first ideas independent, then reconcile overlaps and contradictions centrally. Track inspected and uninspected sources and use waves or saved manageable passes for large collections.

Present a useful small set at the chosen cadence. In brainstorming mode, follow my developing thought, investigate questions that arise and revise the idea rather than repeatedly restarting the intake. Help me choose what to prototype based on what we need to learn. Keep unchosen ideas available without treating them as an approved work queue.

Prototype the ideas we choose

For each selected idea, identify the assumption that a quick prototype could illuminate and define a representative customer task. Build the actual useful demonstration: an interactive product, sample service delivery, worked customer output, game or other artifact suited to the offer. Give a service a concrete experience a customer can examine. Choose scope so the key promise is exercised; a decorative screen is not a demonstration of a functioning service.

Specify inputs, core behavior, expected result and the comparison that would make the test informative. Implement and try the prototype with representative cases. Record what works, corrections, manual work and missing production connections. Verify changing model or product capabilities before depending on them. If an idea cannot be prototyped here, create the closest agreed testable artifact and state which essential assumption it cannot test; ask before substituting a materially different result.

Keep individual build assignments bounded and separate dependent stages. A lead integrates the parts and checks the real task before simulated customer evaluation begins. Do not call an unbuilt concept a tested prototype.

Let simulated customers try it and decide what comes next

Construct relevant simulated customer perspectives from actual requests, complaints, usage and purchasing context. Include materially different needs, constraints and current alternatives. Have me correct consequential profile assumptions. Identify the sources and uncertainties for each profile; a simulation is not the customer’s real judgment.

Give separate simulated customers the prototype and a realistic task, not the creator’s sales pitch or preferred conclusion. Have them attempt the experience when tools permit, explain confusing moments, compare it with their documented current alternative and state what would stop adoption. Keep their first responses independent. If they can only read screenshots or a description, label that as concept or comprehension review rather than a usability trial. Use disclosed separate passes if independent agents are unavailable.

Have an evaluator compare the actual attempts, supported customer needs, technical checks and economics. Simulated reactions can expose confusion, generate objections and guide revisions; they do not demonstrate demand, willingness to pay or successful real-world adoption. Revise worthwhile prototypes and rerun the affected tasks. Preserve rejected versions and what we learned.

Deliver a clear comparison: which ideas look worth further investment, which need a changed offer and which lack a reason to proceed. Explain the evidence and remaining assumption for each. Prepare a proportionate real-customer test for the strongest candidates, with the exact experience or offer, intended participant, observable behavior and decision it would inform. Customer outreach and launch follow actual authorization.

Make the next cycle work

Demonstrate the complete path from a new signal to a linked idea, working prototype, recorded evaluation and decision. Test duplicate intake, an outdated source, a failed refresh, an idea revisited after new evidence and retrieval of an earlier experiment. Verify the actual recurring job and internal delivery where enabled. Give a separate reviewer the tool, source examples and cycle outputs, repair substantive findings and recheck them.

Hand over the working access point, first cycle’s ideas and prototypes, simulated-review results, recommendation and a simple way to change cadence, add a source or revisit a thought. Name remaining access dependencies and any unverified unattended behavior. The useful outcome is a continuing capacity to notice, imagine, build and learn, with one complete cycle demonstrated—not a promise that generated ideas are validated businesses.

Done when

You can use the R&D tool to receive new ideas or enter a brainstorming session, and its first cycle includes developed ideas, selected working prototypes and recorded evaluations. Recurrence is tested or explicitly unfinished; investment recommendations distinguish simulations from real customer evidence.

These instructions were written in September 2026 using the frontier models available at the time. You may now have better tools or models, or restrictions that make some tasks harder. Your AI should adapt to the tools and access you actually have and find the best available way to help. Everything here is a starting suggestion for you and your AI, not a proven best practice for every setup. Feel free to rewrite any of it to better meet your needs.