Scoping decisions
How to evaluate internal tools vs new products
Match the build to the user and the problem before committing to a new product.
Cortez Lake
Choose between an internal tool, a customer-facing product, and an extension to existing software by defining the user, the value, and the work required to operate it.
Separate the user from the buyer
An executive may sponsor the project while an operations team uses the software every day. A customer may pay for a service whose main improvement comes from an internal tool. Start by naming who will use the system and whose problem it resolves.
Document the current task, the expected improvement, and how the team will observe that improvement. This prevents a broad ambition such as “build an AI product” from substituting for a defined need.
Choose an internal tool for a bounded operating need
An internal tool can fit when the users and workflow belong to the organization: a review queue, approval process, case-preparation task, or handoff between teams. The main question is whether it improves the work enough to justify building and maintaining it.
Internal does not mean informal. The tool still needs access controls, support, an owner, and a plan for changes. Validate it with the people who will use it, including those who handle exceptions and reconcile results with other systems.
Test whether customer value belongs in a new product
A customer-facing product needs evidence that the intended users want the capability and can adopt it. In addition to the feature, consider onboarding, support, reliability expectations, commercial terms, and the cost of serving different customers.
An extension may be more appropriate when an existing product already has the identity, data, and workflow context the feature needs. Check the integration limits and long-term fit before creating a separate interface or service.
- Use an internal tool when the primary outcome is better execution within your team.
- Extend an existing product when it can support the use case without an awkward workaround.
- Consider a new product when customer demand and operating requirements justify a separate offering.
Make the investment decision explicit
Compare the options against the same criteria: user value, implementation effort, dependencies, adoption, and operating responsibility. Include buying or configuring an existing product as a real option.
The decision should explain why the selected approach fits, what remains uncertain, and what evidence is needed next. H2H helps teams make that choice before a large implementation commitment. A small test or a decision to defer may be the most useful outcome.
Next step
Decide what deserves a build.
H2H helps your team compare the options, define the user and workflow, and choose a proportionate next step.