When to use
- The same solution may serve multiple units, departments, clients, or tenant-like contexts.
- Ownership, configuration, permissions, onboarding, support, or commercialization are unclear.
Are we building a one-time solution, a reusable platform, a client-first product with future reuse potential, or a scalable product that must work across multiple contexts from the start?
Pick the direction that matches the evidence, ownership model, and reuse potential.
Client-first, reuse friendly
Use this lens when a real client or business unit need exists now, but the team also wants to understand what could stay reusable.
Client-first, reuse friendly
For a client-first path, pay closest attention to intent, product boundaries, platform readiness, MVP scope, and pilot learning. These activities help explain how much reuse can be protected without losing the immediate client need.
Clarify productization intentDefine platform boundariesDefine configuration, tenant, access, and analytics modelDefine MVP and roadmapPlan pilot and validation
When not to use
- The work is a one-off internal workflow with no repeatability need.
- The main uncertainty is broad external-user adoption rather than product operating model.
Start with
- Clarify the productization path: custom, internal platform, reusable client solution, or SaaS-friendly model.
- Define buyer, admin, end-user, governance, support, and configuration needs.
- Identify what must be standardized and what must stay configurable.
Use AI to accelerate the work, not approve it.
Open the AI Assist tab inside an activity for a contextual workflow, verification checks, and prototyping guidance.
Compare configuration, onboarding, administration, permissions, integrations, analytics, pricing, packaging, support, and tenancy.
Keep buyer, governance owner, administrator, and daily-user evidence separate in notes and decisions.
Draft product boundaries, tenant and access models, operations, pricing, architecture readiness, MVP, pilot, and recommendation artifacts.
Create role-specific buyer, administrator, configuration, onboarding, and daily-use experiences using the approved design system.
Activities
What are we building?
Clarify the productization intent before scope hardens.
Activity 1CoreClarify productization intent
Decide whether the work should stay custom, become reusable, become an internal platform, or move toward a scalable product before scope expands.
Typical output: Productization intent decision and tradeoff summary.
Clarify productization intent
Decide whether the work should stay custom, become reusable, become an internal platform, or move toward a scalable product before scope expands.
Typical output: Productization intent decision and tradeoff summary.
Is the problem repeatable?
Use benchmarks, customer layers, and problem evidence to test repeatability.
Activity 2UsefulBenchmarking and research
Understand existing products, alternatives, pricing, onboarding, support, configuration, and analytics patterns.
Typical output: Benchmark matrix and opportunity gap summary.
Benchmarking and research
Understand existing products, alternatives, pricing, onboarding, support, configuration, and analytics patterns.
Typical output: Benchmark matrix and opportunity gap summary.
Activity 3LaterIdentify customer segments
Identify who buys, approves, configures, uses, supports, reports on, and technically enables the product.
Typical output: Customer segment map with interview priorities.
Identify customer segments
Identify who buys, approves, configures, uses, supports, reports on, and technically enables the product.
Typical output: Customer segment map with interview priorities.
Activity 4UsefulDesign the product discovery sessions
Choose the right discovery session formats, participants, evidence capture, and follow-up rhythm.
Typical output: Discovery session plan, notes structure, decision log, and risk log.
Design the product discovery sessions
Choose the right discovery session formats, participants, evidence capture, and follow-up rhythm.
Typical output: Discovery session plan, notes structure, decision log, and risk log.
Activity 5LaterPrototype Guidance for Scaled Solution Discovery
Use prototypes to test flows, roles, dashboards, configuration, tenant behavior, or visual direction before finalizing requirements.
Typical output: Prototype objective, feedback notes, decisions, and next action.
Prototype Guidance for Scaled Solution Discovery
Use prototypes to test flows, roles, dashboards, configuration, tenant behavior, or visual direction before finalizing requirements.
Typical output: Prototype objective, feedback notes, decisions, and next action.
Activity 6UsefulValidate repeatable problem
Determine whether the problem is repeatable across customers or specific to one client.
Typical output: Problem validation summary with evidence strength.
Validate repeatable problem
Determine whether the problem is repeatable across customers or specific to one client.
Typical output: Problem validation summary with evidence strength.
What should be reusable?
Separate core, configurable, extension, custom, and MVP boundaries.
Activity 7CoreDefine platform boundaries
Separate reusable product core from configurable, extension/add-on, and custom requirements.
Typical output: Core, configurable, extension, and custom feature matrix.
Define platform boundaries
Separate reusable product core from configurable, extension/add-on, and custom requirements.
Typical output: Core, configurable, extension, and custom feature matrix.
Activity 8CoreDefine MVP and roadmap
Define the smallest useful product based on intent: current client success or repeatable SaaS validation.
Typical output: MVP scope and initial roadmap.
Define MVP and roadmap
Define the smallest useful product based on intent: current client success or repeatable SaaS validation.
Typical output: MVP scope and initial roadmap.
Can it scale operationally?
Review tenant, admin, support, pricing, technical, and governance implications together.
Activity 9CoreDefine configuration, tenant, access, and analytics model
Clarify tenant, access, configuration, governance, data separation, and analytics models before architecture hardens.
Typical output: Tenant, access, configuration, governance, and analytics model.
Define configuration, tenant, access, and analytics model
Clarify tenant, access, configuration, governance, data separation, and analytics models before architecture hardens.
Typical output: Tenant, access, configuration, governance, and analytics model.
Activity 10UsefulDefine onboarding, support, and operations model
Define how teams, units, or customers are onboarded, configured, trained, supported, escalated, reported on, and maintained over time.
Typical output: Onboarding, setup, support, and operations model.
Define onboarding, support, and operations model
Define how teams, units, or customers are onboarded, configured, trained, supported, escalated, reported on, and maintained over time.
Typical output: Onboarding, setup, support, and operations model.
Activity 11AdvancedExplore pricing and packaging
Create a pricing and packaging hypothesis when external sale, future packages, modules, limits, or add-ons matter.
Typical output: Pricing and packaging hypothesis or future packaging note.
Explore pricing and packaging
Create a pricing and packaging hypothesis when external sale, future packages, modules, limits, or add-ons matter.
Typical output: Pricing and packaging hypothesis or future packaging note.
Activity 12AdvancedAssess technical scalability and architecture
Assess whether architecture can support a scaled, reusable, and governable solution safely and repeatedly.
Typical output: Architecture readiness note with risks and product decisions needed.
Assess technical scalability and architecture
Assess whether architecture can support a scaled, reusable, and governable solution safely and repeatedly.
Typical output: Architecture readiness note with risks and product decisions needed.
What should we do next?
Use pilot learning and final recommendation criteria to choose the next move.
Activity 13CorePlan pilot and validation
Design a controlled pilot to test value, setup, adoption, support, measurement, and risk before full investment.
Typical output: Pilot plan with success metrics and decision criteria.
Plan pilot and validation
Design a controlled pilot to test value, setup, adoption, support, measurement, and risk before full investment.
Typical output: Pilot plan with success metrics and decision criteria.
Activity 14LaterOutput
Package evidence so Product, BA, Tech, QA, Commercial, and leadership can understand the recommendation.
Typical output: Discovery evidence package.
Output
Package evidence so Product, BA, Tech, QA, Commercial, and leadership can understand the recommendation.
Typical output: Discovery evidence package.
Activity 15UsefulFinal Recommendation
Choose the next step based on repeatability, readiness, evidence, architecture, and investment confidence.
Typical output: Final recommendation and decision rationale.
Final Recommendation
Choose the next step based on repeatability, readiness, evidence, architecture, and investment confidence.
Typical output: Final recommendation and decision rationale.
Decision stages
What are we building?
Clarify the productization intent before scope hardens.
Is the problem repeatable?
Use benchmarks, customer layers, and problem evidence to test repeatability.
What should be reusable?
Separate core, configurable, extension, custom, and MVP boundaries.
Can it scale operationally?
Review tenant, admin, support, pricing, technical, and governance implications together.
What should we do next?
Use pilot learning and final recommendation criteria to choose the next move.
Different directions, not a ladder.
The right answer depends on evidence, ownership, repeatability, architecture, and investment appetite. SaaS is not automatically better.
Custom deliveryReusable moduleInternal platform/shared capabilityClient-first reusable productSaaS-style product
People, artifacts, escalation
Minimum participants
ProductCommercial or business ownerGovernance ownerAdmin stakeholdersSupportTech lead
Minimum artifacts
- Productization path decision
- Governance and ownership model
- Role and permission model
- Configuration model
- Support and repeatability model
Escalate if
- Sensitive data, payment, or compliance requirements vary by client or unit.
- Technical architecture cannot support the intended repeatability.
- Commercial promises are being made before operations and support are defined.
Check the evidence before moving forward.
What decision will this discovery evidence support?
What user, process, data, system, or model evidence would change the decision?
Which risk remains unresolved, and who accepts it if the team proceeds?
What artifact proves the team is ready for build, pilot, rollout, or scale?
Continuous Discovery
Cadence
- Weekly or biweekly signal review for live behavior, support issues, and adoption friction.
- Monthly user or stakeholder touchpoints for deeper problem discovery.
- Quarterly roadmap and outcome review using evidence, not only delivery volume.
Activities
- Track behavior, funnel, support, operational, and trust signals after launch.
- Keep a discovery backlog of assumptions, unresolved risks, and improvement hypotheses.
- Run lightweight interviews, usability checks, experiment reviews, or data validation as new evidence appears.
- Feed validated learning into roadmap, backlog, support readiness, and deprecation decisions.
Outputs
Discovery backlogLearning logExperiment or validation planOutcome dashboardRoadmap recommendation