A good business can still trap you 🪤 Melissa Kwan

Being close to a problem can make you dangerously confident about the buyer. Ayse Guvencer calls this the domain expert trap: lived pain can narrow how you see the market. Ayse moved from agency work and roles at Google and Sage into advising early-stage companies, where buyer research kept exposing assumptions teams had treated as facts. Those assumptions can shape the product and sales story before anyone checks them. Breaking them early can save months of work and money later. What we cover 1️⃣ Early enthusiasm can distort the roadmap Early adopters will tolerate rough edges and ask for more. Ayse explains why that enthusiasm is useful evidence and where wider market testing still needs to happen. 2️⃣ Use expertise to start the investigation Solving the problem yourself gives you a useful starting point. Buyer conversations show whether other people see the same problem and feel the same urgency. 3️⃣ Job titles don't define buyers Two people with the same title can be in completely different buying situations. Ayse looks for the trigger and who else shapes the purchase. 4️⃣ Category creation comes with an education bill Creating a category means teaching buyers before you can sell them anything. For an early company, working inside an existing market can be far cheaper. 5️⃣ Churned customers expose what broke Current customers show what is working. People who left can reveal where expectations failed and which assumptions are still shaping the product. Chapters 00:00 The buyer in your head 08:24 The domain expert trap 15:27 When the market surprises you 24:02 Category creation gets expensive 30:27 The 10-customer reality check Find Ayse on LinkedIn, ELVT Advisory and Founder’s Stack Trace Get more founder interviews and practical business lessons in the Millennial Masters newsletter at MillennialMasters.net If this made you think of a founder who keeps adding features because early customers ask for them, send them this 📧

Space startups can raise hundreds of millions before their technology ever flies. Philip Hover-Smoot thinks that can distort what investors see as real progress. Philip left Scout Space, where he’d been CEO, to build Atlas Cup, a spacecraft racing league designed to make rival teams prove what their technology can do in public. His bet is that performance can become proof before revenue arrives. That matters in an industry where funding rounds can look like traction long before anything has flown. What we cover 1️⃣ Funding can look like traction Philip explains why large funding rounds can create the appearance of progress in space even when the underlying technology still has very little public proof. 2️⃣ Creating an earlier test of progress Atlas Cup is designed to give spacecraft companies a shared performance test, so investors and partners can judge what works before normal traction metrics arrive. 3️⃣ Interest matters when others commit something Before the first race, teams had signed up and major brands were already in talks. Philip treats that outside commitment as a more useful early signal than attention alone. 4️⃣ Fundraising can distort the build order Philip is resisting pressure to raise much more and move faster. He wants to prove uncrewed racing first before taking on a far riskier version of the plan. 5️⃣ The identity cost of starting again Philip went close to a year without paying himself. Leaving the CEO role carried its own identity cost after years spent working towards that position. Chapters 00:00 Proving which space startups are real 06:04 Racing spacecraft for proof 15:29 When funding looks like traction 24:08 Selling sponsors before launch 29:51 Why he won’t raise $30m yet 36:41 Starting again without the title Find Philip on LinkedIn Get more founder interviews and practical business lessons in the Millennial Masters newsletter at MillennialMasters.net Know a founder raising before the proof is obvious? Share this with them 📧

You can hand finance to someone else, but you still need to understand what the numbers are saying. Otherwise, you can easily make big decisions without seeing what's really happening. Lauren Pearl learnt that the hard way after a finance-trained classmate diagnosed the family business in minutes. She now advises founders and teaches financial modelling at NYU Stern. Knowing the numbers later made it harder to ignore the truth when her startup Roost needed to close. This episode shows how models can expose problems before a big decision gets expensive. What we cover 1️⃣ What you still need to know Delegating finance doesn’t remove the need to understand it. Lauren explains the numbers founders should know well enough to question decisions and spot when something is off. 2️⃣ Where growth forecasts go wrong Revenue shouldn’t rise in a model just because you want the business to grow. Lauren shows how forecasts become useful when growth is tied to work the business can actually do. 3️⃣ What hiring really costs you Salary is only the starting point. Equipment, tax, HR costs and the delay before a new hire generates cash can turn an affordable-looking decision into a much bigger commitment. 4️⃣ The model before the forecast At the earliest stage, Lauren treats the financial model as a feasibility study. Its first job is to test whether realistic revenue can cover the costs of the business. 5️⃣ When the numbers say stop Lauren knew Roost needed to close before she acted on it. She explains how numbers can make the warning signs harder to ignore when emotion keeps pulling you towards more time. Chapters 00:00 Episode highlights 01:07 Where finance became real 09:50 What founders need to understand 20:01 Growth without work 35:04 Deciding what failure looks like 53:37 The hidden cost of hiring 57:32 Can this business make money? Links Find Lauren on LinkedIn and at Lauren Pearl Consulting. She also co-hosts The Growth Minded CFO podcast. Get more founder interviews and practical business lessons in the Millennial Masters newsletter at MillennialMasters.net. Send this to a founder making big decisions without knowing what the numbers say 💸

You can build a tech company without becoming a developer, as long as you understand enough to work properly with the people building it. Sophia Matveeva, founder of Tech for Non-Techies, learned that after raising money for her first startup and hiring a technical team. She was the CEO, but when a developer started talking about building the back end on Ruby on Rails, she realised she had no idea what he meant. Her first instinct was to learn to code. After taking computer science and Python courses, she realised she was spending hours learning skills that wouldn’t help her do her actual job. What she needed was enough technical understanding to make decisions, ask useful questions, and work effectively with the team. AI has lowered the barrier again. A non-technical founder can now make a convincing prototype in an afternoon, which makes it easier to start building before finding out whether people understand the product or would pay for it. In this episode, we get into what non-technical founders actually need to understand about tech, how to test an idea before spending heavily on it, and where vibe coding stops being enough. What we cover 1️⃣ Speaking enough tech to lead the work Sophia explains what founders need to understand so they can make better decisions and work properly with developers without trying to become one themselves. 2️⃣ Testing demand before writing production code A prototype can get the idea in front of potential customers much earlier and expose problems while they’re still cheap to fix. 3️⃣ Getting feedback people actually mean This part gets into user interviews, avoiding leading questions, and creating enough space for people to tell you when something doesn’t make sense. 4️⃣ Where vibe coding reaches its limit AI can take a non-technical founder surprisingly far, but a convincing prototype doesn’t mean the underlying product is ready for real customers. 5️⃣ The problem a better product still has to solve Customers already have habits, tools, and systems around existing products. Being better isn’t always enough to make them switch. Chapters 00:00 Introduction to Sophia Matveeva 02:08 Is vibe coding improving product testing? 05:34 Why founders need to speak tech 12:54 How to manage developers 15:31 Test your product before building it 18:47 How to get honest user feedback 22:47 Will people actually pay? 25:57 How to challenge your technical team 30:38 Choosing which features to build 32:57 Why Sophia shut down Enty 35:22 Funding versus bootstrapping 37:23 When to stop funding your own business 39:19 Why better products still lose 42:58 What AI changes for non-technical founders 45:47 Building is easier, finding customers isn’t

Konstantin Klyagin has spent more than two decades building software for other companies, and lately he’s also been fixing more of what AI helps people build. Through his agencies Redwerk and QAwerk, he sees what happens after the prototype looks convincing and real users start doing things you didn’t expect. Something that worked perfectly in a demo can suddenly fail on basic workflows, from payments to duplicated bookings. That’s why Konstantin sees AI as a multiplier. It can help you build more, but it can also accelerate a bad decision before you’ve realised you misunderstood what people actually need. When almost anyone can turn an idea into working software, deciding what deserves to be built becomes more important. In this episode, we get into where vibe-coded products start to break, what still needs proper technical experience, and how to build a software business when AI is available to everyone. We also talk about bootstrapping, hiring behind demand, and what 21 years in business taught Konstantin about adapting when circumstances change underneath you. ___ ⭐️ Episode sponsored by DataForSEO ⭐️ Check how your business appears across AI answers and web search. DataForSEO is pay-as-you-go, and new users who sign up through the Millennial Masters get $5 in credits to try it. 👉🏻 Check your visibility 🔎 https://l.dataforseo.com/3Uu7ksv ___