What Entrepreneurs Can Learn from Creative Confidence
Entrepreneurs often treat the business plan or pitch deck as the finish line, polishing a solution in isolation before a single real customer has weighed in — or they avoid the messier, more improvisational parts of building a company because they think of themselves as "operators," not "creative types." Both habits skip the same step: getting close enough to a real problem to know if the solution is even worth building.
The whole book, compressed
This edition works through 4 core lessons — take them one at a time, not all at once.
What's different for your conditions
Tap whichever ones sound like you. Nothing here is sent or saved — it's just for your own noticing.
0 of 4 selected
The core lessons, applied to you
Get close to the real problem or the people affected by it before jumping to solutions
A founder's instinct is to build the thing they already picture in their head; the discipline is to first confirm that picture matches what a real customer actually struggles with.
A founder spends three months building a scheduling feature they're convinced small gyms need, based on a single conversation with a friend who owns one gym. When they finally demo it to ten other gym owners, most say scheduling was never their bottleneck — staffing was.
Before building anything new, spend a week talking to five people who live with the problem daily, asking only about their current workarounds, not your idea.
Generate many possible ideas before judging any of them
Founders under time pressure tend to grab the first workable idea and run, which quietly forecloses better options that were one conversation away.
A two-person startup needs a way to onboard new users faster. The first idea that comes up in a five-minute Slack thread — an in-app tutorial — gets built immediately, without anyone spending fifteen more minutes listing four or five other approaches worth comparing.
Before committing engineering time to any feature, write down at least five different approaches, including a couple of "bad" or unconventional ones, before picking which to pursue.
Build something rough and quick to test an idea, rather than perfecting it in your head first
A rough prototype in front of a real user teaches a founder more in an afternoon than another week of internal debate.
The team argues internally for two weeks over whether a new pricing page will confuse customers, running the debate entirely in hypotheticals instead of showing a rough mockup to five actual prospects.
Turn any unresolved internal debate about a feature into a paper sketch or clickable mockup and show it to three real users within 48 hours.
Treat early failure as useful data and iterate from there
When an early version of a product lands flat — a landing page nobody signs up for, a demo that leaves a room quiet — the useful move is to treat that as information about the problem rather than a verdict on the founder or the venture. Reading the specific reason customers walked away, rather than the fact that they walked away, is what turns a stalled launch into a sharper second attempt. Over time, founders who build this habit stop bracing for each release to be the final word and start treating each one as one data point among many.
Talking to more customers can start to feel like stalling when a launch deadline is close. In practice, a rough test with a handful of real users takes less time than the internal debate it replaces, so it rarely costs the schedule what it feels like it will.
Name one thing, honestly
What is one assumption in your current plan that you're treating as settled but have never actually tested with a real customer?
Good. Now look back at the "Try this" line under whichever lesson feels most connected to what you just wrote, and treat that as this week's actual assignment — not all 4 at once.
The practices from this edition
0 of 3 selected
Run this for seven days
Turn any unresolved internal debate about a feature into a paper sketch or clickable mockup and show it to three real users within 48 hours.