Simon Sinek tells us to start with why. To identify our passion and discover our purpose.

But you don’t need to come up with the why. You can just find someone else’s why.

Copy, steal, follow or borrow.

Most people who’ve contributed to meaningful causes didn’t invent them. They found something that mattered and signed up. The civil rights activist who joined an existing movement. The researcher working on someone else’s hypothesis. The employee building someone else’s company.

Looking for YOUR unique purpose usually leads to paralysis. Meanwhile someone else’s why is already out there with infrastructure, community and momentum.

So if you’re stuck searching, look around at the whys that already exist. Find one that seems important. Then just start.

Your why doesn’t need to be original. It just needs to be enough to get you moving.​​​​​​​​​​​​​​​​

Back when I made music with basic drum machines, everything sat perfectly on the grid. Mathematically correct. Completely lifeless.

You had to manually add swing to push the 16th notes slightly forward. That gave you groove. The offbeats shifted later in time and suddenly the rhythm had pocket. Without swing, hi-hats and snares hit with robotic precision that made everything feel stiff.

Now tools like modern DAWs do this automatically. They randomize both timing and velocity. Some notes rush a bit, others drag. Some hits are louder, others softer. The grid breaks just enough to sound human.

AI writing has the same problem. It sits perfectly on the grid. Every point explained. Every connection spelled out. No space for the reader to fill in gaps.

The fix is similar. Strip out everything someone can read between the lines. Let some ideas hit harder than others. Add your personal stories because those are the velocity changes AI can’t generate.

Take something rigid and mathematical. Make it groove.

Existing companies make the opposite mistake of new companies but end up in the same place. “We have 50,000 customers so our new feature needs to work for all 50,000.” This sounds logical until you realize those customers probably break into distinct groups with completely different needs.

Building for everyone means the feature ends up mediocre for everyone. Instead of transformative for a meaningful subset who become your internal advocates. A useful reframe is asking which 5,000 of your 50,000 customers would get the most value from this new capability. Start there, nail it then expand. The other 45,000 aren’t going anywhere.

Legacy-driven broadness happens because companies mistake their current customer base for their target market. But your customer base is the result of all your previous targeting decisions. Your new feature doesn’t need to serve that entire base. It needs to serve the people who have the problem you’re trying to solve.

The irony is that the “safe” approach of building for your entire market is a riskier strategy. You’re spreading resources thin across a dozen half-solutions instead of creating one solution that people can’t live without.

New companies kill themselves trying to be everything to everyone from day one. “If we only target busy parents, what if busy parents don’t actually want this?” So they expand to busy professionals, students and anyone else who might be interested.

The problem is that a solution that’s amazing for busy parents will naturally attract busy professionals and anyone else juggling priorities. But a solution designed for “everyone who’s busy” will be mediocre for all of them.

Going broad feels safer because it seems like you’re hedging your bets. But you’re actually making a much riskier bet. You’re betting you can out-execute every focused competitor who’s solving the specific problems you’re trying to solve generally. The restaurant that tries to serve “food for everyone” ends up with a massive menu that’s mediocre at everything.

Fear-driven broadness is the opposite of product-market fit.

A big mistake companies make when building products is confusing market with target. Thinking going broad means capturing more market share. But it usually means building something mediocre for everyone instead of something essential for someone specific.

Market is the opportunity. Target is who you’re solving for. When you nail it for a specific target customer, you often discover they’re a wedge into a much larger market. Solving it really well for the target, opens the door to every other closely related segment.

This confusion shows up in two predictable ways. New companies go broad because they’re afraid their specific target won’t be enough to sustain a business. Existing companies go broad because they think new features need to work for their entire customer base. Both approaches backfire for the same reason. Specificity in who you’re serving leads to specificity in what you’re building.

Start every new project with Claude Code by asking it to create an idea.md file. Tell it to listen and structure what you write. Nothing more.

Then just talk.

Dump your thoughts into the chat. Explain the tech stack. Share what you expect the system to do. Write freely. Show screenshots of similar apps. Reference existing patterns you like.

Claude Code will organize everything into idea.md as you go.

Review the file periodically. You’ll spot gaps in your thinking. Add those missing pieces. New requirements will emerge from seeing your ideas structured. Feed those back in.

This creates a feedback loop: Talk. Read. Think. Repeat.

When idea.md feels complete and you’re ready to build, ask Claude Code to break the implementation into testable phases. Each phase should work independently:

• Phase 1: API endpoints you can test with curl
• Phase 2: Mock data and basic responses
• Phase 3: Minimal UI that connects to the mocked backend
• Phase 4: Real data sources
• Phase 5: Polish and edge cases

Every phase produces something you can verify works before moving forward.

The magic is in the constraint. By forcing all your ideas through a single markdown file first, you build clarity before code. By demanding testable phases, you avoid the trap of trying to build everything at once.

99% of the time I use a QR code it’s to browse.

The ads say: fill out the form over here, read more about it over here.

The mental model is to open the browser and… well yes… I need to open the camera app… then scan… then it automatically goes back to the browser.

That little detour through the camera breaks the flow every single time.

You can’t judge a new technology by how well it copies the old one.

It’s like looking at the first cars and asking “Can this plow my field better than my horse? Can it carry as much hay?”

The question isn’t whether it can do what came before. The question is what can it do that nothing else could do.

However, if the new tech is proclaiming to plow the field and the only thing it does is autocomplete, then judge away.

Real innovators are students first. They study, understand, then move.

Innovation is movement. You need to map the territory before you can navigate it.

When using AI most people jump straight to “make me a website about X” without doing the hard thinking first, but AI doesn’t just make us faster when used right, it makes us more thorough. The opportunity isn’t speed, it’s combining research with execution to create work that’s better than what came before. Think like a researcher and ship like startup.