<script type="application/ld+json"> { "@context": "https://schema.org", "@type": "HowTo", "name": "How to Use: Test Assumptions", "description": "Challenging early thinking before options harden. You have a working hypothesis about what is limiting supply chain capability but have not yet committed to a direction and are actively testing whether your read is correct.", "url": "/journey-stages/test-assumptions", "inLanguage": "en", "about": { "@type": "Thing", "name": "Test Assumptions decision stage", "description": "Challenging early thinking before options harden and commitments form" }, "step": [ { "@type": "HowToSection", "name": "Interpretation", "text": "This stage sits between general orientation and vendor evaluation. You are past the point of wondering whether something needs to change. You are not yet at the point of inviting vendors to present. The work here is resolving what kind of solution architecture is actually appropriate for your situation before any vendor has had the opportunity to anchor the conversation." }, { "@type": "HowToSection", "name": "Why the Test Assumptions stage", "text": "Decisions move into this stage when there is a named problem and a working hypothesis about what is causing it, but before any solution provider has been formally engaged. The risk is not that the hypothesis is wrong — it is that it hardens into a commitment before it has been properly stress-tested by someone with no stake in the answer." }, { "@type": "HowToSection", "name": "Where teams get stuck", "text": "Teams at this stage often move forward with more certainty than is warranted. Common patterns include treating early hypotheses as settled decisions, relying on a narrow set of perspectives, assuming alignment where assumptions actually differ, and skipping the architecture direction question." }, { "@type": "HowToSection", "name": "What tends to help", "text": "What is most valuable at this stage is constructive challenge, not validation. Leaders benefit from exposing assumptions to informed peer perspectives, understanding how others approached the build versus buy versus compose question, and separating what is known from what is still assumed." } ], "mentions": [ { "@type": "Person", "name": "Mark Twain" }, { "@type": "Person", "name": "Richard Feynman" } ], "provider": { "@type": "Organization", "name": "BestPractice.Club", "description": "A practitioner-led environment for working through complex, high-stakes supply chain capability investment decisions", "email": "info@bestpractice.club", "url": "https://bestpractice.club" } } </script>

TEST ASSUMPTIONS

Challenging early thinking before options harden and commitments form

It ain’t what you don’t know that gets you into trouble. It’s what you know for sure that just ain’t so

Mark Twain

Interpretation

If you have named the problem — you have a working hypothesis about what is limiting supply chain capability and what kind of investment might address it — but you have not yet committed to a direction and are actively testing whether your read is correct, this is where the quality of the eventual decision is most often determined.

This stage sits between general orientation and vendor evaluation. You are past the point of wondering whether something needs to change. You are not yet at the point of inviting vendors to present. The work here is resolving what kind of solution architecture is actually appropriate for your situation — before any vendor has had the opportunity to anchor the conversation.

This is also the stage where independent peer input is most scarce and most valuable. Vendors cannot be trusted as advisors here because they have a stake in the outcome. Consultants often do too. Reference calls are vendor-selected. The only genuinely independent source is a practitioner who has resolved a comparable architecture question in a comparable context with no commercial stake in the outcome. That is what BestPractice.Club is designed to provide.

Why the Test Assumptions stage?

Decisions move into this stage when there is a named problem, a working hypothesis about what is causing it, and a growing sense that something needs to be done — but before any solution provider has been formally engaged.

The conditions that characterise this stage are: a diagnosis that has been formed internally but not yet independently tested, assumptions about root cause and solution direction that feel settled but have not been exposed to peer challenge, and options that are beginning to narrow before the architecture direction question has been resolved. The risk is not that the hypothesis is wrong — it is that it hardens into a commitment before it has been properly stress-tested by someone with no stake in the answer.

The practitioners who navigate this stage well are those who actively sought out independent challenge before their thinking solidified. Those who did not often find themselves revisiting the diagnosis later, at significantly greater cost.

Why the Orient decision stage?

Decisions typically move into later stages when certain conditions begin to show up:

  • a clearly defined problem,
  • a shared sense of what success looks like,
  • visible senior sponsorship,
  • identifiable trade-offs,
  • and some form of commitment pressure (time, budget, reputation, or dependency).

Based on your responses, those signals don’t yet appear to be consistently present. That doesn’t mean a decision isn’t forming — only that it hasn’t yet solidified into something that most stakeholders would recognise as a concrete project requiring sustained commitment of time, attention, or capital.

In practice, this usually means that while there is intent or concern, key elements of a well-framed decision are still emerging: the real alternatives may not yet be clear, consequences are still being explored, uncertainty remains high, and it’s not yet obvious what would be hard to reverse later.

This is a common — and often sensible — position in complex contexts, where acting too early can be riskier than waiting until the decision is framed clearly enough for others to engage with it confidently.

Where teams typically get stuck

Teams at this stage often move forward with more certainty than is warranted.

Common patterns include:

  • Treating early hypotheses as settled decisions — moving to solution evaluation before the problem framing has been independently tested
  • Relying on a narrow set of perspectives — particularly those of people who already share the same assumptions
  • Assuming alignment where assumptions actually differ across teams — which only becomes visible when finance, IT, or leadership engage
  • Skipping the architecture direction question — moving directly from problem awareness to vendor demonstrations without resolving what kind of solution is actually appropriate

Because progress feels real at this stage, these gaps often go unchallenged until they surface later as resistance, rework, or loss of confidence in the investment case.

What next:

What tends to help at this point

What is most valuable at this stage is constructive challenge, not validation.

Leaders in similar situations typically benefit from:

  • Exposing assumptions to informed peer perspectives — people who have navigated comparable architecture decisions in comparable contexts
  • Understanding how others approached the build versus buy versus compose versus wait question — including what they would do differently
  • Testing whether the diagnosis is correct before it hardens into a solution preference
  • Identifying blind spots before options narrow — particularly around data readiness, organisational capability, and the hidden costs of different architecture routes
  • Separating what is known from what is still assumed

This is less about finding answers and more about improving the quality of the direction that is forming.

Suggested next steps

If this resonates, peer-led discussion with practitioners who have recently resolved comparable architecture questions is typically the most useful next move.

The Confidence Before Commitment meeting on 12 November in London includes a session specifically on how AI is changing the build versus buy trade-off — which addresses the most significant architecture direction shift currently affecting capability investment decisions. It is designed for practitioners at exactly this stage.

Upcoming online sessions also address the specific diagnostic and architecture direction questions that arise at Test Assumptions. See the session calendar for what is coming up.

If you are not yet ready for a session, signing up for relevant updates is the lowest-commitment next step. We will send you practitioner cases and thinking that is relevant to where you are as our members work through similar decisions.

Join us at Confidence Before Commitment

The first principle is that you must not fool yourself... and you are the easiest person to fool

Richard Feynman

A quick note on how to read this

BestPractice.Club is not a consultancy and does not provide advisory services based on full organisational discovery.

What you see here reflects pattern recognition drawn from many years of conversations with supply chain and operations leaders facing real, high-stakes decisions. It is intended to help you orient yourself, clarify your decision position, and understand what often proves useful at similar points — not to provide definitive advice tailored to your specific circumstances.

Any suggestions are indicative, not exhaustive, and are made without full visibility of your organisation, constraints, or risk profile. Decisions remain yours, and should be tested against your own data, context, and governance processes.

If this framing doesn’t quite fit, that’s normal. Real decisions rarely move in straight lines, and teams often revisit earlier stages as new information emerges. If it would help to talk through your situation and sense-check where you are, you’re welcome to schedule a short conversation.