How Noah Fichter built Scout by falling in love with customers, not problems

Executive overview

Most founders fall in love with a specific problem and bang their head against it until it works. The smarter move is to fall in love with a type of customer and search relentlessly until you find their most painful problem.

Noah Fichter learned this through three stages: a high school sneaker bot, scaling a fintech startup, and a long search through the education problem space before finding Scout — a student-monitoring tool for online schools.

If nobody is willing to tell you what they hate about your product, they don't care enough about the problem. That's your signal to stop.

From sneaker bot to first paying customers

• Built a checkout automation bot in high school to buy limited-release sneakers
• Noticed others in the community were desperate for the same access — validated demand before building for others
• Released early with broken software; angry customers stayed because they were bought into the vision
• Iterated weekly based on direct user complaints, staying up through the night before each release
• Core learning: get the product into real hands fast, then use hatred as a signal of genuine care

Scaling at Slash (YC fintech)

• Joined as an early engineer when the platform was unstable but solving a real problem — users loved it despite the rough state
• Learned to manage feedback at scale across a wide range from solo entrepreneurs to high-spend businesses
• Engineers owned customer relationships directly, not just a support team — building required being able to articulate why something mattered to users
• Major mistake: spent months building a personal finance feature without validating it; it flopped completely
• The failure reset the team's operating mode: discover pain first, then build — not the other way around

Searching for the right problem in edtech

• Left Slash to find an education problem worth solving; spent months on nights and weekends with co-founder Max
• Tested lesson planning, data analytics, and platform integrations — each time the market didn't care enough
• Blasted cold emails to thousands of schools with no clear target segment, just to find who would respond
• A single inbound response changed everything: an online school described a concrete, acute problem — teachers couldn't track what students were doing across 50 different online platforms
• Recognised the difference between a vague wish ("I wish my tools talked to each other") and deep operational pain ("we cannot run our school without solving this")
• Applied to YC with the new problem after a previous application was rejected; YC had told them the idea was wrong but backed the founders

Building Scout and operating as a team

• Scout automates student-activity monitoring across platforms for online and hybrid schools
• Early internal structure was chaotic; eventually split responsibilities: Noah owns new sales, Max owns implementation and engineering
• Sharp division created new problems — over time they added overlap during pilots, which span both sales and implementation
• Weekly co-founder check-ins surface internal pain the same way customer interviews surface product pain: name what isn't working, try something different, observe the result
• Every organisational change traces back to a felt problem, not a top-down process decision

Advice for founders in regulated or complex spaces

• Fall in love with the customer, not the problem — it lets you pivot to the real pain instead of defending a bad hypothesis
• People only change behaviour when you solve one of their top three priorities — anything lower on the list won't generate traction regardless of quality
• Validate urgency by listening for hatred, not approval — indifference is the kill signal
• The "idea maze" takes longer than expected; sustain it by making the search genuinely enjoyable, not just a means to an end