Advisory work
Technology roadmap consulting: what to build, in what order
Somewhere on your desk there's probably a plan already. A vendor's proposal, or a list your developer drew up. Both were written by someone who benefits if you say yes to all of it.
I'm Manoj Pillai, an independent consultant in India. A roadmap engagement with me is advice, priced as advice: I study your business and your tools, then tell you in writing what to build, what to buy, what order to do it in — and which expensive ideas to ignore for now.
Book a call →What a technology roadmap actually is
A technology roadmap is a short written plan for your business's software and systems: what to do, in what order, with the reasons attached. Not a 40-slide strategy deck. A document you can read in one sitting and act on for a year.
The order is the valuable part. Renovating a house works the same way — you decide the plumbing before you choose the paint, because doing it the other way round means paying twice. Businesses buy technology in the wrong order constantly: a new website on top of customer data that lives in nobody-knows-how-many spreadsheets, an AI tool bolted onto a process no one has written down.
Just as valuable is the ignore list. At any moment there are five things you could do, and a good roadmap says out loud which three don't matter this year. That sentence rarely appears in a proposal, because nobody selling you technology gets paid for it.
What the engagement produces — and what it doesn't
This is advisory work, and I want the boundary sharp before you spend money on it. You are buying decisions on paper, not software.
The engagement mechanics — rates, models, NDA, how remote advisory works — are the same as for all my work, written down on work with me.
Why shouldn't the builder write your roadmap?
Because the conflict is built into the situation — no dishonesty required. A vendor's plan will lean toward what the vendor sells — that's what a vendor's plan is for. An engineer's plan will lean toward what's interesting to build, because engineers are human and rewriting the boring billing script never makes the list. Neither document is lying to you. Both are answering a different question than yours.
Now the awkward part, stated plainly: I do build work too. So the same conflict could apply to me, and pretending otherwise would be the exact behaviour this page warns you about.
Here's how I keep the roadmap clean. It's priced and paid for as its own engagement, so my fee doesn't grow if the plan gets more ambitious. The document is written for any developer to execute, not just me. And where a recommendation happens to point at work I'd want, the document says so in plain sight — you get the recommendation and the conflict disclosure in the same paragraph, and you decide what to do with both.
If you already have a technical adviser you trust with no stake in the outcome, use them. This engagement exists for the owner who doesn't have that person.
How I put a roadmap together
I start with the business, not the technology. What do you sell, where do the hours go, which numbers can't you see when you want them? The answers usually point at the real problems faster than any tool audit, because the expensive gaps show up as somebody's wasted afternoon long before they show up in a system.
Then I inventory what you already run — the software you pay for, the spreadsheets holding it together, and the things that exist only in one employee's head. Part of a roadmap's job is finding capability you're already paying for and not using.
The ordering rule I apply is unglamorous: whatever is leaking money or hours gets fixed before anything new gets added, however exciting the new thing is. Then come the moves that unblock other moves. The shiny ideas that change nothing this year go on the ignore list, with the date we should look at them again.
All of it happens remotely, over calls and shared documents. My mornings line up with Australia's afternoons — two of my current clients are there — my afternoons with UK mornings, and my evenings with US mornings, so the conversations happen during your normal working hours.
Questions owners ask about roadmap consulting
It's advisory work: I study your business and your existing tools, then give you a short written plan saying what to build or buy, in what order, and what to ignore for now — with reasons you can repeat to anyone. You get decisions and a document, not software. The building, if any, is a separate engagement.
A written roadmap: an ordered list of moves, the reasoning behind each, a realistic cost range for each step, and a record of what we ruled out and why. Short enough to read in one sitting, plain enough to hand to your accountant or your next developer.
A vendor's proposal is a shopping list written by the shop — every problem happens to need what they sell. A roadmap is written by someone paid only for the advice, so "do nothing about this for a year" is an answer I'm free to give. Vendors can't afford that sentence.
No. The document is yours, priced and paid for on its own, and written so any competent developer can act on it. If parts of it point at work I could do, I'll flag that conflict openly in the document itself — and the plan stands whether you hire me, someone else, or nobody.
It depends on how many tools and decisions are on the table, so I won't pretend there's a standard number. I sell advisory work hourly or as a fixed-price project, and we agree the shape and cost on the first call — before anything starts, not after.
Yes — remotely, with real overlap. I'm in India at UTC+5:30: my morning is Australia's afternoon, my afternoon is the UK's morning, and I take US calls in my evening. Two of my current clients are in Australia, so that overlap is part of my normal working week.
Put the plans you've been handed in front of me
30 minutes, free, on Zoom or Google Meet. Bring the vendor proposal or the wishlist if you have one — you'll leave the call knowing whether a roadmap engagement would earn its fee, and I'll tell you plainly if it wouldn't.
Book a call →Advisory only, priced as its own engagement. No build required, no obligation after the document.