Deciding what to change is also a valuable result of exploring an idea.
The initial idea: materials that approve themselves
The team feels that reviews keep repeating and proposes automatic approval. It imagines a screen where someone uploads a piece and receives an answer. The image is attractive because it promises to resolve a familiar frustration. Yet it does not explain what the tool should check or what it can decide from the available information.
Before commissioning that application, review examples of work that currently returns for revision. The aim is not to represent the whole business but to understand the difference between material that is ready and material requiring intervention. In this fictional situation, participants include the creator, someone who knows the commercial terms and someone who authorizes publication.
The finding: the reviews involved different problems
Looking at the examples reveals different reasons for review. One piece needs a change in tone. Another uses an outdated commercial term. A third mentions a project whose publication has not yet been authorized. All return for review, but they cannot be resolved using the same criterion or reference.
The finding changes the original idea. Grouping everything under approval concealed different decisions. Help comparing variants could be useful in the first case; the second needs a current reference; the third requires someone to confirm authorization. A tool can prepare information for those decisions while the team retains the knowledge and permissions needed to make them.
The proposition that emerges after review
The team could shift from automatic approval to better preparation for a review: for example, gathering the variants and context needed by the decision-maker. It could also separate a creation problem from a coordination problem rather than expecting one screen to solve both.
Wiwo.Lab offers tools for creating and working on materials; Wiwo.Ops organizes projects, tasks and collaboration. These public capabilities offer paths worth understanding. The choice and any relationship between products must be reviewed for the specific scope. Exploration’s value lies in defining the work more clearly before assigning it to a new application.
The context behind a number
Before interpreting a metric, agree on what it represents and the conditions behind it.
What is counted and what is excluded.
Three possible decisions, with different reasons
Continuing makes sense when the need remains clear and the representation helps establish what the solution should do. Changing is appropriate when examples reveal that the problem lies elsewhere. Setting a path aside can be reasonable if it requires building something that does not address the main difficulty.
These are options for this example, not an internal Wiwo procedure or a universal recipe. What matters is explaining why a decision follows from what was observed. Exploration becomes more than a presentation seeking approval: it offers an opportunity to adjust the commitment.
- Continue: prepare version comparisons with a defined objective and review owner.
- Change: organize the information accompanying each piece before extending technological assistance.
- Set aside: stop automatic approval if it depends on decisions the team has not yet agreed.
Keep what you learned, even when the idea changes
Record the initial situation, the finding that changed the idea and the selected next step. Keep unanswered questions visible. If a new proposal looks like the first one, explain what changed in its purpose: a similar screen can support a very different decision.
This connects with Humanity, Augmented.: technology extends what people can prepare, understand and do, while judgment provides direction. When speaking with Wiwo, bring what you decided not to build and the reasons. It avoids repeating the same discussion and helps focus work on a capability the team actually needs.
Frequently asked questions
Does changing an idea after exploring it mean the trial failed?
It can mean that useful information emerged. What matters is explaining what was learned and why the new direction better addresses the observed problem.
How can I distinguish a tool problem from an unresolved team decision?
Examine what is missing before work can continue. If nobody has defined a condition, an authorization or who decides, the business needs to answer that question. You can then consider which technological support would be useful.
