Two Ways We Jump: Speed and Certainty
In product development, the jump from an idea to a committed solution can happen for more than one reason. Sometimes a team moves quickly because building has become inexpensive and accessible. Sometimes the team moves with confidence because the customer, requirement, or previous answer feels familiar. In both cases, the result can be the same: a solution arrives before the problem is fully understood.
In Season 7 of Quality during Design, I’m exploring the question, “Why do we jump?” This solo episode looks at two of those reasons: speed and certainty. The issue is not that teams take action. Decisions and movement are necessary. The issue is jumping from partial understanding to commitment without noticing the gap in between: the space where teams should be questioning and investigating the problem.
The gap between an idea and a solution
Early product development includes a period between having an idea and committing to a solution. That is where the team needs to ask: Who is having a problem? What is the problem? What do we need to understand before we can adequately provide a solution?
It is possible to move decisively while still acknowledging what is not known. A decision is not automatically a jump. The design fog appears when the team stops noticing which parts of its understanding are assumptions and which parts have been checked.
Speed: When building becomes a substitute for learning
Today, teams can generate prototypes and concepts faster and more cheaply than before. Generative AI can support software development and concept generation. 3D printing and other rapid-prototyping methods make it easier to produce something tangible and realistic quickly.
That accessibility can make the jump feel harmless. The team can keep busy tweaking, prototyping, and improving while postponing more difficult work: contacting real users, staying with ambiguity, or making a decision tied to the problem the product is supposed to solve.
Speed is useful when the move is genuinely reversible and the feedback loop with users or customers is real. It becomes design fog when the team confuses activity with learning.
A practical check for fast methods
Before building or tweaking, ask two questions:
- What will this action teach us?
- When will we look at the evidence?
A fast-producing method should answer a particular question so the team can make a better-informed decision. If a prototype has no defined learning purpose, or if the team has not decided what evidence would change its direction, speed may only be postponing the important decision.
The opposite of speed is not automatically thoughtfulness. A team can also jump slowly and with a great deal of confidence.
Certainty: When a familiar answer stops being questioned
Certainty can come from an old customer persona, a familiar customer segment, a previous product success, or a long-standing requirement. The team may not feel rushed. It may feel responsible and well-informed. But that confidence can cause the team to stop treating its understanding as an assumption that needs checking.
Customers and their environments change. A product may remain familiar while the context around it changes. Customer expectations, workflows, and uses can shift. Metrics may show that something is happening, but they may not explain what is happening or why.
One useful question is: What do we know because we checked recently, and what do we believe because it used to be true?
When speed and certainty reinforce each other
Speed and certainty do not always operate separately. A team can build quickly because it is certain about the answer, then use the speed of execution as evidence that it was right to proceed. The amount of activity can begin to feel like confirmation.
To monitor speed, focus on what the team expects to learn and identify when new information would cause it to stop or change course. To monitor certainty, ask what has changed since the belief was formed. Consider not only the product but also the customers and the environment in which the product is used.
The question is not whether a team should ever be confident. The question is whether that confidence is still connected to the people using what the team builds.
Key Takeaways
- A decision is not automatically a jump. Teams need to act and make decisions; the problem is committing to a solution without noticing the gap in understanding.
- Speed should be connected to a learning question. A prototype or generated concept is useful when it produces evidence that informs the next decision.
- Certainty needs to be retested. Familiar customers, old requirements, and past successes can become assumptions when the surrounding context has changed.
- Activity is not the same as evidence. Building quickly can reinforce an existing belief unless the team has defined what it will learn and what would change its course.
Your challenge this week
Take one customer assumption your team is relying on and ask: “When was the last time we checked it against current behavior?” Then identify the evidence that would cause you to stop, change course, or revisit the solution.