Tag: developer evangelism

How We Built PR Review Bots In‑House for a Fraction of the Cost—and How You Can Too

PR review bots are all the rage, but they cost a premium. We built our own for cheap that work just as well, if not better. Here's how.

As a VP of Product Management, I care deeply about the velocity and quality of our software delivery. The decision to build our own pull request (PR) review agents came from a simple calculus: we needed tighter control over developer experience, CI/CD integration, and cost—without sacrificing accuracy or reliability. The result was a pragmatic system that accelerates reviews, improves code quality, and pays for itself through faster feedback loops.

Before we wrote a line of code, we defined success. Our objectives were to shorten review cycles, reduce back-and-forth on style and test coverage, and surface risks earlier—measured against DORA metrics like lead time and deployment frequency. That focus aligned the team, guided our build vs buy decision, and anchored scope to the highest-impact use cases.

We started rules-first, AI-optional. The initial release enforced guardrails that are universally valuable: linting and formatting checks, required test coverage thresholds, commit message standards, ownership validation (CODEOWNERS), and basic security scans. These automated gates eliminated predictable review friction, freeing engineers to focus on logic and architecture rather than style debates.

Then we layered intelligence where it mattered. We added lightweight, explainable checks for common code smells and dependency risks, plus optional natural-language summaries that turn large diffs into concise context. Where appropriate, we introduced agentic AI workflows to triage PRs by risk, draft review comments, and suggest missing tests—always keeping humans in the loop. This hybrid approach kept costs low and outcomes high.

Integration with our CI/CD pipeline was non-negotiable. We wired GitHub/GitLab webhooks to a stateless service that queued work, executed checks in containerized workers, and posted results back as status checks and review comments. Caching, parallelization, and smart diff-scoping ensured we only computed what changed, keeping the experience snappy even on large repos.

Adoption hinged on developer experience. We made the bot’s feedback fast, specific, and actionable, with clear remediation steps and links to documentation. Feature flags allowed teams to opt into new checks gradually. ChatOps commands enabled quick overrides for emergencies, while policy-as-code kept rules visible, versioned, and auditable.

We treated this like any product: eval-driven development for accuracy, ongoing telemetry for false-positive rates, and explicit SLAs for response times. We instrumented outcomes end-to-end—tracking PR cycle time, comment-to-merge ratios, and rework—so we could prove the ROI and tune the system without guesswork.

The outcome: a reliable PR review companion that runs on a shoestring budget, integrates cleanly with our workflows, and measurably improves engineering throughput. If you’re weighing build vs buy, start small with rules that deliver immediate value, then layer intelligence where it earns its keep. With a clear product strategy, you can stand up capable PR review bots quickly—and scale them as your needs grow.

If you’re ready to try this yourself, begin with your top three friction points in code reviews, wire them into your CI/CD checks, and pilot with a single team. Iterate weekly, measure relentlessly, and let your developers be your strongest signal. You’ll be surprised how far a pragmatic, product-led approach can take you.

Inspired by this post on Amplitude – Perspectives.

March 27, 2026
25 High-Impact Career Paths for Software Engineers Beyond Coding: My Real-World Playbook

I’ve spent years helping talented engineers explore what’s next when pure coding no longer feels like the only—or best—path. From hiring across cross-functional teams to mentoring career pivots, I’ve seen firsthand how engineering strengths translate into high-leverage roles that shape product, strategy, and growth.

Software engineers have alternative career options leveraging their skills in roles like product manager, data scientist, business analyst, and 22 more.

When an engineer moves into product management, they’re not starting from scratch—they’re redirecting problem-solving, systems thinking, and customer empathy toward outcomes. In practice, that means mastering product discovery, strengthening stakeholder management, and getting fluent in product roadmapping and sprint planning, so decisions are guided by impact rather than “outputs vs outcomes” confusion. I’ve watched this transition unlock empowered product teams and clearer prioritization across complex backlogs.

Data-oriented paths are equally compelling. If you enjoy experimentation and evidence-based decisions, roles in analytics or data science reward rigor. Think A/B testing, identifying the minimum detectable effect (MDE), and using tools like Amplitude analytics to translate behavioral signals into product bets. Pair that with retention analysis and you’ll become indispensable to growth conversations.

Business-facing roles such as business analyst or product marketing manager are ideal if you’re energized by customer problems and market narratives. Your engineering fluency sharpens value propositions, product positioning, and go-to-market strategy in a way that resonates with both buyers and builders. In my teams, the best bridges between product and revenue often came from former engineers who could articulate trade-offs with clarity.

If operational excellence is your edge, consider SRE, DevOps, or cybersecurity. The same instincts that push you toward clean CI/CD pipelines and resilient architectures translate well into incident management, threat detection and response, and privacy-by-design practices. These roles reward systems thinking and the ability to balance reliability with delivery speed.

For engineers who love community and storytelling, developer evangelism is a natural fit. You’ll translate complex concepts into actionable guidance, from in-app guides and product tours to UX writing and documentation. The best evangelists I’ve worked with turn feedback loops into product insight, strengthening activation and product-led growth without heavy sales pressure.

Customer-facing technical roles—solutions engineer, forward deployed engineer, or technical consultant—let you stay close to the product while solving real-world problems. You’ll drive onboarding quality, user activation, and adoption while surfacing insights that influence roadmaps. Done well, this work tightens the loop between customer outcomes and product decisions.

AI-centered roles are expanding rapidly. If you’re curious about AI Strategy, retrieval-first pipelines, or the practical use of LLMs for product managers, you can bring an engineer’s discernment to a noisy space. The most valuable contributors here pair pragmatic architecture choices with clear risk management and measurable business value, not hype.

Leadership tracks remain a strong option too. The IC to manager transition isn’t about title; it’s about raising the ceiling for others. You’ll coach empowered product teams, shape organizational development, and align initiatives to defensible metrics—think DORA metrics for flow, leading indicators for value, and OKRs that measure outcomes over output.

If you’re exploring a pivot, start small and intentional. Run “career A/B tests” by taking on cross-functional projects, shadowing adjacent roles, or shipping a lightweight portfolio that demonstrates the new muscle. Join a ProductCon session, practice conference networking, and refine a narrative that links your engineering foundation to the outcomes your target role owns.

Finally, map your personal unfair advantages—domain knowledge, systems thinking, customer empathy, or operational rigor—to the roles that value them most. With focus, you can reposition your engineering experience into a differentiated story that accelerates your next chapter. The breadth of options is real, and with a deliberate plan, you’ll turn curiosity into conviction—and conviction into impact.

Inspired by this post on Product School.

November 24, 2025
AI Won’t Replace Engineers—Engineers Using AI Will: A Practical Playbook for Your Next Move

Will AI replace software engineers or reshape their roles? Explore risks, opportunities, and alternative career paths in tech.

I’m often asked whether AI will make software engineers obsolete. My short answer: AI is already automating tasks, not eliminating the role. The engineers who learn to orchestrate models, systems, and stakeholders will create more value—not less. The real shift is from keystrokes to judgment, from writing code to designing socio-technical systems that deliver outcomes.

Today’s gen ai assistants—think Claude Code and ChatGPT connector—excel at unit test scaffolding, boilerplate generation, refactoring, docstrings, and code search. When integrated into CI/CD, they can open draft pull requests, annotate diffs, and propose fixes. This lifts developer productivity and frees time for higher-leverage work: problem framing, architecture decisions, and customer discovery.

What changes in the role? We spend more cycles on product discovery, privacy-by-design, and AI Strategy, and fewer on repetitive implementation. We design agentic AI workflows that combine retrieval, tools, and guardrails; we evaluate trade-offs that blend performance, cost, and safety; and we partner with empowered product teams to ship the smallest valuable slice, learn, and iterate.

Measure what matters. If AI is working, DORA metrics should improve: higher deployment frequency, shorter lead time for changes, stable change failure rate, and faster MTTR. Pair that with outcomes vs output OKRs to avoid gaming the system—shaving seconds off a build is meaningless if it doesn’t move activation, retention, or revenue. A unified analytics platform can help connect engineering signals to business impact.

Risk is real—and manageable. AI risk management and data governance are now core competencies, not afterthoughts. Protect IP with robust access controls, context window management, and red-teaming. In production, instrument threat detection and response to catch prompt injection, data leakage, and model drift. Treat this like any other reliability discipline alongside SRE.

If parts of coding get automated, where can great engineers thrive? Several high-impact paths are emerging: platform engineering for LLMs (tooling, evals, observability), SRE for AI-infused systems, developer evangelism and education, product management for AI-native experiences, security engineering focused on model and data threats, and forward deployed engineers who pair with customers to solve messy, real-world problems.

How to upskill fast: build an AI product toolbox and ship small. Prototype gen ai features end-to-end—retrieval, function calling, human-in-the-loop QA—and connect them to your CRM integration or support stack. Use A/B testing with a clear minimum detectable effect (MDE) to validate impact. Leverage CustomGPT workflows for internal enablement and in-app guides or product tours to onboard users safely.

Here’s a pragmatic 90-day plan. Week 0–2: audit your top 10 engineering tasks by time spent; identify 3 that are ripe for AI augmentation. Week 3–6: pilot inside CI/CD with explicit guardrails; track DORA metrics and developer sentiment. Week 7–10: productionize the wins; document runbooks; add incident management paths. Week 11–12: share learnings with product trios, refine your value proposition, and set next-quarter OKRs.

AI won’t replace software engineers; engineers who master AI will outpace those who don’t. If we embrace the shift—toward systems thinking, responsible governance, and customer outcomes—we’ll build better products faster and open new, rewarding career paths. The opportunity is here and compounding.

Inspired by this post on Product School.

November 12, 2025
Inside the AI Tornado: How I Deliver Fast and Secure—Lessons from Vercel’s Aparna Sinha

I’ve spent the past few years building in what often feels like an AI tornado—intense velocity, shifting requirements, and unforgiving expectations for security and quality. When I think about how to turn that chaos into momentum, I’m reminded of a guiding prompt: "Learn how Aparna Sinha, SVP of Vercel, builds in the AI tornado quickly and securely. Aparna shares her practical advice for builders everywhere." That mandate resonates with how I lead product teams to move decisively while protecting our customers and our brand.

In practice, building quickly and securely starts with clarity. I anchor the team on a crisp value proposition, define outcomes over output, and align product discovery with a tight feedback loop. We plan with product roadmapping and sprint planning that front-loads risk: data governance, threat modeling, and privacy-by-design are non-negotiable guardrails. This lets us unlock developer velocity without compromising trust—precisely the balance elite product management leadership aims to achieve.

On the execution side, I use lightweight gen ai experiments to accelerate insight and reduce uncertainty. For gen ai for product prototyping, we spin up narrow, testable slices that validate feasibility, usability, and safety in parallel. Two-week iteration cycles, clear exit criteria, and a secure-by-default posture keep us honest. We instrument a unified analytics view to measure real outcomes, then double down where signal is strongest and deprecate what doesn’t move the needle.

Team topology matters just as much as process. I empower product trios to own customer value end-to-end, pair forward deployed engineers with design and PM for rapid discovery, and practice developer evangelism to amplify adoption patterns early. This creates the foundation for product-led growth: a self-reinforcing loop where users teach us what to build next, and we respond with precision. Strong stakeholder management keeps go-to-market aligned so we can scale learnings into repeatable wins.

Security is everyone’s job, not a final checklist. We embed data governance and compliance considerations from day one—so speed becomes sustainable, not reckless. The outcome is a product culture that moves fast with conviction: disciplined experimentation, clear decision frameworks, and a shared commitment to quality.

If you’re building in the AI tornado, focus on three levers: sharpen outcomes (what matters), reduce uncertainty (prove it fast), and codify trust (bake in safety). Do this consistently, and your team will ship faster with fewer reversals—while compounding credibility with customers and the market.

Inspired by this post on Amplitude – Perspectives.

October 24, 2025
From $2M to $100M ARR: Inside fal’s Explosive Pivot and the Future of Generative Media

Generative media is no longer a curiosity on the edges of product roadmaps—it’s fast becoming a core capability. Watching one company sprint from uncertainty to undeniable traction reminded me how much a decisive pivot, a developer-first brand, and ruthless focus can bend a growth curve. This is a story about finding product-market fit in real time, scaling with intention, and staying lean while the category accelerates beneath your feet.
Gorkem Yurtseven is the co-founder and CEO of fal, the generative media platform powering the next wave of image, video, and audio applications. In less than two years, fal has scaled from $2M to over $100M in ARR, serving over 2 million developers and more than 300 enterprises, including Adobe, Canva, and Shopify. In this conversation, Gorkem shares the inside story of fal’s pivot into explosive growth, the technical and cultural philosophies driving its success, and his predictions for the future of AI-generated media.
What stood out to me first was the clarity of the pivot: “How fal pivoted from data infrastructure to generative inference.” The hardest decisions often feel like abandonment—of code, roadmap, and even identity—but the right pivot reframes everything around a higher-signal customer need. That decision, described as “The hardest decision that saved the company,” unlocked a new trajectory and set a crisp north star for the team.
Equally important was the market intuition. As they put it, “Why ‘generative media’ is a greenfield new market.” Greenfield means pattern-breaking strategy: prioritize outcomes over parity, embrace new workflows rather than retrofit old ones, and measure value in quality, latency, and unit economics—not just features. In my experience, this is where product teams win or lose: you either build the new default or get trapped perfecting the old one.
fal’s “explosive year” wasn’t luck; it was systems thinking applied to a developer platform. The team stayed small—”lean <50-person team” and “Staying nimble as a 45-person company”—and built a brand that feels genuinely for builders: “Building a brand that resonates with developers.” That shows up in everything from docs and SDKs to the cultural quirks that scale signal, like “Why fal has 500 Slack channels.” Velocity and clarity compound when communication is designed for ownership.
Early traction came from sharp use cases and fast feedback loops. I loved the transition arc from “The early adopters of the first fal product” to “The transition from toy to tool.” In a new category, the fastest path to durable usage is making something delightful and then relentlessly hardening it for production: uptime targets, deterministic APIs, transparent pricing, and repeatable performance. That’s how you move from demos to dependable workflows.
The timing call is bold and specific: “Why 2025 is the year of AI-generated video” and “Predicting AI-generated film in 2027.” If you build in gen AI, this matters. Video will force teams to optimize for cost per second, temporal coherence, and developer ergonomics across long-running jobs. The winners will combine model choice (OpenAI, Anthropic, Google DeepMind, Stability AI; “Stable Diffusion XL (SDXL)”, “Sora”, “DALL-E”, “LLaMA”) with world-class inference, smart caching, and autoscaling that feels invisible to the developer.
On the go-to-market side, I see a masterclass in founder-led GTM and developer evangelism. “Competing in a fast-moving, fragmented market” requires sharp messaging and distinctive ideas. The story behind “GPU Rich / GPU Poor” is a perfect example: a memorable narrative that encodes a real infrastructure advantage. Pair that with “fal’s greatest optimization wins” and you get a brand promise rooted in measurable performance, not just clever copy.
Culture and team design are the force multipliers. “How to build a world-class team” and “fal’s unique hiring philosophy” emphasize high-slope talent, ownership, and speed over headcount. The result is a product org that ships, learns, and iterates without bureaucratic drag. For technical founders, “Learning sales as a technical founder” is a reminder that the best sales motion often emerges from the same instincts as great product discovery: ask better questions, observe real workflows, and sell through outcomes.
Here’s how I translate these lessons into a practical playbook for product leaders working in gen ai and developer platforms: double down on developer experience (time-to-first-output, clear pricing, robust SDKs), make latency and reliability your product features, sequence the roadmap from delightful demos to dependable production tools, and stay lean enough to pivot as models and use cases evolve. Above all, treat “Why generative media is a greenfield market” as a call to invent the defaults others will copy.
Looking ahead, the path is clear: as AI-generated video normalizes in 2025 and professional-grade content follows by 2027, the products that win will combine inference excellence with a brand developers trust. If you’re building in this space, now is the moment to ship fast, optimize relentlessly, and meet creators and developers where they already work.

October 22, 2025
Twilio’s CEO on Peaks, Valleys, and C-Suite Truths: Hard-Won Lessons for Product Leaders

When I study enduring product companies, I look for the inflection points that shaped them. In revisiting the journey of Jeff Lawson, co-founder and CEO of Twilio, I was struck by his longevity and resilience — he’s spent the last 13 years building and running the company, including leading through a successful IPO in 2016. From my product leadership lens, the arc of Twilio’s growth offers a playbook packed with hard-earned lessons for builders at every stage.

One of the early peaks came from defying conventional wisdom. Rather than waiting for perfect product-market fit from a single product, Jeff pushed to launch a second product in Twilio’s early days. I’ve taken a similar stance in my own work: when customer signal is strong and the surface area is adjacent, a thoughtfully scoped second product can accelerate learning, diversify revenue, and strengthen the platform story — as long as you preserve focus with crisp strategy, clear ownership, and a rigorous roadmap.

But no ascent is without valleys. A pivotal low point arrived when one of Twilio’s biggest customers, Uber, significantly scaled back their investment in Twilio’s products. Every product leader knows the sting of concentration risk — when a single customer’s shift reverberates across forecasts, roadmaps, and morale. The real lesson is how you respond: deepen value for the broader customer base, rebalance your portfolio, and institutionalize dependency reviews so one customer’s change doesn’t become an existential threat.

Jeff’s operating system also reflects a powerful inheritance from Amazon: a bias to “write it down.” I share this conviction. Clear, written narratives clarify assumptions, expose trade-offs, and make decisions auditable over time. It’s why “PowerPoint is a terrible decision-making tool.” Slides may persuade; writing forces us to think. In my teams, we prefer narrative memos, PR/FAQ-style artifacts, and decision logs to drive alignment, speed, and accountability.

Inside the C-suite, Jeff instituted practices that many product organizations underutilize. They run post-mortems when things go right — not just when they go wrong. In my experience, reverse-engineering wins reveals the leading indicators and repeatable behaviors that often get lost in celebratory moments. Equally important, Jeff had an “aha” moment that his executive team needed to argue more. Healthy debate is not dysfunction; it’s a prerequisite for durable decisions. The goal is principled dissent, time-boxed contention, and a clear decision owner — then unwavering commitment to execution.

For company-builders across industries and growth stages, these patterns are universally applicable: expand thoughtfully, manage risk before it manages you, privilege writing over slides, study your wins, and cultivate constructive conflict. That’s how you turn peaks and valleys into durable operating rhythms that scale from product-market fit to public markets.

If you want a deeper dive into Jeff’s philosophy on engineering leverage and developer-first cultures, his book “Ask Your Developer: How to Harness the Power of Software Developers and Win in the 21st Century.” is a practical field guide: https://www.amazon.com/Ask-Your-Developer-Software-Developers/dp/0063018292

For a closer look at how Twilio operationalizes company values — including the famous “draw the owl” ethos — explore this overview: https://review.firstround.com/draw-the-owl-and-other-company-values-you-didnt-know-you-should-have

You can follow Jeff on Twitter at @jeffiel.

Inspired by this post on First Round.

October 22, 2025
Inside Figma’s 5-Phase Community-Led Growth Playbook to Ignite Organic GTM

When I study companies that turn product-market fit into durable, compounding momentum, Figma stands out. In this breakdown, I walk through Figma’s five phases of community-led growth and share how I’d apply each step to build an organic growth engine. My lens is product management leadership paired with pragmatic GTM thinking, so the emphasis is on what to do, when to do it, and why it works.

Phase 1 centers on the lessons from years in stealth mode — specifically, how to start planting the seeds for a community when you don’t have a fully-formed product. I focus on the inflection point to emerge from stealth, what signals matter, and how to use early feedback loops for product discovery without over-rotating on feature requests. Quietly building is necessary; quietly engaging is essential.

In this early phase, my playbook prioritizes rigorous product discovery, crisp problem narratives, and a cadence that makes learning visible. I invest in relationship-building with credible early adopters, share prototypes thoughtfully, and shape outcomes over output through disciplined product roadmapping and sprint planning. The goal is to design a community that feels invited into the creative process while preserving the integrity of your vision.

Phase 2 is all about the launch playbook — from taking over design Twitter, to marketing to folks who tend to bristle at traditional SaaS marketing. Here, founder-led GTM matters. I pair zero to one B2B marketing with specific audience rituals, leaning into channels where the product can be experienced, not just described. The message avoids enterprise jargon and instead showcases feel, speed, and collaboration, so the community can instantly “get it.”

Phase 3 shifts the focus to activation via community gravity. The goal is to get folks to try the product, even if they weren’t going to switch over right away to designing in Figma full-time. This is where I formalize an evangelist strategy — spotlighting workflows, templates, and stories that reduce the cost of the first session. I think about developer evangelism patterns applied to designers: celebrate makers, distribute small wins widely, and build momentum with authentic, peer-to-peer proof.

The final two phases connect passionate individual users to an enterprise strategy. They didn’t layer in a sales team until four years after the product launched, and didn’t add a paid product tier until another two years after that. Those choices underscore a disciplined sequencing of PLG with a sales overlay — land with love, expand with proof, monetize with timing.

In practice, this means evolving from bottoms-up adoption to clear value narratives for team and enterprise tiers, while tuning SaaS pricing and packaging to customer maturity. I optimize the handoff from product-led signals to sales motions, align success metrics to outcomes (not just usage), and enable procurement-friendly paths without dulling what made the product magical. That’s the GTM trade-off: protect the community engine while scaling into enterprise.

If you’re building your own community-led growth engine, these phases offer a durable blueprint: learn in stealth, launch where your audience lives, activate with authentic evangelism, and scale with a thoughtful enterprise bridge. Done well, this approach compounds — it strengthens product-market fit, accelerates zero to one B2B marketing, and sets the stage for sustainable growth without overreliance on paid channels.

October 21, 2025
How Retool Hit $2M ARR Pre‑Launch: My Playbook on Developer Focus, Product‑Market Fit, and GTM

I spend my days building and scaling B2B products, and Retool’s journey to $2M in ARR before launch is a masterclass in focus. It’s also a case study I revisit when coaching teams on developer evangelism and founder-led GTM.

Listening to David Hsu recount the early decisions made the strategy crisp: stay laser‑focused on developers, remove the boilerplate of internal tools, and earn trust with speed.

Retool, a low-code platform for developers building custom internal tools.

Today, Retool is valued at over $3 billion and has some of the biggest companies in the world building apps on its platform.

Early on, plenty of smart folks thought the idea for Retool would fail and that the product’s developer focus would sink the company. I’ve heard variations of this skepticism whenever a team doubles down on a specific persona—especially developers.

What struck me is the clarity around the target customer and the discipline to pursue language-market fit. When you get the words right for developers—their jobs-to-be-done, primitives, and constraints—you lower friction across product discovery, onboarding, and activation.

Equally instructive is how Retool nabbed its earliest customers (which includes Brex, DoorDash and a Fortune 500 BigCo) and the way the team prioritized creating incredibly tight feedback cycles with these early evangelists. That’s founder-led GTM at its best: sit with users, ship fast, instrument everything, and turn customer conversations into a roadmap.

On the surface, Retool’s path to product-market fit seems incredibly smooth. But as David tells it, there were plenty of bumps in the road — and he’s got tons of advice for early-stage founders that are finding their footing. I’ve lived those bumps, too; they’re signals to tighten the loop, not reasons to pivot away from your core user.

My takeaways for product leaders: start with developer empathy, not feature breadth. Use founder bandwidth to run high-frequency user sessions, shadow internal tool builds, and test copy until you hit language-market fit. Treat docs, templates, and examples as part of the product; they often outperform UI tweaks for time-to-value.

Operationally, stand up a lightweight, metrics-driven pipeline that connects discovery to delivery. I like a weekly cadence that pairs qualitative insights with activation, time-to-first-value, and expansion signals—classic product-market fit lessons that prevent local optimizations. When you see pull, lean into developer evangelism and zero to one B2B marketing, not paid acquisition.

If I were replicating this playbook today, I’d deploy a small, forward-deployed team to embed with design partners, capture real workflows, and ship improvements daily. Pair that with clear outcomes vs output OKRs so the team optimizes for customer outcomes, not just shipping velocity. That’s how you earn trust with developers and translate it into durable ARR.

Retool’s story reinforces a principle I teach often: conviction in the right user beats broad appeal every time. Focus wins, feedback compounds, and the market rewards teams that can turn skepticism into traction—especially when the users are developers.

October 21, 2025
Decentralized Community Masterclass: Bottom‑Up Growth, Creator Partnerships, First Hires

I recently sat down with Ben Lang, Head of Community at Notion, to unpack how a decentralized, bottom‑up community can power durable, compounding growth. In my day-to-day leading product, I’ve seen community-led growth move markets—hearing the detailed playbook behind it brought the strategy into sharp focus for operators and founders alike.

Since joining the company in 2019, Ben has had his hand in several high-impact projects at Notion that has grown its tight-knit community of passionate Notion evangelists into millions of users today.

But before he was doing this as a full-time job, Ben was already spreading his love for Notion in his free time as a voracious product user. After discovering the tool on Product Hunt, he became obsessed. He got on the company’s radar after launching his own Notion template gallery on Product Hunt and joined as one of the first 15 employees.

In our conversation today, we focus on the nuts and bolts of building a global community that drives user growth. Ben shares tactical advice on: Tackling community organically from the bottom-up, and why you shouldn’t go top-down; What companies are best suited to a centralized vs. decentralized community approach; Partnering with YouTubers and other creators; His advice to founders on finding your own first community hire.

Here’s my biggest takeaway on the bottom-up vs. top-down decision: bottom-up wins trust before it asks for anything. When you enable passionate users to teach, build, and share—then get out of their way—you unlock authentic advocacy that no paid campaign can replicate. Practically, this looks like community-led onboarding (templates, live office hours, and user-run meetups), lightweight governance (clear brand and safety guardrails), and a creator toolkit (assets, sample briefs, and success stories) that fuels developer evangelism and product discovery without stifling creativity.

On centralized vs. decentralized approaches, fit matters. Centralized communities shine when your product is compliance-heavy, your ICP requires curated expertise, or you need consistent, high-signal feedback loops. Decentralized communities thrive when your value compounds through remixing and sharing—think modular templates, integrations, and a vibrant ecosystem of product creators. My operating rule: start centralized for quality and learning, then progressively decentralize as playbooks harden and local leaders emerge. Instrument the handoff with clear roles, lightweight certifications, and community health metrics (activation, contribution velocity, and sentiment).

Creator partnerships—especially with YouTubers and niche educators—act as force multipliers. Treat creators like product partners, not channels: co-develop curricula, share early product roadmaps where appropriate, and equip them with data-backed talking points and reusable assets. Build a transparent value exchange (rev share, affiliate programs, early feature access), define success upfront (reach, engagement, and downstream activation), and keep content evergreen with updates tied to releases. The result is a repeatable growth loop that blends PLG, social proof, and zero to one B2B marketing.

For founders hiring the first community leader, optimize for a builder-operator hybrid: someone who has shipped programs, written docs, hosted events, and can close the loop from insight to iteration. Look for evidence of creator empathy, editorial judgment, lightweight product instincts, and the ability to scale through systems (templates, playbooks, and tooling). Define outcomes, not activities: measure community-led pipeline, activation lift, retention improvements, and the velocity of high-quality user feedback feeding product management leadership.

The throughline is simple: community is a product. Design it with the same rigor—clear ICPs, onboarding, retention hooks, and feedback loops—and it becomes a durable moat. Whether you lean centralized or decentralized, start bottom-up, enable your best users, and let creators help you tell the story the market actually wants to hear.

October 21, 2025
Open-Source GTM Masterclass: Pricing, Packaging, and Paywalls with Grafana Labs’ COO

I sat down with Douglas Hanna, Chief Operating Officer at Grafana Labs. Grafana Labs is an observability stack built around Grafana, a leading open-source technology for dashboards and visualization.
Douglas is a seasoned revenue leader, previously leading operations and GTM strategy at Zendesk. At Grafana Labs, Douglas has been instrumental in scaling GTM at the open-source company — building up both team headcount and its revenue model.
In our conversation today, Douglas dives deep into the process of bringing products to market at an open-source company. That focus on disciplined go-to-market execution resonates with my own experience building product-led motions that respect the community while establishing clear, sustainable paths to revenue.
We explore the different facets of building and scaling a revenue model at an open-source company. Douglas opens up the GTM playbook at Grafana Labs sharing: I found these principles especially actionable for open source monetization, SaaS pricing, and zero to one B2B marketing.
“When to commercialize a feature vs. switch to a hosted version of a product” — In practice, I look for telltale signals: features that impose heavy operational burden (security, scale, multi-tenant reliability), generate significant infrastructure or support costs, or require advanced governance. That’s when a hosted version can deliver outsized value. For individual features inside the core, I favor commercialization only when the value metric is unambiguous and the user experience remains seamless for the community. The key is a clear migration path from self-managed to hosted, with pricing aligned to usage or outcomes.
“Tried and tested frameworks for pricing and packaging” — I anchor on a few staples: value metrics that correlate with customer outcomes, willingness-to-pay testing, and the 3C lens (customer, competition, company). For packaging, a tiered “good/better/best” model helps segment needs, while usage-based or consumption pricing can unlock elasticity for developer-led adoption. I’ve seen price fences (SSO, RBAC, advanced analytics, scale limits) work well when they map to enterprise readiness rather than core functionality.
“How Grafana Labs thinks about what to put behind a paywall” — I share the same philosophy: keep community-loved, foundational capabilities open to preserve trust and growth, and place enterprise-grade scale, compliance, and governance behind the paywall. This often includes SSO/SAML, audit logs, granular access controls, advanced alerting, longer retention, and premium SLAs. The litmus test is whether the paywalled capability primarily serves larger teams’ risk, reliability, and control requirements.
“How the GTM team was built over time” — The sequencing matters. Early on, lean into product-led growth with strong developer evangelism, documentation, and onboarding. As adoption accelerates, add sales-assist, solutions engineering, and forward deployed engineers to convert complex use cases. Over time, layer in customer success, pricing operations, and ecosystem partnerships. Hiring profiles evolve from generalists to specialists, but the connective tissue remains a tight loop between product, community, and revenue.
Throughout our discussion, I appreciated the rigor in tying pricing and packaging decisions to measurable value, while safeguarding the open-core experience. That balance is the difference between short-term monetization and durable category leadership in observability.
You can follow Douglas on Twitter at @douglashanna.
If you’re building or scaling an open-source business, these GTM patterns provide a pragmatic blueprint: lead with community, monetize enterprise needs, and align pricing to real-world usage. It’s a playbook that rewards trust, clarity, and iteration — and it’s one I’ve seen drive repeatable growth when executed with discipline.

October 21, 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