Business Lessons Hiding in a Builder's Quiet Decisions
Most business advice focuses on dramatic moves: the big launch, the viral post, the bold pivot. Yet the lessons that tend to hold up over years are often hidden in quieter decisions. What did the builder cut from the plan? In what order did they tackle things? What did they decide not to build? When you follow a public builder such as Todd Michael, whose work spans books, a podcast, a browser-game arcade, and a strategy call offering, these smaller choices are often more instructive than any single headline. This article offers a method for reading them, along with questions you can apply to your own work.
Start With What Was Left Out
Every project is a series of subtractions. A podcast episode omits a tangent; a product launch omits features; a business plan omits channels. When you study a builder's public output, the omissions are usually more revealing than the inclusions, because they show what the builder considered non-essential. Ask: what does this project clearly not try to do? Where does the creator decline a format, a platform, or an audience they could have chased?
A useful exercise is to write down three things a project does and three things it conspicuously does not do. Then ask whether the absences are deliberate. A catalog of books that stays focused on a few core themes, for example, suggests a decision about identity rather than a lack of ideas. Your own takeaway might be to define the boundary of your offer before you define its growth plan.
Read the Sequence, Not Just the Result
Outcomes are visible; sequences are not. A builder who publishes a memoir, then a how-to book, then a podcast, is telling you something about dependency and order. Which asset came first, and which one was built on top of it? Sequencing decisions reveal assumptions about what has to exist before something else can work.
To apply this to your own business, map the order of your last three significant projects. For each, note what had to be true before the next step made sense. Did you need an audience before selling? Did you need a repeatable process before hiring? If your sequence looks random, that is a signal to write down dependencies explicitly before your next launch.
Treat Public Building as a Record of Constraints
Builders who work in public expose their constraints, whether they mean to or not. Time, budget, tools, and attention all shape what gets shipped. A project that moves in small increments may be constrained by a single person's hours. A project that pauses for months may be waiting on a dependency or a decision. Reading these constraints teaches you what to plan around instead of pretending they do not exist.
When evaluating any creator's public work, ask questions such as: What seems to limit the pace here? Is the bottleneck production, distribution, or decision-making? What would have to change for the pace to double? These questions turn passive admiration into diagnostic thinking that you can use on your own operation.
A Checklist for Extracting Lessons
Use the following plain-language checklist when you study any builder's body of work, including the public projects at toddmichael.tv. First, identify two or three projects and state, in one sentence each, what problem they seem designed to solve. Second, list what each project leaves out on purpose or by apparent choice. Third, reconstruct the order in which the projects appeared and note which one depended on the others. Fourth, look for recurring constraints such as time, format, or audience size. Fifth, write one decision you would make differently or the same way in your own context, and say why.
Keep the output short. A lesson you cannot state in two sentences is probably not yet a lesson. Revisit your notes after a month and check whether your conclusions still hold when you compare them with new evidence from the same source.
Applying the Lessons to Your Own Work
Once you have extracted a few lessons, translate them into your own operating rules. If you learned that a builder protected a narrow theme, define the theme that your own project will protect. If you noticed a deliberate sequence, write your own dependency chain on paper. If you saw a constraint that shaped pace, plan your calendar around that constraint rather than around an ideal schedule.
Remember that you are learning patterns, not copying outcomes. A strategy that worked for one builder in one context may not transfer. The value of close reading is that it sharpens your questions, which is far more useful than any borrowed answer. Ask better questions, record your reasoning, and test your conclusions against your own results over time.