Translation and notes
A readable adaptation of the article's core ideas, with the original source clearly credited.
A founder's resourcefulness includes following the implications of feedback, even when those implications are uncomfortable. That is the idea behind this short adaptation; taking advice seriously does not mean obeying it. The procurement-software scenario below is an independent exercise, not a complete translation or a method attributed to the original author.
Imagine a buyer saying that a finance manager must approve use of your software. Before treating this as a request for an approval-workflow feature, separate the customer's statement from your interpretation. Approval might concern a real purchase, entering company data, or merely evaluating the tool. With permission, ask the process owner to walk through a past request using redacted or fictional information. Record where authorization was required and what stopped progress. If that person is unavailable, mark the question unresolved rather than treating silence as evidence for a feature.
Write two competing explanations: the workflow is missing, or a limited evaluation simply needs permission. Review a non-operational workflow mockup to explore the first; ask whether a fictional-data session without company-system connections is permitted to explore the second. Do not bypass organizational approvals or process real purchases. Name an owner, a review date, and an observation that would weaken each explanation before beginning. An end-of-week review is a possible boundary for this exercise, not a general sales benchmark.
At review, choose a bounded outcome: enough evidence for another prototype, one specific follow-up conversation, or a pause. Document the observation, the interpretation that changed, and the remaining uncertainty. Send the customer a brief recap to check for misunderstanding. A single organization's process does not establish market-wide demand. The useful output is a decision another teammate can inspect, including its scope and the evidence that would cause the team to revisit it, rather than a count of suggestions accepted.
Selected advice from the article
- Prepare fields for the statement, interpretation, open question, owner, and review date.
- Use fictional data and respect the customer's approval process.
- Review the decision note with a teammate before scheduling feature development.
Operating takeaways
- Keep customer statements separate from team interpretations.
- Clarify whether approval concerns a purchase, data use, or evaluation.
- Define a contrary observation and review date for each explanation.
- Treat unavailable decision-makers as unresolved evidence.
- Assign follow-up ownership and limit conclusions to the observed context.
Quick feedback
What did this article make clearer for you?
Choose a reaction or share a question or experience. Useful responses can shape future notes.
This is a free adaptation, not a word-for-word republication of the original article.