A lot of SaaS products ship fast and skip the thinking. This episode is about what happens when you don't, and why that actually matters for growth.
Bob Baxley spent 35 years designing software at Apple, Yahoo, Pinterest, and ThoughtSpot. Products he worked on have been used by hundreds of millions of people. He's one of those people who has spent a long time thinking carefully about what makes software genuinely good, not just functional, and why so few companies get there.
In this conversation, we get into how to build a culture where quality is the standard, how to get your whole company to care about design without a single presentation, and how the decisions you make at the conceptual level shape everything downstream.
🧠 What you'll learn in this episode:
0:00 - Why the tech industry is in a speed race and what that means for product quality
7:37 - How Bob fell in love with computing at 11 years old and why that shaped everything after
12:31 - Why timing matters as much as talent when it comes to what you can build
13:58 - How economic pressure from VCs is changing the pace of design work inside companies
24:36 - The real difference between sales-led and product-led companies, and why it never changes after founding
27:05 - Why design teams have hurt themselves by hiding their process from the rest of the company
30:00 - How Bob's team ran an internal influence campaign at ThoughtSpot using weekly Loom videos
35:49 - What a head of design actually does on a sales call and why it worked
37:42 - Design tenets vs. design principles, and which one actually helps teams make decisions
42:30 - What choreography over control looks like in practice for a design leader
47:51 - The difference between micromanagement and being in the details, and why it matters
54:55 - How to think about quality within constraints instead of chasing world class as a target
1:00:46 - Why taste is hard to compete on, and which layer of the market you actually need to nail first
1:01:15 - A simple exercise to raise the taste level of your engineering team
1:06:08 - The three stages every market goes through before design becomes a competitive advantage
1:12:36 - What it really means to design for the person on the other side of the glass
1:16:57 - Why user research needs to be a ritual, not a one-time sprint
1:20:44 - The Post-it note observation that turned into a multi-billion dollar company
1:24:29 - Bob's favorite apps and what they got right at the conceptual model level
💡 Actionable takeaways from Bob
Steal these quick wins:
1. Run the "three favorite apps" exercise with your team
Ask everyone to name their three favorite apps .Not the ones they use most, their actual favorites. Getting your team to sit with that question starts a real conversation about what quality actually means versus what just has good distribution.
2. Show the work before it's done
Bob's team at ThoughtSpot made a 22-minute Loom video every week for 35 weeks, showing projects at every stage and sent it to the whole company. It shifted how every department understood and valued design work, without a single big presentation or formal pitch. If your team feels invisible inside the company, this is a low-cost way to change that.
3. Replace your design principles with tenets
Principles like "be clear" or "feel responsive" don't help anyone make a decision because nobody argues the opposite. A tenet is a hard-edged statement your team agrees on once so they stop relitigating the same debate.
4. Go watch your users outside the context of your product
When Bob was asked about ZenMaid, his recommendation was to visit cleaning business owners and understand how they think and run their business, not just how they use the software. Watching how someone actually works, before you introduce your product into the conversation, gives you better ideas than any feature interview.
5. Ask an LLM you've been using regularly: "What outdated mindset am I holding onto that's no longer serving me?"
The answer Bob got shifted how he thought about control and leadership. His suggestion is to run it with an LLM that has enough context on you to give a real answer, not a generic one.
