Discovery Workflow | FH Development Studio

Overview

Use this checklist to keep scoping clear, complete, and accountable.

The workflow is intentionally not connected to any backend yet. It exists as a structured planning surface the upcoming admin app can adopt.

1. Intake and Initial Framing

Capture the basics before discussing solutions so the recommendation starts from the real problem and constraints.

Clarify requester and business contextRecord the company, point of contact, and whether the work supports a new initiative, an existing product, or internal operations. Define the problem in plain languageDocument what is not working today, who is affected, and what success would feel like from the client’s perspective. Identify delivery pressureNote deadlines, launch windows, staffing constraints, or dependencies that materially shape scope decisions.

2. Users, Platforms, and Product Context

Make sure the team understands who the product serves and where it needs to perform well.

List target users or stakeholder groupsCapture primary users, secondary users, internal teams, and anyone else who influences requirements or approval. Confirm platform expectationsDocument whether the work targets iPhone, web, responsive marketing pages, internal dashboards, or a multi-platform release. Review current assets or product stateRecord existing designs, codebases, live URLs, analytics, support notes, or screenshots that provide relevant context.

3. Scope Definition

Translate the problem into a practical first-release scope before design and build recommendations are made.

Define must-have outcomesSeparate required capabilities from secondary ideas so the first release is realistic and strategically useful. List explicit out-of-scope itemsDocument what will not be included in the first phase to reduce ambiguity and prevent hidden expansion later. Identify dependencies and blockersCapture content, credentials, assets, approvals, integrations, app store requirements, or third-party services needed before work can proceed smoothly.

4. Risk and Recommendation Review

Pressure-test the plan before the work shifts into estimates, sequencing, and execution.

Call out technical and delivery riskNote any architecture concerns, unknown integrations, unclear content ownership, or timeline assumptions that could change the recommendation. Choose the strongest first-release approachDocument whether the best path is a lean MVP, a focused redesign, a support stabilization pass, or a staged implementation plan. Align on next-step recommendationSummarize the recommended scope, likely sequence, expected inputs, and what FH Development Studio should prepare next.

5. Handoff Into Delivery Planning

Close discovery by making the decision trail clear enough for design, development, or admin workflow follow-up.