Building, and Whatnot

In the last two years, 31,832 people applied to be a Product Manager at Whatnot. We hired one. You're twice as likely to hit a hole in one as you are to get a job by simply applying.

That’s not a process failure. I’ve been building products – and product teams – for over a decade and one of the biggest factors in deciding to come to Whatnot ~3 years ago was the very deliberate product culture. No one knows what it means to be a PM in the world of AI, but everything I see says the industry is moving towards us and how we build here - because no tool will make you useful if you aren’t doing the right job.

First we have to acknowledge: the average PM is deeply average.

The product function emerged in response to scale – engineering teams got too big for CEOs or GMs to manage directly, so a business <> tech conduit was needed. Over time we lazily generalized the role to “every time you hire an Engineering Manager you hire a PM”. But where an Eng Director managed 30-40 people through their EMs a PM Director just managed five. Incentives govern the world, so those Director’s jobs became “justify growing my eng partners headcount” so they could, in turn, grow theirs to become a VP. Slowly the role of junior PMs shifted from “CEOs of the product” to “babysitters of buttons” and product-minded engineers to infantilzied order takers.

Then COVID hit and the industry hired a mind-boggling 500,000 new software engineers in just four years and ~80,000 new PMs were minted to match. That’s 80,000 PMs buried within gargantuan teams at FAANG, far from any customer, 50 layers from the zoom where it happens, taught paint-by-number PM’ing at a product school, in an era of unearned engagement growth where seemingly anything worked.

The likelihood of someone emerging from that with great product instincts, experience and grit actually feels less likely than hitting a hole in one.

Second: we made our best, worse.

When your job is supervising five people, all you can do with your day is get in other people's work. They dislike that and label it micromanagement in an anonymous survey so you back off. How then do you spend your time? You story-tell, shepherd things through review so your teams are ‘succeeding’, justify resources. But you don’t know what story to tell so you stand up a user research team to tell you the jobs to be done, then a PMM function to tell that story to customers. The function that came to be strategically important because it gathered context and disseminated clarity abstracted itself out into increasingly ivory towers.

But the actual truth is in the data models of your systems, in sales calls, CX tickets, in the analytics – not in the pretty 2x2 made to simplify it all.

All the time you spend playing management means your innate understanding of the issues is getting stale, your instincts for your customer duller, the likelihood you’re right is dropping.

Our batting average as a function dropped both because the denominator expanded AND because its expansion meant everyone who was good at product seven years ago was promoted out of doing any actual work (or got rich enough that the incentive to stay and play politics was low).

The Whatnot Way

Since its earliest inception, the Whatnot product team has been built on a somewhat simple premise: we regret that product management exists. Sales and engineering got on just fine before we were hired, so where they can, they should just ship without procedural gatekeeping or nonsense paperwork. Product is a trade, not a qualification. Anyone who does it well learned by doing and by being around great people doing.

I was in an interview recently where someone told me Whatnot felt like Twitch and eBay had a baby - culturally it couldn't be more wrong, but in terms of the product span it's a decent comp. A conservative estimate says those two organizations combined have >400 PMs. We have 20. 20 PMs for 1200+ total employees.

Our PMs are mapped to problems, not to EMs. Those two often overlap, but aren’t the same thing. If you’re building a new sales format for fashion sellers you’re going to be pretty hand in glove with the EMs who own how listings and inventory works, but equally with the logistics and payments EMs.

Having to work across multiple stacks and weigh impacts to different customers isn’t easy – it requires broad context of the business, the ability to foresee downstream impacts of changes to any feature, prowess at context switching, the ability to build and spend trust across a whole org rather than with one partner. That’s why we hire almost exclusively senior PMs. PMs who are over endless alignment meetings and itching to build again. Or, we convert promising sales or ops folks and let them learn by doing. We're always looking for the hole-in-one mid-career L5/L6 hire, but the stats don’t lie about how often we find them.

Finally, everybody ships, including me. I am always working directly with a team of engineers and designers to ship features as an IC, and so are both of our cofounders. When it was time to test out if it was feasible for PMs to vibecode small features, I was the guineapig. When it was time to hand onboard our first seller in Australia, it was our cofounder Logan doing it. When Zendesk started dropping customer tickets, it was our CEO Grant talking to their support engineer.

As a company we require every employee to sell, buy and do CX tickets or we give them a below expectations rating. If PMs are to lead in a company with that commitment to customer centricity we’ve gotta be deep in how things work and broad in why. We call it “being T-shaped” – having a breadth of context and the depth of your area, simultaneously. Depth and experience allow you to make decisions quickly, not having to wait for 5 layers of management to review it means those decisions become actions.

Members of Technical Staff

There is so much noise right now about "building"... No, product requirement docs aren’t dead. A PRD is just a vessel for thinking clearly about a problem and articulating that to others. Make yours interactive if you like, no one cares. No, the cost of shipping a bad product hasn’t gone to zero, it's still paid by your customers. Throwing spaghetti at them 16x faster is not, in fact, a revolution, it's simply annoying. And no, everyone's not gonna be an S-tier Eng and Designer and PM all in one. A few folks will be, but the same drivers of specialization – what people enjoy and are good at – will still drive how we work.

What is shifting is the realization that being an IC is a way better use of many people skills, experience, and limited time on this earth than redrafting the same document for the 5th time to fit the current pedants preferred formatting. A few PMs at Whatnot are managers, but each of them spends 90%+ of her/his time as an IC. There’s no distinction in our titles or comp for those who manage or don’t because we see no inherent virtue in it. AI gives us incredible leverage – I can move faster at just about every task in the development process, whether that's understanding data that used to require a data scientist to untangle or turn a PRD into every permutation of CX SOPs that would normally be the subject of long nights in the office on launch week. I can build a bot to triage the 100 questions a week from sales or to find the localization gaps we left in a recent experiment.

The most disruptive thing about AI for PMs is its shown that the leverage of coaching people up and working through them just isn’t the singular source of leverage it once was. Especially if those people are – through no fault of their own – deeply average. But that leverage is only available to people who still know how to do the work.

What's especially encouraging about this trend is it's going to entice the best PMs back to doing actual PM work. The thinking about the needs of the customer and the business and the good taste to solve it the best way. As a customer of other companies, I’m excited to see the luminaries of our industry getting back to building – it's gonna make their products better. As someone obsessed with building the smallest, most highly leveraged PM team in history, I’m excited for it to release the incredible humans who've been phoning in roadmap reviews for half a decade.

Show, don’t tell

Below I’m going to copy (in full) the one document we have about how we work on Product at Whatnot. If we’ve met even once you won’t need me to tell you who the author is – this is how we talk and how we work.

You can also go look at who works on our team – there’s at least six people on the team today who could be CPO at a series B-C startup who will spend their evening on the phone with sellers, 400 queries deep in a Hex Thread or drafting v1 comms for tomorrow’s launch. It’s four former founders who have never in their life agreed that something is outside their purview. Its four ex-FAANG directors who no longer spend their days debating where people should live in a nine box grid. It's six early stage PMs who’ve incredible taste, being told they need to try more things because we only learn by doing.

I doubt our erstwhile declaration of max 20 PMs will last – the opportunity in front of us at Whatnot is so enormous that we won't constrain ourselves arbitrarily - but the bar for who we hire will only go up as the industry and AI tools continue to reward great ICs with leverage. If you’re one of those folks, and what I’ve described above is what gets you going, you’ll work out how to get in touch with me.

Building at Whatnot

Building great products is hard. It's not just that you have to have the right insight as to the problem, get the details right, take it to market right, measure it correctly so you understand its performance or iterate on it quickly. It's that you have to do all those things or it doesn’t work. Worse, failing is expensive. We have few teams and a massive amount of opportunity in front of us - batting .300 is great if you play in the MLB but to realize our aspirations we need closer to .500. Without a high average we either constrain growth in the short term or we couple business growth to headcount growth and constrain ourselves in the long term.

This document has 2 parts:

1. Our philosophy - this will not change
2. Our processes - these will evolve and current SOT kept here

How we build gives us leverage

You can’t construct a building a room at a time, you have to design the whole building at once and build it all at once. Thankfully, we don’t work in construction, we work in software. Building iteratively is our superpower. We always launch the smallest unit that provides real user value and a solid user experience, but we design things further out to ensure we can scale it.

The happy path of a successful product here walks 7 steps consistently:

1) It's something that matters for users and our business

Ruthlessly prioritize the most impactful things that solve for our users and business needs.

• You must be able to articulate that value explicitly“enable scaled retailers to sell products stored in multiple locations in a single show - by updating ‘ships from’ to be a product field, not a show field”
• Think about the system.

1. Is this product immediately valuable when launched?
2. Is it a ‘building block’ for other things?

If (1) isn’t true, do not proceed. If (1) is true, work out how it can become (2) over time.

2) It’s something people want

Understand their pain points, desires, and behaviors to create a product for them.

• You don’t know that unless you understand the user you’re building for in detail. Marry together qual and quant.
• Think about your product in the context of existing product workflow.
• Don’t layer over crap.
• Don’t blow up a workflow that solves problem B because you’re focused on problem A
• If the problem is real - do you know how they’re working around it today?
• Beware shiny objects. Especially shiny objects you’ve built elsewhere in the past.

3) Customer needs do not align with our org charts / are never met with a single feature.

If you’re building locally you’re building naively.

• You must be working back from a complete customer experience, not code ownership. Go solve the problem, period.
• The inverse is true too - other PMs will need to push into “your area”. Help them.
• This principle is why we strive to have the smallest possible Product and Design team. The more folks there are whose role is narrowly defined the more myopic roadmaps get and the more time we waste on coordination and consultation.

4) It’s the simplest possible solution that solves the problem.

The key to building fast & reliable products that users love is avoiding unnecessary and non-impactful work

• Simple isn’t just fast to build, it's typically also the most successful.
• Thinking about the system does not mean build the whole system upfront.
• The more you build before you know you’re right, the more expensive it is when you’re wrong.

5) It was validated with the smallest possible audience.

You’re just guessing until someone is using it.

• Get paper or clickable prototypes into the hands of sellers ASAP. Staff dogfooding catches bugs better than it validates a solution because we're not our customers.
• Think about your GTM motion
• Seller Facing Products: Start with <10 sellers, scale either by count of sellers or to a few categories before going to GA.
• Buyer Facing Products: Start with either a category or a small % and ramp with signal.
• Ecosystem Products (visible to both): Start with either a category or a small market
• If you’re in validation mode, solving for awareness (internal or external) is a failure mode.
• It's so subscale it doesn’t actually impact people
• You don’t know if it's going to work yet - don't waste folks time

6) Once validated we iterate it like crazy.

Once live to customers, we’re shipping weekly if not daily improvements.

• If you hear “once we ship X we can move to Y” it is a giant red flag.
• Once we know it’s gonna be a thing you need to go back and solve for Catex and CX
• Launch, validate, measure, iterate, iterate, iterate > then move to the next priority.

7) We run through walls once in beta

Getting a spark is hard. Once you have one you’ve gotta pour on the fuel or it will die.

• Biggest risk to launching hyper-simple hyper-early products is they’re incomplete and thus not truly long term useful. Once you launch you’re on the clock to get from high potential to high impact.
• Zero in on maximizing the value you’re creating and not managing every little complaint, risk or repercussion.
• Working out what complaints, risks and repercussions to worry about is a judgment question for each launch. Worrying about non-risks is as dangerous as failing to worry about them

8) This ain’t the bachelor - decouple everything

There is a natural tendency when designing a system to want to ship multiple parts of it at once. In a sufficiently complex system like ours, chances are multiple teams are working on components of a system in parallel and it may seem sensible to ship them together so its one big change vs two. It's also a trap.

• As long as each piece is independently viable and beneficial to customers, launch them ASAP
• It lets us measure each more effectively and understand their relative contributions
• Leaving beneficial products waiting in staging for another is bad for customers

The role of reviews and feedback

We have documented a product process whose intent is to ensure we’re working on the right things and in the right way. This includes visibility, approval and accountability functions. More important than blindly adhering to that process however is internalizing the underpinning philosophy - which is well articulated in this twitter thread… (seriously, read it before proceeding)

1. In a complex system you need way more alignment than you think to actually get to the right answer. Because that word can be misinterpreted:
2. Alignment never means consensus. Consensus is the enemy of good decision making.
3. Alignment does not mean coupling workstreams. Coordination is the enemy of speed.
4. The litmus test of alignment - a written plan. If Grant's asking for one, we’re not aligned.
5. Autonomy at Whatnot is autonomy of implementation. No-one has or should expect autonomy of strategy. Without alignment autonomy is squandered.

To meet expectations at Whatnot a PM or Designer

1. Identifies things that need alignment immediately and actively seeks it out
2. Moves quickly from alignment to implementation because they deeply understand the discussion and the alignment. They do not listen for a ‘yes’ in discussions.
3. Can fill in the implementation details with their team / rapidly unblock decisions that trail alignment.

Why Speed Matters

Our whole system is premised on maximizing the speed of shipping the right thing. 1-3 of the happy path are about working out what we think the right thing is, 4-7 about how we validate, iterate and scale that thing. We do that because:

1) Everything in our system compounds - the good and the bad

In 2025 we ran 750 experiments across about 250 business days, which comes out to roughly 3 ship/don’t ship decisions per day. If you simulate the long term impact of making each of those decisions just 3 calendar days faster the impact over a 2 year horizon is >$1.1B of incremental earnings for Whatnot Sellers. Not the impact of those products, just the impact of making those decisions fractionally faster. Every delay in shipping the right thing hurts our customers, and the bigger we get the more the opportunity/cost of speed.

2) Once speed is lost it never comes back

Humans naturally conform and come to rely on process, so even ones invented for narrow use cases get applied more liberally than intended. Incentives shift to following the system vs having the impact the system was designed to ensure and the organizations muscle memory to “know, but go” is atrophied and lost. There is almost no single mistake we could prevent that would be a good trade off long term for slowing down the speed with which we build.

3) Speed isn’t the reason for mistakes/errors

Committees only prevent mistakes as a byproduct of preventing progress. Judgement is what actually prevents mistakes. Shipping more frequently builds our judgement - like an athlete we get stronger through reps. While building reps, teams can leverage the judgement of those with more reps and more context - continuous ad hoc guidance from product leadership, visibility for key risk mitigations like legal and comms at the earliest stages of planning (if there are hurricanes we need to avoid in the Atlantic, we need to know that when we’re plotting the course, not as we’re casting off), category or country leads who can proxy how specific customers may react. As a part of thinking about the system, PMs should seek to anticipate impacts of their launches, but are never gated either by having sought out, or by taking any feedback/input they get. Product review is the only gate in our development process.