Your digital transformation roadmap by Friday

What this is

This is a guide to planning your company’s digital transformation and AI adoption roadmap yourself, in one week, with the people you already have. It comes with a template and six prompts for any AI assistant, so you can run the whole thing without outside help.

A digital transformation or AI adoption strategy doesn’t have to be Strategy with a capital S, with months of meetings, a committee and a large consulting engagement. It can be a practical, lightweight exercise you run yourself in a week. The long version has a cost of its own, because every month spent planning is a month the same problems keep costing you. And the plan gets better once something is running. When people see a process that has always worked one way suddenly work ten times better, they start seeing what else could change.

The foundation is smaller than it looks. In one week you find your company’s real problems, put a number on each and rank them. Then you pick one and start it, and the rest of the list becomes your roadmap.

At the end of the week you have:

1. A ranked list of the company’s top problems, each with a rough cost
2. Leadership’s goals, lined up against that list
3. One first thing, started

I ran this every quarter at a high-growth tech company before Paloma, and this guide adapts it for mid-sized companies. The examples come from one of our customers, Seedcorp, a seed producer in Turkey, whose story runs through the guide.

What you need: someone to run it, one or two people from each department with heavy operational work, a way to record calls, any AI assistant, and this guide with the resources at the end of it: a template, six prompts and two messages.

The week at a glance

If you have more conversations than fit in a Monday, spread them over Monday and Tuesday and move everything else by a day. Not every company moves at the pace of a tech company, and the week can stretch. Try to keep it to ten days at most, because the deadline is what makes people take it seriously.

Two weeks before: set it up

Make it official

The week works because it is short and everyone takes it seriously. Give it a name, put it in the calendar, set hard deadlines, and have the owner announce it. Whatever doesn’t make the list this round waits for the next one. That is what stops people from turning up after the list is ranked with “actually, I also had this.”

Choose who runs it

The person running the conversations needs two things that rarely sit in one person: enough authority that the deadlines hold, and enough neutrality that people tell them what is actually crushing them.

When I ran this before Paloma, I came from the product team. I had no team of my own to protect, and enough standing that people trusted my judgment and accepted a no. They told me things they would not have told someone reporting to the COO.

In most mid-sized companies it works better to split the two. The owner brings the authority: announces the week, sets the deadlines, joins the final pick. The facilitator brings the neutrality: someone who has been there long enough to know how every department works, and doesn’t run one. Some ideas for who that could be:

• A quality or continuous-improvement lead who already has cross-team working experience
• A next-generation family member who hasn’t taken over a department yet
• The finance controller
• The owner’s right hand, someone who has been around for years and owns no process

Or an outsider consultant like us, who is neutral by default.

Choose who takes part

Every department with heavy operational work, which might mean more than the operations team. If finance runs a heavy operation, for example, finance is in.

One or two people per department, never more. You want someone strategic enough to judge where help would pay off, and close enough to the daily work to know what hurts. Usually that is a director, sometimes a senior manager. I’d argue that a director who can’t speak to the core problems of their own department shouldn’t be in that seat, but that’s a different conversation.

Send the heads-up

Two weeks out, tell participants what is coming and ask them to start now: talk to their teammates, listen to their problems, and list what bothers them most. Both messages are at the end of the guide.

Monday: one conversation at a time

One-on-one, never a room

Talk to each person alone. In a room, priorities clash and the meeting turns into a debate about whose problem matters more, instead of a full list. One-on-one, people say more, and they are easier to align later. Diplomats call this shuttle diplomacy. I first came across it for roadmaps in Product Roadmaps Relaunched, a book for product managers, and the principles carry over.

Record every conversation

Use a recorder that works well with AI: a meeting notetaker such as Granola or Wispr Flow, or the transcript that Teams and Google Meet can make. You will hand the transcript to an AI afterwards, so you can listen instead of taking notes. Teams that have done this before can fill the template first and walk you through it. The first time, just talk.

If you need to see how someone works on their screen, start a video call with just the two of you and your notetaker, even if you’re sitting side by side, and ask them to share their screen. The recording then holds what they showed you as well as what they said. You only need this when the screen matters.

Problems first, solutions later

The first conversation is only about problems. People are much better at describing what is wrong and how it works today than at picturing the fix, and the fix they walk in with is often aimed at a symptom. Solutions come in a second round, for the top problems only.

How to ask

This is the part that matters most. The quotes are questions I asked Rashid, who runs Seedcorp, over three sessions this summer.

1. Open wide, then keep asking what else. “Whatever is hard for you.” “What else bothers you in production?” Keep going until the area is drained.
2. Ask why until the cause shows. “Why is that hard?” “Why do you care about this problem?” “What information do you need to know?” Three or four whys usually get you from a symptom to a missing input or a habit.
3. Ask how it works today, even when the question sounds naive. “What does booking something mean?” “When you say data, what do you mean?” The plain version is where the real steps show up.
4. Ask for the last time. “When did this last bite you, and what happened?” A specific incident is easier to describe than a pattern, and it is where the cost number comes from later.
5. Ask for the evidence. “Can you show me some examples?” “Can I see the file?” Go and look if you can.
6. Check whether software is the fix at all. At Seedcorp, a recurring production mistake looked like it needed a better tool. Two questions in, Rashid said himself that a tool wouldn’t change it. Some problems are people, process or policy, and the list should say so.
7. Reflect it back, to make sure you have the load-bearing part of the problem right. “The problem is that ________. Is that the problem?” At Seedcorp, a problem that arrived as “we can’t see our costs” turned out to be about collecting the data. Once the data existed, the calculation was the easy part. Same symptom, a different problem, and a different fix.

Leadership, separately

Talk to the owner and the leadership team on their own, top down: their goals for the year, what worries them, what is already planned. You’ll line this up against the list at the end of the week.

Prompt 1 builds a question guide for each department before you sit down.

Tuesday and Wednesday: one list

Let AI write the rows

On Tuesday, give each recording or transcript to an AI assistant with prompt 2. It turns the conversation into rows in the Problem inventory: one problem per row, in their words, with how it is handled today and the system it lives in. It leaves the cost and the priority empty, because those belong to the team.

The team puts a number on each problem

The cost comes from the team, not the facilitator. It doesn’t need to be precise. It needs to be honest, and comparable across the list. Two shapes cover most problems, shown here with made-up numbers:

• Time. Hours spent, times the hourly cost of the person spending them: a report that eats a week of an analyst’s time every month, say $800 a month.
• Risk. Something that is usually fine and expensive when it isn’t, times how often it happens: a missing quality check that ends in a refund four times a year.

When a team gets stuck, the facilitator asks what the problem affects and suggests a rough way to measure it. “How many hours a week do you spend chasing this?” “What’s the swing if this price is 10% wrong?” The team still works out the amount. Prompt 3 helps here.

The question underneath all of it: with the resources you have, where do you put your chips?

Send the list back

Send each person their rows on Tuesday and give them until the end of Wednesday. They add the impact and the calculation in their own time, because nobody can do that on the spot.

Limited votes

Then they rank, with a fixed budget:

• P0, fix now: at most 10% of the list, and at least one
• P1, next: 20%
• P2, later: 30%
• P3, not now: everything else

Round down. A department with 30 problems gets three P0s, six P1s and nine P2s, and the template does the sum. If a department sent two people, they share one budget.

Asked on the spot, people name ten top problems. With a budget, they pick the handful that matter.

Rank how much the problem hurts, not whether technology can fix it. At Seedcorp, one problem nearly moved down a level because its fix wasn’t a technical one. The list ranks the problem; whether technology can solve it comes after the vote.

Thursday and Friday: rank, pick one, start it

Merge and rank

Put every department’s list in one place. Prompt 4 finds the duplicates and groups related problems. Line the list up against leadership’s goals and what you can spend next quarter. Look for clusters: problems that share one cause or one fix, or a single fix that removes five other problems.

The top problems, second round

Now solutions come in. For each P0 and P1, ask the person who raised it: “How would you solve this if you had one full-time person on it and no time limit?” Keep the question to time, not money. At Seedcorp, the first answers were more people or more devices. Once the question was about time, the answers showed what the real fix was and which step was blocked. Then ask: “Why don’t you do that now?” The answer is usually the real blocker.

The clearest case at Seedcorp was a problem Rashid called the single biggest driver of results in the field. He worked through the physical fixes himself, ruled them out on cost and labour, and landed on satellite data: “not perfect, but miles better than what we’re doing now, which is nothing.”

Prompt 5 gives each top problem two or three possible approaches, including ones that aren’t software, a kind of fix and a rough size. Treat it as a first guess for people to correct.

Pick one thing and start it

Don’t wait for the roadmap to be finished. Pick one problem from the top of the list and start on it the week after. These questions help:

• Does it sit in one team?
• Is the data already somewhere?
• Is the work the same every time, or full of “it depends”?
• Who would own it?
• Would it be worth solving even if you had to redo it in a year?
• Is the system it touches about to be replaced?

“Won’t we have to redo it later?”

If you’re worried about that, the problem may not be acute enough to go first. You put a cost on it on Wednesday, and a problem that costs that much every month pays for its own rework. Building has also never been cheaper. What a later plan replaces is the build. What carries over is the part that took the time: understanding the problem, and the data.

If you buy something for it

Ask any vendor two questions. Can this handle the next problem on our list too? And can our data and logic come out if we leave?

After the week

The rest of the list is your roadmap. Run the week again next quarter, or every six months if your company moves at a steadier pace. It gets easier each round. After a few, teams fill the template themselves before the week starts, and the conversations get shorter.

If you would rather not run it yourselves, an outsider is neutral by default, and this is the week we run with companies in our Speedrun program. We train your team on how AI actually works, build the roadmap with your people in the room, and ship the first tool on the list by Friday.

The template

Make a copy in Google Sheets (needs a Google account), or download it for Excel. Five tabs:

1. The week. The table above as a checklist, with dates and an owner per step.
2. Problem inventory. One row per problem: department, group, the problem in one line, in their words, said or inferred, the last time it happened and what happened, how it is handled today, the system it lives in, who deals with it today, the cost as the team estimates it, how they got the number, priority, notes.
3. Vote budget. Enter the length of a department’s list and it shows how many P0s, P1s and P2s that department gets.
4. Top problems. The P0s and P1s, filled after the vote: why it is there, how they would solve it with one full-time person and no time limit, possible approaches, kind of fix, rough size, whether people will have to change how they work, the picking questions, the pick.
5. Leadership. Each goal or concern, whose it is, and which problems on the list it touches.

Messages

From the owner, two weeks before

Subject: Roadmap planning week, ________

From ________ to ________ we’re running roadmap planning week. ________ will sit down with one or two people from each team, one at a time, to list the problems that cost us the most time, money or worry. By the end of the week we’ll have one ranked list for the whole company, and we’ll start on the first item the week after. Whatever doesn’t make the list this round waits for the next one, so please take it seriously. ________ will be in touch about times.

From the facilitator, to each participant

In two weeks I’ll sit down with you for about an hour to talk about what makes your team’s work harder than it should be. Before then, ask your team what slows them down, what they end up redoing, and what they worry about, and bring the list. This round is only about problems, not solutions.

The prompts

Six prompts, one for each moment in the week, written for any AI assistant. They are a starting point. Your company, your tools and your assistant will differ, so expect to tweak them until they work for you, and treat what they give back as a first draft for your people to correct.

Prompt 1

Before a conversation: a question guide for one department.

When: the day before each one-on-one. Paste in: who you are talking to, their department, one line on your company. Fills: nothing; it is your guide for the conversation.

I'm running roadmap planning week at our company: one week where we list and rank the problems that slow each department down, so we can pick what to fix first. Tomorrow I'm interviewing [NAME, ROLE] from [DEPARTMENT] for about an hour. Our company: [ONE LINE ON WHAT YOU DO]. What I already know about their work: [A FEW LINES, OR "NOTHING YET"].

Write me a one-page question guide for this conversation. It is about problems only. Solutions come later in the week, for the top problems only, and I should not suggest any.

Include:
1. A short opening I can say in my own words: we want honest answers, nothing is too small, and anything not raised this week waits for the next round, so bring it all now.
2. Five or six open questions to start, such as what takes up their week and what goes wrong most often. Add a few plain questions about the work I described, like "What does booking something mean?"
3. The follow-up questions to use on each problem they raise, in this order:
   - How does it work today, step by step? (I should ask the plain question even if I think I know the answer.)
   - When did it last happen, and what happened?
   - Why does it happen? (Keep asking why until the answer is a cause, not a symptom.)
   - Why do you care about this problem?
   - If people get it wrong: did they not have what they needed, or did they have it and get it wrong anyway?
   - Which system or file does it live in? Can you show me?
   - Who deals with it today?
   - If they describe a fix: what would that fix stop happening?
   - If something obvious hasn't been done: what is in the way?
4. A line to check my understanding before moving on: "So the problem is ___. Is that right?"
5. "What else?" as the last question in each area, until they run out.

Keep it to one page of questions. No questions about budgets or which tools to buy.

Prompt 2

After a conversation: the conversation as inventory rows.

When: the same day as the interview. Paste in: the transcript or your notes. Fills: the Problem inventory tab, every column except cost, how they got the number and priority.

Below is the transcript of a roadmap planning week interview. [INTERVIEWER'S NAME] ran the interview; [NAME, ROLE, DEPARTMENT] was interviewed. If speakers are labelled by number, the one asking the questions is the interviewer. The transcript was made automatically, so names and systems may be misspelled.

Turn it into rows for our problem inventory, one row per distinct problem, with these columns in this order:
Department | Group | Problem in one line | In their words | Said or inferred | Last time it happened, and what happened | How it is handled today | System it lives in | Who deals with it today | Cost (team's estimate) | How they got the number | Priority | Notes

Rules:
- Problem in one line: what goes wrong, not a missing tool. If they only said "we have no system for X", write that and add a follow-up question below.
- In their words: a short quote copied from the transcript, not reworded.
- Said or inferred: "Said" if they said it, "Confirmed" if the interviewer put it into words and they agreed, "Inferred" if it is your reading. Use "Inferred" rarely, and say in Notes what it is based on.
- Group: a short label for the area, such as "planning" or "invoices".
- System it lives in: the ERP, a portal, Excel, email, WhatsApp, paper, as they named it. If you are unsure what a name refers to, add a question mark.
- Write "Not said" wherever the transcript doesn't tell you. Never fill a gap with a guess.
- Leave Cost, How they got the number and Priority empty. The team fills those in.
- If they describe a fix, put it in Notes as "Their idea: ...". If the interviewer suggested a fix, put it in Notes as "Interviewer's idea: ...". Neither one is a problem row.
- If they describe something that makes many problems harder (not enough people, skills or time), give it its own row with the group "Constraint".
- If they give several reasons for one problem and each is a problem in its own right (data nobody records, a number that means something different to each person, nobody with time to do it), give each reason its own row in the same group, not a line in Notes. Notes hold ideas and context only. Before you finish, read every Notes and "How it is handled today" cell and move any reason something goes wrong into its own row in the same group.
- The rows go back to the team. If they criticise a colleague who could be identified, or say something sensitive about the company, leave the remark out of the rows and list it at the end under "For the facilitator only". The problem behind it stays in the rows, in neutral words. A customer complaint about a mistake is a problem, not a sensitive remark.

Give me the rows as a table I can paste into a spreadsheet. Then list the follow-up questions I should ask, including "when did it last happen?" for every row where that is "Not said".

[PASTE TRANSCRIPT OR NOTES]

Prompt 3

When a team is stuck on a number.

When: the team is filling in cost and can’t get started. Paste in: the row, and anything they already know. Fills: the way to work out cost and how they got the number; the team still supplies every amount.

Our team is stuck putting a number on this problem from our roadmap planning week inventory:
[PASTE THE ROW, OR DESCRIBE THE PROBLEM]
What we know so far: [ANY FACTS: HOW OFTEN IT HAPPENS, HOW MANY PEOPLE, WHAT IT COST LAST TIME]

Help us estimate what it costs without making up any numbers. We will supply every amount, so leave every input blank, even one you could work out from what we told you.

1. Start with the last time it happened: which questions would show what that one time cost (hours, money, an unhappy or lost customer, a penalty)?
2. List what this problem affects: people's time, money, risk, customers, decisions.
3. Give one to three rough ways to put a number on it, each as a simple sum with the inputs we need to find. Use only the ones that fit this problem:
   - Time: hours per week, times the number of people, times their hourly cost, times weeks in a year.
   - Risk: how many times a year it happens, times what one time costs.
   - A decision made on bad information: the amount at stake, times how far off the decision could be.
4. For each sum, the question to ask and who in the company could answer it.

If it really can't be measured in money or hours, say so, and suggest a question that shows its effect on our other problems instead. A rough number we can defend is the goal, not an exact one. Keep the whole answer to one screen.

Prompt 4

Merging the department lists.

When: after each department has filled in costs and votes. Paste in: every department’s rows, with the header. Fills: the Group column; it changes nothing else.

Below are the problem lists from each department in our roadmap planning week. The first line is the header.
[PASTE ALL DEPARTMENT ROWS, WITH THE HEADER ROW]

Help me merge them into one list. Do not change any priority or cost, and do not drop any row.

1. Duplicates: rows from different departments that describe the same thing going wrong in the same work. Suggest one wording, and keep every department that raised it. Problems that only look alike, such as the same kind of mistake in two different processes, are not duplicates.
2. Groups: a group label for each row, so problems with the same cause sit together. Keep the existing labels where they fit. Name each group by what goes wrong, not by a missing tool. One line per group on the shared cause.
3. Knock-on problems: where one problem looks like it causes another, say which causes which.
4. Conflicts: where what one department does or wants works against what another department needs. List both sides so we can talk to each department separately. Only list conflicts the rows show; if there are none, say so.

Give me back the group label for each row by row number, then the four lists.

Prompt 5

The top problems, after the vote.

When: after the second round of conversations, for the P0s and P1s only. Paste in: the top problems with what people said about them in the second round. Fills: the Top problems tab: possible approaches, kind of fix, rough size, and whether people have to change how they work.

These are our top problems from roadmap planning week (P0 fix now, P1 next), with what the team told us about each in the second round: why it matters, and how they would solve it if they had one full-time person and no time limit (a what-if, not a hire).
[PASTE THE TOP PROBLEMS AND THE SECOND-ROUND NOTES]
Our company: [ONE LINE]. Tools we already have: [THE ERP, EXCEL, WHATSAPP, ANYTHING ELSE].

For each problem, give a first guess for us to correct:
1. Does their own solution deal with the cause? One line.
2. Three possible approaches: one that is not software (a rule, a role, a habit, a supplier, a device), one that uses what we already have, and one that uses AI tools as they exist today, described in plain words for someone who has never used them. No approach may ask us or you to write code or scripts; say what the tool does instead. If a fix was tried before and didn't stick, the first approach is finding out why.
3. Kind of fix: software (including a better spreadsheet or a change in the ERP), collect the data first, not software, or needs hardware or outside help.
4. Rough size, by how much it touches, not by time:
   S: one team, and the data already exists.
   M: a few teams, or the data needs cleaning or collecting first, or comes from an outside source.
   L: new hardware, data nobody has yet, or several of our systems joined together.
   If an L fix could be tested with a small trial first, size the trial too.
5. Will people have to change how they work? Who?
6. What would make this guess wrong, and what to check.

Give your reasoning in a sentence or two per problem. If an approach mentions a weekly report, say who reads it: it is internal unless the problem says it is for customers. Do not re-rank the problems. Do not suggest monitoring employees' personal phones or private messages; if that looks like the only fix, say it is a policy or legal question, and otherwise don't raise it.

Prompt 6

Thursday and Friday: lining the list up against leadership’s goals and picking.

When: the last day of the week, before leadership picks. Paste in: the Top problems tab, the Leadership tab, and what you have to spend next quarter. Fills: the picking questions and the pick, plus a draft roadmap.

It's the last day of our roadmap planning week. Below are:
- Our top problems, with priority (P0 fix now, P1 next, P2 later, P3 not now), cost, kind of fix and size: [PASTE THE TOP PROBLEMS TAB]
- Leadership's goals and concerns for next year: [PASTE THE LEADERSHIP TAB]
- What we have next quarter: [PEOPLE, BUDGET, OUTSIDE HELP]

Help leadership make the call. Lay out the choice; don't make it for us, and don't change the priorities.

1. Top down against bottom up: for each goal, the problems that touch it. Then any goal with no problem under it, and any P0 that no goal covers.
2. Clusters: one fix that would remove several problems, and problems that cause other problems.
3. For the five strongest candidates for the first thing to start, taken from the top of the list, P0s and P1s, a table answering: Does it sit in one team? Is the data already somewhere? Is the work the same every time, or full of "it depends"? Who would own it? Would it be worth solving even if we had to redo it in a year? Is the system it touches about to be replaced? Add its priority, cost and size.
4. The one you would suggest starting first: the smallest candidate high on the list that answers these questions well, ideally serving a goal. Suggest a bigger one only if you say why no smaller one is worth starting. The reason in two sentences, and what would make a different pick better. A missing owner is for leadership to name, not a reason to rule a candidate out.
5. The rest as a draft roadmap: what comes next quarter, and what waits.