Capture a repeatable process, explain its reasoning and limits, and test the resulting sequence.
You already explain your best ideas to clients, colleagues, and audiences. Join Mike Giannulis, founder of Dictate, for practical 10- to 15-minute episodes on turning that spoken expertise into a published book through conversations with an AI interviewer. Each episode gives experts, coaches, and business owners one clear step to capture their ideas, shape their message, and move their book forward.
Episodes of this show are narrated by an AI-generated voice.
A process you explain regularly may contain useful material for a chapter. Today we will make its steps, reasoning, and limits easier to see.
Welcome to Talk Your Book Into Existence with Mike Giannulis, founder of Dictate. Learn how to turn the ideas you already share out loud into a published book, one conversation at a time. Today, you will leave with one practical step you can use on your own book.
A quick note before we begin: this episode is narrated by an AI-generated voice.
The Method You Already Use But Have Never Written Down.
Start with a question: what problem do people regularly ask you to help solve? Choose something specific enough that you can describe what you actually do. You are looking for a useful explanation, not a claim that your approach is unique or works for everyone.
A process can become familiar enough that you stop noticing its parts. You may check one thing before another, ask a particular question, or recognize when the usual approach needs adjusting. Writing those choices down makes them available for examination. Some may belong in your book; others may turn out to be habits that need rethinking.
In my book, I describe the gap between what you know and what you have articulated as a place to look for material. Treat that as a starting exercise. The explanation still needs evidence, context, and a clear purpose for the reader.
Here is a hypothetical example. Imagine a designer who helps small teams prepare a project brief. She starts by asking who will use the result, then what the project needs to achieve, then which constraints matter. She asks the team to give one concrete example of success. If people disagree, she records the disagreement before moving on to possible designs.
The designer might regard those questions as ordinary preparation rather than a method. Yet the order matters to her: first the user, then the purpose, then the constraints. Asking for an example helps reveal whether the team means the same thing by words such as simple or effective. This is an invented illustration of how a routine can be explained, not a report of a real client outcome.
That sequence could become the basis of a chapter. The author would need to explain why each question comes where it does, show what a useful answer looks like, and describe when the order should change. Naming a sequence is the beginning of that work. It does not establish that the process is new, proven, or sufficient for every project.
Here's how you find yours. Think about the last five clients you helped. Not the complicated edge cases. The typical ones. The people who came to you with the same problem you've solved twenty times before. Now ask yourself: what did I look for first? What did I check second? At what point did I know what the real issue was?
Your answers may reveal a sequence, a decision tree, or a set of questions you return to. If the work does not follow a fixed order, do not force it into one. Describe the conditions that make you choose one step rather than another.
You do not have to invent a new field to write something useful. A clear explanation of a familiar task can help a reader, especially when you show the reasoning and limits. Give credit to ideas and methods you learned from others. Distinguish your adaptation from the underlying approach instead of claiming ownership of every part.
If you worry that someone has already written about your topic, compare the specific reader and task you want to address. What question remains confusing? What example would make the explanation clearer? Your contribution may be a useful application or a careful synthesis. You do not need to claim that nobody else has ever combined the ideas in the same way.
So before you move any further, do this. Take a blank page. Write at the top: "The problem my clients bring me most often is blank." Fill in the blank. Then write: "The first thing I always check is blank." Fill that in. Then: "The next thing I do is blank." Keep going until you've described the whole sequence.
Don't edit it. Don't make it sound impressive. Just describe what you actually do, in order, the way you'd explain it to a smart friend over coffee. That's your raw material. That's where the method lives.
If you want to work through this process in more detail, my book, Talk Your Book Into Existence, is at startdictate.com/talk-your-book. The link is also in the episode notes.
How to Shape That Process Into Something a Reader Can Follow.
Once you have the sequence rough on paper, the next move is making it teachable. And those are two different things. Having a process and teaching a process require different work.
Here's what teachable actually means. A reader who has never met you should be able to read your method, understand the problem it solves, follow each step in order, and know whether it worked. That's the bar. Not impressive. Not comprehensive. Followable.
The clearest way I know to structure this is to work through five things, in order. Problem first. Then steps. Then the reasoning behind each step. Then the limits of the method. Then the intended outcome.
Start with the specific situation. In our designer example, a team has several ideas for a project but no shared brief. The task is to agree on who the work serves, what it should accomplish, and what remains undecided. That is more useful to a reader than a broad promise to improve creativity or communication.
Then describe the actions. Ask each person to name the intended user. Compare the answers. Write down the goal in plain language. List the constraints and unresolved questions. Each instruction should make clear what the reader is being asked to do. If a step depends on a previous decision, say so.
Explain the reasoning. Why ask about the user before discussing possible designs? In this example, it helps the team evaluate ideas against a shared purpose. The reader may still disagree with that order, but now they can see its rationale. Give enough explanation for someone to understand the choice rather than follow a checklist mechanically.
Name the limits. Our hypothetical briefing exercise assumes the relevant people can discuss the project and that the goal can still be clarified. If key decision makers are absent or a requirement is fixed, the exercise may need adjustment. Say what information or authority the reader needs before using the method. Limits help define the task; they are not a failure of the explanation.
Describe the intended output without guaranteeing success. In this example, the team aims to produce a draft brief with a named user, a goal, constraints, and open questions. That is a document they can inspect and revise. It does not guarantee agreement or a successful design. Separate the immediate output of the exercise from the larger outcome you hope it supports.
Now, at some point in this process you're going to want to name the method. And that's reasonable. A named framework is easier to teach, easier to remember, and easier to reference throughout a book. But here is the thing: name it after you understand it, not before. A lot of experts get stuck trying to invent a clever name before they've actually articulated what the steps are. Get the steps clear first. Plain language first. The name, if you need one, comes after.
Keep claims proportional to the evidence. If you have used a method in your own work, explain the setting accurately. If you draw on other people's research or frameworks, identify the source. Our invented designer example illustrates an explanation; it supplies no evidence about results. Do not turn a plausible story into a success claim.
You now have a possible chapter structure: the situation, actions, reasoning, limits, and intended output. Test whether those parts connect. Does the example show the steps you listed? Do the limits match the reader you named? A method-centered book may use this structure repeatedly, while other books need a different approach. Choose it because it helps your reader, not because every chapter must follow the same template.
Record Yourself First, Write Later.
If starting with a written chapter feels difficult, try explaining one process aloud. Speaking is an option for capturing material, not a requirement or a guarantee. You can also begin with notes, a sketch, or a short written answer. Choose a format that lets you examine what you actually do.
For this exercise, make a short recording and then review it. The recording is a working source, not a performance.
Find a repeatable process you explain regularly. One client situation, one problem type, one diagnostic sequence. Something you've walked through enough times that you could do it mostly on autopilot. Set your phone to record. Then explain the process out loud, as if you're talking to a smart client who's never been through it before.
Use a few notes if they help. Start with the problem, explain what you check and why, and describe where the process gets complicated. Pause when you need to think. If you are unsure about a detail, mark it for checking rather than trying to sound certain.
Aim for eight to fifteen minutes, or a shorter session if that is more manageable. Listen back for the sequence and for missing explanations. You may find a useful phrase, but you may also find that the order is unclear. Both are helpful results: one gives you material to keep, and the other shows you what to develop next.
Once you have the recording, list the steps you described in order. Just bullet points. Step one, step two, step three. Don't worry yet about what to call each step or whether the list is perfectly tight. Get the sequence visible on a page.
Then ask yourself two questions. First: is there a step I skipped in the recording because I assumed it was obvious? If yes, add it. Obvious to you is not obvious to your reader. Second: is there a step I included that I always do but couldn't actually explain the reason for? If yes, spend five minutes thinking through the reasoning. If you cannot explain the reason, investigate it before teaching the step as necessary.
This exercise follows the interview-based approach of capturing your explanation before shaping the prose. It does not remove the writing stage. It gives you source material to organize, question, and revise, with or without help from an interviewer.
And once you have a recorded, listed, reasoned sequence, you are much closer to a chapter than you realize. You have the problem. You have the steps. You have at least the beginning of the reasoning. You have something a writer or an AI system can work with. You've moved from "I should write a book someday" to "I have the core of chapter four on my phone right now."
The target is one process, one recording, and one provisional list. Compare the list with a real situation you can appropriately discuss. Where would it need a branch or exception? What evidence supports the advice? Your book will involve both thinking and writing, and this exercise gives you something concrete to work on.
Choose one process you explain regularly and record a short walkthrough, using notes if helpful. Then list the steps, the reason for each, and one situation where the order would change. Check any uncertain details. That list is a starting point for a chapter, not a finished or proven method. Your next task is to make the explanation clear enough for a reader to question and understand.
Take the next small step on your book today. For more guidance, find Talk Your Book Into Existence at startdictate.com/talk-your-book.
Visit startdictate dot com slash talk your book.
Next time on Talk Your Book Into Existence: Choose a Book Format That Serves Your Reader. Decide what the reader should be able to understand or do, then choose a format that supports that result. Follow the show so the next episode is ready when you are.
Thanks for listening to Talk Your Book Into Existence. Follow the show for your next practical step, and share this episode with someone who has a book in them. Your next conversation could be the start of a chapter.