> For the complete documentation index, see [llms.txt](https://productcommittee.docs.intersectmbo.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://productcommittee.docs.intersectmbo.org/committee-outcomes/product-research/product-research-grants/product-researches-initiatives-grants/rfp-01-customer-segmentation-and-profiling.md). # RFP 01: Customer Segmentation and Profiling Tender type: Request for Proposals Issued by: Cardano Product Committee / Intersect Research portfolio: Product Research Initiatives Final publication date, submission deadline, clarification window, expected project period, submission method, and contact will be confirmed on the Product Research Initiatives - Grants page before the call opens. *** ## 1. Executive Summary ### Strategic question Who are Cardano's current and potential customer segments, what does each segment need from Cardano, and which segments should be prioritized for activation through specific partner and channel strategies? ### Evidence gap Cardano does not yet have a validated segmentation and profiling model that distinguishes current users and ecosystem participants from potential external demand segments. Without this, product strategy, funding, communications, and partner development risk being too broad to produce measurable adoption. ### Decision unlocked This research should enable Cardano stakeholders to decide which customer segments to prioritize first, which partner or channel pathways are most credible for each segment, and what adoption signals should be used to evaluate whether activation is producing real usage rather than cosmetic interest. ### Expected outputs The selected vendor will produce a validated segment map, current Cardano customer/user profile, priority segment briefs, segment sizing assumptions, value proposition and switching-condition analysis, a segment x vertical x channel matrix, a partner/channel activation map, an adoption signal framework, and a concise decision memo. ### Requirement priority The required core is to answer the decision gates with traceable evidence and produce the required decision outputs. Optional methods, templates, or stretch work should be separated from the core scope and budget. *** ## 2. Strategic Context The Cardano Product Committee has received funding to commission a portfolio of product research initiatives aligned with Cardano's long-term product direction and Strategy 2030 priorities. The purpose of the portfolio is to define the evidence Cardano needs before making product, adoption, funding, partnership, and strategic decisions. This RFP is the first research initiative in that portfolio. It focuses on customer segmentation and profiling. The work should inform the Cardano Product Committee and the broader Cardano ecosystem. It should not be treated as a passive market research exercise or a generic persona study. The purpose is to produce evidence that can guide prioritization, partner strategy, activation planning, future grant design, and downstream research. Cardano's current audiences include many different types of participants, including builders, users, operators, contributors, partners, and community members. The research should identify which of these groups are meaningfully different, what they do, what they value, and what would cause them to deepen or begin adoption. It should also test demand hypotheses outside the existing Cardano and crypto-native audience. *** ## 3. Research Problem Statement Cardano lacks a validated, decision-ready understanding of its current and potential customer segments. Existing audience categories may be too broad to guide action. Labels such as "developers," "retail users," "enterprises," or "institutions" are not sufficient unless they are tied to observable behavior, jobs-to-be-done, decision criteria, current alternatives, adoption blockers, switching conditions, and reachable channels. This creates a strategic problem: * product and ecosystem priorities may be based on assumptions rather than validated customer needs; * funding and grants may support broad narratives rather than high-potential segments; * partner outreach may lack a clear view of which segments are reachable through which channels; * external demand beyond the current crypto-native audience may be overstated, understated, or poorly defined; * adoption may be measured through weak signals such as attention, stated interest, or one-off engagement rather than recurring use, partner commitment, or measurable activity. The selected vendor must close this evidence gap by producing a segmentation and profiling model that can support prioritization and partner/channel strategy. *** ## 4. Definitions For this RFP, "customer" should be understood broadly but operationally. A Cardano customer segment may include current or potential users, builders, buyers, operators, partners, or ecosystem participants whose behavior or decisions can affect Cardano adoption, usage, funding, partnership, or product strategy. ADA holders and governance participants may be included where relevant, but they should not dominate the research unless their behavior is linked to product adoption, activation, partner relevance, or ecosystem strategy. The RFP should prioritize segments that create, enable, or influence measurable adoption. The selected vendor may refine these definitions during the research design phase, but any revised definition must remain decision-useful and evidence-based. *** ## 5. Objectives The selected vendor will be expected to: 1. Profile current Cardano customers, users, and ecosystem participants, including what they do, what they value, and how they engage. 2. Identify named customer segments based on meaningful differences in behavior, motivation, job-to-be-done, decision criteria, and adoption pattern. 3. Test hypotheses about potential demand outside the current crypto-native Cardano audience, especially in adjacent sectors or verticals where blockchain may solve a genuine problem. 4. Define segment-level value propositions, current alternatives, objections, adoption blockers, and switching conditions. 5. Prioritize segments based on adoption potential, reachability, strategic relevance, evidence quality, and effort required. 6. Map each priority segment to credible channels, partner archetypes, and activation pathways. 7. Distinguish real adoption signals from cosmetic activity for each priority segment. 8. Identify which segment findings should be handed to other Product Research Initiative RFPs for deeper study. 9. Produce a reusable segmentation framework that can be refreshed on a 12-18 month cadence. *** ## 6. Decision Gates Applicants must design their methodology around the following decision gates. A proposal that does not map methods and deliverables to these gates will be considered weak fit for this RFP. | Decision Gate | Evidence Required | YES Means | NO Means | Action Unlocked | | ---------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------- | --------------------------------------------------------------- | | Can Cardano's current customers/users be segmented into behaviorally meaningful groups? | Current ecosystem evidence, interviews, survey evidence where relevant, optional user-behavior or on-chain data | Cardano has distinguishable current customer/user groups with different motivations and needs | Current customer understanding is too shallow or fragmented for reliable segmentation | Establish a reusable segmentation baseline | | Which current segments show the strongest adoption signal? | Segment-level evidence of recurring use, builder activity, capital/activity contribution, product usage, partner relevance, or ecosystem participation | Some current segments merit priority support | Current activity is too cosmetic, speculative, or weakly connected to durable adoption | Prioritize retention, activation, grants, and support | | Are there credible customer segments outside the current crypto-native Cardano audience? | Hypothesis-driven demand discovery with external respondents, desk research, and evidence of real problems and alternatives | Cardano has plausible growth segments beyond existing insiders | External demand is unvalidated, unreachable, or better handled elsewhere | Define external segment opportunities or reject weak hypotheses | | What job-to-be-done does each priority segment need Cardano to satisfy? | Segment interviews, observed behaviors, current alternatives, pain points, decision criteria, and switching conditions | Priority segments have specific needs Cardano can address or test | Segment needs are too vague or disconnected from Cardano's strengths | Shape value propositions, product inputs, and partner strategy | | Which segments are reachable through credible channels or partners? | Channel mapping, partner archetype analysis, access constraints, and stakeholder validation | Some segments can be activated through identifiable partners or channels | Segments may be attractive but are not currently reachable | Prioritize partner and channel strategy | | Which segments should be prioritized first? | Comparative scoring across adoption potential, reachability, strategic relevance, effort, and evidence strength | A ranked segment strategy can guide action | Findings do not support confident prioritization | Direct resources toward highest-confidence segments | | Which questions should be handed to other RFPs? | Boundary analysis across enterprise, government, stablecoin, AI, L2, brand, use-case, and partner-network research | Some questions are better resolved by specialized RFPs | Segmentation scope is overloaded or duplicative | Keep this RFP focused and improve portfolio alignment | | What counts as real adoption signal for each priority segment? | Segment-specific evidence thresholds, examples of valid evidence, and excluded vanity metrics | Future activation can be measured against meaningful indicators | Activation may be evaluated through ambiguous or cosmetic metrics | Improve KPI design for pilots, grants, and partner work | *** ## 7. Scope of Work ### In scope The selected vendor should cover: * current Cardano customer/user profiling; * segmentation of current and potential customer groups; * jobs-to-be-done per segment; * decision criteria, blockers, current alternatives, and switching conditions; * hypothesis-driven demand discovery outside the current crypto-native audience; * segment-level sizing assumptions with stated confidence and methodology; * prioritization of segments for the next 12-24 months; * partner and channel strategy by segment; * segment x vertical x channel mapping; * adoption signal definitions by segment; * cross-RFP handoff notes; * reusable segmentation framework. ### Out of scope and handoff boundaries This RFP should remain focused on segmentation, profiling, prioritization, and partner/channel strategy. It may identify findings relevant to other Product Research Initiatives, but it should not attempt to fully answer those initiatives. Adjacent topics should be handled as follows: | Topic | In Scope for This RFP | Out of Scope for This RFP | | ------------------------------------- | ------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------ | | Enterprise and RWA | Identify enterprise-related segments, needs, blockers, and channel hypotheses | Full enterprise readiness, SLA, compliance, or production-readiness assessment | | Government and emerging markets | Identify relevant customer or partner segments and broad demand hypotheses | Regional entry strategy, regulatory analysis, or country-level playbooks | | Use cases and competitive positioning | Capture segment-level current alternatives and switching criteria | Full vertical landscape or chain-by-chain competitive audit | | Brand awareness and perception | Capture segment-level trust signals, objections, and value proposition response | Full awareness baseline, brand perception study, or messaging campaign | | Stablecoin liquidity | Identify stablecoin-related user or partner segments and demand signals | Liquidity depth analysis, incentive design, market-maker strategy, or venue strategy | | L2 and interoperability | Identify segments blocked by scalability or interoperability needs | Technical L2 demand study, bridge strategy, or value-flow analysis | | Enterprise delivery partners | Identify partner/channel archetypes for reaching segments | Full certification model or delivery partner network design | | AI commercial positioning | Identify AI-related customer or builder segments where relevant | Full AI market positioning, narrative testing, or go/no-go vertical assessment | Findings that materially affect another research initiative should be captured in the Cross-RFP Handoff Memo rather than expanded inside this RFP. ### Optional / nice-to-have stretch scope Applicants may propose optional stretch scope, priced separately, such as: * light value proposition testing for top priority segments; * early partner archetype mapping by segment; * segment-specific adoption KPI suggestions; * deeper survey work for current Cardano user profiling; * optional on-chain or user-behavior analysis; * a crosswalk showing how segmentation findings should inform the other eight RFPs. ### Cross-RFP boundary guidance | Topic | Treat In This RFP As | Hand Off To | | --------------------------------------- | --------------------------------------------------------- | ------------------------------------------------------ | | Enterprise customers | Segment definition, need, blockers, channel hypothesis | Enterprise and RWA Readiness Assessment | | Government or emerging market buyers | Segment hypothesis and broad access route | Government and Emerging Markets Entry Strategy | | Use-case competitiveness | Segment-level current alternatives and switching criteria | Use-Case Landscape and Competitive Positioning | | Brand perception | Segment-level trust signals and objections | Brand Awareness and Perception | | Stablecoin users or liquidity providers | Segment definition and demand signal | Stablecoin Liquidity Incentive and Activation Strategy | | AI-related buyers or builders | Segment hypothesis and credibility signal | AI Commercial Positioning | | L2 users/builders | Segment hypothesis and adoption blocker | L2 Adoption and Interoperability Demand Study | | Delivery partners | Partner/channel archetype | Enterprise Delivery Partner Network | *** ## 8. Required Methodology The selected vendor must use a mixed-method research design. Desk research alone is not sufficient. The methodology should include: * desk research to establish hypotheses and context; * primary research with current Cardano users, builders, operators, or ecosystem participants; * primary research with external non-Cardano respondents; * stakeholder or partner/channel validation; * explicit segmentation logic; * evidence standards for segment validation; * confidence levels and limitations; * bias controls; * decision-gate mapping. ### Core research hypotheses Applicants should test, refine, or reject hypotheses such as: | Hypothesis | What Must Be Tested | Decision Relevance | | -------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------- | ---------------------------------- | | Cardano's current users can be segmented into distinct groups | Whether current users differ meaningfully by behavior, motivation, need, or adoption pattern | Enables current customer profiling | | Some current segments show stronger adoption signal than others | Whether segments differ in recurring use, builder activity, capital/activity contribution, or partner relevance | Guides prioritization | | Cardano has credible customer opportunities outside the current crypto-native audience | Whether external audiences have real problems Cardano could plausibly solve | Expands strategy beyond insiders | | Priority segments have different decision criteria and switching conditions | What each segment needs before choosing or deepening use of Cardano | Enables value proposition design | | Reachability differs by segment | Which channels or partner archetypes can credibly reach each segment | Enables partner strategy | | Current interest is not always real adoption | Whether segment activity can be tied to measurable behavior or decision commitment | Prevents vanity metrics | ### Primary research expectations Applicants must include primary validation. The proposal should explain: * who will be interviewed or surveyed; * why those respondents are relevant; * how respondents map to proposed segments; * how external audiences will be reached; * how insider bias will be controlled; * how negative cases will be included where possible, such as people who chose another chain, stopped using Cardano, or considered but rejected Cardano. Indicative minimum interview expectations: | Interview Category | Indicative Range | Purpose | | ---------------------------------------------------- | ---------------: | ---------------------------------------------------------------- | | Current Cardano users/builders/operators | \[15-25] | Profile current customers/users and identify segment differences | | Ecosystem stakeholders with cross-segment visibility | \[5-10] | Validate segment structure and channel assumptions | | External non-Cardano respondents | \[15-25] | Test demand outside the current crypto-native Cardano audience | | Partner/channel candidates or experts | \[5-10] | Validate reachability and partner strategy | | Total suggested range | \[40-70] | To be justified by applicant scope and budget | Applicants may propose different sample plans, but they must explain why the sample is sufficient to answer the decision gates. ### Survey expectations Survey work is optional but encouraged where the applicant can demonstrate credible recruitment and data quality. Survey work may be useful for: * broader current Cardano user profiling; * testing segment-level motivations; * comparing value proposition appeal; * estimating relative segment prevalence; * validating prioritization assumptions. Survey evidence will be considered weak if recruitment is limited to a single Cardano social channel, respondent quality is unaudited, recruitment bias is undisclosed, or questions measure only stated enthusiasm without behavior, current alternatives, or switching conditions. ### Optional on-chain or user-behavior analysis On-chain or user-behavior analysis is optional and should depend on vendor capability and data availability. Applicants that propose such analysis must explain: * which data sources will be used; * what behavior the data can and cannot show; * how wallet or user-level assumptions will be handled; * how privacy and data handling will be addressed; * how behavioral evidence will be connected to segment definitions. If a proposed method depends on unavailable, proprietary, or paid data, it must be marked "requires validation." ### What should not count as evidence The following should not be treated as sufficient evidence: * unattributed claims about what "the market" wants; * generic blockchain adoption narratives; * Cardano community sentiment presented as external demand; * market sizing without assumptions and source traceability; * personas based only on demographics; * segments defined only by labels; * competitor claims without evidence; * value propositions not tested against segment decision criteria; * interview counts without respondent relevance; * survey samples with undisclosed recruitment bias; * findings that do not map to a decision gate. *** ## 9. Expected Deliverables Deliverables are grouped into core decision outputs, supporting research outputs, and public/community-facing outputs. ### Core decision outputs | Deliverable | Description | Format | Acceptance Criteria | | ----------------------------------- | -------------------------------------------------------------------------------------------------------------------- | ------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Executive Decision Memo | Concise synthesis of what Cardano should do differently based on findings | PDF/doc, max \[8] pages | States top segment priorities, partner/channel implications, defer/no-go recommendations, evidence confidence, and next actions | | Validated Segment Map | Named segmentation model covering current and potential customer segments | Table, map, and narrative | Each segment includes definition, evidence basis, job-to-be-done, current alternative, decision criteria, blockers, switching conditions, and confidence level | | Segment Prioritization Model | Ranking of segments by adoption potential, reachability, strategic relevance, evidence strength, and effort required | Scoring table plus explanation | Uses transparent scoring criteria, shows tradeoffs, identifies top, watchlist, and deprioritized segments | | Segment x Vertical x Channel Matrix | Matrix showing which segments connect to which verticals and channels | Spreadsheet/table | Shows segment, relevant vertical, activation channel, partner archetype, reachability, evidence basis, and recommended next step | | Adoption Signal Framework | Definition of real adoption indicators by segment | Framework table | Lists strong signals, weak/cosmetic signals, minimum evidence threshold, and suggested measurement method per priority segment | ### Supporting research outputs | Deliverable | Description | Format | Acceptance Criteria | | --------------------------------------------------- | -------------------------------------------------------------------- | --------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | | Research Design and Decision-Gate Map | Detailed plan showing how the vendor will answer each gate | PDF/doc, max \[10] pages | Maps methods to gates, includes sample plan, recruitment sources, evidence limits, and bias controls | | Current Cardano Customer/User Profile | Profile of current Cardano consumers/users | Report section plus summary table | Separates user types by observable behavior or role and includes evidence source per claim | | Segment Persona Briefs | Concise briefs for each priority segment | 2-3 pages per priority segment | Includes job-to-be-done, motivations, blockers, alternatives, decision criteria, value proposition, channel route, partner archetypes, and adoption signals | | External Demand Validation Memo | Evidence on potential non-Cardano customer segments | Memo plus evidence table | Includes external respondent evidence and distinguishes validated, weak, and rejected hypotheses | | Value Proposition and Switching Conditions Register | Segment-level propositions and conditions required to choose Cardano | Table/register | Includes current alternative, required proof, value proposition, objection, switching trigger, and evidence basis | | Cross-RFP Handoff Memo | Findings that belong in other research initiatives | Memo, max \[5] pages | Maps relevant findings to other RFPs and explains why they should be handled elsewhere | | Final Research Report | Full research record | PDF/doc | Includes methodology, sample, evidence tables, findings by decision gate, limitations, and source traceability | ### Public/community-facing outputs | Deliverable | Description | Format | Acceptance Criteria | | ----------------- | ------------------------------------------------- | ---------------------------- | -------------------------------------------------------------------------------------------------------------------------------- | | Presentation Deck | Presentation-ready summary | Slide deck | Covers question, evidence gap, method, segment map, priorities, channel implications, adoption signals, limits, and next actions | | Public Summary | Non-confidential summary suitable for publication | Markdown/PDF, max \[5] pages | Includes key findings, methodology overview, evidence caveats, publishable recommendations, and excludes sensitive data | *** ## 10. Acceptance Criteria Each deliverable must be decision-useful, evidence-based, and traceable. Every factual claim must be traceable to a source, interview, survey result, dataset, or clearly identified vendor judgment. Every priority segment must include: * segment definition; * job-to-be-done; * evidence basis; * current alternative; * decision criteria; * adoption blocker; * switching condition; * channel or partner route; * adoption signal; * confidence level. Every recommendation must state: * what should be done; * who the action is relevant for; * what evidence supports it; * what uncertainty remains; * what should not be concluded from the evidence. A deliverable will be considered unacceptable if it: * treats current Cardano insiders as the whole market; * provides personas without evidence; * uses broad audience labels without behavior or needs; * produces market sizing without assumptions; * offers all-positive segment recommendations; * fails to identify weak or rejected hypotheses; * does not distinguish real adoption from cosmetic activity; * does not map outputs to decision gates; * duplicates other RFP scopes without clear handoff. *** ## 11. Vendor Eligibility Applicants may be independent researchers, consultancies, ecosystem teams, academic groups, or consortia. Subcontracting is permitted where responsibilities are clearly defined. Applicants should demonstrate: * segmentation, customer research, or market research experience; * primary research capability; * ability to reach current Cardano and external non-Cardano respondents; * understanding of Web3, L1 ecosystems, or adjacent adoption markets; * ability to translate research into product, partner, or adoption strategy; * ability to manage research ethics, data handling, and confidentiality; * capacity to deliver concise, decision-oriented outputs. Preferred but not mandatory capabilities include: * prior L1/L2 ecosystem research; * product strategy experience; * partner/channel strategy experience; * survey design and analysis; * on-chain or user-behavior analytics; * experience communicating research for both executive and public audiences. *** ## 12. Proposal Submission Requirements Applicants must follow the shared Submission Pack and include the common documents: cover letter, technical proposal, budget proposal, team credentials, evidence access plan, ethics/data handling statement, and conflicts declaration. Applicants bidding on multiple Product Research Initiative RFPs must disclose shared staffing, shared respondent recruitment, shared evidence collection, and any assumptions that could create respondent fatigue or duplicated outreach. For this RFP, the technical proposal must also include: * segmentation logic and proposed segment validation method; * respondent/sample plan covering current Cardano participants and external non-Cardano respondents; * decision-gate mapping; * partner/channel activation approach; * plan for distinguishing real adoption signal from stated interest; * cross-RFP handoff approach for findings that belong to other research areas. Budgets should separate core scope from optional stretch scope and explain how cost relates to evidence access, respondent quality, and decision usefulness. ## 13. Evaluation Guidance Proposals will be assessed using the CPC standard research grant evaluation framework: Fit to Grant Objectives, Team Capability, Proposal Quality and Execution Plan, and Cost Efficiency. The full scoring framework is maintained on the shared evaluation page. For this RFP, strong fit means the proposal clearly maps its methodology and deliverables to the segmentation decision gates; includes primary validation beyond Cardano insiders; distinguishes current user profiling from external demand discovery; defines how segments will be prioritized; and explains how partner/channel strategy and adoption signals will be produced. Proposals will score lower if they rely only on desk research, provide generic personas, omit external validation, fail to connect findings to prioritization and partner strategy, or do not disclose relevant conflicts of interest. Cost will be assessed against evidence value, not simply lowest price. Higher budget requests should explain how the added cost produces materially stronger evidence, better respondent access, higher confidence, or more decision-useful outputs. ## 14. Timeline and Milestones Final calendar dates will be confirmed on the Product Research Initiatives - Grants page before the call opens. | Milestone | Target Date / Timing | Purpose | | ----------------------------- | ------------------------- | ---------------------------------------------------------------------------------- | | RFP publication | Confirmed on grants page | Open call for proposals | | Clarification window opens | Confirmed on grants page | Applicants may submit questions | | Clarification window closes | Confirmed on grants page | Final clarification responses issued | | Proposal deadline | Confirmed on grants page | Applicant submissions due | | Award notification | Confirmed on grants page | Selected vendor notified | | Kickoff | Project week 1 | Confirm scope, decision gates, workplan, and communication cadence | | Research design approval | Applicant-proposed timing | Approve sample plan, instruments, data sources, and bias controls before fieldwork | | Early signal check | Applicant-proposed timing | Review early segment hypotheses and recruitment progress | | Interim findings review | Applicant-proposed timing | Test whether evidence is answering decision gates | | Draft deliverables review | Applicant-proposed timing | Review segment map, prioritization model, channel matrix, and adoption signals | | Final report and presentation | Applicant-proposed timing | Deliver final outputs and decision memo | | Public summary | Applicant-proposed timing | Publish non-confidential summary | Applicants should propose a timeline appropriate to their methodology. Unrealistic timelines should be avoided, especially where primary external validation is proposed. *** ## 15. Governance, Reporting, and Communication The selected vendor will participate in structured checkpoints. | Checkpoint | Purpose | | ------------------------- | --------------------------------------------------------------------------------------------------- | | Kickoff | Confirm objectives, decision gates, workplan, and communication norms | | Research Design Review | Approve sample plan, interview/survey instruments, data sources, and bias controls before fieldwork | | Early Signal Check | Surface early segment hypotheses, recruitment issues, and data limitations | | Interim Findings Review | Test whether evidence is answering the decision gates | | Draft Deliverables Review | Review segment map, prioritization model, channel matrix, and adoption signal framework | | Final Presentation | Present final findings, limitations, decisions enabled, and recommended next actions | The reporting cadence should be proportionate to project length, but at least one interim findings review and one draft deliverables review are required. *** ## 16. Risks, Bias Controls, and Safeguards Applicants must include a research integrity plan. | Risk | Required Control | | ----------------------------------- | ------------------------------------------------------------------------------------------------------------------------- | | Cardano insider bias | Separate insider findings from external validation; disclose respondent affiliations | | Overweighting loud ecosystem voices | Use defined recruitment logic and avoid relying only on visible community participants | | Weak external demand evidence | Include non-Cardano respondents and identify rejected or weak hypotheses | | Survey bias | Disclose recruitment channels, respondent quality checks, and limitations | | Unsupported market sizing | State assumptions, sources, and confidence levels | | Cosmetic adoption signals | Define real adoption indicators per segment and exclude vanity metrics | | Scope creep | Use cross-RFP handoff logic for enterprise, government, brand, use-case, stablecoin, AI, L2, and partner-network findings | | Conflicted recommendations | Require conflict declarations and mitigation plans | | Sensitive data exposure | Separate public findings, committee-facing findings, and raw data | The final report must include a limitations section explaining what the research can and cannot support. *** ## 17. Clarification Process Applicants may submit clarification questions during the clarification window. Questions may address: * scope; * decision gates; * deliverables; * data availability; * respondent access; * budget format; * confidentiality; * public/private outputs; * overlap with other RFPs. Responses should be maintained in a rolling Q\&A log where practical so applicants receive consistent information. If a response materially changes scope, deadline, or eligibility, the RFP timeline may be adjusted. The clarification process also helps assess applicant judgment. Strong questions should demonstrate specificity, methodological awareness, and realistic tradeoff thinking. *** ## 18. Data Handling, Confidentiality, and Public Summary The selected vendor must provide a data handling plan covering: * consent process for interviews and surveys; * anonymization approach; * storage and access controls; * treatment of confidential or commercially sensitive information; * handling of raw interview notes or transcripts; * treatment of survey data; * publication boundaries; * retention and deletion plan. Research outputs should distinguish: * public findings suitable for community publication; * confidential findings suitable only for CPC/internal review; * raw data that should not be published. A public summary is required unless confidentiality constraints make specific findings unsuitable for publication. Some findings may remain committee-facing if publication would damage respondent trust, reveal sensitive strategy, or expose commercially confidential information. *** ## 19. Human Subject Research Ethics Because this RFP requires interviews, surveys, or other primary research with current and potential users, the selected vendor must apply basic human-subject research safeguards. At minimum, the vendor should: * obtain informed consent for interviews, surveys, recordings, and attribution; * allow respondents to participate anonymously or confidentially where appropriate; * avoid collecting unnecessary personal or sensitive data; * explain how raw notes, transcripts, survey data, and recordings will be stored, accessed, retained, and deleted; * separate public findings from confidential respondent evidence; * avoid overstating findings from small, biased, or non-representative samples. The vendor should not publish respondent-identifying information without explicit permission. *** ## 20. Conflicts of Interest Applicants must disclose any actual, potential, or perceived conflicts of interest, including: * paid work for Cardano ecosystem entities; * affiliation with Cardano projects, vendors, foundations, committees, or community organizations; * financial exposure that could benefit from segment prioritization; * governance roles or voting influence; * subcontractor conflicts; * relationships that may bias respondent recruitment, research design, or recommendations. Declared conflicts do not automatically disqualify an applicant. Undisclosed conflicts may be grounds for rejection, non-award, or termination. *** ## 21. Terms and Conditions Standard terms and conditions will be provided through the shared tender process before award. Applicants should assume that final award terms will cover ownership and permitted publication of deliverables, confidentiality, payment milestones, termination, data protection, subcontractor approval, warranties or disclaimers, and the governing process. *** ## 22. Appendix A: Proposal Checklist Applicants should confirm that their proposal includes: * [ ] Cover letter * [ ] Understanding of the brief * [ ] Proposed methodology * [ ] Decision gate mapping * [ ] Workplan * [ ] Team qualifications * [ ] Relevant experience * [ ] Data sources * [ ] Stakeholder access plan * [ ] Risk and bias mitigation plan * [ ] Timeline * [ ] Budget breakdown * [ ] Conflicts declaration * [ ] Ethics and data handling approach * [ ] Prior work examples, if applicable *** ## 23. Appendix B: Required Decision Gate Mapping Template | Decision Gate | Method Used | Evidence Source | Deliverable | Limitation / Risk | | -------------------------------- | ----------- | --------------- | -------------- | ----------------- | | Current customer segmentation | \[Method] | \[Source] | \[Deliverable] | \[Risk] | | Current adoption signal | \[Method] | \[Source] | \[Deliverable] | \[Risk] | | External demand discovery | \[Method] | \[Source] | \[Deliverable] | \[Risk] | | Segment job-to-be-done | \[Method] | \[Source] | \[Deliverable] | \[Risk] | | Channel and partner reachability | \[Method] | \[Source] | \[Deliverable] | \[Risk] | | Segment prioritization | \[Method] | \[Source] | \[Deliverable] | \[Risk] | | Scope handoff to other RFPs | \[Method] | \[Source] | \[Deliverable] | \[Risk] | | Real adoption signal | \[Method] | \[Source] | \[Deliverable] | \[Risk] | --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://productcommittee.docs.intersectmbo.org/committee-outcomes/product-research/product-research-grants/product-researches-initiatives-grants/rfp-01-customer-segmentation-and-profiling.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.