Project Snapshot
Overview
The client arrived with a working prototype for a multi-tier reseller network app — but the admin layer that would actually run the business had never been mapped. Discovery research with the founder defined what the product really needed. This case study covers the discovery phase of the engagement; the specified admin layer was subsequently built, and the platform is live.
- Product Research Consultant
- Discovery Researcher
- Requirements Analyst
- Founder Interviews
- Prototype Walkthrough
- Workflow Mapping
- Requirements Elicitation
- Specification Validation
- Admin layer defined — then built and deployed
- Membership up 300% since launch
- Manual operations moved onto the platform
Context
Challenge
- Requirements lived in the founder's head
- Tier & authorization logic undocumented
- Prototype showed end-user flows only
- Build blocked without an admin specification
Without externalizing the founder's operational knowledge, no development team could build the part of the product the business actually depended on.
Research Focus
Objectives and guiding questions for the discovery work.
Research Approach
Discovery moved from what existed, to what was missing, to what to build. Mapping centered on the member lifecycle: join (individually or by referral) → admin approval → earn commission through referrals and prepaid-product sales → monthly payout request, approved and processed by the operator.
Methods
- Semi-Structured Founder Interviews
- Prototype Walkthrough (contextual inquiry)
- Requirements Elicitation
- Operational Workflow Mapping
- Feature Specification
- Priority Validation with Founder
Analysis & Findings
What the discovery work revealed about the gap between the prototype and the product.
- Each referral collected ID docs, a verification photo, and proof of payment
- None of that intake logic had been defined as an operator requirement
- What looked like a social feature was structured business onboarding
- Three access states (provisional → full member → admin) governed every login
- Provisional state rendered as a broken experience — not a designed transition
- The model existed only in the founder's head
- Registration required a payment receipt — but no review-and-approval flow existed
- Nothing in the prototype let an operator approve, reject, or act on submissions
- Discovery exposed the gap between collecting and processing
- The founder held all business logic — nothing had been written down
- No development team could build the admin layer without externalizing it first
The referral flow looked like a user feature. It was the business's primary intake operation — with no operator side defined.
Document collection, identity verification, and tier authorization were all hidden inside one member-facing form. A prototype shows what users will see; discovery research uncovers what the business needs to run it.
Outcomes
Research contributions that converted an incomplete prototype into a buildable product.
Deliverables
The operator functions the platform needed — including the registration review queue and member-state management the prototype lacked.
Operator and reseller workflows traced across tiers.
Build order grounded in operational necessity, validated with the founder.
An interview-and-mapping process the client can re-run as the product evolves.
Impact
Reflection
What this project revealed about discovery research with founders.
The question that unlocked the project was "what happens after submission?" Feature-wishlist conversations never reached it — walking the real workflow to its end state did.
The referral form was the most polished part of the prototype — multi-step navigation, photo uploads, draft persistence. But after submission there was nothing: no review queue, no approval state, no operator action. The sophistication of the intake form made the missing half invisible.
For founder-led products, the first research task is converting tacit operational knowledge into explicit requirements — before building anything more.