An Advisor’s Experience Is Not Yet Your Evidence

Imagine a hypothetical early-stage SaaS founder sitting down with an advisor. The product has some promising conversations behind it, several possible directions ahead, and a team waiting for priorities. The founder asks for a roadmap. The advisor recognises a familiar pattern and begins describing what worked elsewhere.

That recognition may be valuable. It may also be where the wrong plan begins.

My direct answer: before asking an advisor what to build, ask why their experience applies to your business, what they are assuming, and how you can test that relevance before committing the team.

Experience needs a translation step

I value experience, including the perspective I bring from enterprise technology, SaaS product building and consulting. But I do not think experience should enter a founder’s planning process as an instruction that needs no explanation.

My advisory roles with BeagleSecurity and Zopnote are part of my background. I am not describing their work or speaking for either company here. The distinction I want to explore is broader: having seen a problem before is not the same as having seen this problem under these conditions.

A recommendation can be sensible in one business and premature in another. The difference may be who buys, who implements, how much support adoption requires, or whether the team can sustain the proposed work.

Before accepting the recommendation, I would want a founder to ask:

“What was true in the situation that shaped this advice?”

That question does not dismiss experience. It makes experience usable.

Ask what makes the comparison relevant

Consider a hypothetical SaaS product whose founder is deciding whether to prioritise a self-service setup flow or a deeper integration requested by a prospective enterprise buyer.

An advisor who has worked around self-service products might favour reducing setup friction. Someone with enterprise experience might favour the integration. Both recommendations can sound persuasive because both have a coherent story behind them.

The founder needs more than the story.

I would ask the advisor to explain which conditions support their recommendation. Does the prospective user have authority to adopt the product? Can the product deliver meaningful value without access to another system? Would the requested integration serve a repeatable need, or mainly this particular buyer?

These questions expose the connection between past experience and present circumstances.

The most useful follow-up may be:

“Which difference between that situation and ours matters most?”

A strong analogy survives attention to its differences. A weak analogy depends on everyone overlooking them.

Separate a principle from a proposed feature

I find it useful to distinguish three things in advice: the principle, the interpretation and the proposed action.

For example, “help a customer reach useful value sooner” is a principle. “Setup is preventing that” is an interpretation. “Build a setup wizard” is a proposed action.

Those are not interchangeable.

If the interpretation is wrong, the feature can be well built and still miss the problem. Perhaps setup is manageable, but the buyer cannot secure internal ownership. Perhaps the product depends on information the user does not yet have.

The founder should therefore ask:

“What observation led you from the principle to this particular action?”

If that observation is missing, I would rather make the next step an investigation than disguise a guess as a delivery commitment. In the hypothetical example, walking through setup with a prospective user could be more useful than immediately assigning a wizard to engineering.

This is not an argument for endless discovery. It is an argument for spending a little effort checking the explanation before spending substantially more effort implementing it.

Turn advice into something the team can examine

Before a roadmap discussion ends, I would use this checklist:

• Origin: What experience or observation is this recommendation based on?
• Similarity: Which conditions genuinely match our situation?
• Difference: Which mismatch could make the recommendation unsuitable?
• Inference: What are we assuming rather than directly observing?
• Check: What can we inspect or try before committing substantial work?
• Choice: What are we choosing now, and what are we deliberately leaving open?

The resulting plan may be less impressive on a slide. It should be easier for the team to understand and act on.

I do not believe an advisor earns trust by making every answer sound settled. I believe trust grows when a founder can see how the answer was reached.

A roadmap is useful when it carries that reasoning forward. Otherwise, the founder may leave with someone else’s confidence rather than a clearer view of the business they must build.