Startup advisory
Ask Your Advisor What Their Advice Will Commit You To
Before asking an advisor what to build next, ask what their recommendation will make the company responsible for. A useful advisory conversation exposes obligations, not just opportunities.
Imagine a hypothetical early-stage SaaS founder preparing for an advisory meeting. The product backlog is open. A prospective enterprise customer has requested additional capabilities. The founder wants help turning competing requests into a sensible sequence.
The advisor could produce a convincing list. But before anything enters that list, I would want the founder to ask a less comfortable question: what will following this advice commit the company to?
My direct answer: before asking an advisor for a roadmap, ask them to explain the obligations their recommendation creates, who will carry them, and which attractive choices it will make harder to pursue. A useful sequence should follow those answers, not conceal their absence.
A recommendation creates work beyond the build
My perspective comes from enterprise technology, SaaS product building, and technology and product consulting. I also serve as an advisor to BeagleSecurity and Zopnote. These reflections are my own, not accounts of their work or positions.
When I consider a product direction, I find it useful to separate the initial effort from the continuing responsibility.
A capability may be straightforward to demonstrate but demanding to explain, configure, support, and maintain. A change intended to help one buyer may also alter what future buyers expect from the company. The development task ends; the obligation may not.
That is why I would encourage a founder to ask an advisor:
“If we follow this recommendation, what must we keep doing after the release?”
The answer should reach beyond engineering. Does the direction require more implementation guidance? A different sales conversation? Someone who can resolve exceptions without repeatedly pulling the founder away from other work?
These are not arguments against ambition. They are questions about whether the proposed ambition has an operating home.
Ask which kind of company the advice assumes
Return to the hypothetical founder. Suppose the choice is between offering extensive customer-specific configuration and keeping a narrower, more standard product.
Both directions can sound reasonable in isolation. The first may accommodate a wider range of requirements. The second may make the offering easier to explain and support. Neither is automatically the right answer.
The important advisory question is not simply which capability comes first. It is:
“What kind of company are you assuming we want to run?”
Advice can quietly assume that a founder wants a service-intensive enterprise business, a more self-directed product experience, or some deliberate combination. If that assumption remains unspoken, a roadmap can become an accidental business model.
I would also ask: “What must we become good at for this direction to work?”
A recommendation that depends on strong implementation delivery is incomplete if it discusses only software. Equally, a recommendation to standardise the offering should acknowledge the customer requests the founder will need to decline.
The choice becomes clearer when the advisor names the organisational demands alongside the product benefits.
Make the sacrifice visible before agreeing
Founders do not need an advisor merely to make an appealing direction sound more appealing. I believe the greater value lies in making its price understandable.
Not every price appears in a budget. Some appears as founder availability, support complexity, or a sales promise that becomes difficult to withdraw.
A question I would put near the centre of the meeting is:
“If we choose this direction, what should we stop offering, pursuing, or implying?”
This is more demanding than moving a feature down a backlog. It asks whether the company is prepared to align its conversations with its choices.
In our hypothetical example, choosing a standard offering while continuing to suggest that every buyer can receive bespoke treatment leaves the decision unfinished. Choosing extensive configuration without assigning responsibility for its ongoing support does the same.
The advisor should help the founder see that gap. The founder must still own the commitment.
Leave with a commitment checklist
Before requesting a detailed roadmap, I would use this checklist with an advisor:
- Continuing work: What responsibilities remain after the capability is delivered?
- Ownership: Who will carry each responsibility, and what capacity do they have?
- Company shape: What operating model does this recommendation assume?
- Necessary refusal: Which requests or opportunities should we decline if we choose it?
- External promises: What must sales and customer communication stop implying?
- Readiness: Which responsibilities can we accept now, and which require preparation first?
The result need not be a large document. A short, explicit account of accepted obligations can give a roadmap something solid to organise.
I value advisory work that leaves a founder clearer about responsibility, not simply more enthusiastic about possibility. Before deciding what the team should build next, I want the founder to be able to say: this is what we are choosing to carry.
Background references
Written with AI assistance from the author’s confirmed background. Reflective examples are illustrative, not client case studies.
A product or technology decision on your mind?
Contact Nizam