You may already know what you want to build: a book, workshop, course, app, service, community, or consulting offer. Naming the product makes the project easier to imagine because the form immediately gives you something to design. But it can also make you loyal to a solution before you are clear about what the work should make possible for the person you want to help.
The better starting question is not What should I build? It is What should become possible for whom because I build something?
That is the promise.
The product gives you something concrete to work on
Suppose you decide to write a book. Almost immediately, you can think about chapters, stories, length, cover design, and publication. If you decide to create a workshop, you can build learning objectives, modules, exercises, slides, and an agenda. An app suggests features. A consulting business suggests packages and services.
There is nothing foolish about beginning this way. A product gives an idea a container, and builders need containers. The form reduces ambiguity because you already know many of the decisions that come with it.
The problem begins when the container quietly becomes the reason for the work. You start asking what else the course needs instead of asking whether people need a course. You add another chapter because books have chapters, another module because workshops have modules, or another feature because software can carry features. Each decision may be defensible on its own while the project moves farther away from the difference it was supposed to create.
That is how a product can become more complete without becoming more useful.
I spent years thinking in workshops
For many years, workshops were a natural way for me to think about my work. Clients asked for workshops. I was a trainer and facilitator, so I knew how to design them. We could clarify the topic, identify learning objectives, build the sessions, run activities, facilitate discussion, take photos, collect evaluations, and close the event knowing that people had experienced something worthwhile.
And worthwhile workshops do matter. A good session can help people see a situation differently, practise with others, have conversations they were not having before, and leave with more energy and clarity. I still believe in that kind of experience.
But I kept seeing what happened after people returned to work. The same pressure was waiting. The same systems were still operating. The same unfinished work, difficult conversations, deadlines, and supervisor habits returned. Someone could understand delegation during a workshop and still take the work back when a deadline was threatened. A manager could agree with the importance of feedback and still postpone the conversation when it became uncomfortable.
That was the gap I had to confront.
The workshop was good. But the old game was stronger.
Once I saw that gap clearly, the design question changed. Instead of asking only, What workshop should I create?, I began asking, What journey will help people keep moving after the first experience? That question eventually pushed the work beyond standalone training events toward tools, scorecards, practice experiences, cohorts, workplace application, and other forms of support depending on what people needed next.
The workshop did not become wrong.
It stopped being automatically right.
When the promise changes, the product may need to change too
The difference became even clearer while I was designing experiences for new supervisors.
It would have been easy to begin with topics. New supervisors need communication, delegation, motivation, accountability, feedback, coaching, decision making, and performance management. Put those topics in order and you have the beginnings of a supervisory course.
But supervisors do not face topics at work. They face moments.
A newly promoted supervisor asks a former peer to complete an important report. The employee says, “Yes, I understand,” and the supervisor has only a few seconds to decide whether that answer is enough. Later, when the work starts slipping, she feels the familiar urge to take over because finishing the task herself seems faster than diagnosing why the work is stuck.
Those are not modules. They are critical moments in which a supervisor must make a move.
Once the intended result became clearer, the form had to answer to it. If the promise were simply help supervisors understand supervision, then explaining the right topics might be enough. But if the promise is closer to help new supervisors make useful moves in the moments where leadership becomes real, then understanding is only part of the design.
They need to recognize those moments. They need useful plays they can practise. They need opportunities to try them, adapt them, return with evidence, and learn what actually happened in the workplace.
That thinking helped shape Shift30 as a guided workplace experience rather than merely thirty days of content. The experience is organized around a mission, critical moments, practice, workplace application, Action Teams, and evidence because those elements are closer to the promise than a larger list of topics would be.
This is what starting with the promise can do.
It does not tell you that workshops, courses, books, or apps are bad products. It gives you a reason to choose one.
The product is the container
A book is a container. So is a workshop, coaching session, app, checklist, membership, video series, community, service, or four-week learning experience.
Each container has strengths. A book can carry an idea to people you may never meet. A workshop lets people practise together. A short card can sit beside someone when a critical moment arrives. A conversation can respond to what one person needs now. Software can make a recurring action faster and more reliable.
Those are design advantages, not reasons for existence.
The promise answers another question:
What useful difference is this container supposed to help create?
That distinction matters because a product may need to change while the promise remains steady. If readers need a shorter guide instead of a large book, shortening the book may serve the promise. If managers understand a workshop but need a practice card at work, the card is not a distraction from the workshop. It may be a better carrier of part of the promise.
The form should be allowed to move.
The reason for the work should be harder to move.
A promise is not a dramatic marketing claim
The word promise can easily sound like advertising, so I want to draw a boundary around it.
I am not asking you to claim that your product will transform someone’s life in seven days, double a person’s income, or turn every participant into an extraordinary leader. You do not control another person’s choices, effort, circumstances, or results, and pretending otherwise makes the promise less useful as a design tool.
Think instead about a use promise.
A use promise names something your work is designed to help make possible. A guide might help someone compare three options before making a difficult decision. A workshop might help supervisors practise one conversation they usually avoid. A tool might help a manager make expectations visible before work starts.
This is close to the discipline I use when designing Minimum Lovable Plays: the promise should be simple enough to show what the tool or play helps someone do in the moment that matters.
The promise does not guarantee the final result.
It gives the builder a responsibility.
The familiar move is to protect the product
Once you have invested time in a form, it becomes difficult to question it.
You build a course and people do not finish it, so you improve the videos and add another module. Managers leave a workshop inspired but fail to use the practice, so you add more explanations. Customers keep asking for personal help from a self-service product, so you create a longer FAQ.
Those responses make sense. You already know the product. You have invested in it. Changing the existing form feels safer than reopening the larger design question.
But sometimes the evidence is not asking for a better version of the same container.
It is asking whether the container fits the promise at all.
Perhaps people do not need another lesson. They need a cue at the moment of action. Perhaps managers do not lack understanding; they lack repeated practice under realistic pressure. Perhaps a supposedly self-service problem actually requires some human judgment.
If you begin with the product, those possibilities can feel like threats to the project.
If you begin with the promise, they become design options.
Remove the method from the sentence
One practical way to uncover the promise is to temporarily remove the product from your description.
Instead of saying:
We will create an online course that teaches managers how to delegate.
try describing what should become different:
When managers hand off important work, they can make the expected result clear, transfer ownership, and check progress without automatically taking the work back.
Now you have room to think.
Perhaps an online course belongs in the solution. Perhaps managers need a live practice session. Perhaps a simple delegation card would do more for the critical moment than another hour of content. Perhaps the strongest design combines a short learning experience with repeated workplace practice.
You do not yet have to know.
The promise gives the possible products something to compete for.
Move the promise closer to a moment
Even a well-intentioned promise can remain too broad to guide design.
“Help people succeed” gives you very little to build from. So does “develop better leaders,” “improve communication,” or “help entrepreneurs grow.” These may describe territories worth working in, but they do not yet tell you what the person will be doing differently.
Move closer to the moment.
Ask when the person needs your work, what they are trying to accomplish, what normally happens, and what should become possible instead.
Consider the supervisor who is about to hand off an important task. The familiar move is to explain the assignment, hear “Yes, I understand,” and continue. The misunderstanding becomes visible hours or days later.
A more useful promise might be:
Help the supervisor make understanding visible before the employee begins the work.
That statement immediately creates better design questions. What must the supervisor say? What must the employee be able to explain back? Does this require a script, a card, a rehearsal, an example, or something else?
A vague aspiration may inspire the work.
A specific moment can begin to design it.
Try the Promise Before Product Play
Take one thing you are planning or already building. For a few minutes, remove its current form from the conversation. Do not think about the number of chapters, modules, features, packages, pages, or sessions.
Complete this sentence:
When ______ is trying to ______, I want what I build to help them move from ______ to ______. I will know it helped when ______.
Then work through four moves:
- Name the person and moment. Get closer than “leaders,” “parents,” or “entrepreneurs.” Who is doing what when the need appears?
- Name what happens now. Describe the current response or difficulty without hiding your preferred solution inside it.
- Name the useful movement. What should the person be able to do, choose, see, or complete differently?
- Name the proof. What observable sign would suggest that what you built actually helped?
Suppose your original idea is I want to create a program for new supervisors. After removing the product, you might write:
When a newly promoted supervisor is handing important work to a former peer, I want what I build to help her move from assuming that agreement means understanding to making the expected result visible before work begins. I will know it helped when both people can describe the same result, standard, and next step.
Now bring the product back.
What is the most useful form for helping that happen?
That question is much better than starting with, How many modules should the program have?
Use the promise to examine something you already built
You do not have to throw away an existing product to use this idea.
Take one chapter, feature, session, exercise, service step, or tool and ask what part of the promise it helps carry. If you cannot answer immediately, investigate before removing it. The connection may simply need to become clearer.
You may also discover that the product is trying to carry several promises at once. A workshop that tries to create awareness, build skill, change habits, solve every workplace barrier, and sustain the behavior for six months may be asking one container to do too much.
The point is not to make everything smaller.
The point is to make the design answer to the difference it exists to create.
Your first win is not a finished product
You can benefit from this article before you ship anything.
Your first win is being able to say clearly:
This exists to help ______ do ______ when ______.
Once that sentence becomes clear, choices become easier to challenge. You can question a chapter that does not serve the promise. You can remove an exercise that is engaging but unnecessary. You can test a simple manual service before investing in software. You can discover that a short guide is more useful than the large book you originally imagined.
The promise will not make every decision for you.
It gives every decision something to answer to.
The promise also tells you what proof to follow
Eventually, something will be built.
The book gets published. The workshop ends. The app launches. The program reaches its final week.
Those are meaningful production milestones, but they do not yet tell you whether the promise happened.
Completing the workshop proves that the workshop happened. If the promise was to help supervisors make understanding visible before work begins, then the more interesting proof appears later: Did they ask the clarifying question? Could employees explain the expected result? Was there less avoidable rework? Did the play survive when the workplace became busy again?
This is why the distinction matters so much:
The product gives you something to ship. The promise tells you what to follow.
In my own supervisor work, this eventually led to a much more demanding standard. The real product is not the slide deck, course, workshop, or playbook. What matters is whether the supervisor leads differently afterward: a clearer instruction, a braver conversation, a stronger huddle, better follow-through, or an employee who finally understands what good work looks like.
The container matters because it carries the work.
The promise matters because it tells you whether the work traveled far enough.
Let the product earn its shape
This week, choose one thing you are planning, building, or already selling and temporarily remove its product name.
Describe the person. Describe the moment. Describe what happens today. Describe what should become possible instead. Then name one piece of evidence you would be glad to see after the person uses what you build.
Only then ask again:
What should I build?
You may arrive at the same answer. The workshop may indeed be the right container. The book may be exactly what the promise needs. The app may solve the recurring problem better than anything else you could create.
If so, you will now build it for a clearer reason.
Or the promise may lead you somewhere else.
That is not losing the project. It is allowing the project to become more faithful to why you wanted to build it in the first place.
Start with the promise. Let the product earn its shape.
Continue building
If you cannot yet name what deserves to become different, begin with Begin With a Problem Worth Solving. The problem gives the promise something real to answer.
If the promise is clear but the project keeps becoming larger, continue with Build the Minimum Lovable Version. That page helps you decide how much version one actually needs in order to create one useful win.
And for the larger journey—from an important idea to something another person can use, test, and help improve—return to Build Something.
The next question is no longer simply what you want to create.
It is what must become possible—and what form gives that promise its best chance to become real.