Business development and engineering can drift apart when one side counts conversations and the other counts shipped features. The weekly review I want to introduce at Thora Vietnam will connect both to the same uncertainty. Its purpose is to decide what to test next, using evidence from discovery, coding, deployment and actual use.
Bring one experiment record
Each active experiment should have an owner, a hypothesis, a bounded action and a decision date. Before the review, attach observations and unresolved questions. Keep evidence that disagrees with the hypothesis; otherwise the meeting becomes a progress presentation.
For a small company, one clearly maintained page is more useful than a dashboard that nobody can explain.
Separate delivery from learning
Start by stating what was delivered, then ask what is now better understood. Deploying a demonstration is a delivery event. Discovering that users need a human review step is a learning outcome. Both matter, but they answer different questions.
Also ask whether the evidence is strong enough to decide. Sometimes the next step is better observation rather than another feature.
Make a bounded next commitment
Choose whether to continue, adapt or stop the experiment, and write the reason. Translate that decision into one next action with an owner and a review date. Avoid changing the customer segment, offer and delivery method simultaneously; that would make the next result difficult to interpret.
A pivot should be a reasoned change in direction, not a new name for an unchanged assumption.
Keep the record useful outside the meeting
The proposed review should leave a short decision log that informs the next discovery conversation and the next development task. Carry forward important risks and customer commitments. Over time, this can become Thora Vietnam’s operating memory: what was tried, what was observed and why the next choice was made.
Connect the weekly review to a manageable work queue
For an initial routine, Thora Vietnam can keep one active delivery experiment per available owner and a separate list of ideas waiting for evidence. This is a proposed capacity rule, not a report of the current team. Discovery conversations can continue, but new delivery promises should account for support and existing commitments.
A short proposed agenda is: review the original question, inspect the evidence, check delivery effort, decide the next move and assign one bounded action. Change the meeting length to fit the work; a meeting held every week is not evidence of learning by itself.
Make pivot, persevere and stop operational decisions
Continue when the evidence justifies testing the same core assumption again or serving the same need more reliably. Change direction when a specific assumption has been contradicted and there is a reason to test an alternative. Stop when the potential benefit does not justify further cost, access cannot be obtained or the pilot exceeds agreed limits.
For example, interest from users without buyer commitment could justify testing a different commercial offer, not necessarily rebuilding the product. A workflow that only works with constant intervention could justify narrowing its scope. Record what changes and what stays fixed so the next observation remains interpretable.
Use a short decision record and carry it forward
Bring the record into the next discovery conversation, technical task and customer update. Keep the original observation separate from the interpretation, and keep a link to the evidence with access appropriate to its sensitivity.
Review date and experiment:
Original question and agreed limits:
What we delivered:
What we observed, including contradictions:
Cost, support effort and remaining uncertainty:
Decision and rationale:
Next action, owner and review date:
What must be true before we expand:Let later implementation follow repeated learning
A future monthly review can compare patterns across experiments: which customer need recurs, which offer is accepted, which deployment steps repeat and which support burden grows. Use those patterns to decide whether to document a service package, improve onboarding or test a reusable component. Do not turn every request into a roadmap commitment.
Future PNSoft articles about Thora Vietnam should connect to a dated experiment or clearly state that they propose a next step. When there are actual results, publish the relevant context, limitations and changed decision. Until then, this series remains a practical guide for implementation rather than a completed-business case study.
Further reading
Background for the method; the Thora Vietnam workflow above is a proposed application.
The Lean Startup — Methodology
