Month: October 2025

  • Scaling With Heart: Self-Aware Leadership, Tough Calls, and 10x Team Performance

    Scaling With Heart: Self-Aware Leadership, Tough Calls, and 10x Team Performance

    I’ve spent enough cycles scaling product organizations to know that leaders grow—or their companies stall. In this reflection, I distill the practices I rely on to scale an org, develop myself, and raise the performance ceiling across teams, especially when the economic environment demands sharper focus and better decisions.

    To ground this discussion, I often point leaders to exemplary people-first operators. Jack Altman is the co-founder and CEO of Lattice, a people success platform for building engaged, high-performing teams. Lattice has raised over $330M, and was last valued at $3B. His work on culture and performance—captured in “People Strategy”—reinforces many of the principles I use daily.

    I start with self-awareness because it’s the keystone. If I can’t see my own patterns—when I’m avoiding conflict, over-controlling, or confusing activity with outcomes—everything else degrades. I cultivate self-awareness by writing brutally honest weekly retros, asking my staff for one piece of constructive feedback every month, and running periodic 360s to reveal blind spots. The goal isn’t comfort; it’s truth. When I improve my signal on reality, my decisions get faster and my team gains confidence.

    Difficult conversations are a gift to performance. I’ve learned to tackle them quickly, with empathy and specificity. I name the gap between expectation and outcome, share observable examples, state the impact on the team, and propose a clear path forward with timelines. If emotions run hot, I slow down, seek to understand, and stay on the behavior and results—not the person. Avoidance compounds culture debt; candor repays it with interest.

    Scaling a company introduces predictable failure modes. I’ve seen leaders confuse hiring errors with management errors; it matters which you’re facing. A hiring error shows up as persistent gaps in role fundamentals even after clear expectations, coaching, and time-bound support. A management error usually stems from ambiguous goals, poor context, or inadequate resources. I assume management error first and fix the environment. If results still lag, I revisit the hire.

    Delegation versus control is a healthy tension. Early, I’ll “micro-mentor” on critical work to teach quality, taste, and judgment—then expand autonomy as pattern recognition develops. My rule: delegate outcomes, keep ownership of standards and context. I never give up the responsibility to set the bar for the team and to protect the product vision; those are one-way doors that define the company’s trajectory.

    Building a product organization that compounds requires clarity and context. I ensure every product trio understands the strategy, customer segments, and constraints. We anchor on outcomes vs output OKRs, maintain a living strategy doc, and write decision memos that document trade-offs. When context flows, people need fewer approvals and produce better work, faster.

    On so-called micro-management, here’s my take: it’s a tool, not an identity. Early in a function or with a new leader, I may be intentionally hands-on to transfer judgment. The moment competence and trust are proven, I deliberately pull back. The mistake isn’t micro-managing; it’s forgetting to stop.

    CEO-level context setting is non-negotiable. I articulate the narrative behind the plan—the why, the constraints, the risks, and what we’re not doing. Transparency isn’t oversharing; it’s sharing the right information at the right fidelity so people can make aligned decisions. I model this with written updates, open Q&A, and by explaining how major calls were made.

    Some of the most valuable leadership work happens in uncomfortable conversations. I prepare by drafting the core message, testing it for clarity and fairness, and deciding what success looks like for the person and for the business. I also own the decision. When the stakes are high, I don’t outsource the final call or feedback to a proxy; accountability builds trust.

    Speed versus accuracy in decision-making is situational. For reversible bets, I bias to speed, time-box the experiment, and set clear kill criteria. For one-way doors, I slow down, increase the sample of perspectives, and pressure-test assumptions. I counter hidden biases in group discussions by starting with silent written proposals and independent scoring before we debate out loud.

    I’ve even experimented with removing myself from recurring meetings for a cycle. The outcome: decisions kept moving, and I learned where my presence added value versus created drag. Now I show up intentionally—for feedback on taste, to unblock cross-functional issues, or to deliver context—then get out of the way.

    Here are four practices that consistently pay off for me: protect deep work blocks for strategic writing, conduct weekly customer calls, review hiring quality monthly, and keep a running list of hard problems only I can solve. This keeps me oriented toward leverage, not busyness.

    Talking to customers is an art. I avoid solution-leading questions and ask about current workflows, pains, and the last time the problem showed up. I go five whys deep, quantify the value of a better outcome, and listen for language customers use to describe success. The best product discovery lives in those unpolished details.

    Great leaders are constant learners. I rotate through books, operator peer groups, product management leadership communities, and curated newsletters. I also treat my own organization as a learning system—post-mortems, pre-mortems, and lightweight experiments build institutional knowledge faster than any single playbook.

    To maximize employee performance, I use a simple model: Clarity x Capability x Motivation x Environment. Clarity means crisp expectations and definitions of done. Capability is skills and experience, which I grow via coaching and targeted practice. Motivation blends purpose, recognition, and meaningful goals. Environment covers tools, psychological safety, and focus time. If any factor is near zero, performance collapses; my job is to diagnose and raise the lowest one.

    When long-time employees stop scaling with the company, I address it early. Sometimes a role redesign or releveling unlocks success. Other times, a dignified, well-supported transition is the right call for everyone. Avoiding the issue erodes trust; handling it with clarity and care strengthens culture.

    Low-performing but well-liked employees create a leadership test. I separate likability from impact. If values are strong but performance lags, I set a time-bound plan with clear checkpoints. If progress doesn’t materialize, I act. Keeping someone in a role they’re not meeting hurts the team and the individual by delaying a better fit.

    When someone is let go, I’m thoughtful about what to share. I communicate the change promptly, state the role-level rationale without gossip, thank the person for their contributions, and reinforce the plan going forward. The aim is to honor privacy while maintaining clarity about standards.

    In today’s tougher macro environment, I refocus on capital efficiency, ROI-driven roadmaps, and slower, more deliberate hiring. I raise the bar for product bets, validate earlier with customers, and price for value. Constraints, when embraced, sharpen strategy and execution.

    Aligning career goals with company goals is ongoing work. I use growth frameworks, individual development plans, and quarterly conversations that link business outcomes to skill-building. When people see a path to mastery and impact, performance accelerates.

    Most leaders underestimate their team’s potential. I raise expectations with ambitious, outcome-based goals, ensure people have the context to operate like owners, and celebrate learning velocity as much as wins. When standards, support, and trust rise together, teams routinely outperform even optimistic forecasts.

    Resources I recommend: Jack’s book: https://www.amazon.com/People-Strategy-Culture-Competitive-Advantage/dp/1119717043. Jack’s company, Lattice: https://lattice.com/. First Round Capital’s Newsletter: https://review.firstround.com/newsletter.

    Book a consult png image
  • My playbook: Intuition vs data, big swings, and product-led growth lessons from Slack

    My playbook: Intuition vs data, big swings, and product-led growth lessons from Slack

    I get asked constantly how I decide when to trust my gut, when to lean on data, and when to take a big swing versus iterate. As a product leader, my answer has been shaped by hard-won lessons building B2B SaaS, product-led funnels, and enterprise features. Recently, I revisited Slack’s approach to decision-making, product reviews, and balancing product-led vs sales-led growth—and distilled a set of practices I use with my teams today.

    Noah Desai Weiss is the Chief Product Officer of Slack, and has an accomplished track record inside and outside of the company. He started Slack’s Search, Learning, and Intelligence division, led the Self-Service (SMB) Business, and led the Expansion and Virtual HQ product areas (responsible for Huddles, Clips, and more). Before joining Slack, Noah was the SVP of Product Management at Foursquare (raised over $390m), and was a Product Manager at Google.

    The throughline for me starts with a simple truth: not all decisions should be data-driven. Early in a product’s life—or when exploring a novel experience—data is often either unavailable or misleading. That’s where intuition, taste, and judgment come in. I treat intuition as a hypothesis generator and momentum maker, then instrument quickly to validate direction. This blend of “When to use intuition vs data to drive decisions” has saved me from overfitting to small datasets and from analysis paralysis when speed was the real advantage.

    I’ve learned that “Taste and judgment are learnable.” You can coach it. Review artifacts together. Run side-by-side comparisons of design explorations. Write down what “good” looks like and why. My teams keep a living gallery of exemplary UX patterns and empty-state copy that exemplifies our bar. Over time, this scales the craft of intuition across a larger org—just as “How Slack scales intuition across their product org” suggests.

    Of course, there are “Challenges of intuition-led product building.” The biggest are founder or leader overreach and survivorship bias. I mitigate this with timeboxed discovery: we commit to a clear decision date, capture our priors in writing, and express our confidence as a range rather than a point estimate. This sets up a healthy dynamic for “Managing pace vs accuracy in decision-making.” We move fast when reversibility is high, we move slower when the blast radius is large.

    Matching people to the work matters too. Some product problems are inherently ambiguous and benefit from researchers, designers, and PMs who derive energy from the unknown. Others are best led by optimization-oriented builders who light up when the metric moves. I’m explicit about “Matching people to data vs intuition-driven work,” and I rotate folks so they can build both muscles.

    In remote and hybrid environments, I’ve found the most underrated traits are proactive context-sharing, crisp written communication, and the ability to create signal in Slack and docs. “Underrated qualities for remote workers” aren’t just stylistic preferences—they are execution speed ups. I look for people who make everyone around them smarter asynchronously.

    On product process, I’m inspired by “How Slack runs product reviews.” My rubric: one problem statement, a tight narrative memo, the bet framing (assumptions, risks, kill criteria), and outcomes tied to “outcomes vs output OKRs.” We align on the decision owner, consent vs consensus, and the next irreversible checkpoint. This keeps reviews from becoming theater and pushes decisions to the right altitude.

    Culture shows up in small moments. “The importance of a team’s ‘vibe’” is tangible: Do we demo early? Do we celebrate learned negatives as much as wins? Do engineers, designers, and PMs feel joint ownership of the experience, not just their function’s slice? When the vibe is right, latency from idea to insight collapses—and that compounding is everything in product discovery.

    Portfolio balance matters. I aim for a mix that lets us keep shipping customer-visible improvements while reserving room for breakthroughs. “Balancing “big swings” with incremental improvements” requires explicit ring-fencing: 70/20/10 works well for many orgs. Big swings get stage gates and PR/FAQ-like artifacts; incremental bets get weekly ship cadence and tight measurement. When we miss, we run pre-mortems and decision journals, reinforcing “Rituals for good decision-making.”

    Go-to-market is where strategy meets friction. My guidance on “Advice on product-led vs sales-led growth” is to design the handshake up front. Let product-led growth do the land—self-serve activation, collaborative aha, bottoms-up virality—and let sales-led growth do the expand—security, compliance, procurement, multi-workspace governance. Instrument the handoffs, define eligibility heuristics, and ensure pricing doesn’t punish adoption. This is also where “Which products should focus on end-users versus executives” gets real; optimize early journeys for end-user success while giving executives the portfolio-level control and analytics they require.

    I’m continually impressed by “What Slack learns from Salesforce.” Enterprise trust, admin controls, and scalable GTM motions can coexist with consumer-grade product craft. That hybrid DNA is powerful. I’ve adopted similar patterns: build for end-user joy, layer enterprise-grade controls, and price to match value realization, not procurement theatrics.

    Speaking of pricing, “Pricing lessons from Salesforce and Marc Andreessen” pushed me to keep pricing simple enough for PLG while being flexible enough for enterprise. Seat-based pricing remains intuitive for collaboration products, but usage and “SaaS pricing” add-ons can map value to heavy features without overcrowding your price page. The key is to test willingness to pay early, avoid grandfathering yourself into a corner, and treat packaging changes like product changes—with discovery, rollout plans, and success metrics.

    Humility isn’t fluffy—it’s an execution advantage. “Slack’s humility and why it matters” resonates with how I try to lead: ruthlessly honest about what we don’t know, eager to learn from customers quickly, and unafraid to reverse course when the evidence changes. That humility turns into speed because we stop defending past decisions and start iterating toward truth.

    When working with a strong product voice at the top, “How to build product with a product-focussed founder” comes down to mutually agreed principles. Capture the founder’s taste in explicit heuristics, define the moments where their judgment should overrule the process, and codify how dissent and disagree-and-commit work in practice. This protects clarity without stifling creativity.

    Here are the topics I unpacked and continue to apply across teams: “When to use intuition vs data to drive decisions,” “The most underrated traits in a remote work environment,” “How Slack runs product reviews,” “The importance of a team’s ‘vibe’,” “Managing pace vs accuracy in decision-making,” “Balancing “big swings” with incremental improvements,” and “Advice on product-led vs sales-led growth.” Each one is a lever that compounds when used together.

    Curious to learn more about Slack? You can try Slack Pro and get 50% off using this link.

    Creative Selection – Inside Apple’s Design Process During the Golden Age of Steve Jobs: https://www.amazon.com/Creative-Selection-Inside-Apples-Process/dp/1250194466

    Salesforce acquires Slack: https://slack.com/blog/news/salesforce-completes-acquisition-of-slack

    Thinking in Bets – Making Smarter Decisions When You Don’t Have All the Facts: https://www.amazon.com/Thinking-Bets-Making-Smarter-Decisions-ebook/dp/B074DG9LQF

    Book a consult png image
  • Hard-Earned Lessons from Loom: Product Strategy, Alignment at Scale, and Hiring That Wins

    Hard-Earned Lessons from Loom: Product Strategy, Alignment at Scale, and Hiring That Wins

    I’m always looking for crisp, scalable ways to drive product strategy, organizational alignment, and cross-functional performance that actually ship outcomes. Studying Loom’s operating system—and the career arc behind it—offered a masterclass worth sharing. Anique Drumright is the COO at Loom, a video communication tool for streamlining workflows. Loom has raised over $200M, and was last valued at $1.5B. Anique has a proven track record across product development, executive leadership, and building high-performing organizations. Before joining Loom, Anique was the VP of Product at TripActions, where she scaled the team over 8x globally, and she has also held multiple roles at Uber. In this breakdown, I dig into best-practice product management, how to achieve alignment at scale, the mechanics of cross-functional performance, Anique’s approach to finding top organizational talent, how to hire for roles outside your area of expertise, the most common fail cases with internal and external recruitment, and the specific interview tactics that actually surface the truth. One theme I return to often is the transition from product management to executive leadership. As a PM, I optimize for customer insight, prioritization, and execution velocity. As an exec, I optimize for clarity, systems, and sustained energy across teams. The job shifts from owning a roadmap to owning the conditions under which many roadmaps thrive—organizing for outcomes, setting non-negotiable standards, and removing ambiguity. Storytelling sits at the center of launch excellence. I love how Loom anchors launches in a human narrative: define the painful “before,” demonstrate the transformative “after,” and spotlight one memorable capability that makes the switch inevitable. I pair this with a crisp narrative memo, a demo-first internal review, and a simple, outcome-oriented success metric—so product, marketing, and sales sing the same chorus. Managing cross-functional scope and performance requires ruthless role clarity and shared measures of success. I align on a single definition of the customer problem, agree on leading indicators we can move now, and assign one DRI per decision. When we use outcomes vs output OKRs, we unlock better trade-offs: fewer features shipped, more customer problems solved. Organizational alignment is both essential and fragile. What looks like misalignment is usually mismatched time horizons, unclear ownership, or different definitions of success. The antidote is explicit agreements: who decides, how we decide, and what “good” looks like this quarter. When in doubt, I over-communicate context, not tasks. I’ve seen at scale—Uber is a notable example—that alignment travels fastest through shared rituals, not longer documents. Weekly business reviews, lightweight decision logs, and a common operating cadence create a heartbeat the org can follow. The point isn’t ceremony; it’s repeatable clarity. My go-to alignment rituals are simple. A Monday priorities memo sets the narrative and the week’s must-win outcomes. Midweek, a cross-functional stand-up surfaces risks and unblocks dependencies. Friday, we close the loop with a red-yellow-green on outcomes and a short retro on decisions—not just results—so we compound learning. One-on-ones are performance multipliers when they’re designed well. My winning format: start with energy and focus (what’s giving or draining energy), review outcomes not activity, walk a single thorny decision to closure, and end with explicit asks in both directions. Over time, this builds trust and speed. When and how to help functional leaders matters. I jump in when a decision is high-impact and ambiguous, when speed has stalled, or when the problem crosses multiple functions. Otherwise, I coach on principles and expect leaders to own the path. If I’m often in the weeds, we have a structure or talent gap—not a diligence problem. Hiring outside my domain expertise starts with outcomes, not resumes. I write the first-90-day outcomes, name the decisions the role must own, and recruit with a structured case that mirrors the real job. I bring in a domain advisor to probe depth and run a work-sample test to reduce false positives from polished storytellers. For senior leaders, my favorite interview questions are simple and hard to fake: Tell me about the last time you changed your mind on a critical decision—what evidence moved you? Walk me through your operating cadence—meetings, artifacts, and decisions—in a typical month. Describe your hardest cross-functional miss and the system you changed to prevent a repeat. The specificity of answers reveals the operator from the commentator. I adjust the hiring process when I’m outside my depth: heavier emphasis on work samples, more structured rubrics, a domain expert panel, and reference checks that test for actual outcomes. When the role is pivotal, I’ll run a paid trial project with clear guardrails; reality is the best filter. Common patterns of failed external hires: they manage optics over outcomes, never rewire the system, and don’t create leaders beneath them. Failed internal promotions often show up as scope growing faster than judgment, a reluctance to reset standards with former peers, or success limited to a familiar domain. Avoid over-promotion by decoupling recognition from scope; celebrate excellence without inflating title or span prematurely. To get honest answers in interviews, I normalize candor and ask for receipts. I request artifacts—planning docs, dashboards, postmortems—and I probe for the counterfactual: what would you do differently if you had to do it again? In reference checks, I ask for moments of truth: the hardest feedback you gave them, a decision you disagreed with and how they handled it, and the exact conditions under which you would rehire them tomorrow. Sustaining energy is an executive’s quiet superpower. I watch team energy levels as closely as metrics. What inspires people in a company is progress they can feel, standards that mean something, and leaders who tell the truth. If we keep those three alive, performance follows. A month in the life of a COO (and frankly any executive operator) is a portfolio: setting the narrative and outcomes, running the operating cadence, calibrating talent, and clearing systemic blockers. The best leadership dynamics work because roles are explicit, trust is earned through delivery, and debates resolve into single-threaded ownership—not committee compromises. Resources for further exploration: Loom (https://www.loom.com/), Navan (formerly TripActions): https://navan.com/, Teach for America: https://www.teachforamerica.org/, Uber: https://www.uber.com/. Timestamps I mapped my notes to for quick scanning: [00:03:00] similarities and differences between PM and executive leadership roles; [00:06:53] storytelling in launches; [00:10:01] cross-functional scope and performance; [00:13:41] goal-setting with functional leads; [00:16:59] organizational alignment; [00:20:40] alignment at scale; [00:24:06] alignment rituals; [00:25:23] one-on-one format; [00:27:49] supporting functional leads; [00:29:13] hiring outside your expertise; [00:32:55] interview questions; [00:33:55] adapting the hiring process; [00:36:09] failed external hires; [00:37:40] failed internal hires; [00:39:05] avoiding over-promotion; [00:40:51] inspiration; [00:45:40] getting honest answers; [00:47:12] reference checks; [00:51:29] a month in the life of a COO; [00:52:52] energy levels; [00:54:53] leadership dynamics; [00:57:30] outsized career influences.
    Book a consult png image
  • From Zero to One in B2B Marketing: My Proven SaaS Playbook for Growth, Hiring, and Attribution

    From Zero to One in B2B Marketing: My Proven SaaS Playbook for Growth, Hiring, and Attribution

    Early-stage B2B marketing is where momentum is made or lost. In my product leadership work, I’ve seen that getting from zero to one requires uncommon focus, founder-led GTM discipline, and a tight feedback loop between product, sales, and marketing. In this narrative, I share the playbook I use—and the patterns I took from top operators—to help SaaS teams build credibility fast, compound learnings, and scale repeatable growth.

    Alex Kracov is the CEO and Co-Founder at Dock, and the former VP of Marketing at Lattice. Alex joined Lattice as the first marketer and third employee, and he helped to grow the business from seed to 1850+ customers. Prior to Lattice, Alex was a consultant at Blue State Digital — the team that elected President Obama and orchestrated projects at Google. Since leaving Lattice in 2021, Alex co-founded Dock, a B2B platform that has streamlined the customer buying experience for clients like Loom, Origin, and Instabug.

    Here’s the agenda I use to guide founders and early marketing leaders: the 2023 SaaS marketing playbook; how to start your early-stage B2B marketing; how to prioritize resources across multiple marketing bets; how to think about attribution; Lattice’s unorthodox million-dollar marketing campaign; how to hire for early marketing roles; what makes a standout marketer; and advice for building your first website.

    When I spin up early-stage B2B marketing, I start by defining the shortest path to signal. That means a crisp ICP, problem-first messaging, and one or two channels where our buyers already congregate. At this stage, I bias toward founder-led discovery calls, live product walkthroughs, and tight content that proves outcomes—not features. This creates the raw material for positioning, case studies, and a credible top-of-funnel narrative.

    Short-term versus long-term goals must be explicitly balanced. I set near-term pipeline and learning targets (e.g., qualified conversations per week, time-to-insight from experiments) alongside long-term brand assets (evergreen content, customer proof, category POV). The rule of thumb I apply: stabilize one growth motion before layering the next, so we don’t overfit to noise or dilute the message.

    Allocating resources across marketing bets is a portfolio problem. I structure it as 70/20/10: 70% on the core motion that’s already working, 20% on adjacent bets with clear hypotheses, and 10% on contrarian experiments that could unlock step-change distribution. Weekly syntheses convert experiment data into decisions—double down, redesign, or retire.

    On attribution, I’m pragmatic. Early on, precision is less valuable than directionality. I pair multi-touch analytics with qualitative inputs (self-reported attribution, sales notes, community signals). The question I ask: which narratives and channels consistently show up in won deals? That blend avoids over-crediting the last click and keeps us honest about how trust is actually formed in B2B.

    Your first website is a conversion engine and a trust anchor. The first thing people should see on your website is the problem you solve, the outcomes you deliver, and a frictionless way to see the product in action. I recommend a tight hero message, social proof above the fold, a short demo video or interactive experience, and clear CTAs for both buyers who are ready now and those who need to explore.

    Brand and positioning mature with evidence. I translate discovery insights into a simple hierarchy: category, problem, unique insight, product proof, outcomes. At Lattice, strong brand clarity met operational excellence; at Dock, product-led collaboration sells the value by making the buying experience itself the demo. In both cases, the lesson stands: great B2B brands tell a truth buyers can quickly verify.

    Bold bets can be force multipliers. Lattice’s unorthodox million-dollar marketing campaign underscores a principle I use sparingly but decisively: when the narrative, timing, and distribution are aligned, a high-conviction investment can set the agenda for your category. The bar is high. The insight must be non-obvious, the creative durable, and the measurement plan rigorous.

    Hiring for early marketing roles, I optimize for learning velocity, narrative craft, and cross-functional empathy. The ideal first marketer is a full-stack generalist who can research, write, ship, analyze, and partner with sales and product. Experience matters, but potential—ownership, curiosity, systems thinking—often outperforms. I scale the team once one motion is repeatable and there’s a clear backlog of work we can’t tackle without specialization.

    Conferences and communities are underrated if used deliberately. I set specific objectives (target accounts, partners, customer content) and treat events as field research and content engines. Every conversation informs messaging; every meeting has a next step; every session becomes a clip, post, or asset. The outcome is pipeline plus reusable proof.

    My 2023 SaaS marketing stack emphasizes speed to insight: product analytics to observe behavior; a CRM and marketing automation platform to orchestrate journeys; lightweight data pipelines for attribution; a CMS for shipping content fast; and collaboration tools that put buyers and sellers in the same workspace. What matters most is not the logo set—it’s the operating cadence that converts data into action.

    If you’re going from zero to one, keep it simple: validate your ICP, ship a compelling narrative, pick one channel to master, and measure what buyers say and do. Sequence beats scope. Credibility compounds. And the best marketing is a mirror of a product that solves a painful, urgent problem—beautifully.

    Timestamps: [00:00:00] Intro [00:02:45] The challenges and opportunities in early-stage B2B marketing [00:05:13] How to think about short-term versus long-term marketing goals [00:07:31] Allocating resources across marketing bets [00:09:13] Signs your marketing is working [00:11:20] The most underutilized marketing strategy [00:13:03] Creating your company’s first website [00:14:22] How Lattice formed its brand messaging and positioning [00:18:22] Dock’s innovative approach to marketing software [00:20:14] The first thing people should see on your website [00:23:10] Lattice’s most successful early-stage marketing tactics [00:28:05] Determining which marketing strategies are still relevant [00:30:25] Lattice’s unorthodox million-dollar marketing campaign [00:33:26] Why Alex had an outsized impact at Lattice [00:37:05] Lessons from his first marketing hires [00:39:41] When to scale your marketing team [00:40:55] Building an effective early-stage marketing team [00:42:30] A tough conversation with the CEO & Co-founder of Lattice [00:44:46] Achieving early-stage marketing alignment [00:46:20] Transitioning from employee to entrepreneur [00:49:19] Getting the most out of conferences [00:50:47] Selecting marketing channels in the early stages [00:52:44] Hiring marketers for experience versus potential [00:56:34] The 2023 SaaS marketing stack [00:58:19] Advice for Zero to One marketing [00:60:46] What successful B2B marketing looks like

    Referenced: Dock: https://www.dock.us/ Lattice: https://lattice.com/ Jack Altman: https://www.linkedin.com/in/jackealtman J Zac Stein: https://www.linkedin.com/in/jzacstein

    Where to find Alex Kracov: Twitter: https://twitter.com/kracov/ LinkedIn: https://www.linkedin.com/in/alexkracov Website: https://www.kracov.co/

    Where to find Brett Berson: Twitter: https://twitter.com/brettberson LinkedIn: https://www.linkedin.com/in/brett-berson-9986094/

    Book a consult png image
  • Supercharge Your Engineering Org: Alignment, AI, and Productivity from Adobe to Etsy

    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.

    Book a consult png image
  • Building Products in a Post-LLM World: Hard-Won Lessons, Skeptic Busters, and Team Playbooks

    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.

    Book a consult png image
  • Inside Rewind AI’s Playbook: PMF Breakthroughs, Bold Twitter Fundraise, and the Future of AI

    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.

    Book a consult png image
  • From Founder-Led GTM to Repeatable Product-Market Fit

    From Founder-Led GTM to Repeatable Product-Market Fit

    You have several paying customers, a founder who can rescue almost any sales call, and a roadmap full of requests. That can feel like product-market fit. It may also be a collection of individually negotiated successes that will break the moment you add leads, sellers, or a second customer segment.

    The practical test is not whether the founder can win another deal. It is whether the same type of customer buys for the same reason, reaches value through the same core path, and stays or expands without bespoke intervention. Founder-led go-to-market should discover that pattern and turn it into a system someone else can operate.

    Founder-led GTM must reveal a repeatable unit

    Founder-led GTM has two jobs. The visible job is closing customers. The more important job is learning why a specific customer buys, what the product must do to deliver value, and which parts of the sale can be repeated.

    A founder can cross gaps that would stop a normal go-to-market motion. They can redesign the demo, promise roadmap work, adjust pricing, pull engineers into implementation, and lend personal credibility to an uncertain purchase. That flexibility is useful while the company is learning. It also distorts the signal. A deal is not evidence of repeatability if it depends on founder status, an unplanned feature, an unusual commercial exception, or invisible manual work.

    Before widening the funnel, define the unit you are trying to repeat:

    • Who: The customer segment, operating context, user, economic buyer, and disqualifying characteristics.
    • What: The acute workflow problem the customer is already trying to solve, described through the last real occurrence rather than a hypothetical future need.
    • Why now: The event, cost, risk, or operational pressure that makes the status quo unacceptable.
    • Promise: The business outcome the buyer expects, not the collection of capabilities being sold.
    • Path: The minimum sequence from setup to first proof to realized value.
    • Boundary: The conditions under which you should decline the opportunity rather than turn an outlier into roadmap policy.

    I find it useful to turn the path into a three-frame value storyboard. The first frame captures the current pain step by step. The second identifies the first moment when the customer can see that the product works. The third shows the completed workflow and the business result the buyer can verify.

    Give each frame observable evidence. The pain might be demonstrated by time spent, an error, a delayed handoff, or exposure to risk. The first-value frame needs an activation event that both the product and customer can recognize. The final frame needs an outcome in the customer’s terms. This storyboard becomes a shared contract across product, sales, implementation, and the customer. If a proposed feature does not move a customer toward one of those frames, it should not automatically enter the core roadmap.

    Early teams often mistake breadth for demand. Ten different feature requests can mean ten customers want ten different products. A narrower signal is more valuable: one capability repeatedly attracts urgency, earns willingness to pay, concentrates meaningful usage, and shortens the path to value. When those signals converge, a zoom-in decision can be stronger than expanding the feature set.

    Do not focus on a feature because customers compliment it. Look for three forms of evidence together: qualitative pull, concentrated behavior, and business impact. An adjacent request belongs in the core only when it serves the same customer, workflow, buyer, and value metric. Otherwise, treat it as a separate hypothesis.

    Run early accounts as controlled learning cohorts

    If every early customer is different, a company-wide average tells you very little. Group similar accounts into tight cohorts and assign explicit learning goals to each cohort. Keep the major assumptions stable enough to interpret the result. Changing the segment, pain, packaging, channel, and onboarding model at the same time produces activity, not knowledge.

    A disciplined founder-led loop looks like this:

    1. Qualify against the repeatable unit. Record why the account fits and every exception required to include it. An attractive logo is not a substitute for fit.
    2. Reconstruct the last instance of the problem. Ask the customer to walk through what happened, who touched the workflow, where it failed, and what the failure cost. This is more reliable than asking what features they might want.
    3. Sell the outcome to the economic buyer. The CEO is useful when the outcome and organizational change genuinely sit with the CEO. Otherwise, find the person who owns the cost, risk, or operating result. Use that conversation to test whether the value narrative survives beyond the end user.
    4. Ask for payment early. Praise and participation show interest. Payment tests whether the problem and proposed outcome justify a budget decision. Document discounts, special terms, and bundled services so revenue is not mistaken for a clean pricing signal.
    5. Deliver with high-touch support. Observe the real workflow, perform uncertain steps manually, capture edge cases, and write down each intervention. Manual delivery is productive when it creates reusable knowledge.
    6. Classify what you learned. Recurring, core, and deterministic work should move toward the product. Bounded variation can become an implementation or support playbook. One-off work that does not strengthen the core should be declined or priced and managed separately.

    This is the practical meaning of doing the job before automating it. The objective is not to build a permanent services layer around an immature product. It is to see enough of the workflow to distinguish the stable system from its edge cases.

    White-glove support can remain a strategic learning channel until three things are true: the top five pain patterns are becoming repeatable, there is a clear route to tooling or self-service, and customer feedback reaches the product team quickly enough to change the default experience. High-touch delivery is not inherently unscalable. Unclassified manual work is.

    Keep a one-page record for every account. Capture the ICP evidence, triggering event, buyer, promised outcome, commercial exceptions, activation milestones, manual interventions, realized result, and renewal or expansion signal. At the end of the cohort, compare the records side by side. The repeated pattern matters more than the most enthusiastic anecdote.

    The cohort review should end with a decision. Narrow the ICP, focus the product, revise the value narrative, change packaging, repair onboarding, or reject the hypothesis. If the review ends with a longer list of features but no changed assumption, the learning loop is incomplete.

    Measure fit with revenue, engagement, and value

    Revenue alone can reflect founder skill, heavy services, or favorable terms. Usage alone can reflect curiosity or a useful tool that is not important enough to fund. A compelling customer outcome can still fail commercially if activation, packaging, or distribution is too difficult. Product-market fit becomes more credible when revenue, engagement, and value strengthen together.

    SignalQuestion it answersUseful evidenceDecision it should inform
    RevenueWill this customer pay, remain, and expand?Pilot-to-paid conversion, logo retention, Net Revenue Retention, and expansionWhether pricing, packaging, qualification, and the commercial motion are working
    EngagementDoes the product become part of the intended workflow?Time to first value, activation milestones, and depth, frequency, and breadth of usageWhether onboarding and the core product path are becoming easier to complete
    ValueDoes usage create the result the buyer expected?Customer-specific outcomes such as cost savings, yield improvement, or risk reductionWhether the product solves a problem important enough to sustain demand

    Choose three to five REV metrics for each lifecycle stage, ensuring the set covers revenue, engagement, and value. Define thresholds by cohort and by the natural cadence of the workflow. A low-frequency process should not be judged by a daily-use standard. The relevant question is whether the intended workflow is completed when the need occurs and whether that completion produces the promised result.

    Do not blend every customer into one company average. A mature core segment can hide a weak new cohort, while a large expansion can disguise poor pilot conversion. Compare like with like and examine the movement between cohorts. You are looking for a product that becomes easier to sell, faster to adopt, and more valuable without increasing the exceptional effort around each account.

    The shape of the REV score tells you where to invest next:

    • Engagement and value are strong, but revenue is weak: Investigate pricing, packaging, qualification, and sales enablement before adding product breadth.
    • Revenue is strong, but engagement lags: Pause segment expansion and fix onboarding, the first-value moment, and the core workflow. Contract value does not compensate for a product customers fail to adopt.
    • Engagement is strong, but value is unproven: Instrument the business result and return to the economic buyer. Frequent activity is not automatically meaningful impact.
    • Value exists only after extensive manual intervention: Decide which interventions can become product defaults, repeatable services, or disqualifiers. Do not hide them inside a blended margin or implementation number.
    • All three signals improve across comparable cohorts: The motion is a candidate for transfer and controlled scaling.

    REV should function as a lifecycle diagnostic, not a badge declaring that product-market fit has been achieved forever. The balance will change as the product, segment, and buying motion mature. What matters is that the scorecard tells you which constraint to address next.

    Pass the transfer test before you scale

    A founder-led motion becomes repeatable when another capable operator can run it from documented choices rather than founder intuition. This does not mean the founder disappears from strategic accounts or stops talking to customers. It means routine progress no longer depends on the founder rescuing qualification, the demo, pricing, implementation, or value proof.

    Build the minimum operating system before adding volume:

    • An ICP with observable qualifiers, disqualifiers, trigger events, users, and economic buyers
    • An outcome narrative tied to the three-frame value storyboard
    • A discovery sequence grounded in the customer’s last real experience of the problem
    • A demo that follows the core value path rather than touring every capability
    • Pricing and packaging boundaries, including the exceptions that require approval
    • Activation and time-to-value milestones visible to product, sales, and customer success
    • An objection and proof library built from actual deals
    • Implementation and support playbooks for the recurring pain patterns
    • Escalation rules that separate a product gap, a service need, and a poor-fit customer
    • A distribution wedge that reliably reaches the defined customer

    Test the system in stages. First, let the operator observe the founder. Next, let the operator lead while the founder remains silent unless an agreed escalation condition appears. Then let the operator run a comparable opportunity without the founder. Start with lower-risk interactions, review the evidence after each stage, and update the system where it fails.

    The location of the failure points to the work. Poor qualification suggests an unclear ICP. A feature-heavy demo suggests weak positioning. Repeated implementation rescue suggests a product or onboarding gap. Inability to prove the result suggests weak value instrumentation. Hiring more sellers addresses capacity; it does not repair any of those problems.

    A scalable go-to-market system does not necessarily mean a larger sales team. For an SMB or product-led motion, distribution may compound through integrations, partner ecosystems, search, lifecycle communication, or in-product discovery. Apply the same test: can the channel repeatedly reach the intended customer, set the right expectation, activate the core workflow, and produce healthy REV signals?

    Treat every new segment as another fit search

    Repeatability in one segment does not automatically transfer to another. A move from smaller customers to larger organizations can change the buyer, urgency, security requirements, implementation path, sales process, value metric, and support model. Treat the expansion as a new product-market-fit hypothesis rather than an extra filter in the existing funnel.

    Give the adjacent segment its own ICP, storyboard, cohort, and REV thresholds. Protect the working core while the new motion is uncertain. A 70/20/10 portfolio split can be a useful starting constraint: roughly 70% of capacity hardens the core, 20% tests adjacent growth, and 10% explores longer-term bets. It is not a universal law, but it forces the cost of expansion into the open.

    Keep the roadmaps separate until the evidence shows that the same capability can serve both segments without weakening the core. Interest from a prestigious logo is not proof. Neither is a contract held together by custom implementation.

    Use the same restraint with category creation. New category language is warranted when existing labels constrain the value story, the product reliably produces a distinct outcome, and customers begin using the language without prompting. Before those signals appear, inventing a category adds an education problem to an unresolved fit problem.

    Key takeaways

    • Founder-won revenue is traction. Repeatable fit requires the same kind of customer to buy, activate, realize value, and remain without bespoke rescue.
    • Define the unit of repetition as a specific customer, painful workflow, triggering event, promised outcome, core product path, and boundary.
    • Use early accounts as controlled learning cohorts. Price early, observe the real workflow, and classify every manual intervention.
    • Measure revenue, engagement, and value together. The combination explains whether the constraint is commercial, behavioral, or tied to customer outcomes.
    • Transfer the motion in stages before adding volume. A new hire can absorb capacity only after the underlying decisions are legible.
    • Treat every segment expansion as a fresh fit search, with its own cohort and evidence, while protecting the proven core.

    Your next two weeks should produce evidence, not a larger funnel. Storyboard the core value journey, choose three to five REV measures for each relevant lifecycle stage, group current customers into comparable cohorts, and mark every commercial exception and manual intervention. Then run a cohort review and make one decision: narrow the ICP, focus the product, change packaging, repair onboarding, or transfer a repeatable step.

    If the evidence cannot support one of those decisions, the answer is not more scale. Keep the founder inside the learning loop until the motion is clear enough to teach, measure, and repeat.

    References

    • Shivam.Consulting Blog – Mastering Product-Market Fit with the REV Model: My Battle-Tested Category Playbook
    • Shivam.Consulting Blog – How a 3-Time Founding Team at Pilot Unlocked Product-Market Fit Faster – My Proven Playbook
    • Shivam.Consulting Blog – Pulling Off the Zoom-In Pivot: Luminai’s Kesava on Focus, Sales Psychology, and Product-Market Fit
    • Shivam.Consulting Blog – How I Repeatedly Find Product-Market Fit: Shippo-Inspired Playbook for Bold Product Leaders
    • Shivam.Consulting Blog – Building Zapier by First Principles: Hard-Won Growth, Distribution, and Hiring Lessons
    • Shivam.Consulting Blog – Intuition, White-Glove Support, and Relentless Execution: Lessons from Looker to Omni
  • Open-Source Commercialization: A Developer-Led Playbook

    Open-Source Commercialization: A Developer-Led Playbook

    Your repository is gaining adoption. Developers are asking for integrations, while larger companies want security reviews, support, and a managed option. The tempting response is to pick an enterprise feature, hide it behind a paywall, and call that a business model. That can just as easily weaken the adoption engine you are trying to monetize.

    Your real job is to preserve the low-friction path that developers value while charging for the new burdens that appear when usage becomes organizational: operating infrastructure, governing access, satisfying compliance requirements, guaranteeing reliability, and supporting critical workloads. The boundary between those two experiences determines whether developer adoption compounds into revenue or stalls in mistrust.

    Choose the commercial promise before choosing paid features

    Open source, a managed cloud, and an enterprise edition are not merely three packages of the same software. Each makes a different promise.

    • An open-source project gives developers autonomy. They can inspect it, run it, extend it, and decide whether it deserves a place in their stack.
    • A managed service takes operational responsibility away from the customer. The customer pays to avoid provisioning, upgrades, scaling work, multi-tenant reliability problems, and routine maintenance.
    • An enterprise offering helps an organization control risk. The buyer pays for identity, governance, compliance, support, and predictable operation across teams.

    These promises can coexist, but you should not blur them. If customers mainly want you to operate the software, a hosted product is the natural commercial surface. If they can operate it but need policy controls and contractual assurance, an enterprise package is more coherent. If value and cost both rise with workload, consumption pricing may fit better than a fixed feature tier.

    Start with a short commercialization brief. It should answer the following questions before anyone debates individual paywalls:

    1. What useful outcome must a developer be able to reach without paying?
    2. Which responsibilities become materially harder when the product moves from an individual project to a production system?
    3. Who feels that difficulty: the developer, platform team, security team, procurement function, or executive owner?
    4. Is the customer paying for software capability, transferred operations, reduced risk, or guaranteed service?
    5. Can a successful community user move to the paid product without rebuilding the implementation?

    The first answer is your community promise. Protect it. The second through fourth answers reveal the commercial job. The last answer tests whether you have a growth path or merely two products that happen to share a name.

    Write the boundary down and make ownership explicit. A visible open-core stewardship model can make decisions easier to inspect: contributors can see what belongs in the shared foundation, customers can understand what they are buying, and product teams have a durable standard for future packaging debates.

    Licensing requires separate care. Open core is a commercial architecture, not a license, and changing package boundaries does not automatically change rights granted under earlier releases. Before relicensing code, moving contributed work into a proprietary edition, or changing contributor terms, use qualified open-source legal counsel. A product decision is not a substitute for a license review.

    Put the paywall where organizational complexity begins

    A durable paywall usually appears where the beneficiary changes. The foundational workflow benefits every developer and drives distribution. Governance, compliance, managed operation, and contractual reliability primarily benefit organizations with larger systems and more downside risk.

    That gives you a practical starting map:

    Customer jobLikely commercial surfaceWhat should remain intactEvidence to seek
    Run the core workflow independentlyOpen-source projectA complete, credible path to the product’s foundational valueSuccessful setup, repeated use, extensions, and community participation
    Avoid operating the systemManaged cloud or hosted serviceThe ability to self-manage without deliberate degradationRequests for hosting, upgrades, scaling help, security operations, or migration support
    Control access and prove complianceEnterprise tierThe individual developer workflowRequirements for SSO or SAML, granular role-based access, audit logs, and policy enforcement
    Reduce production and support riskEnterprise tier or support planSelf-service documentation and a usable community experienceRequirements for advanced alerting, longer retention, premium support, or service-level commitments
    Expand a measurable workloadUsage-based or consumption pricingA low-friction entry point and transparent meteringA value metric that grows with customer outcomes and produces a bill the customer can anticipate

    This is a hypothesis map, not a universal feature list. SSO, audit logs, retention, and support can be sensible enterprise fences because they serve organizational control. They are poor fences when withholding them makes the foundational product unsafe or unusable for the very community responsible for its adoption.

    Run every proposed paywall through five tests:

    1. Beneficiary test: Does the capability mainly help an individual do the core job, or help an organization govern many people and systems?
    2. Burden test: Does delivering it create meaningful infrastructure, reliability, security, or support responsibility for your company?
    3. Value test: Can the customer explain the operational cost, risk, or delay the capability removes?
    4. Trust test: Will a reasonable maintainer see the boundary as funding a stronger ecosystem, or as weakening the open product to manufacture conversion?
    5. Migration test: Can users upgrade without changing their architecture, redoing configuration, or losing state?

    If a feature fails the beneficiary or trust test, keep it open unless you have unusually strong contrary evidence. If it passes the burden and value tests, it is a stronger hosted or enterprise candidate. If migration fails, fix that before increasing acquisition. More adoption will otherwise create more stranded users, not more qualified demand.

    Only then should you select a pricing structure. A good, better, best model works when customers progress through qualitatively different needs, such as collaboration, governance, and enterprise assurance. Usage-based pricing works when consumption is measurable, understandable, and connected to value. Outcome-based pricing requires an outcome that both sides can define and attribute; without that clarity, it turns normal product variance into a billing dispute.

    Use the customer, competition, and company lens to pressure-test the result. Customer analysis tells you which outcome deserves a budget. Competition includes the do-it-yourself alternative, not just commercial vendors. Company analysis tells you whether the price can support the infrastructure, security, support, and go-to-market obligations attached to the promise.

    Willingness-to-pay work should test decisions, not compliments. Ask prospective buyers to compare real package boundaries, identify what they could approve, and explain what would block procurement. A positive answer to a vague question about paying someday is not pricing evidence. A buyer choosing between concrete offers and naming the approval path is much closer to it.

    Turn developer adoption into a designed growth loop

    Free availability is not developer-led growth. A project grows commercially only when developers reach value, return, bring the product into a team, and encounter a paid path that solves the next problem without undoing their earlier work.

    Design that journey as a sequence of observable transitions:

    1. Discovery: A developer finds a credible example, integration, technical explanation, or community recommendation that matches a current problem.
    2. First value: The developer completes the core workflow with sensible defaults and without needing a meeting.
    3. Repeated value: The product becomes part of an actual development or production routine rather than a one-time experiment.
    4. Team adoption: Configuration, projects, dashboards, workflows, or operational responsibility begin to span more people.
    5. Organizational need: Security, governance, reliability, procurement, or managed-operation requirements emerge.
    6. Upgrade: The team moves to the commercial offer while preserving its implementation, knowledge, and momentum.

    For each transition, write the obstacle that can prevent it and the product response that removes that obstacle. Discovery may fail because the positioning is broad and the documentation does not name a concrete job. First value may fail because setup exposes infrastructure decisions before the user has seen the benefit. Team adoption may fail because permissions and shared workflows were added as afterthoughts. Upgrade may fail because the cloud product requires a new configuration model.

    Your activation definition should describe achieved value, not administrative activity. Creating an account, starring a repository, cloning code, or downloading a package proves interest. It does not prove that the product worked. Define the first meaningful result for your product and instrument that event wherever users have consented to telemetry.

    Then simplify the path to that result. Give the user a strong default. Defer optional configuration. Provide a working example that can be changed after it succeeds. Make error messages point to the next corrective action. Treat documentation, command-line output, sample projects, and migration tooling as parts of the product rather than promotional material around it.

    The proof moment depends on the product. It might be a successful deployment, a populated dashboard, a completed pipeline, or a policy enforced against a real resource. Whatever it is, make that moment fast, visible, and repeatable. Developers tolerate depth once they trust the result; complexity before proof merely consumes goodwill.

    Developer evangelism should reinforce this loop. Its job is to teach useful patterns, reveal friction, and give technical users a credible path into the community. Treating every interaction as lead capture damages that role. Product and go-to-market teams still need feedback, but they should earn it through useful documentation, transparent communication, responsive community work, and clear consent.

    The commercial transition deserves the same product discipline as onboarding. Show what changes when a team upgrades. Preserve configuration and integrations. Explain the usage metric before a bill arrives. Provide migration validation or a preview when the move carries operational risk. If a solutions engineer must manually reconstruct every deployment, you have a services dependency rather than a scalable upgrade path.

    Measure the handoff and add GTM capacity in sequence

    Repository stars, package downloads, community membership, and documentation traffic are useful reach indicators. None of them, alone, tells you whether users activated, retained, or developed a reason to buy. Keep reach separate from product value and commercial intent.

    A workable scorecard follows the user’s progression:

    • Reach: Which channels bring developers with the problem your product actually solves?
    • Activation: What share of observable new users reaches the first meaningful result?
    • Retention: Do activated users repeat the core workflow or continue operating real workloads?
    • Team adoption: Does use expand into shared projects, environments, workflows, or operational ownership?
    • Commercial intent: Are users exploring hosting, migration, security documentation, governance controls, support, or service commitments?
    • Revenue quality: Do paid customers retain usage, expand for understandable reasons, and continue receiving value from the metric you charge against?

    Self-managed open source creates an unavoidable visibility gap. Do not fill that gap by pretending public activity equals product usage or by collecting invasive telemetry. Use opt-in product signals, cloud behavior, support requests, community conversations, version adoption, and direct customer discovery as different pieces of evidence. Keep the limits of each signal visible in the dashboard.

    Sales assistance should begin when customer complexity appears, not merely when a developer downloads the product. Stronger triggers include a request to migrate a production workload, satisfy security review, coordinate several teams, obtain contractual support, implement access governance, or model a substantial managed deployment. Those signals give sales and solutions teams a real problem to solve.

    The go-to-market organization should grow in the same order as the bottlenecks:

    1. When the bottleneck is adoption, invest in product experience, documentation, onboarding, community, and developer evangelism. Adding sellers cannot compensate for a developer path that does not reach value.
    2. When the bottleneck is technical evaluation or migration, add sales-assist, solutions engineering, and forward deployed engineering. Their purpose is to resolve complex implementation risk and return patterns to the product team.
    3. When the bottleneck is repeatability and expansion, add customer success, pricing operations, and ecosystem partnerships. Their purpose is to make value delivery, billing, retention, and adjacent distribution systematic.

    Keep one feedback loop across those functions. At a fixed operating cadence, review the largest activation obstacle, the most frequent scale or governance request, failed migrations, paywall exceptions, and the reasons paid customers did not expand. Assign a single owner to each decision, then record the community promise, target buyer, evidence, value metric, migration effect, and trust risk.

    This decision log prevents the commercial boundary from becoming a collection of historical accidents. It also gives product leaders a way to revisit assumptions without reopening every philosophical argument about open source. New evidence can change a package; the underlying decision standard should remain stable.

    Key takeaways

    • Define the community promise before selecting anything to monetize. The free product must deliver a complete foundational outcome.
    • Choose a hosted offer when customers want operational responsibility transferred to you; choose enterprise packaging when they need governance, compliance, control, or assurance.
    • Gate capabilities at the point where organizational complexity begins, not at an arbitrary point in the developer’s first-value journey.
    • Use pricing tiers for qualitatively different needs and consumption pricing only when the usage metric is measurable, valuable, and predictable.
    • Measure activation, retention, team adoption, and commercial intent separately from public reach indicators.
    • Add developer education, technical sales assistance, customer success, and pricing operations as their corresponding bottlenecks emerge.

    Start with one production workflow. Mark what must remain open for a developer to succeed, what operational responsibility a hosted service could absorb, and what organizational risk an enterprise tier could reduce. Validate the paid side with the people who own those burdens before moving code or setting prices.

    If maintainers cannot explain why the boundary is fair and buyers cannot explain why the paid offer is valuable, the model is not ready. When both explanations are clear, commercialization stops being a tax on adoption and becomes the mechanism that helps adoption survive at scale.

    References

    • Shivam.Consulting Blog – Open-Source GTM Masterclass: Pricing, Packaging, and Paywalls with Grafana Labs’ COO
    • Shivam.Consulting Blog – Open Source to Revenue: How GitLab Scales Transparency, Community, and Enterprise Growth
    • Shivam.Consulting Blog – How Radical Simplification Drove Vercel’s Product-Market Fit: Lessons for PMs and Founders
    • GitLab – Stewardship and open core business model
  • Goal-Setting for AI Products: How I Plan, Prioritize, and Confidently Ship in a Nonlinear GenAI World

    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.

    Book a consult png image
  • Engineering Leadership That Scales: Strategy, Velocity, and Org Design from Carta, Stripe, Uber, Calm

    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
    Book a consult png image
  • Inside Bard’s Playbook: How to Ship AI Fast, Build Ethically, and Outlearn Competitors

    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.
    Book a consult png image