On this page
At 9:30 pm, a mentor tells you to narrow your customer segment. The next day, another tells you to expand it. Without a student founder mentor decision log, both conversations become loose notes, and your team ends up acting on whoever spoke last.
Why mentor advice needs a record
Student founders often collect advice faster than they can test it. You speak to alumni, professors, operators, investors, early users, and friends who have built before. Each person sees your company through a different lens, which means their recommendations can conflict without either person being wrong.
The problem starts when advice enters your work as an instruction rather than an input. “Build this feature,” “charge more,” and “find a co-founder first” are not decisions by themselves. They are hypotheses shaped by someone else’s experience, incentives, and available information.
A mentor decision log gives every major recommendation a place to live. It records who said it, what problem they were reacting to, what evidence existed at the time, what you chose, and what happened after you acted. That record protects you from memory bias and from changing direction every week.
For a student founder, this matters because your time is limited. Classes, exams, placement pressure, team coordination, and customer work compete for the same hours. A written decision system helps you spend those hours on the few questions that can change your startup’s direction.
Build your student founder mentor decision log
Your log does not need expensive software or a complex operating setup. Start with one shared document or spreadsheet that your core team can access. Create one entry for every piece of advice that could affect your customer, product, pricing, team, funding plan, or go-to-market motion.
Do not log generic encouragement. Log advice that asks you to make a trade-off. If a mentor says your pitch needs more clarity, ask what specific claim, slide, or proof point is weak before adding the entry.
Use these fields for each entry:
- Date: When did you receive the advice?
- Source: Who gave it, and what is their relevant context?
- Decision area: Customer, product, pricing, team, funding, or go-to-market.
- Advice received: Write the recommendation in plain language.
- Evidence cited: What customer data, market observation, or operating experience supported it?
- Your decision: Accept, reject, defer, or test.
- Owner and deadline: Who will act, and by when?
- Result: What did you learn after acting?
Keep the wording short enough that your team will maintain it. A decision log is useful only when it becomes part of how you work, not another document you update before a review meeting.
Separate opinions from evidence
Mentors can be experienced and still give advice that does not fit your stage. A founder who scaled a sales team may have strong views on hiring but limited context on whether you have found a customer problem worth solving. Your job is to respect the experience without outsourcing your judgment.
Use a simple filter before you act. Ask whether the advice is based on direct evidence from your startup, a comparable company, or a broad belief about how startups should work. The first category should carry the most weight.
| Type of input | What it sounds like | What you should do |
|---|---|---|
| Customer evidence | “Five users could not complete this step.” | Investigate and test a fix quickly. |
| Comparable experience | “We faced this issue when selling to colleges.” | Check whether your customer and buying process are similar. |
| Personal preference | “I would never use a product designed this way.” | Record it, but do not treat it as market proof. |
| Investor expectation | “You need a clearer use of funds.” | Assess whether it exposes a fundraising gap in your story. |
Add an evidence score beside each entry: strong, partial, or weak. This stops a confident opinion from quietly becoming your roadmap. It also makes later reviews easier, because you can see whether your team acted on data or on pressure.
When two mentors disagree, do not average their advice. Identify the assumption beneath each view, then design the smallest test that can prove one assumption wrong.
Run a weekly decision cadence
A log works when it has a review rhythm. Set aside 20 minutes every week with your co-founders or core team. Review new entries, assign tests, close old decisions, and flag advice that has become outdated because your product or customer understanding changed.
Use a status column: open, testing, decided, or closed. A structured mentoring guide recommends linking decisions to a document or issue with a status and date, then reviewing handoffs in the next work cycle. That approach is useful for student teams because it turns conversations into accountable work rather than vague follow-ups. Source
- Monday: Add advice from the previous week and identify decisions that need evidence.
- Midweek: Run customer calls, prototype checks, pricing conversations, or desk research tied to open entries.
- Friday: Decide what to continue, stop, or test again.
- Before mentor meetings: Send the two or three unresolved decisions, not a broad company update.
This cadence changes the quality of mentor conversations. Instead of asking, “What should we do next?”, you can ask, “We have evidence pointing in two directions. Which assumption do you think we are missing?” That is a better question, and it earns better feedback.
If you want help turning early founder activity into a disciplined fundraising plan, Apply for Nebula 1.0. Our current live program is a two-week fundraising sprint for founders who need a sharper investor case.
Turn advice into small tests, not permanent changes
Most mentor advice should create a test before it creates a permanent product or business decision. A student team can lose weeks building a feature because one experienced person said it was necessary. You need a cheaper way to learn whether the recommendation holds up with your own customers.
Write the test directly in the decision log. If a mentor says your users need a dashboard, the test is not “build dashboard.” It could be “show a clickable dashboard prototype to six active users and measure whether they use it to answer a repeated question.”
Write every test in this format: “We believe [customer] will [behaviour] because [reason]. We will know this is directionally true if [observable result] happens by [date].”
This format prevents teams from calling activity a result. A landing page is not validation. A prototype is not validation. A mentor meeting is not validation. The result is the customer behaviour you observed after putting a clear proposition in front of the right person.
Record negative results with the same discipline as positive ones. A rejected suggestion can save months of work, and it gives you a better basis for the next mentor discussion. Over time, your log becomes a map of decisions you considered, tested, and retired.
That map is especially useful when your team changes between semesters. New contributors can see why the company chose its current direction instead of reopening every old debate.
Use the log to manage mentor relationships well
A decision log improves the mentor relationship because it closes the loop. Mentors invest time when they can see what happened after a conversation. Sending a short update that says, “We tested your suggestion, here is what we found, and here is the next question,” shows that you take their input seriously.
Do not send every mentor every entry. Match the update to the person’s area of experience. A product operator needs the product decision and customer evidence; an investor may care more about your traction narrative, use of capital, and the risks that remain before a raise.
A current mentor conversation tracker frames the core practice well: record the conversation, advice, lessons, next steps, and follow-up actions in one place. Source Your version should add one field many teams miss: what you decided not to do and why.
That field protects your focus. Early-stage startups die from scattered effort more often than from a lack of ideas. When you can explain why you declined a feature, delayed a raise, or narrowed a customer segment, your team builds conviction without becoming stubborn.
We build alongside founders across validation, product, fundraising, and go-to-market. If you are serious about turning mentor input into customer evidence and investor-ready decisions, Apply for Nebula 1.0 and bring your hardest open decision into the sprint.
Sources
Enjoyed this? Get the next one in your inbox.
Fundraising guides and validation frameworks, every two weeks. No spam.
Frequently asked questions
What is a mentor decision log for a student founder?
It is a shared record of mentor advice, the evidence behind it, your decision, the owner, the test or action taken, and the result.
How often should a student startup review its mentor decision log?
Review it once a week with the core team, then update it after important mentor meetings, customer calls, or tests.
What should a founder do when two mentors give conflicting advice?
Identify the assumptions behind each recommendation, assess the evidence, and run the smallest practical test that can distinguish between them.
Ready to build your startup?
We work with a small number of founders each year — mentorship, fundraising support, and a co-founder network included.
Start a conversation
Talk to the founder directly. We reply within two working days.
Applying to Nebula 1.0? Apply here →