business/ · 2,236 w · 10 min · ✎ dialogue

Product Management

Product management is the discipline of connecting customer needs to business goals through shipped software — sitting at the intersection of engineering, design, and strategy without controlling any of them. This article covers what separates top-tier PMs from competent ones (drawing on Amazon, Google, and Facebook frameworks), Jason's own PM journey from Percolate to Etsy to founding Midgame, a self-assessment scorecard for evaluating PM fit, and lessons from building in regulated markets like fintech and cap table management. The through-line: a great PM earns influence they were never granted, operates with radical clarity on goals, and treats shipping as the only real proxy for progress.

What Great PMs Actually Do

The Top 1% (Ian McAllister, Amazon)

Ian McAllister's oft-cited Quora answer on what distinguishes the top 1% of PMs is worth taking seriously because it moves past obvious platitudes. His list:

Think big — Not constrained by current resources or current market conditions. Describes large disruptive opportunities and has concrete plans for capturing them. The key word is "concrete" — thinking big without execution specificity is daydreaming.
Communicate — Makes a case that is impossible to refute or ignore. Uses data when available, but also taps into biases, beliefs, and emotional triggers that move decision-makers. Getting 10 engineers to prioritize your roadmap without having the authority to command them is a communications problem.
Simplify — Knows how to get 80% of value from 20% of effort, repeatedly, in a compounding way. Not "launch fast and fix later" — but correctly identifying which 20% of work creates which 80% of value before scoping begins.
Prioritize — Sequences projects correctly: quick wins vs. platform investments, offense (growth) vs. defense (reducing churn, fixing bugs, reducing technical debt). Getting this ratio wrong is one of the most common PM failure modes.
Forecast and measure — Estimates project benefit before starting, tracks it after launching, and folds those learnings into future prioritizations. Most PMs do the latter poorly; many skip it entirely.
Execute — Grinds it out. Recognizes no fixed bounds on scope. "Does whatever is necessary to ship" includes recruiting, doing bizdev, escalating, producing button copy, and arguing with legal.
Understand technical trade-offs — Doesn't need to write code, but needs to roughly estimate complexity without dev input and understand the trade-offs in major architectural decisions.
Understand good design — Knows the difference between good and great design and can articulate it to designers. Not just "I know it when I see it" — can point to the specific gap and suggest directions.
Write effective copy — Every additional word dilutes the value of the previous ones. A great PM agonizes over button labels and calls-to-action, not just product strategy.

McAllister's honest conclusion: he's not sure he's ever hired a genuine 1% PM before they were recognized as one. Better to hire a 10% PM who actively develops along these dimensions.

The Google Perspective (Edward Ho)

An engineer's view of the best PMs at Google adds nuance missing from the above:

Take full ownership — You're the first to look for bugs, the first to communicate with users, the first to worry about getting it right. It's not someone else's responsibility — ever.
Be persuasive, not commanding — None of the team reports to you. You convince rather than command. This is easier when you're visibly in the trenches with everyone else.
Be endlessly positive — The PM is the team's window to the larger company. If you're negative about the million things that could go wrong, the team assumes the company perceives their work that way. Positivity is not naivety; it's leadership.
Be fearless with executives — Give succinct answers and defend your team's ideas directly. Freezing under exec questioning is fatal.
Celebrate your team, not yourself — Self-promotion is obvious and poisonous. Look at the best Google product blogs: posts are written by a wide array of team members, not the PM.

The Wall Street Journal's take: the perception of PM as "mini-CEO" misleads. The job includes scheduling, note-taking, triaging bugs. Power comes from influence built through ownership, not from a title.

Jason's PM Journey

Percolate (2014–2015): Creating the Role from Within

Jason joined Percolate as the 100th employee without a formal job description. There were no PM roles at the time — just a 6-person marketing team and a CEO who wanted "more hackers" on it. When asked about the lack of a PM opening, Jason's thinking: "When you're joining a rocketship, you don't ask what seat."

He started in editorial (writing 5 blog posts per week, editing 16 additional posts), moved into lead generation (producing 12 major pieces of collateral — whitepapers, webinars, case studies — generating 5,700+ leads in 8 months), and eventually made a formal case for transitioning into product.

That case is itself instructive. Rather than asking for the role, he built a scorecard:

Dimension	Jason	Typical Outside Hire
Customer/Market Knowledge	5	3
Culture Fit	5	3
Design/Product Sense	4	4
Project Management	4	4
Technical Chops	3	5
Total	21	19

The argument: deep customer knowledge and culture fit can compensate for technical gaps, especially when the technical gap is closable over time and the knowledge gap is not. He got the role.

As PM on the sales demo, Jason shipped 9 releases of what prospects consistently called "the most powerful and sophisticated sales demo they've ever seen" — then initiated a major overhaul to transform a rigid linear narrative into a modular, flexible demo.

Lessons from one month in as PM:

Say when you don't know. Bullshit works in many settings, but PM answers lead directly to decisions and wasted engineering time.
Clear goals and tenets are different things. Goals are what you're trying to do; tenets are how you'll operate. Both need to be explicit.
Always do the unblocking work first. In content marketing you can pick tasks based on mood. In product, others can't do their part until you do yours.
Watch for scope creep. The waterfall instinct is to add one more feature before the next release. This lengthens timelines and compounds delay in a vicious cycle. Two-week sprints with cut scope create higher morale and more output.

Etsy (2015–2017): Building for 3M Shop Owners

The connection to Etsy started with a book. While traveling in Peru, Jason read Building Products for the Web by Randy Hunt, Etsy's VP of Design. He wrote about it on his blog, the review got enough traction that Hunt introduced him to Nickey Stakard, a senior PM at Etsy. They were scheduled to have coffee, the timing didn't work out, and 17 months later they finally connected — she had been promoted to Group PM and was looking for someone to fill her old role.

The Shop Management role focused on building tools for Etsy's 3 million shop owners, 80% of whom were women. The product challenges were meaty: improving inventory management, pricing tools, analytics dashboards, and merchant communication — all while navigating the tension between Etsy's creative/handmade identity and its ambitions as a public benefit corporation on NASDAQ.

Lessons from Etsy:

Clear project goals matter more than you think. Ambiguity about what "success" means on a project leads to misaligned effort across design, engineering, and product.
Know your product's history. Decisions that look arbitrary often have well-reasoned backstories. Ignoring them leads to rediscovering old problems.
Different teams have different working styles. Be flexible, but advocate for the processes you know work.
Don't let mobile just trail web. Mobile isn't a port — it's a different context with different constraints. Treating it as secondary produces second-rate experiences.
You can't please everyone — focus on the users that matter most to the business goals right now.

Midgame (2019–2021): CEO and Founder, Voice Analytics for Esports

Midgame was Jason's most technically ambitious product: voice analytics for esports teams. The product joined Discord voice channels during practice sessions and games, pulled individual audio tracks, and provided insights about team communication — measuring call-out length, repetition, and crosstalk.

The insight came from observing a pro Overwatch coach who was hand-transcribing audio from team scrimmages to write corrections on bad calls. This kind of high-effort workaround — paying consultants to listen in live, transcribing 18 hours of audio from a 3-hour game (6 players) — is a classic Jobs-to-be-Done signal that automation has latent demand.

Within 8 weeks, the team had interviewed 50 college esports teams and contacted over 100. Communication came up as a top priority consistently. They launched a private beta with two dozen teams including Harvard, UCLA, and a pro Fortnite team, and partnered with a League of Legends tournament in Illinois to gather competitive audio from 34 teams.

The JTBD framework shaped the product roadmap:

Coaches need: immediate post-game analysis ("why did we lose?"), feedback for individual players, overall team performance trends over time, and comparative data against other teams.
Players need: positive contributions identified, and interesting self-insight.

The product roadmap evolved from basic analytics (measuring three core attributes) to guidance (reminding quiet players to speak up) to platform (moat built on proprietary comms data no competitor could replicate). Midgame was ultimately acquired.

Facebook's Product Culture (Zuckerberg)

Facebook's product culture under Zuckerberg combined top-down direction with bottom-up building:

Teams built features on the side, showed them off internally, and shipped when ready — "hackathon culture" embedded into the regular workflow, not isolated to special events.
Metrics over qualitative feedback: "People will rarely write just to say 'I really like your product.'" Qualitative feedback is systematically biased toward complaints and edge cases. Build instruments that measure what users actually do.
Small onboarding details compound dramatically. One internal study found that sorting email contacts differently could increase invite sends by 3-4x. The implication: activation and onboarding deserve the same engineering and design rigor as the core product.

The meta-principle: Facebook treated product decisions as empirical questions, not matters of opinion. A/B tests, activation funnels, and retention cohorts were first-class products, not afterthoughts.

Building in Regulated Markets

Digits and Pulley (Jeff and Yin — Adverb Interview)

The interview covers two companies building in heavily regulated, domain-expertise-intensive markets: Digits (real-time financial software replacing QuickBooks) and Pulley (equity management and cap table software replacing Carta).

On domain knowledge: Jeff's team at Digits didn't hire accountants initially — they hired a UCLA professor to teach them accounting, then read textbooks. They thought they understood the domain. They were wrong: a team offsite revealed they'd missed the concept of journal entries entirely, which required a rewrite of their software architecture. The question Jeff now sits with: "Would hiring domain experts earlier have made a better product, or biased it in the wrong direction?" Yin's take: "Know enough to be dangerous, but not to be jaded." A Harvey AI associate who practiced law for one year built a better product than a 20-year partner would have.

On incremental building: Digits spent six years building toward their full vision incrementally. The sequence: expense calculator (low engagement but beachhead) → reporting tools (accounting firms loved this, high engagement) → full general ledger (required massive investment, delayed until ready) → full growth mode. The lesson: you cannot skip steps in regulated software. NetSuite spent 5 years and $120M to build its ledger from scratch. The market won't wait, but the product can't be rushed past quality thresholds that regulators and customers demand.

On startup speed: "We do all-hands every 48 hours, weekly sprints MWF." The ability to shift direction rapidly — to be a speedboat rather than a ferry — is a structural startup advantage that gets squandered when companies slow down their decision cadence before they need to. Jeff's related insight on AI: "You can't just sprinkle AI on this." Digits built its ML team years ago; their core products work without AI, and AI enhances rather than replaces the underlying accounting logic. Startups shipping AI demos in 10 days are a long way from real products.

On fundraising psychology: Jeff argues fundraising is "largely psychological." Different investors respond to different signals — quantitative (trajectory, CAC, unit economics) vs. qualitative (vision, inevitability). The best pitches create a FOMO mindset: "Of course this is going to happen." Yin adds that showing a demo at seed stage can be counterproductive — you just described a grand vision and then showed something that doesn't live up to it. At seed, early customers are often buying you and your domain expertise, not the current product.

startup-pivots — PM decisions in the context of pivots; when to stay the course vs. redirect
product-market-fit — The north star for PM work; what it feels like to find it and what to do with it
growth-and-scaling — Post-PMF product strategy; transitioning from finding product-market fit to scaling distribution
sales-and-marketing-systems — How PM and marketing intersect; building demos that sell, understanding customer language
coaching-offerings — Jason's coaching practice applied to product leaders and founders who are stuck

Thread · 0 replies+ add reply

no replies yet — be the first to write back to this article.