Making a Recommendation
Write a decision memo that exposes the reasoning and the risk. · Product Judgment · Lesson 15 · 4 min
Making a Recommendation · 4 min
Situation
The meeting has opinions but no decision.
A customer-support team cannot keep up with weekly account reports. Sales wants automation before an upcoming pilot. Engineering sees three options with different costs.
Your job is to turn that disagreement into a recommendation someone can assess. A memo should make the decision easier, not document every conversation.
Structure
Put the choice in a clear sequence.
State context, problem, options, trade-offs, recommendation, reasoning, and risk. Include the decision owner and the concrete ask when needed.
Keep facts separate from forecasts. “We have 12 pilot accounts” is a fact in this scenario. “We expect 200 accounts next quarter” is a planning assumption that needs a source and confidence level.
Decision memo
Context and problem.
“The pilot begins Monday with 12 accounts. Support currently assembles each weekly report in 20 minutes. At pilot volume that is four hours per week. The numbers already exist, but assembling and checking them is manual.”
“The decision is how to deliver accurate reports during the pilot without delaying the start or committing to an unproven platform investment.”
Decision memo
Options and trade-offs.
“A: a fixed export and a documented manual check, estimated at three days. This meets the pilot date but retains operational work.”
“B: scheduled reports with monitoring, estimated at three weeks. This reduces repeated work but delays availability.”
“C: a flexible report builder, estimated at eight weeks. This supports more use cases but adds complexity before we know which reports customers value.”
Decision memo
Recommendation and reasoning.
“Choose A for the pilot, with one report template and a named support owner. The team has capacity for four hours a week, and the pilot's purpose is to learn whether customers use the report.”
“Record corrections and requests during the pilot. Revisit B when sustained report work exceeds the agreed support capacity or when demand is established. Do not begin C without evidence that customers need self-service customization.”
Decision memo
Risk and ask.
“The main risk is an incorrect manual report. Require a second-person check for the pilot and a clear correction process. If support cannot commit the capacity, A is not viable and we must change the date or scope.”
“Ask: approve the narrow pilot approach today and confirm the support owner. Review the operating data after two report cycles.”
Think it through
What would change your recommendation?
If 200 accounts were already contracted for Monday, manual work would rise to roughly 67 hours each week at the same rate. That changes the capacity argument.
You might narrow the pilot, simplify the report further, or negotiate timing for automation. The correct response follows the changed conditions, not loyalty to the original option.
Remember this
Recommend an option, not a list of possibilities.
Show why the option fits the evidence and constraints, what it costs, and which risk needs active management. A strong recommendation is decisive without pretending uncertainty has disappeared.