Key Takeaways

  • Whatnot's product culture, championed by CPO Tom Verrilli, operates on a "verify then trust" principle, challenging the typical "trust but verify" model for senior leaders.
  • Founder-CEO Grant clears his entire day to troubleshoot features and data directly with individual contributor (IC) teams, pulling up tickets, code, and analyzing data line by line.
  • This deep 'in-the-weeds' involvement prevents macro decisions from being made without a real understanding of micro-level ground truth.
  • Verrilli argues this hands-on approach, when leadership is "specifically correct" in their feedback, counters the negative perception of 'micromanagement' and ensures leaders add real value.
  • The goal is to correct and unblock teams through direct engagement, fostering a truth-seeking environment over one of political alignment.

The Method: Why Whatnot's Leaders Get 'In The Weeds'

Most leaders delegate. They read reports, check dashboards, and trust their teams. But at Whatnot, the rapidly growing livestream shopping platform, their founder-led product culture hinges on a different philosophy: "verify then trust." CPO Tom Verrilli argues that product management's widespread existence is regrettable in many companies, pushing instead for leaders to stay deeply 'in the weeds' to make better product outcomes.

Verrilli explains that while hiring great people is essential, Whatnot’s leaders, including CEO Grant, actively immerse themselves in the minutiae of product development. “The real answer is obviously the better people you hire the more you can kind of like totally trust that they know what they're doing. But we tend to live in a verify then trust land,” Verrilli says. This isn't about second-guessing; it's about staying connected to the ground truth. He describes how CEO Grant will sit in a review, question a detail, and then commit serious time: “I'm going to clear the rest of my day. Let's sit and figure it out.” This means literally pulling up tickets, examining code, and sifting through data line by line with the engineering and design teams.

This level of hands-on engagement, what Verrilli calls “time spent actually working alongside those teams like in the trenches trying to solve something,” is the antidote to poor leadership. He draws a sharp distinction between 'in-the-weeds' leadership and what often gets labeled as micromanagement. “Top-down works well if leadership is good enough to be in the weeds and be specifically correct,” he explains. Micromanagement, conversely, “falls apart... where you don't actually know ground truth and then you attempt to manage people from above.” Without pushing yourself down to sit alongside IC engineers and designers, you simply don't have the micro-level understanding needed for sound macro decisions.

Where This Breaks Down

This 'in-the-weeds' method, while powerful, isn't for every leader or every situation. Its effectiveness hinges on the leader's actual competence and currency with technical details, product logic, and user experience. If a founder-CEO can't genuinely be "specifically correct"—if their input isn't truly helpful or informed—this approach quickly devolves into the micromanagement it aims to avoid. An out-of-touch leader clearing their day to dig through a codebase they don't understand might waste team time and erode trust, rather than build it.

Furthermore, while suitable for a company like Whatnot, with its lean PM model and relatively focused product domains, infinite scalability is a challenge. As a company grows to hundreds or thousands of engineers across many different products, it becomes physically impossible for a single CEO or even a small leadership team to maintain this level of detail across every initiative. The method works best when leaders can pick their battles, focusing their deep dives on critical, high-impact areas where their unique insights can genuinely move the needle.

What to Do With This

This week, pick one pressing feature or bug your team is tackling. Instead of just reviewing a report or accepting an update, block two hours on your calendar. Sit with the ICs—engineers, designers, or PMs—who are closest to the problem. Have them literally pull up the relevant code, design files, or data points. Go through it line by line, asking clarifying questions. Aim to understand the specific ground truth, then provide specific, actionable feedback or help unblock them directly.