Technology decisions
Separate today's product from tomorrow's roadmap.
Keep current capability, configuration work and supplier roadmap commitments separate when comparing technology options.
In a hypothetical supplier demonstration, a team asks whether the platform can handle an important approval rule. The answer is encouraging: the capability is on the roadmap for next year. By the time the evaluation notes are combined, the requirement is marked as covered. A roadmap can be useful evidence of direction. It is not the same as a capability that exists, has been demonstrated and can be relied upon for your planned launch.
Use four evidence labels
For each important requirement, record one of four positions: available now, possible through agreed configuration, requires additional delivery, or planned by the supplier. Keep these labels visible in the comparison instead of converting them too early into a single score.
“Available now” should mean the relevant scenario was demonstrated or verified in suitable current product evidence. “Configuration” should identify who performs it, what it affects and whether it sits inside the proposed scope. Additional delivery needs an owner, estimate, dependency and acceptance route. A roadmap item remains a future dependency.
Make the roadmap dependency explicit
If a future capability matters to the decision, record the supplier's stated target, the evidence provided and the business date by which it would need to be usable. Distinguish a published commitment from an indicative conversation.
Ask how the supplier communicates changes, whether the item is included in the proposed commercial arrangement and what customer action would be required to adopt it. Do not invent contractual certainty from a presentation slide. Confirm consequential commitments through the actual proposal and agreement.
Decide what happens if it moves
For every critical future item, define the practical fallback. The business might change its process, retain another tool, deliver a bounded workaround or choose a different platform. Each option carries work and risk that belongs in the decision.
Avoid a fallback that quietly depends on the same unconfirmed capability. If the roadmap date moves, name who decides whether the overall plan changes and what evidence they will use.
Recheck before commitment and mobilisation
Roadmaps change. Review important future dependencies before contract, detailed design and mobilisation. Replace old statements with current evidence and keep the earlier position in the decision record where it explains why the option was selected.
Then keep product fit and delivery confidence visible together. A strong current product may still create an unacceptable dependency; a promising roadmap may be worth monitoring without being treated as delivered. Rethink's technology second opinion can provide an experienced challenge to both the stated capability and the plan around it.