What are we building?
Clarify the productization intent before scope hardens.
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?
Content adapted from the original platform and SaaS discovery materials into an interactive scaled-solution playbook.
Client-first, reuse possible
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 possible
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
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
Decision stages
Use the stages to understand how the activities connect without reading the full framework in one pass.
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.
Explore the framework one activity at a time.
Choose the path that best matches your situation. The activity guide will update to show which activities are Core, Useful, Later, or Advanced for that path.
What are we building?
Clarify the productization intent before scope hardens.
What are we building?
Clarify the productization intent before scope hardens.
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.
Output: Productization intent decision and tradeoff summary.
Is the problem repeatable?
Use benchmarks, customer layers, and problem evidence to test repeatability.
Is the problem repeatable?
Use benchmarks, customer layers, and problem evidence to test repeatability.
Benchmarking and research
Understand existing products, alternatives, pricing, onboarding, support, configuration, and analytics patterns.
Output: Benchmark matrix and opportunity gap summary.
Identify customer segments
Identify who buys, approves, configures, uses, supports, reports on, and technically enables the product.
Output: Customer segment map with interview priorities.
Design the product discovery sessions
Choose the right discovery session formats, participants, evidence capture, and follow-up rhythm.
Output: Discovery session plan, notes structure, decision log, and risk log.
Prototype Guidance for Scaled Solution Discovery
Use prototypes to test flows, roles, dashboards, configuration, tenant behavior, or visual direction before finalizing requirements.
Output: Prototype objective, feedback notes, decisions, and next action.
Validate repeatable problem
Determine whether the problem is repeatable across customers or specific to one client.
Output: Problem validation summary with evidence strength.
What should be reusable?
Separate core, configurable, extension, custom, and MVP boundaries.
What should be reusable?
Separate core, configurable, extension, custom, and MVP boundaries.
Define platform boundaries
Separate reusable product core from configurable, extension/add-on, and custom requirements.
Output: Core, configurable, extension, and custom feature matrix.
Define MVP and roadmap
Define the smallest useful product based on intent: current client success or repeatable SaaS validation.
Output: MVP scope and initial roadmap.
Can it scale operationally?
Review tenant, admin, support, pricing, technical, and governance implications together.
Can it scale operationally?
Review tenant, admin, support, pricing, technical, and governance implications together.
Define configuration, tenant, access, and analytics model
Clarify tenant, access, configuration, governance, data separation, and analytics models before architecture hardens.
Output: Tenant, access, configuration, governance, and analytics 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.
Output: Onboarding, setup, support, and operations model.
Explore pricing and packaging
Create a pricing and packaging hypothesis when external sale, future packages, modules, limits, or add-ons matter.
Output: Pricing and packaging hypothesis or future packaging note.
Assess technical scalability and architecture
Assess whether architecture can support a scaled, reusable, and governable solution safely and repeatedly.
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.
What should we do next?
Use pilot learning and final recommendation criteria to choose the next move.
Plan pilot and validation
Design a controlled pilot to test value, setup, adoption, support, measurement, and risk before full investment.
Output: Pilot plan with success metrics and decision criteria.
Output
Package evidence so Product, BA, Tech, QA, Commercial, and leadership can understand the recommendation.
Output: Discovery evidence package.
Final Recommendation
Choose the next step based on repeatability, readiness, evidence, architecture, and investment confidence.
Output: Final recommendation and decision rationale.