Tag: product management leadership

Supercharge Your Engineering Org: Alignment, AI, and Productivity from Adobe to Etsy

I obsess over building high-velocity engineering organizations that ship meaningful outcomes. When I evaluate what reliably moves the needle—across startups and scaled enterprises—it always comes back to alignment, disciplined management, and a modern view of engineering productivity. Recently, I revisited a set of insights that crystallize these themes and translate them into practical rituals any leader can adopt.

Kellan Elliott-McCrea is a Head of Engineering at Adobe, overseeing Frame.io, a newly acquired video review and collaboration platform. He is known for his experience and expertise as an engineering leader. He was previously a VPE at Dropbox, and CTO at Etsy where he built and led a team of 300 people, from tech and platform reboot through to IPO. Kellan also built and scaled teams at Flickr, and has a coaching and advising practice for companies looking to supercharge their engineering teams.

Here’s what we dig into when we talk about world-class engineering orgs: how software engineering has changed in the last 10-15 years; the future of software engineering, and the impact of AI; the importance of alignment and tactics for achieving it; how to think about and enable engineering productivity; lessons on culture from Adobe, Dropbox, and Flickr; concrete tips for being a better manager; and rituals for building business literacy throughout an org.

Let’s start with a reality I see in my own work: engineering teams are bigger than they were a decade ago, despite dramatically better tools and platforms. The reason isn’t inefficiency—it’s scope. Today’s products carry higher bars for reliability, privacy, security, compliance, and multi-surface experience. The coordination surface area has exploded. That’s why operating models must evolve: clear interfaces between teams, standardized decision-making, and reliable cross-functional rhythms are no longer nice-to-haves—they’re throughput constraints.

Alignment, then, is the ultimate speed multiplier. I’ve learned the hard way that slow teams are rarely under-skilled; they’re misaligned. “Slow teams are misaligned teams.” To counter this, I anchor on a few tactics: articulate a clear strategic narrative (why now, why us, why this), commit to outcomes vs output OKRs, and institutionalize decision logs so debates don’t reset every sprint. When teams know the customer problem, the business bet, and how their work ladders up, the flywheel starts turning.

On engineering productivity, I avoid vanity metrics and favor a portfolio: flow and focus (interruptions, WIP), system signals (lead time, deployment frequency, change fail rate), and outcome alignment (how progress maps to customer value and revenue impact). Tools matter—DX investment in CI/CD, observability, and paved roads—yet the largest gains usually come from simplifying priorities and reducing cross-team coupling. Fewer, better bets will beat “more tickets shipped” every time.

The future of software engineering is inseparable from AI. In my practice, I treat gen ai and gen ai for product prototyping as core accelerators: copilots for code and tests, scaffolding services that convert specs to boilerplate, and retrieval-augmented knowledge that collapses the gap between tribal lore and action. The key is to measure impact at the team level—cycle time, defect escape, and learning velocity—so AI augments engineering judgment rather than creating hidden complexity.

Culture is the compounding edge. Lessons on culture from Adobe, Dropbox, and Flickr converge on a few essentials: invest in psychological safety and clarity of purpose, operationalize blameless learning, and make information radically accessible. “How Complex Systems Fail, by Richard I. Cook, MD” is a touchstone here—complexity punishes organizations that rely on heroics and rewards those that build resilient systems and shared mental models.

For managers, I return to a short, durable list. Schedule real one-on-ones that prioritize coaching over status. Write more than you speak; clarity scales through documents. Run crisp, time-boxed decision forums with pre-reads and owners. Close the loop on feedback—especially in moments of disagreement—by documenting trade-offs and naming the decider. These concrete tips for being a better manager build trust, accelerate decisions, and enable autonomy.

Every high-performing engineering org I’ve led invests in business literacy as a first-class ritual. I recommend monthly “Finance 101” briefings, customer support ride-alongs, and deal reviews to connect engineers to revenue realities. Pair that with tactics and rituals for enabling effective teams—weekly written updates, demo-driven reviews, and pre-mortems—and you get sharper prioritization and far better cross-functional coordination.

Why so few companies successfully go multi-product? Most underinvest in platforms, shared services, and explicit funding models for internal APIs. The remedy: treat platforms as products with clear roadmaps, SLAs, and customer empathy; align incentives so teams don’t fork capabilities in the rush to ship; and adopt technical governance that favors standardization where it compounds and freedom where it differentiates.

For compensation and career architecture, I pressure-test common models by asking: does this design reward the behaviors we say we want? If we value outcomes, impact, and enabling others, the ladders should reflect it. When the incentives match the mission, the org learns faster and scales cleaner.

Referenced:

Adobe: https://www.adobe.com

Dropbox: https://www.dropbox.com/

Flickr: https://www.flickr.com/

Frame: https://www.frame.io/

How Complex Systems Fail, by Richard I. Cook, MD: https://how.complexsystems.fail/

How Etsy Grew their Number of Female Engineers by Almost 500% in One Year https://review.firstround.com/How-Etsy-Grew-their-Number-of-Female-Engineers-by-500-in-One-Year

Where to find Kellan Elliott-McCrea:

Twitter: https://www.twitter.com/kellan

LinkedIn: https://www.linkedin.com/in/kellanem

Website: https://kellanem.com/

Personal blog: https://laughingmeme.org/

My bottom line: if you want to supercharge your engineering org, anchor on alignment, measure what matters, and leverage AI to elevate—not replace—engineering judgment. Do that, and you’ll turn coordination costs into compounding advantages that show up in customer value, velocity, and morale.

October 21, 2025
Building Products in a Post-LLM World: Hard-Won Lessons, Skeptic Busters, and Team Playbooks

The ground rules for product development have changed in the post-LLM world. I’m sharing a practical, first-person playbook—lessons I’ve pressure-tested in my own product org—to help you build AI-native products with confidence, cut through hype, and deliver outcomes that compound.

Sprig is an AI-powered user insights platform that has raised over $88m. Today’s discussion features two key individuals in Sprig’s journey so far: Ryan Glasgow, Sprig’s CEO and founder; and Kevin Mandich, Sprig’s Head of Machine Learning. Before Sprig, Ryan was an early PM at GraphScience, Vurb, and Weeby (all of which were acquired), and Kevin was an ML Engineer at Incubit, and a Post-Doctoral Researcher at UC San Diego.

In today’s episode, we discuss: Key lessons from the Sprig founding story; Product development in the pre vs. post-LLM world; How to overcome AI skepticism; How to evaluate new models and how to know when to switch; Why you need an ML engineer; Sprig’s “AI Squad” team structure; How Sprig upskills all team members on AI.

Founding story takeaways I keep returning to: conviction compounds when paired with continuous discovery. Early on, prioritize direct customer signal over elegant architectures. I’ve seen the fastest learning loops come from a tight PM–ML partnership that prototypes quickly, validates with real users, and refactors only after signal stabilizes. The Jobs to Be Done Framework: https://hbr.org/2016/09/know-your-customers-jobs-to-be-done remains my favorite lens to separate what the model can do from what the customer actually needs done.

Pre vs. post-LLM product development requires a mindset shift. Pre-LLM, we wrote deterministic systems and pushed the edge with models like Google’s BERT model: https://en.wikipedia.org/wiki/BERT_(language_model). Post-LLM, we design probabilistic systems, treat prompts like code, and invest in evaluation harnesses from day one. I routinely prototype with Chat GPT: https://chat.openai.com and scaffold experiments with Langchain: https://www.langchain.com/ to compress discovery cycles. The key is shipping guardrails and UX affordances that make non-determinism feel trustworthy.

On AI skepticism, I don’t argue—I demonstrate. I target one painful workflow, build a narrow, high-precision solution, and expose transparent failure modes with a human-in-the-loop escape hatch. This reframes AI from magic to leverage. In customer-facing settings (think customer support ai strategy), we measure deflection and satisfaction together so automation never outpaces user psychology.

Evaluating new models—and knowing when to switch—demands a clear rubric: task quality (ground-truthed), latency at p95, unit economics, privacy/compliance, and operational reliability. I run shadow evaluations before swapping production dependencies, then phase changes behind flags with canaries and backstops. Tools like Auto-GPT: https://github.com/Significant-Gravitas/Auto-GPT are useful for ideation, but I never skip rigorous offline and online evaluation before a cutover.

Why you need an ML engineer: the fastest teams pair a product manager who owns the problem framing with an ML engineer who owns the feasibility frontier. This duo translates ambiguous jobs into measurable tasks, instrumented datasets, and iterative model/UX improvements. In my experience, this partnership reduces time-to-learning more than any single tooling decision.

Sprig’s “AI Squad” team structure mirrors what I’ve seen work: a cross-functional pod with a PM, ML engineer, data engineer/analyst, design, and platform partner. The squad ships thin slices end-to-end, owns their eval suite, and meets weekly to review errors, edge cases, and customer feedback. We track outcomes vs output OKRs to ensure velocity serves impact—not the other way around.

Upskilling the entire team on AI is non-negotiable. I’ve had success with lightweight rituals: weekly demo hours, prompt libraries maintained in Jira: https://www.atlassian.com/software/jira, red-team exercises to uncover failure patterns, and internal brown bags where engineers and PMs teach each other. Small, frequent exposure beats heavyweight training.

For deeper exploration and hands-on experimentation, I reference: Auto-GPT: https://github.com/Significant-Gravitas/Auto-GPT; Chat GPT: https://chat.openai.com; Google’s BERT model: https://en.wikipedia.org/wiki/BERT_(language_model); Jira: https://www.atlassian.com/software/jira; Jobs to Be Done Framework: https://hbr.org/2016/09/know-your-customers-jobs-to-be-done; Langchain: https://www.langchain.com/; Sprig: https://sprig.com/.

Timestamps: (02:50) Intro (04:57) What attracted Kevin to Sprig (05:53) Kevin’s background before Sprig (07:56) How Ryan gained conviction about Kevin (09:55) Key technical challenges and how they solved them (18:46) How to overcome AI skepticism (21:47) The early difficulties of building an ML-enabled product (25:06) Evaluating new models and knowing when to switch (35:09) Using Chat GPT (37:23) Product development in the pre vs. post-LLM world (39:53) The impact of AI hype on Sprig’s product development (45:36) Balancing AI automation with user-psychology (48:47) Do recent LLMs reduce Sprig’s competitive advantage? (51:00) The importance of “selling the vision” to customers (54:40) How Sprig structures teams (57:25) How Sprig upskills all team members on AI (60:25) 3 key tips for companies trying to navigate AI (66:05) Major limitations with LLMs right now (70:27) The future of AI and the future of Sprig

Three guiding principles I use daily: first, reduce surface area—start with one high-value job and earn trust with reliability. Second, treat evaluation as a product—version prompts, log failures, and continuously retrain on your own data distributions. Third, design for collaboration—pair AI with human judgment and transparent controls so users feel empowered, not replaced. Post-LLM success isn’t about chasing models; it’s about building resilient systems, teams, and learning loops.

October 21, 2025
Inside Rewind AI’s Playbook: PMF Breakthroughs, Bold Twitter Fundraise, and the Future of AI

I sat down with Dan Siroker to explore the product, fundraising, and AI strategy lessons behind Rewind AI’s rapid rise — and to reflect on what I would adopt in my own product management practice today. Dan Siroker is the co-founder and CEO at Rewind AI, a personalized AI powered by everything you’ve seen, said, or heard. Dan launched Rewind to an emphatic response on Twitter, and used a public pitch video to fundraise at a $350m valuation. Prior to starting Rewind, Dan co-founded Optimizely, which reached $120m ARR before being acquired by Episerver, a content management company. Dan was also the Director of Analytics for Obama’s first presidential campaign.
What stood out immediately was Rewind’s journey to Product Market Fit and how deliberately the team instrumented learning loops. As a product leader, I pay close attention to how founders reduce ambiguity: narrow the target segment, ship thin slices, measure engagement cohorts, and iterate fast. Rewind’s early focus on utility and trust — not novelty — created the conditions for PMF while the team resisted the temptation to over-scope.
I was especially interested in how Rewind works and how the team managed scope while building a category-creating product. By focusing on personalized recall powered by on-device intelligence and a clear privacy narrative, they avoided the common trap of trying to solve everything for everyone. My own rule of thumb is to enforce brutal prioritization around the highest-intent jobs-to-be-done, then earn the right to expand. That same discipline shows up in Rewind’s cultural mantra for shipping and validating fast.
Lessons from Optimizely echo throughout. Being a second-time founder sharpens pattern recognition — from building high-clarity cultural values to operationalizing product-market fit. I’ve found that codifying operating principles early helps a team move faster with fewer collisions, and Dan’s approach to open feedback and public learning raises the bar for transparency.
On product positioning as a category creator, the team leaned into outcomes over features, which is critical when the mental model is new. Rather than compete in a features arms race, they framed a compelling before-and-after: instant, searchable memory that augments cognition. In my experience, that level of narrative clarity drives founder-led GTM and accelerates word-of-mouth.
We also dug into where to build in AI, and what makes a “wrapper” thin versus thick. My take: thin wrappers add shallow convenience on top of foundation models; thick wrappers integrate proprietary data, workflow depth, distribution advantages, and durable UX moats. Founders should aim for thick wrappers with unique data flywheels, not commodity interfaces easily displaced by platform shifts.
Operationalizing Product Market Fit remains a craft. I routinely use leading indicators like activation rate, day-7/day-30 retention for key actions, and sentiment via structured PMF surveys. Rahul Vohra’s framework for measuring and optimizing Product Market Fit: https://review.firstround.com/how-superhuman-built-an-engine-to-find-product-market-fit is a proven playbook. Pair that with cohort-based instrumentation and tight audience segmentation to reveal the “sharpest edge” of value.
On AI hype, we aligned on a pragmatic view: real value accrues where latency, accuracy, and privacy meet workflow depth. Apple’s Silicon: https://www.macrumors.com/guide/apple-silicon/ and on-device acceleration will keep unlocking new consumer experiences, while ChatGPT: https://chat.openai.com/ has reset expectations for natural interfaces. The cautionary tales of Google Glass: https://en.wikipedia.org/wiki/Google_Glass and Google Wave: https://en.wikipedia.org/wiki/Google_Wave remind me that timing, social acceptability, and use-case clarity matter as much as technical novelty.
Data privacy is now a core buying criterion, not a checkbox. I see a clear trend toward local-first approaches, explicit consent, and user agency — especially for products that touch memory, identity, and personal archives. Framing value through Maslow’s Hierarchy of Needs: https://www.simplypsychology.org/maslow.html helps prioritize trustworthy utility over gimmicks.
Dan’s one-of-a-kind Twitter fundraising strategy was a masterclass in founder-led GTM. By sharing a public pitch and engaging directly with early users and supporters, he compressed feedback cycles and aligned community, product, and capital. For reference, see Dan’s public Twitter fundraise: https://twitter.com/dsiroker/status/1646895452317700097 and Dan’s Rewind demo tweet: https://twitter.com/dsiroker/status/1638799931891920897. The transparency extended to leadership practice as well, with Dan publicly sharing his own 360 performance reviews: https://twitter.com/dsiroker/status/1689763756459675650 — a bold move that builds trust.
I’m watching what’s next for Rewind with interest, particularly around thicker integrations, extensibility, and collaboration patterns. In the next decade, I expect assistive AI to become ambient, multimodal, and context-aware — an ever-present copilot that feels less like a tool and more like an extension of cognition.
Referenced: Apple’s Silicon: https://www.macrumors.com/guide/apple-silicon/
Referenced: ChatGPT: https://chat.openai.com/
Referenced: Dan publicly sharing his own 360 performance reviews: https://twitter.com/dsiroker/status/1689763756459675650
Referenced: Dan’s public Twitter fundraise: https://twitter.com/dsiroker/status/1646895452317700097
Referenced: Dan’s Rewind demo tweet: https://twitter.com/dsiroker/status/1638799931891920897
Referenced: Google Glass: https://en.wikipedia.org/wiki/Google_Glass
Referenced: Google Wave: https://en.wikipedia.org/wiki/Google_Wave
Referenced: Maslow’s Hierarchy of Needs: https://www.simplypsychology.org/maslow.html
Referenced: Optimizely: https://www.optimizely.com/
Referenced: Paul Graham: https://twitter.com/paulg
Referenced: Rahul Vohra’s framework for measuring and optimizing Product Market Fit: https://review.firstround.com/how-superhuman-built-an-engine-to-find-product-market-fit
Referenced: Rewind AI: https://www.rewind.ai/
Referenced: Scribe (which morphed into Rewind): https://www.scribe.ai/about
Where to find Dan Siroker: Twitter: https://twitter.com/dsiroker
Where to find Dan Siroker: LinkedIn: https://www.linkedin.com/in/dsiroker
Where to find Dan Siroker: Personal website: https://siroker.com/
Where to find Dan Siroker: Blog: https://medium.com/@dsiroker
My takeaway for founders and product leaders: obsess over segmentation, instrument for learning, and tell a crisp narrative that earns trust. Thick wrappers, privacy-first design, and founder-led GTM are how you win the next wave of AI.

October 21, 2025
How I Repeatedly Find Product-Market Fit: Shippo-Inspired Playbook for Bold Product Leaders

Every so often, a team of outsiders rewrites the rules of a legacy industry. The shipping ecosystem — dominated by incumbents and labyrinthine carrier rules — is one of those places. Studying the Shippo story sharpened my own playbook for repeatedly finding product-market fit, scaling founder-led GTM, and building enduring product management leadership in complex, regulated markets.

Shippo provides an API and dashboard that makes shipping easy for e-commerce businesses, marketplaces, and platforms. The company has raised $100m+ and was last valued at $1b in 2021. Laura Behrens Wu, the Founder & CEO, graduated from Harvard University and was heavily influenced by a short internship at LendUp, which exposed her to Silicon Valley and startup culture. Those facts matter, but what matters more for product leaders is how a pivot-stricken origin story turned into a repeatable engine for product-market fit.

What stands out first is the value of timing and outsider perspective. When you’re not anchored to industry dogma, you ask naive questions that unlock real pathways. That outsider advantage is powerful in infrastructure spaces: you can reframe a messy carrier matrix into a software abstraction that customers actually love. In practice, this looks like translating carrier complexity (labels, rates, tracking, insurance) into a clean API and intuitive operations dashboard. That reframing is often the “minimum lovable product” that earns your first wave of believers.

How did the early customers show up? Not through magical virality, but through relentless customer discovery and speed. The best teams get to problem–solution clarity by obsessing over real workflows and truncating the time between insight and iteration. Instead of guessing, they shadow customers, instrument onboarding, and resolve “time to value” friction the same day. In shipping, that often meant shaving steps off label creation, surfacing the right carrier at the right moment, and making refunds and error-handling invisible. When the product removes toil, the first customers do your advocacy for you.

I’m often asked when founder-market-fit is necessary. My take: it’s essential when distribution is relationship-based or when the product requires nuanced domain credibility to earn trust. It’s less critical when the problem is universal and the value proposition can be proven in-product with objective outcomes (cost, speed, reliability). In those cases, an outsider with excellent product discovery and operational discipline can win — sometimes faster — because they aren’t burdened by legacy assumptions.

The path to product-market fit rarely ends at PMF-1. The real craft is finding PMF again and again. That means treating each expansion — from SMBs to larger merchants, marketplaces, and platforms — as a new PMF search. The job isn’t to add features; it’s to requalify and re-earn fit in each segment with clear hypotheses, segment-specific metrics, and willingness to sunset what no longer serves the core. This mindset prevents bloat and keeps the roadmap oriented around outcomes, not wishlist output.

To prioritize across core versus new bets, I lean on the 3 Horizons Framework and complement it with the 70/20/10 rule from Google. Concretely, we allocate roughly 70% to hardening the core (reliability, performance, unit economics), 20% to adjacent growth (new segments, deeper integrations), and 10% to long-term bets (platform shifts, new business models). This keeps us honest about trade-offs: core customers fund tomorrow’s innovation, and tomorrow’s innovation creates optionality without starving today’s results.

Talking to users is a skill that compounds. My guidance: avoid building by proxy and focus on the last instance of the problem, not the hypothetical future. Ask, “Tell me about the last time you shipped an order that went wrong — what happened step by step?” Then quantify the cost of pain (time, money, churn risk). Triangulate what users say with what logs show. In shipping, the answers often live in edge-case handling, where reliability becomes the true differentiator over feature count.

On fundraising, the narrative that resonates is grounded and specific: the size of the pain you eliminate, the stability of your cohorts, and proof you can expand ARPA without sprawl. When you’re building infrastructure, reference integrations and ecosystem leverage matter: how you fit alongside Shopify, Stripe, and marketplaces, and how you abstract complexity from carriers like FedEx and UPS. Clarity on the motion — founder-led GTM at the start, instrumented and repeatable over time — creates confidence you can scale responsibly.

Culturally, I optimize for hiring people I can learn from. Early teams benefit from operators who love ambiguity and measure themselves by business outcomes over output. In practice, that means product creators who can run discovery, partner with engineering on pragmatic scoping, and speak directly with customers. It also means building a culture where we celebrate removal of code and process as much as the addition — every deletion that improves reliability or time to value is a strategic win.

One operational ritual I’ve adopted is inspired by Amp It Up by Frank Slootman. I send a concise “Sunday Email” that reiterates the company narrative, the top priorities for the week, what’s on track/off-track, and the few decisions that truly matter. This simple cadence lifts clarity, pushes intensity, and protects focus. It also makes Monday meetings needless replays rather than forums for decision-making — decisions are already made; execution follows.

For those interested in the broader context and influences, I regularly revisit resources that shaped my thinking on communication, leadership, and shipping ecosystems: Amp It Up by Frank Slootman (https://www.amazon.com/Amp-Unlocking-Hypergrowth-Expectations-Intensity/dp/1119836115), Jerry Colonna (https://www.linkedin.com/in/jerry-colonna-reboot/), Josh Koppelman (https://www.linkedin.com/in/jkoppelman/), Khalid Halim (https://review.firstround.com/the-science-of-speaking-is-the-art-of-being-heard), the 70/20/10 rule from Google (https://www.itonics-innovation.com/blog/702010-rule-of-innovation). For ecosystem context: Expedia (https://www.expedia.com/), FedEx (https://www.fedex.com/), UPS (https://www.ups.com/us/en/global.page), Stripe (https://stripe.com/), Shopify (https://www.shopify.com/), LendUp (https://www.lendup.com/), and Shippo (https://goshippo.com/). For SMB context, this overview is useful: SMBs (https://www.fool.com/the-ascent/small-business/articles/smb-business/).

The enduring lesson is simple and hard: outsiders win by translating complexity into leverage, then doing it again for the next segment. If you apply the 3 Horizons Framework, talk to users with rigor, and amplify clarity with a weekly operating cadence, you’ll keep rediscovering product-market fit — not once, but over and over as your market expands.

October 21, 2025
Building Zapier by First Principles: Hard‑Won Growth, Distribution, and Hiring Lessons

I’m drawn to companies that break the mold through first principles and disciplined product management. Zapier is one of the clearest examples of this mindset at scale—and a rich case study for product-market fit, a durable distribution engine, founder-led GTM, smart fundraising, and people management rooted in scrappiness and intellectual honesty.
Wade Foster is the Co-founder & CEO at Zapier, a platform for building workflow automations without a developer. Zapier was started during 2011 in Columbia, Missouri, and by 2021, it was valued at $5b, having only raised $1.3m. Prior to founding Zapier, Wade had just two professional jobs, and had never managed or hired anyone. He worked as a PM on a web app used by 20k students, and as an Email Marketing Manager at Veterans United – a role that had a significant influence on Zapier’s eventual success.
In this analysis, I explore the core decisions and behaviors that shaped Zapier’s trajectory—from counterintuitive early calls to the long game of distribution and product discovery. Along the way, I connect these choices to practical lessons for product management leadership and founder-led execution in SMB-focused SaaS.
The stories and thinking behind Zapier’s most unorthodox decisions
How Wade thinks about product market fit
How Zapier built their powerful distribution engine
The fascinating story of Veterans United, and its impact on Zapier
How Wade thinks about fundraising
Why Wade lives by “don’t hire ‘til it hurts”
Key lessons on people management
Here’s how I frame the journey. First, product-market fit wasn’t pursued as a one-time milestone—it was earned through relentless iteration on real user workflows. Zapier’s no-code promise met SMBs where they worked, stitching together tools without developer help. That focus on everyday jobs-to-be-done created natural pull and allowed the product to compound through integrations and developer evangelism.
Second, distribution wasn’t an afterthought; it was the strategy. By integrating with the tools customers already used, Zapier built a distribution engine through partner ecosystems, search, and long-tail use cases. This is a masterclass in founder-led GTM—pairing product discovery with scalable, integration-led growth rather than chasing flashy enterprise contracts too early.
Third, staying disciplined about the customer segment mattered. While many teams get pulled “upmarket,” Zapier resisted a premature enterprise pivot and doubled down on SMBs—where the combination of clear value, velocity, and breadth of use cases produced durable traction. That decision amplified their reach without diluting the product’s simplicity.
On fundraising, the restraint speaks for itself. With only $1.3m raised through 2021, the team focused on outcomes over vanity metrics and built a real business before scaling headcount. This connects directly to the operating rule of “don’t hire ‘til it hurts”—resource constraints forced clarity, scrappiness, and ownership. As a hiring philosophy, it raises the bar on execution while minimizing the organizational drag that comes with premature scaling.
People management lessons show up in the day-to-day: hiring for bias-to-action, testing for scrappiness, and aligning teams around outcomes vs output. Process followed principle—not the other way around. As a leader, I’ve found that combination of accountability, autonomy, and intellectual honesty is what sustains velocity as complexity grows.
Finally, I appreciate the throughline from Veterans United to Zapier: operational excellence in email marketing and lifecycle thinking carried over into distribution, activation, and retention. The craft of simple, repeatable systems—applied over years—beats silver bullets every time.
Key themes I unpack include: The fascinating story of Veterans United; Lessons from Veterans United; The most important things Zapier got right; How Zapier built their powerful distribution engine; Why Zapier didn’t move to focusing on enterprise; How Wade thinks about product market fit; The role of skill vs luck in Zapier’s success; What was hard about building Zapier; Key lessons on people management; Rule of thumb: “don’t hire ‘til it hurts”; Zapier’s #1 hiring mistake; How to test for scrappiness in the hiring process; Do hiring playbooks transfer between companies?; The 12 year evolution of Zapier’s product; How Zapier makes product decisions; How Zapier thought about competition; How to foster intellectual honesty in yourself and your org; The people who most impacted Wade’s worldviews.
Referenced:
Basecamp: https://basecamp.com/
Bingo Card Creator: https://www.bingocardcreator.com
Bryan Helmig, Co-founder of Zapier: https://www.linkedin.com/in/bryanhelmig
John Wooden quote: https://www.thewoodeneffect.com/be-quick-but-dont-hurry/
Mailchimp: https://mailchimp.com/
Mike Knoop, Co-founder of Zapier: https://www.linkedin.com/in/mikeknoop
Patrick Mckenzie, creator of Bingo Card Creator: https://www.linkedin.com/in/patrickmckenzie/
PayPal: https://www.paypal.com/
Salesforce: https://www.salesforce.com/
SMBs: https://www.techtarget.com/whatis/definition/SMB-small-and-medium-sized-business-or-small-and-midsized-business
Stripe: https://stripe.com/
Thinking in Bets by Annie Duke: https://www.amazon.com.au/Thinking-Bets-Annie-Duke/dp/0735216355
Tony Xu, CEO of DoorDash: https://www.linkedin.com/in/xutony/
Twilio: https://www.twilio.com/
Veterans United Home Loans: https://www.veteransunited.com/
Zapier: https://zapier.com/
If you lead product in a high-velocity SaaS environment—especially in SMBs—there’s a lot to borrow here: design for real jobs-to-be-done, make distribution your strategy, practice restraint in fundraising and hiring, and cultivate a culture that values scrappiness and intellectual honesty. That’s the path to compounding advantage.

October 21, 2025
Intuition, White-Glove Support, and Relentless Execution: Lessons from Looker to Omni

I’m constantly drawn to product stories where intuition, customer obsession, and raw effort compound into durable advantage. This conversation with Colin Zima crystallized that arc—from pioneering high-touch support at scale to balancing gut feel with data to ship what matters. The through-line for me: when you operationalize empathy and pair it with disciplined execution, you create momentum that’s almost impossible to copy. Colin Zima is the co-founder and CEO of Omni, a business intelligence tool that has raised over $26.9m. Prior to starting Omni, Colin was Chief Analytics Officer and VP of Product at Looker, which was acquired by Google for $2.6b. Colin was an early employee at Looker, and stood up its high-touch customer support arm, which turned into a cornerstone competitive advantage for the company. What resonated most with my own practice is how deliberate investment in white-glove customer support can become a product strategy lever—not just a service function. When you’re in a category-creating phase or displacing an entrenched incumbent, those high-touch loops are how you learn the truth fast, reduce onboarding friction, and convert early believers into reference customers. The trick isn’t whether to do it; it’s when, why, and how to sequence it so the economics still make sense as you scale. On scaling high-touch support, I look for three signals before pushing the gas: repeatability in the top 5 user pain patterns, a crisp path to tooling and self-service, and tight product feedback loops that turn today’s premium assistance into tomorrow’s default experience. That’s how white-glove support pays for itself—first as acceleration for adoption, then as inputs that harden the core product. I also emphasize role clarity and career ladders so support becomes a talent engine, not a cul-de-sac, which makes hiring for and hiring from customer support a strategic advantage. Colin’s intuition-based approach to product echoes a belief I hold closely: data is essential for validation and prioritization, but it rarely originates the leap. Intuition frames the bet; data sizes the risk; customers ground the narrative. I’ve seen the merits—speed, conviction, and differentiated UX—and the downsides when intuition goes unchecked—overfitting to edge cases or mistaking novelty for value. The balance is intellectual honesty: writing down the thesis, the counter-thesis, and the disconfirming evidence you’ll accept before you commit resources. I was especially struck by the operational rigor behind hitting goals for 24 quarters in a row. That kind of consistency doesn’t happen by accident; it comes from outcomes over output, sober forecasting, and the cultural discipline to cut or delay work that doesn’t ladder up. I coach teams to make the target visible, tie metrics to customer value, and then prune relentlessly—because the opportunity cost of “almost done” is usually invisible until the quarter slips. The founding story of Omni reminds me that category shifts rarely come from a single breakthrough. They’re the product of dozens of earned insights about where the market is going and what’s still too hard for customers today. I pay close attention to how founders maintain intellectual honesty as the narrative tightens—keeping a clear line between what we know from the field and what we’re assuming, and revisiting that line often. There’s also practical career wisdom here. When choosing which startup to join, I look for founder clarity on the core problem, the early design partners, and the distribution wedge. On founder-market fit, I care less about domain tenure and more about a pattern of shipping, learning, and adjusting fast. And Colin’s unpopular opinion on how to hire good PMs aligns with my experience: bias toward builders who can synthesize customer reality, technology constraints, and go-to-market timing—then communicate clearly and commit. If you’re building in data and analytics, these references are useful context for the ecosystem and buyer expectations: BigQuery: https://cloud.google.com/bigquery, Hotel Tonight: https://www.hoteltonight.com/, Omni: https://omni.co/, Tableau: https://www.tableau.com/. For those who want to go deeper with Colin’s thinking and product journey, you can find him here: Twitter: https://twitter.com/drinkzima?lang=en and LinkedIn: https://www.linkedin.com/in/colinzima/. My takeaway as a product leader: make white-glove customer support a strategic instrument, not a cost center; let intuition set bold direction while data governs scope; and cultivate the operational cadence that makes hitting your goals a habit, not a headline. That combination is how you compound trust with customers and ship products that stand the test of time.

October 20, 2025
Open Source to Revenue: How GitLab Scales Transparency, Community, and Enterprise Growth

I’m endlessly fascinated by how modern platforms turn open source momentum into durable, enterprise-grade businesses. Ashley Kramer is the CMO and CSO at GitLab, a publicly listed DevSecOps platform. She started out in software engineering before becoming a product leader, and eventually, a marketer. Most recently, Ashley was the CPO and CMO at Sisense, a data analytics company last valued at over $1b. That multifaceted path mirrors the intersection I live in daily—where product management leadership, developer evangelism, and go-to-market strategy converge to drive sustainable growth.

What stood out to me most was the precision with which GitLab layered a commercial model on top of open source roots. The nuance matters: the difference between open core and open source isn’t just semantic; it determines packaging, pricing, and how you balance a vibrant community with enterprise-grade requirements. The tensions of being a commercial, open source company are real—especially when you’re serving many different customer segments with distinct needs. From my seat, this is the essence of open source monetization: protect developer trust while building clear value for enterprises that justifies “consumption SaaS pricing,” security, and support.

Transparency plays a starring role. GitLab’s culture shows the power—and the trade-offs—of working in the open. I’ve seen firsthand how openness accelerates alignment, speeds up product discovery, and reinforces outcomes vs output OKRs. But you must be deliberate. Examples, benefits, and downsides of a transparent company culture are on full display in their handbooks and public processes, which I frequently reference for my own teams. Why GitLab is transparent about their marketing and the 2 examples of GitLab’s uniquely transparent culture provide a blueprint for building trust at scale—while the downsides of being a transparent company remind us to design guardrails.

On the marketing front, the role of marketing at GitLab underscores a systems mindset: define the customer problems, align with the product roadmap, and ensure tight collaboration with sales and community. GitLab’s main marketing metrics, combined with a clear model for how marketing collaborates with product, make the strategy both measurable and adaptable. I’ve applied a similar approach by anchoring campaigns in user outcomes, then instrumenting every touch—from content to conversion—to close the loop with product usage and retention.

Structure supports strategy. The thinking behind GitLab’s org structure, in and around marketing, is a reminder that ownership beats approval chains. GitLab’s planning process and GitLab’s meeting structure and cadence reflect a discipline that’s hard to achieve without cultural scaffolding. In my experience, explicit planning rhythms and written decision logs are force multipliers for cross-functional execution and faster product-market fit lessons.

Selling to enterprise as an open core company demands clarity on what’s free, what’s paid, and why. That’s where serving many different customer segments becomes both an art and a science. Developer love and enterprise readiness can coexist when you design the offer thoughtfully—feature gating that respects the open source ethos, security and compliance that satisfy a “CISO,” and pricing models that feel fair. For teams driving developer evangelism, the north star remains unchanged: remove friction, amplify community contributions, and provide a clear, upgrade-worthy path for enterprises.

When it comes to campaigns, I took away a simple, durable lesson from an example of a recent marketing campaign: anchor the narrative in customer pain, tie it to measurable outcomes, and connect the dots—from awareness to activation to expansion—across product and marketing. An example of GitLab’s marketing in practice reinforces that even in highly technical domains like “DevSecOps,” the most effective storytelling is still about clarity and credibility.

I also appreciate how Ashley’s background informs execution. Benefits of having an engineering and product background as CMO include crisper problem definitions, better partnership with product leaders, and the ability to translate complexity into value propositions that resonate with both developers and executives. It’s a competitive advantage I’ve leaned on throughout my own career as we scale platforms and craft founder-led GTM motions into repeatable engines.

For leaders building in the open, a few resources are worth bookmarking—and I keep returning to them when refining strategy, process, and messaging.

DevSecOps: https://about.gitlab.com/topics/devsecops/

GitLab’s open core business model: https://handbook.gitlab.com/handbook/company/stewardship/

GitLab’s open source employee handbook: https://handbook.gitlab.com/handbook/people-group/

GitLab’s open source marketing handbook: https://about.gitlab.com/handbook/marketing/

GitLab’s open source remote handbook: https://handbook.gitlab.com/handbook/company/culture/all-remote/guide/

GitLab legal team’s SAFE framework: https://about.gitlab.com/handbook/legal/safe-framework/

GitLab: https://gitlab.com

E-Group: https://about.gitlab.com/company/team/e-group/

CISO: https://www.cisco.com/c/en/us/products/security/what-is-ciso.html

Sid Sijbrandij, CEO of GitLab: https://www.linkedin.com/in/sijbrandij/

Tableau: https://www.tableau.com/

Pulling it all together, here’s the playbook I see: make the open core boundary unmistakably clear, invest deeply in your developer community, operationalize transparency with documented processes, and build revenue with enterprise-grade features that map to real-world risk and scale. Do that well, and you earn the right to price for value—while staying true to the community that made the product possible.

October 20, 2025
How Radical Simplification Drove Vercel’s Product-Market Fit: Lessons for PMs and Founders

When I study category-defining products, I look for the decisive moment where simplification unlocks scale. Few stories illustrate this better. Guillermo Rauch is the CEO of Vercel, a frontend-as-a-service product that was valued at $2.5b in 2021. That headline number matters, but the underlying playbook matters more: simplify the developer path to value, create a default that feels inevitable, and let adoption compound. Vercel serves customers like Uber, Notion and Zapier, and their React framework – Next.js – is used by over 500,000 developers and designers worldwide. For a product creator, those are the signatures of extreme product-market fit: an obvious customer set, a loveable default framework, and a platform that scales with developer ambition. From a product management leadership lens, this is a masterclass in developer evangelism and founder-led GTM, not just technology. Guillermo started his first company at age 11 in Buenos Aires and moved to San Francisco at age 18. In 2013, he sold his company Cloudup to Automattic (the company behind WordPress), and in 2015 he founded Vercel. I read this arc as a sequence of product discovery moments: start with a sharp user problem, ship the smallest credible solution, and iterate where the usage is loudest. The throughline is obsession with experience—reducing friction until the product’s default path feels like magic. Reflecting on the Cloudup era, I see a blueprint for outcomes vs output OKRs. Shipping features is easy; aligning them to a few hard outcomes is what prepares a company for scale or acquisition. That discipline shows up later in Vercel’s sequencing: tight technical scope, clear constraints, and relentless measurement of time-to-first-value. On origin and early validation, the insight was deceptively simple: give frontend teams a zero-config way to build, preview, and ship. The V1 product wasn’t a kitchen sink—it was a clean, repeatable flow from commit to deploy. The early skeptics (and there are always skeptics) helped refine the edges; real usage pressure-tested the defaults. The paradox of developers is alive here: we demand power without complexity. The genius is delivering depth without exposing every knob on day one—Next.js did exactly that. My advice on finding product-market fit mirrors this path: collapse the distance between intent and impact. Design the onboarding so one successful path feels pre-ordained. Put forward deployed engineers beside the customer, and treat their feedback as your fastest route to truth. Keep founder-led GTM longer than you think; it’s the most direct signal path you’ll ever have. An open source business becomes successful when adoption is the front door and the cloud is the living room. Open source monetization works when you resist taxing the developer and instead charge for the operational guarantees that companies need at scale: performance, security, governance, and global reliability. Next.js as a community engine and Vercel as a managed “frontend-as-a-service” is a textbook pairing. The trend toward a “Front-end Cloud” is structural. As teams modularize on services like AWS and adopt modern stacks with Next.js, React Native, and headless partners such as Contentful or Shopify, the frontend becomes the primary assembly layer. That’s why people now pay so much attention to the front-end: it’s where the brand lives, the iteration cycles are fastest, and the performance budget is now a business KPI. Positioning and category creation here relied on clarity over cleverness. Name the job-to-be-done, anchor on speed and reliability, and make the default workflow visibly better than the DIY alternative. When the default wins, you earn the right to go multi-product. The key is sequencing: expand from core strengths and ship adjacent capabilities that shorten time-to-value across the same journey. On AI, I’m seeing gen ai shift from novelty to necessity. The immediate wins are in gen ai for product prototyping (faster ideation, copy, and component scaffolding) and in developer experience (test generation, refactors, and safe migrations). The long arc over 10–20 years points to engineering where we curate constraints and verify outcomes, while machines propose implementations. That raises the bar for PM rigor: better problem statements, tighter acceptance criteria, and sharper product discovery. My enduring heuristics for building better product experiences are simple. Eliminate decisions the user shouldn’t have to make. Make the fastest path the default path. Optimize for the preview moment because that’s where confidence is built. And measure success by how little the user has to think to achieve a powerful result. If you apply that mindset—plus disciplined developer evangelism and thoughtful open source monetization—you give your product a real shot at extreme product-market fit.

October 20, 2025
Goal-Setting for AI Products: How I Plan, Prioritize, and Confidently Ship in a Nonlinear GenAI World

I build and ship AI products in an environment where the frontier changes weekly, so my planning system has to be adaptive, evidence-driven, and unapologetically outcome-focused. In this piece, I share the frameworks I use to set goals for generative AI, balance research with product execution, and scale responsibly — drawing sharp lessons from one of the most influential applied AI companies operating today.

Consider Runway, an applied AI research company shaping the next era of art, entertainment, and human creativity. Runway has raised $237m and was one of Time Magazine’s “100 most influential companies” in 2023. Runway has been a persistent viral sensation in recent years, and is behind many of the most famous AI demos online.

The earliest stages of an AI company often begin with research breakthroughs, scrappy prototypes, and clever distribution. In practice, that means leveraging containerization (https://aws.amazon.com/what-is/containerization/) and Docker (https://www.docker.com/) to package models reproducibly, showcasing work where practitioners already gather — Hugging Face (https://huggingface.co/), Hugging Face Spaces (https://huggingface.co/spaces), and Hugging Face Model Hub (https://huggingface.co/docs/hub/models-the-hub) — and tapping infrastructure like Replicate (https://replicate.com/) to get demos into people’s hands. Early, magical use cases — like the Green screen tool by Runway (https://runwayml.com/green-screen/) — teach us which problems are both technically feasible and viscerally valuable.

I’ve learned to be cautious about “The limitations of being “customer-driven” when building in AI”. Traditional product discovery assumes needs are legible and solutions are relatively deterministic. In generative AI, user desire often follows model capability, not the other way around. The job is to triangulate: run tight user loops to validate perceived value, instrument objective model quality, and explore novel interaction patterns that customers can’t yet articulate. I treat this as a portfolio of discovery bets — some customer-led, some capability-led, all evaluated against clear outcome thresholds.

Balancing research development with product development requires organizational design that prevents context-switching tax while preserving velocity. I pair research pods with product pods, supported by forward deployed engineers and domain PMs who translate evaluation metrics into user-visible milestones. Safety and content moderation sit on the critical path, not as afterthoughts — think policy definition, classifier tooling, abuse red teaming, and clear escalation playbooks. This balance is how you move from a great demo to a dependable product without losing momentum.

Goal-setting amidst constant change in AI starts with outcomes vs output OKRs. I write OKRs in terms of user impact and model performance thresholds — for example, target ranges for latency, quality scores against a golden dataset, or creator retention — then let teams choose the highest-leverage outputs (data pipelines, fine-tuning, UX improvements) to get there. Why I don’t plan very far ahead: I treat the annual view as a vision and bet map, the quarterly view as a constrained slate of outcomes, and the 6–8 week cycle as the execution heartbeat. AI roadmaps are hypotheses; evaluation harnesses and launch gates are the truth.

Community is a force multiplier. Forming a vocal community and fostering community requires real access and real listening: early release cohorts, office hours, and transparent changelogs. How they picked users for early release matters — diversity of use cases, sophistication of workflows, and willingness to give crisp feedback. Expanding past the first 100 users of Gen-2 demands readiness: evaluation parity across modalities, scalable infra, and safety coverage. Done well, this motion compounds learning while building authentic advocacy.

For founders, my advice echoes the core lessons above. Start with a narrow, high-intent wedge and prove durable value fast; let founder-led GTM compress the feedback loop; instrument everything from day one; and resist the urge to over-plan features before you’ve nailed outcomes. Product-market fit lessons in AI often arrive via small, fast experiments — not grand, long-range plans. Ship thin slices that demonstrate unmistakable value, then iterate toward a system, not a single feature. When in doubt, shorten the loop and improve the evaluation harness.

People often ask: Will AI replace video editors? My view is that AI will replace zero editors who master these tools — and many who don’t. The winners blend taste, storytelling, and generative leverage. The products we build should honor this reality: design for control, iteration, and co-creation, not just automation.

If you’re mapping the progression of tech and use-cases, a few public references are instructive: Runway Gen-1 (https://research.runwayml.com/gen1) and Runway Gen-2 (https://research.runwayml.com/gen2) show how capability unlocks new workflows and demand. Runway’s 30 AI Magic Tools (https://runwayml.com/ai-magic-tools/) illustrates portfolio thinking — a suite of composable powers rather than a monolith.

For builders focused on gen ai for product prototyping through production: keep your demo muscle strong, your evaluation stronger, and your outcomes strongest. Invest in community, treat safety as a feature, and let your OKRs steer what ships — not the other way around.

October 20, 2025
Engineering Leadership That Scales: Strategy, Velocity, and Org Design from Carta, Stripe, Uber, Calm

I’m often asked how I translate lessons from hypergrowth engineering organizations into practical playbooks for product and platform teams. In this piece, I unpack the patterns I’ve seen repeatedly work—anchored by what I admire about Will Larson’s approaches at Carta, Calm, Stripe, and Uber—and how I apply them to build resilient, high-velocity orgs. Will Larson is a case study in modern engineering leadership. As CTO at Carta—an ownership and equity management platform—he helped guide the company after it raised at a $7.4b valuation in 2021. Before that, he was CTO at Calm, founded Stripe’s Foundation Engineering org, and led Uber’s Platform Engineering people and strategy. He’s also the author of Staff Engineer and An Elegant Puzzle, both essential reads for leaders leveling up from line management to org design. When I craft an engineering strategy, I start by writing down a small set of clear principles. This isn’t performative; it’s an alignment mechanism. Principles reduce decision thrash, make trade-offs explicit, and help teams navigate ambiguity without constant escalation. I’ve found the discipline of writing them down upfront pays off 10x in execution quality later. For the strategy document itself, I structure it so anyone can understand the why, what, and how in one sitting. A useful pattern: a sharp problem definition, a few guiding policies, and a concise set of coherent actions. That scaffolding keeps the strategy legible and actionable across functions—especially as it ladders into product roadmaps, platform investments, and talent plans. Every engineering strategy has two parts. First, compounding capabilities: the platform, tooling, and architecture that unlock future velocity. Second, targeted bets: focused initiatives that advance near-term outcomes. Neglect either and you either stall out later (too many quick wins, no compounding) or fail to ship value now (all compounding, no customer impact). Turning strategy into action requires ruthless translation. I map each guiding policy to a small number of initiatives with owners, milestones, and outcome metrics—not output. This is where outcomes vs output OKRs matter: measure the user or business result, not just the deliverable. It’s also where you surface dependencies early and avoid the Hidden Variable Problem that quietly derails timelines. I’m particularly intrigued by Carta’s unique “navigator” model, which blends technical leadership with cross-functional guidance to accelerate execution while preserving autonomy. In my experience, similar patterns work when leaders are explicitly accountable for both system health and product outcomes—reducing the gap between platform decisions and customer value. Engineering velocity is explainable, measurable, and optimizable. I anchor on DORA and the research from Accelerate (book), and I complement it with the SPACE (framework) to account for satisfaction and collaboration, not just delivery. The story I tell executives is simple: pick a few canonical measures, instrument them consistently, and then drive the feedback loops—branching strategy, CI/CD hygiene, change size, and operational excellence. Choosing the right metrics for an engineering org matters as much as the metrics themselves. I use a balanced set: delivery (lead time for changes, deployment frequency), quality (change failure rate, availability), and flow (work in progress, batch size). Then I pair these with narrative context so the numbers inform decisions rather than become a game to win. On policy, nuance beats orthodoxy. Great leaders define clear, default rules while acknowledging real-world exceptions. I’ve learned to document the policy, define who can grant exceptions, and track exception volume to spot design flaws. The goal isn’t rigidity—it’s predictable operations with a safe on-ramp for edge cases. Micromanagement is a symptom, not a root cause. Telling someone “don’t micromanage” is often counterproductive. Instead, I focus on what’s missing—trust, clarity, or visibility. If leaders can see the plan, the risks, the checkpoints, and the demo cadence, they don’t need to hover. If they still do, fix incentives and accountability, not just behavior. I avoid management anti-patterns by watching for early signals: policies without principles, roadmaps without strategy, meetings without decisions, or dashboards without actions. The best engineering executives pair systems thinking with crisp communication. They’re close enough to the details to ask sharp questions, yet disciplined enough to scale through managers and staff engineers. Executive communication is an asymmetric game. I tailor the message to the decision horizon: one slide for the ask, one for the trade-offs, one for the plan and risks. The Minto Pyramid (framework) helps—lead with the answer, then support it. In meetings, the fastest way to derail progress is to lack a clear owner, a time box, or pre-reads. Fix those and you reclaim hours every week. For presentation feedback, I’ve found a cadence that works: clarify the objective, highlight the single biggest risk, and eliminate anything that doesn’t move the decision forward. A bad sign with direct reports is when updates are status-only and insight-light; I coach toward “what changed, why it changed, and what you need.” For early-career engineers, the most durable advantage is compounding learning: pick hard problems, write more than you think you should, and seek out leaders who invest in your growth. For team development, I borrow a simple model: staff your keystones, instrument your systems, and build a culture where the best ideas win, not the loudest voices. If you want to explore the foundations behind these practices, start here. Accelerate (book): https://www.amazon.com/Accelerate-Software-Performing-Technology-Organizations/dp/1942788339 Good Strategy, Bad Strategy (book): https://www.amazon.com/Good-Strategy-Bad-Difference-Matters/dp/0307886239 DORA: https://dora.dev/ SPACE (framework): https://queue.acm.org/detail.cfm Minto Pyramid (framework): https://untools.co/minto-pyramid Carta: https://www.carta.com/ Calm: https://www.calm.com/ Stripe: https://www.stripe.com/ JavaScript: https://www.javascript.com/ KAFKA: https://kafka.apache.org/ Ruby on Rails: https://rubyonrails.org/ To go deeper on Will’s writing and perspective, these are great starting points. Twitter/X: https://twitter.com/lethain LinkedIn: https://www.linkedin.com/in/will-larson-a44b543/ Personal website/blog: https://lethain.com/ An Elegant Puzzle (book): https://www.amazon.com/Elegant-Puzzle-Systems-Engineering-Management/dp/1732265186 Staff Engineer (book): https://staffeng.com/book

October 20, 2025
Inside Bard’s Playbook: How to Ship AI Fast, Build Ethically, and Outlearn Competitors

I spend a lot of time helping teams reconcile two pressures that define modern product management: ship fast enough to learn and compete, but slow enough to be safe, ethical, and useful. Studying Bard offers a crisp blueprint for navigating that tension and leveling up how we build with Generative AI. Jack Krawczyk is a Senior Director of Product at Google, building Bard. Bard is Google’s collaborative, conversational, and experimental AI tool that’s bridging the gap between humans and bots, while addressing ethical considerations around AI. After joining the project in 2020, Jack helped ship Bard in less than four years. Bard sources information directly from the web, and now enables users to inquire about and summarize YouTube videos. From a product management lens, the most valuable takeaway is the sequencing: problem definition → principled constraints → rapid public learning with clear guardrails. I’ve seen this order de-risk speed. When we anchor teams on a tight product thesis and ethical framework, we unlock faster iteration without drifting into feature theater. Shipping early—especially with a Large Language Model (LLM)—can feel risky. Yet the decision to open Bard to the public quickly reflects a disciplined bias toward learning velocity. In my experience, the longer we delay real-world feedback with LLMs, the more our internal assumptions calcify. Early exposure surfaces edge cases, calibrates safety systems, and drives better prioritization than any lab-only evaluation can. Ethics in AI is not a separate workstream; it’s a product requirement. I anchor cross-functional reviews on harm modeling, transparency, and user agency. Bard’s framing makes this explicit: collaborative, conversational, experimental—language that signals co-creation and responsible exploration rather than unfettered automation. That positioning matters for trust and sets expectations for both quality and limitations. Differentiation in AI assistants increasingly hinges on live context and modality. Bard sources information directly from the web, and now enables users to inquire about and summarize YouTube videos. In practice, this moves Bard beyond static Q&A toward dynamic sensemaking. I advise teams to ask: what fresh, authoritative context can our system responsibly ingest to reduce hallucinations and increase actionability? On development speed, I look for a culture that marries ambition with measurable risk reduction. That means small, end-to-end vertical slices; evaluation harnesses aligned to user outcomes, not model vanity metrics; and weekly red-teaming that actually changes the roadmap. Outcomes vs output OKRs are critical here—optimize for quality-adjusted learning per unit time, not just feature count. Early user research should be embedded, not episodic. I’m a proponent of forward deployed engineers paired with product and research to observe failure modes in the wild and close the loop quickly. With LLM-based experiences, qualitative signals (confusion, trust breaks, cognitive load) often precede quantitative ones; instrument both and let them inform each other. Deciding when to ship comes down to clear thresholds. I pressure-test launch criteria with two prompts: what would change my mind tomorrow, and what could break if we’re right but too early? For AI features, I also require recovery paths—explanations, undo, source attribution—so that small misses don’t become trust-ending moments. As for the competitive landscape—Bard versus ChatGPT, and others—users ultimately reward utility, reliability, and workflow fit. I encourage teams to pick a sharp use case, lean into their unique distribution or data advantage, and prove value in minutes, not weeks. “Generative AI” is table stakes; reliable outcomes in a real job-to-be-done is differentiation. Zooming out, I see three fronts shaping the future of LLM, Generative AI, and AGI: model capability, grounding and retrieval quality, and product ergonomics. Most teams overinvest in capability and underinvest in grounding and UX. The fastest wins often come from better retrieval, tighter prompts, and clearer affordances—not just a larger model. For aspiring AI developers, start narrow and instrument deeply. Pick a workflow with painful status quo, ship a thin slice, measure correctness and confidence, and iterate with real users. For non-LLM companies, the mandate is different: augment your core product where AI reduces friction or unlocks frequency—don’t bolt on a chatbot because everyone else did. For product leaders, AI changes the craft in two ways. First, prototyping is faster—use this to expand the option space early. Second, evaluation requires new muscles—build an experimentation and safety stack that blends qualitative red-teaming with quantitative reliability and cost controls. The leaders who thrive will combine taste with statistical rigor. If you want to go deeper, these references are useful: Bard: https://bard.google.com/; ChatGPT: https://chat.openai.com/; Duet AI: https://cloud.google.com/duet-ai; Free courses on machine learning by Andrew Ng: https://www.andrewng.org/courses/; Google Assistant: https://assistant.google.com/; Introducing Google Assistant to Bard: https://blog.google/products/assistant/google-assistant-bard-generative-ai/; Large Language Model (LLM): https://en.wikipedia.org/wiki/Large_language_model; Meena: https://blog.research.google/2020/01/towards-conversational-agent-that-can.html. In sum, the Bard blueprint reinforces a simple truth: ship with a thesis, learn in public with care, and let principled constraints accelerate—not slow—your path to product-market fit. That’s how we create value fast, build ethically, and stay ahead in the next era of AI.

October 20, 2025
Winning with Open Source and SaaS: My GTM Playbook, Monetization Tactics, and Founder Fit

I’m often asked how to win when your product strategy spans both open source and closed source. My short answer: treat community, product, and go-to-market as one system, then sequence each move with ruthless clarity. Reflecting on Neha Narkhede’s journey helped crystallize a practical playbook for building, monetizing, and scaling category-defining platforms.

Neha Narkhede is a co-founder at Confluent, a data streaming software that raised at a $9.1b valuation in 2021. Neha later co-founded Oscilar, a no-code platform that helps companies detect and manage fraud. Before building these two companies, Neha was a Principal Software Engineer at LinkedIn where she co-created Apache Kafka. Neha is ranked #50 on Forbes’ list of “America’s Richest Self-Made Women 2023” with an estimated net worth of $520m.

Here’s what stood out to me as a product leader: the origin of Apache Kafka inside LinkedIn wasn’t just a technical breakthrough—it was an obsessive response to a clearly defined, acute infrastructure pain. Open sourcing it wasn’t a marketing move; it was a distribution masterstroke that built trust, accelerated adoption, and seeded a future enterprise business.

On company-building, the “Zero to One” at Confluent was uniquely disciplined: build for a specific customer early on, earn credibility with developers through education and evangelism, and simultaneously position as an enterprise-grade solution. I’ve seen this duality—developer-first credibility with enterprise posture—unlock velocity in complex platform markets.

Monetizing open source product works when you’re intentional about what to license and what to open source. Commercial value clusters around enterprise security, governance, scalability, observability, and reliability features—plus SLAs customers can’t get from the community. That’s how you can run two businesses within one company: a software business and a SaaS business that remove operational burden and expand the addressable market.

Confluent’s approach to SaaS versus software is instructive. Confluent Cloud delivers a consumption SaaS model where pricing aligns to value realized, not just time elapsed. Subscription SaaS versus consumption SaaS requires different GTM motions, different product telemetry, and different revenue operations. I’ve found success by matching pricing units to customer mental models and by instrumenting usage early to drive product-led expansion.

Developer evangelism played a pivotal role in category creation. It’s not merely about talks and tutorials—it’s a systematic way to collapse time-to-value, reduce perceived risk, and compress a buyer’s learning curve. When you blend education with hands-on pathways—demos, sandboxes, quickstarts—you transform top-of-funnel curiosity into bottom-of-funnel conviction.

Founder-led GTM was another powerful theme. Early on, I prioritize direct customer conversations, hands-on discovery, and live deal support. The order of operations matters: validate the ICP, close lighthouse customers, codify the repeatable sales narrative, then operationalize outbound once the signal-to-noise ratio is high. That sequence prevents premature scaling and preserves momentum.

For second-time founders, the takeaway is focus and speed. Build differently the second time by compressing cycles from speculation to product realization. Neha’s “proactive research sprint” resonates with my own practice: pressure-test the problem, define must-have requirements with real users, and ensure you’re solving problems people are actually willing to pay for—before building full-stack.

Oscilar exemplifies this clarity. A no-code platform to detect and manage fraud aligns to an urgent, quantifiable pain with measurable ROI. That’s founder-market fit: where your experience, the market’s urgency, and the product’s capabilities directly reinforce one another.

If you’re navigating open source and SaaS together, here’s the practical synthesis I use: define your ICP early; decide what to open source versus license based on enterprise risk and operational burden; invest in developer experience and evangelism to power category creation; choose pricing that mirrors value realization (consumption when possible); and keep founder-led sales at the forefront until the narrative is truly repeatable. Done well, you can run two businesses inside one company without diluting focus.

Apache Kafka: https://kafka.apache.org/

Confluent: https://www.confluent.io/

Confluent Cloud: https://www.confluent.io/confluent-cloud/

Jay Kreps, co-founder at Confluent: https://www.linkedin.com/in/jaykreps/

Jun Rao, co-founder at Confluent: https://www.linkedin.com/in/junrao/

MongoDB: https://www.mongodb.com/

Oscilar: https://oscilar.com/

Where to find Neha:

LinkedIn: https://www.linkedin.com/in/nehanarkhede/

Twitter/X: https://twitter.com/nehanarkhede

Website: https://www.nehanarkhede.com/

October 20, 2025