The Retrieve phase focuses on gathering all existing insights, data, and knowledge that can inform the work. This phase is a deliberate opportunity to break silos and surface information, expertise, and learnings from across the organization and partner ecosystem—not just within your immediate team. By thoroughly retrieving knowledge, you avoid duplication, leverage prior investments, and ensure everyone is building on a shared foundation.
Purpose
- Collect all relevant research, data, and prior work from both internal and external sources.
- Identify knowledge gaps, verify existing insights, and surface contributions from different teams or stakeholder groups.
- Ensure the entire project team—and all collaborating groups—are fully informed before new work begins, preventing misalignment and missed opportunities.
Key Questions
- What existing insights or data are available, and from whom? Are there external partners, departments, or prior projects we should consult?
- Where are these insights stored, and who owns or maintains them? Are there dependencies on other groups?
- Are there gaps, overlaps, or outdated areas in current knowledge? Who can help verify or fill these?
- What previous work, research, or assets can we leverage or build upon from other teams, products, or communities?
- Who else in the organization or network has relevant context, expertise, or lessons learned?
- What risks exist if we miss or overlook available information—especially regarding cross-team dependencies or historical blind spots?
- How will we document and transparently share what we’ve retrieved so everyone stays aligned?
Read the research report on the importance of collecting existing data. [Document Link – PDF]
Case Study Example: Dog Park Finder App (Fetch Spotter)
Applying the Retrieve Phase:
What existing insights or data are available?
- Public city data sets of registered dog parks
- Internal analytics from prior community app features
- User support tickets requesting park info
Where are these insights stored, and who owns them?
- City data: Municipal open data portals, managed by city IT departments
- Prior analytics: Internal dashboard, owned by Product Owner
- Support data: Customer Success team’s Zendesk reports
Are there gaps or outdated areas in current knowledge?
- Many parks lack updated hours, amenity details, or user ratings
- Prior feature usage didn’t track location or park-specific engagement
What previous work can we leverage or build upon?
- Old “Park Finder” microsite codebase
- Third-party dog-friendly location APIs
- Engagement patterns from existing user communities
Who else in the organization has relevant context or expertise?
- Customer Support staff with insight into common user frustrations
- Marketing team with connections to local pet groups
What risks exist if we miss or overlook available information?
- App launches with inaccurate or incomplete park listings
- Missed partnership opportunities with local organizations
- Outstanding data access risks from Origin phase
How will we document and share what we’ve retrieved?
- Central shared Confluence page for data sources and gaps
- Weekly sync meetings to review research status
| Data Source | Owner/Contact | Storage Location | Access Status | Notes |
|---|---|---|---|---|
| Registered Dog Parks (Public City Data) | City IT Dept. | Open Data Portal | Requested – Pending | Awaiting data use approval |
| Prior Community App Analytics | Product Owner | Internal Analytics Dashboard | Available | Data covers app usage, not locations |
| User Support Tickets | Customer Success | Zendesk Reports | Available | May need cleaning/filtering |
| Old “Park Finder” Microsite Codebase | Engineering Lead | Legacy Code Repository | Available | Needs review for integration |
| Third-party Dog-friendly Location APIs | Product Owner, Eng. Lead | External API Portal | Requested – In Progress | Limited trial access for evaluation |
| Local Pet Group Engagement Patterns | Marketing | CRM / Email Analytics | Available | Data shared monthly |
Sample Data Inventory Table
This data inventory table clarifies what data exists, who is responsible, where it is stored, and the current access status. Update as your project progresses.