Stop learning from Steve Jobs
|
Hey Reader! Everyone tells you to study Elon Musk. Here's the problem: those people aren't relatable. When I made a video about the 8 challenges non-tech founders actually face, I didn't pull from famous founders. I went to Reddit. Specifically r/entrepreneur and r/SaaS, and read through threads written by regular people in the middle of building real businesses. Founders venting at 2am about what went wrong. Sharing what worked. No PR spin. No personal brand to protect. That's where the honest stuff lives. Before you watch the video, try this:
The most useful mentor you'll find might be some anonymous founder who posted once and never came back. Cheers, P.S. When your research tells you it's time to build something. That's where I come in. I'll give you an honest read on whether the idea holds up, and exactly what it'll take to build it. Book a free strategy call → (3 slots a month, that's it.) |
Upstack Studio
Hey Reader! I want to make it concrete. Because "your processes are broken" is easy to say. It's harder to actually see, Especially when you're inside the business every day. So here are 3 signs the process is the real issue:The same mistake keeps happening with different people. If multiple team members have made the exact same error, it's not a hiring problem. The process doesn't protect against that mistake. No amount of training will fix it. The process needs to change. Onboarding a new...
Hey Reader! Tip: Setting deadlines without your team's input isn't managing. It's guessing out loud. Why: Technical work doesn't run on willpower. Deadlines set without developer input ignore testing requirements, hidden complexity, and the fact that some requests might be outright impossible. Do this: Manage your team, don't dictate to them: Set expectations and deliverables together — let the team give input on timelines and scope Once expectations are clear, give them room to breathe...
Hey Reader! Tip: Don't blindly copy your competitor's tech stack. Why: What works for them might be wrong for you. Their tech stack was built around their business model, their team size, their budget, and their specific problems. Those choices came with tradeoffs and limitations baked in. If you copy their stack without knowing any of that context, you're also copying the baggage that came with those tools; limitations that were acceptable for them but might be completely wrong for your...