Ask an Advisor to Name the Job Before Drawing the Roadmap

Imagine a hypothetical early-stage SaaS founder arriving at an advisory session with a crowded feature list. There are requests from prospective buyers, gaps noticed during demonstrations, and improvements the team would like to make. The founder asks for help turning it all into a roadmap.

The advisor could start arranging the list. But that would quietly assume that everything on it belongs to the same problem.

My direct answer is this: before asking an advisor what to build next, ask them what kind of help the business needs now—and what that help should produce. Diagnosis, commercial choice, and delivery planning are different jobs. A roadmap is only one possible outcome.

Ask which job the session is meant to do

My perspective comes from enterprise technology, SaaS product building, and consulting. I am also an advisor to BeagleSecurity and Zopnote; these reflections do not describe their private work or speak on their behalf.

I think advisory work becomes more useful when its purpose is explicit. A founder should be able to ask: “Are you helping me understand the problem, choose a direction, or organise execution?”

If the problem is unclear, the useful output might be a set of unanswered questions and a way to investigate them. If the direction is unsettled, it might be a comparison of two commercial paths. If the direction is already chosen, sequencing work may be exactly right.

These are not stages that must always happen in order. They are different uses of attention. Confusing them can make a session feel productive while leaving the actual difficulty untouched.

I would rather leave a founder with a clearly named job than an impressive plan for a job nobody agreed to do.

Ask whether a product request hides a commercial choice

Consider a hypothetical SaaS team deciding between a customer-specific integration and improvements to standard onboarding.

At first glance, this looks like a prioritisation exercise. An advisor could compare effort, urgency, and expected usefulness. But the founder may actually be choosing between a service-intensive offer for selected accounts and a more repeatable offer with narrower commitments.

Neither path is automatically wrong. They ask different things of the business.

The useful question for the advisor is: “Which business choice are we treating as if it were merely a feature choice?”

For the integration, the conversation should include who will support it, whether its scope can be repeated, and what the customer is being offered beyond software. For onboarding, it should include which customers the standard experience is intended to serve and what assistance remains necessary.

The advisor’s job is not to turn every request into strategy. It is to notice when sequencing cannot resolve a choice about the offer itself.

Ask what form the answer should take

A roadmap gives work a sequence. It does not necessarily explain the offer, define a service commitment, or clarify who must make a commercial decision.

Before the session moves towards a roadmap, I would encourage a founder to ask: “What should we leave with that we do not have now?”

The answer could be a short description of the intended customer and offer. It could be a comparison of a standard package and a tailored engagement. It could be an implementation-responsibility outline. Sometimes it really is a delivery sequence.

Choosing the output matters because it shapes the conversation. If the team needs to clarify what it will sell, a feature calendar may be premature. If that choice is settled, another broad strategy discussion may simply delay execution.

I want advisory help to fit the present work, not expand to fill every available conversation.

A checklist before requesting the roadmap

Before an advisory session, I would suggest writing down:

• The immediate difficulty: What is the team unable to move forward with?
• The requested job: Do we need diagnosis, a commercial choice, or sequencing?
• The hidden commitment: What are we promising customers if we take this path?
• The useful output: What document or clear choice would make the session worthwhile?
• The next owner: Who will act on that output inside the business?
• The stopping point: What would count as enough help for this particular task?

That last question deserves space. Advisory work should not become an indefinite substitute for management.

A founder does not need every conversation to produce a roadmap. Sometimes the most valuable result is recognising that the next task belongs in the offer, the sales process, or the implementation agreement—not in the engineering backlog.

For me, useful advice begins with that modest discipline: name the job, do it clearly, and let the founder get back to building.