Tag: outcomes vs output OKRs

  • The Human Side of Engineering Leadership: Practical Plays to Build Creative, High-Performing Teams

    The Human Side of Engineering Leadership: Practical Plays to Build Creative, High-Performing Teams

    Engineering leadership is a human sport first and a technical sport second. The longer I lead product and engineering teams, the more convinced I am that world-class execution comes from clarity, trust, and an environment designed for deep work — not just clever architectures or more process. In my role leading product, I see the biggest unlocks happen when we combine operational excellence with empathy and purpose.

    My “utopia” — where engineers have time to create and invent — starts with sacred focus time. I protect no-meeting blocks, design sprints that include exploration, and carve out recurring capacity for prototypes and technical debt. When builders know they have sanctioned space to think, we get more product discovery, better ideas, and fewer last-minute heroics.

    Shipping software at scale is difficult, and it’s harder to ship today than ever before. Complexity from microservices, compliance, security, platform fragmentation, and AI-driven surface area expands every quarter. The counter is operational hygiene: clear ownership, ruthless scope, a predictable release cadence, excellent tooling, and a culture that values outcomes over activity.

    What makes a startup operationally sound is surprisingly simple to describe and hard to do consistently. Define decision rights, keep teams small and mission-aligned, instrument everything, and ship on a reliable train. Feature flags, dark launches, automated testing, and crisp rollbacks turn risk into routine. Most importantly, we write things down — intents, constraints, and success metrics — so execution scales beyond any single leader.

    Product managers can dramatically improve engineering culture. The fastest way is through precision: sharp problem statements, explicit success metrics, clear acceptance criteria, and honest trade-offs. I hold our team to “outcomes vs output OKRs,” framing goals by customer and business value rather than task volume. PMs should also shield makers from thrash, resolve ambiguity quickly, and bring real users into the room early and often.

    From an engineer’s perspective, good product management sounds like respect for the craft. We acknowledge performance budgets, technical constraints, and the hidden cost of complexity. We ask for estimates responsibly, show our work in decision docs, and make room for forward deployed engineers to close the loop with customers. When PMs consistently do these things, trust grows — so does velocity.

    The role of product compared to design and engineering is easy to state and easy to forget: product owns the why and what, design owns how it feels, engineering owns how it works, and all three own the outcome. I treat the PM job as system optimization across functions — removing friction, sequencing bets, and maximizing learning per unit of time. When incentives are aligned to shared outcomes, handoffs turn into collaboration.

    Micromanagement kills creativity. Declarative versus prescriptive leadership is the antidote: set the intent, define the constraints, agree on the measures of success — then get out of the way. I replace step-by-step tickets with a one-page brief and a weekly demo cadence. Guardrails create safety; autonomy creates ownership; together they create better software.

    I foster a debate culture by making disagreement safe and productive. We write RFCs, invite dissent, time-box decisions, and “disagree and commit” when the window closes. Good debates chew on assumptions, not people. The payoff is compounding judgment and a team that can argue well without leaving scars.

    Three leadership ideas I practice every week: first, default to clarity — ambiguity is the silent killer of execution. Second, manage energy, not just time — sustain the team’s battery with realistic pacing and visible wins. Third, train judgment — distinguish one-way doors from two-way doors and match decision speed to reversibility.

    Understanding employee motivation is a superpower. People move for different reasons — mastery, autonomy, purpose, progression, compensation, recognition. I map motivations explicitly in 1:1s and shape work accordingly. When someone’s day-to-day aligns with what they value most, performance and retention both rise.

    My advice on discovering what motivates people is straightforward: ask better questions and observe the work. I love asking, “What feels like play to you but looks like work to others?” I rotate responsibilities to run small experiments, then codify what sticks in growth plans. Motivation is dynamic; treat it like a product you’re constantly rediscovering.

    On org design, I review team topology every six months. Strategy changes and customer needs evolve; our organization should, too. I favor lightweight reorgs — adjusting missions and interfaces rather than wholesale reshuffles — and I use rotations to refresh learning without destabilizing roadmaps. The aim is responsiveness without chaos.

    One habit I see in successful leaders is relentless focus on outcomes. We inspect impact, not activity, using transparent scorecards, weekly business reviews, and OKR hygiene that spotlights real progress. When outcomes are the north star, prioritization becomes sane and teams feel meaning in their work.

    Sound judgment is crucial for decision-making. I separate reversible from irreversible choices, run pre-mortems, and keep a decision log so we can learn at the portfolio level. Informed speed beats perfect slow, and fast follow-ups are a feature, not a bug.

    Crystallized lessons from large-scale software environments keep proving true: cadence beats heroics, observability pays for itself, and investment in developer experience is the highest-ROI platform bet you can make. Also, write it down — clear artifacts are how complex systems learn together.

    I stay wary of becoming irrelevant. The antidote is shipping, curiosity, and deliberate learning — talking to customers weekly, pairing with engineers, and letting junior talent teach me new tools and patterns. Relevance is earned every quarter.

    If I had to pick one leadership lesson, it’s this: people remember how you made them feel. Trust, candor, and consistency create the conditions for excellence. The best strategy in the world won’t move if people don’t feel seen, safe, and challenged.

    I’ve changed my mind on a few big things: more documentation beats more meetings, hybrid can outperform in-office with the right rituals, and smaller, more frequent reorganizations are better than large, rare ones. I used to think speed and quality were a trade-off; now I think clarity gives you both.

    My growth has been shaped by thoughtful operators, designers, and engineers who taught me to balance ambition with stewardship. Their fingerprints are on these practices, and my teams’ results are better for it. The human side of engineering leadership isn’t soft — it’s the hard edge that makes everything else work.


    Book a consult png image
  • Customer Success Masterclass: How I Design, Build, and Scale a World‑Class CS Org

    Customer Success Masterclass: How I Design, Build, and Scale a World‑Class CS Org

    Customer success is not a department I bolt on after product-market fit — it’s a strategic engine I design in parallel with product, sales, and support. In my role as VP of Product Management at HighLevel, I’ve learned that the fastest way to accelerate growth is to operationalize value delivery, from onboarding to renewal. In this masterclass-style breakdown, I share how I formalize customer success in early-stage companies, the hiring and compensation tactics that actually work, and the metrics and rituals that keep teams focused on outcomes.

    When I formalize customer success at a startup, I start small and intentional. The goal of v1 isn’t scale — it’s clarity. I define the core moments that matter (onboarding, time-to-first-value, activation, expansion), codify the handoffs with sales and product, and set outcomes vs output OKRs so the team is measured on customer impact, not activity. Only once I can consistently predict value delivery do I introduce more specialization and automation.

    Early hiring order matters. I typically hire ICs before building out a full CSM layer. Think implementation managers, solutions consultants, and forward-deployed problem solvers who can translate ambiguous customer needs into product-anchored outcomes. These folks create the playbooks and close the “last mile” between product capabilities and customer workflows — a prerequisite to scaling a durable CS org.

    My tactics for hiring standout talent are simple and disciplined. I source for learning athletes who show a bias for action and executive presence, not just a customer-facing resume. I run structured interviews and working sessions that simulate real problems. Three questions anchor my evaluation: 1) Tell me about a customer who was at risk — how did you quantify the risk and what did you do? 2) Describe a time when you influenced product direction using customer evidence — what changed? 3) Walk me through a renewal or expansion you orchestrated — what was your strategy, and how did you align incentives across sales, product, and CS?

    Fail-case patterns are consistent across stages. The most common are: reactive firefighting instead of proactive planning, weak business acumen (can’t tie product usage to business value), and poor cross-functional muscle (inability to influence product, marketing, and sales). I avoid these by probing for data fluency, systems thinking, and evidence of repeatable playbooks — not one-off heroics.

    I actively consider candidates with non-traditional backgrounds. Teachers, analysts, management consultants, and product-adjacent operators often outperform because they are structured thinkers, exceptional communicators, and relentless about outcomes. I assess them through scenario work and mentorship plans that accelerate domain onboarding.

    I index hard toward a bias for action. In interviews and trial projects, I look for people who quickly form hypotheses, validate with customers, and ship iterative solutions. The best CS operators don’t wait for perfect data — they create momentum while instrumenting the learning loops that improve precision over time.

    Here’s what v1 of customer success looks like in my playbook: a crisp onboarding journey with defined exit criteria, a success plan that ties product capabilities to business goals, a lightweight QBR rhythm focused on outcomes, and a clear escalation path for risk. I keep the tooling lean and favor a living playbook over ornate process — speed and clarity beat bureaucracy.

    Key early-stage customer success metrics include adoption and depth of feature usage, time-to-first-value, product-qualified accounts, renewal intent, gross and net revenue retention, and engagement signals from executives and power users. I complement the numbers with disciplined rituals: weekly risk reviews, a win/loss “value realization” debrief, and a Voice of Customer readout that feeds directly into product discovery.

    Should customer success or sales own renewals? My answer: align ownership to your business model. If your product is value-expansive with complex deployments, CS should co-own or own renewals to manage risk and value realization. If your motion is highly transactional or heavily quota-driven, sales can own the paper while CS owns the health and expansion signals. What matters most is a single, unambiguous source of truth for renewal accountability.

    Where customer success fits into the org depends on stage and strategy. Early on, I advocate for a direct line of sight to the executive team and tight integration with product and sales. As the company scales, I ensure comp plans, OKRs, and planning cadences keep incentives aligned across functions. Misalignment between CS and sales (especially on expansion vs retention) is one of the fastest ways to erode customer trust.

    To distinguish a product problem from a customer success one, I ask: is the failure one-to-many and reproducible (product), or one-to-few and context-specific (CS and onboarding)? If multiple segments show the same friction, I escalate to product with evidence: cohort analysis, user journeys, and a prioritized hypothesis backlog. If the issue is account-specific, I focus on enablement, configuration, and stakeholder alignment.

    There’s a simple way to reduce churn: make value realization explicit and measurable from day one. Define what “success” means with the customer, instrument usage and outcomes, review progress in standing rituals, and intervene early when leading indicators fall. A proactive executive sponsor program — including direct outreach from product leadership on at-risk accounts — can be a force multiplier.

    To get honest feedback, I decouple discovery from renewal cycles, use third-party or product-led surveys, and create safe, structured avenues for critique (e.g., advisory councils with clear rules of engagement). I also return the favor: close the loop on what we learned, what we shipped, and what we’re shelving — customers reward transparency with candor.

    When customer success and product teams collaborate well, the whole system accelerates. Product discovery gets sharper, roadmaps reflect real-world value drivers, and launch readiness improves because CS has co-authored the enablement and rollout plan. I treat CS as a core input to product discovery, not just a downstream implementer.

    Structuring an early CS team is about coverage and clarity. I start with a player-coach leader and a few high-caliber ICs, define segmentation and ratios (e.g., enterprise vs scaled), and standardize handoffs with sales and support. As signals stabilize, I layer in specialization: implementations, technical success, renewals management, and scaled programs for long-tail accounts.

    For compensation packages, I align variable pay to controllable, outcome-centric metrics: gross retention for core CSMs, net retention for expansion-focused roles, implementation milestones for onboarding teams, and shared targets with sales when collaboration is essential. I avoid activity-based comp and use tiered accelerators to reward durable, high-quality results.

    Aligning customer success with the business model is non-negotiable. In a low-touch, product-led motion, I invest in scaled programs, education, and in-product guidance. In complex B2B software, I prioritize executive alignment, value engineering, and strategic QBRs that map product adoption to business outcomes. The throughline is the same: prove ROI, relentlessly.

    In B2B software, the role of customer success is to operationalize value realization. That means orchestrating people, product, and process so customers achieve their outcomes faster, renew with confidence, and expand because the value is undeniable. When done right, CS transforms from “post-sales support” into a revenue-creating, product-sharpening discipline.

    Common customer success mistakes I see repeatedly include spinning up process before purpose, underinvesting in onboarding, confusing relationship management with executive influence, burying CS under misaligned incentives, and measuring output instead of outcomes. Avoid these, and you’ll build a world-class customer success org that scales with conviction.

    Referenced: Aaron Levie: https://www.linkedin.com/in/boxaaron/, Box: https://www.box.com/, David Love: https://www.linkedin.com/in/david-s-love/, Gainsight: https://www.gainsight.com/, Jon Herstein: https://www.linkedin.com/in/jonherstein/, Jonathan Lister: https://www.linkedin.com/in/jonathanlister/, Ken Fine: https://www.linkedin.com/in/kmfine/, Medallia: https://www.medallia.com/, Nick Mehta: https://www.linkedin.com/in/nickmehta/, Opower: https://www.oracle.com/utilities/opower-energy-efficiency/


    Book a consult png image
  • How to Find Your Product Wedge: Battle‑Tested SMB SaaS Lessons from Square, Gusto, and My Playbook

    How to Find Your Product Wedge: Battle‑Tested SMB SaaS Lessons from Square, Gusto, and My Playbook

    Every enduring platform I admire started with a sharp product wedge—an unmistakably form‑fitting solution to a painful, persistent problem. In my own work leading product teams, I’ve seen how a great wedge unlocks momentum, trust, and distribution long before you earn the right to build horizontally. In this piece, I break down what I’ve learned from studying companies like Square and Gusto, and share the practical playbooks I use to find wedges, scale them, and turn them into platforms.

    SMBs require unique software solutions because their constraints are different: time is scarce, tasks are juggled by a small team, and workflows span both the front of house and the back office. What wins is software that collapses steps, automates compliance, and delivers clear ROI in hours—not quarters. If you can’t demonstrate immediate utility and reduce cognitive load, you won’t earn a second week of usage, let alone loyalty.

    The level of specificity required when building for SMBs is higher than many expect. “Form‑fitting” isn’t just a metaphor—it’s the difference between adoption and abandonment. In practice, that means obsessing over the exact moments of friction: where data gets retyped, where the cash drawer doesn’t reconcile, where payroll rules create anxiety. The fastest way to a wedge is to remove a choke point so completely that your product becomes the default way of working.

    Building vertical versus horizontal SaaS is a strategic fork in the road. Verticals can win by encoding industry nuance (menus, wage rules, inventory, tip pooling), which drives faster adoption but narrows TAM and increases service intensity. Horizontal suites maximize TAM but risk feeling generic until they’ve earned trust. The play is often sequential: tight wedge first, then carefully adjacent expansions that preserve the original fit while compounding value.

    Inside strong product orgs, decision‑making frameworks make that sequencing explicit. I lean on outcomes vs output OKRs to clarify what must improve for customers, not just what we plan to ship. I pair that with crisp guardrails—who we are building for, what problems we solve end‑to‑end, and what we intentionally ignore—for speed and focus. When everyone knows the game we’re playing, we can move faster with fewer meetings.

    How to build horizontally from a wedge product: start by mapping the “jobs” that cluster around your wedge and identify which are triggered before, during, or after your core workflow. Expand into the nearest job that either (1) eliminates a costly handoff, (2) compounds your data advantage, or (3) increases switching costs without increasing complexity. Sequence matters; stitch together two workflows perfectly before you add a third.

    I use The Three Horizons Model to balance the portfolio. Horizon 1 protects and grows the wedge with relentless quality and speed. Horizon 2 extends into adjacencies that deepen customer value and LTV. Horizon 3 explores new bets with asymmetric upside. The discipline is to time‑box and stage‑gate Horizon 3, so you develop options without starving the core or confusing the narrative.

    Crafting a compelling vision for products means painting a clear picture of the world customers want—and the shortest believable path to get there. The vision should connect the wedge to a future platform, but every waypoint must feel pragmatic. When assessing Horizon 3 bets, I look for early signs of inevitability (regulatory tailwinds, data scale effects, platform shifts) and a credible edge we uniquely possess.

    To give product teams the freedom to try things, I design for speed with safety: small, API‑first modules, toggled rollouts, and success metrics agreed upon upfront. Creating a risk‑taking culture isn’t about celebrating risk; it’s about celebrating validated learning. Make it cheap to run thoughtful experiments and easy to kill what doesn’t work.

    Developing good product sense and intuition takes deliberate practice. I treat it like athletic ability: you can’t outsource reps. The fastest builders I know run weekly customer conversations, share raw call notes, and practice “storyboarding” real workflows until they can spot friction on sight. Five signs of great product sense: you predict failure modes before launch, you simplify scope without losing the magic, you can articulate the must‑have moment, you measure what matters, and you know when to say “not yet.”

    Shipping faster without increasing headcount comes from better constraints, not heroics. I favor fewer, larger bets; pre‑wired cross‑functional pods; ruthless de‑scoping to the must‑have moment; and a zero‑tolerance policy for work that doesn’t move a core metric. Shorten the distance from insight to production, and speed shows up everywhere.

    Generative AI is reshaping product discovery and prototyping. Tools like Copilot are accelerating content generation, scaffolding, and testable flows, which lets teams validate value propositions earlier and with more fidelity. I use gen AI for product prototyping to pressure‑test onboarding copy, simulate edge cases, and explore variations that would have taken weeks to mock by hand.

    If you’re building for SMBs today, choose a wedge you can dominate, prove undeniable value fast, and then expand deliberately—one adjacent workflow at a time. The companies we admire didn’t skip steps; they sequenced them with conviction.

    References and resources worth exploring:

    Alyssa Henry: https://www.linkedin.com/in/alyssa-henry-0905692/

    Copilot: https://copilot.microsoft.com/

    Gokul Rajaram: https://www.linkedin.com/in/gokulrajaram1/

    Gusto: https://gusto.com/

    High Output Management: https://amazon.com/High-Output-Management-Andrew-Grove/dp/0679762884

    Marty Cagan: https://www.linkedin.com/in/cagan/

    Opendoor: https://www.opendoor.com/

    Silicon Valley Product Group: https://www.svpg.com/

    Square: https://squareup.com/

    The Three Horizons Model: https://www.mckinsey.com/enduring-ideas-the-three-horizons-of-growth

    Toast: https://pos.toasttab.com/


    Book a consult png image
  • Scaling Enterprise AI That Sells: Battle-Tested Playbooks for PMF, Champions, and Agentic AI

    Scaling Enterprise AI That Sells: Battle-Tested Playbooks for PMF, Champions, and Agentic AI

    Enterprise AI is exhilarating and unforgiving. I’ve seen gorgeous demos fall apart under real-world constraints and seemingly modest pilots unlock outsized value at scale. In this reflection, I share the playbooks I rely on to build, scale, and sell generative AI in the enterprise—what actually moves deals, secures product-market fit, and sustains trust with the C-suite and the front line.

    Why is it so difficult to scale AI products for enterprise? Because the bar is higher on every dimension: data governance, security, extensibility, integration depth, reliability, and measurable ROI. An enterprise-grade, full-stack generative AI platform isn’t just a model; it’s the surrounding system—observability, evals, policy, workflow, and human-in-the-loop—that makes outcomes predictable, auditable, and safe. The fastest path to adoption is simple: deliver on-brand, on-policy content and decisions using a customer’s first-party data, and prove that quality holds up under load.

    My north star is dependability over demo magic. The number one challenge is making model output dependable across messy, high-variance enterprise inputs. I build an evaluation harness early, with gold datasets, task-specific metrics, and human adjudication. Every change ships behind guardrails and is measured against cost, latency, and quality SLOs. When governance, change management, and procurement show up (they always do), I treat them like first-class product requirements, not hurdles.

    Champions are the secret to winning complex accounts. I map the org, find operators who feel the pain daily, and quantify that pain in dollars and hours. Then I define success criteria upfront—time-to-value in under 30 days, measurable uplift (e.g., deflection, conversion, cycle time), and a plan for scale. I deploy forward deployed engineers alongside the business to co-design workflows, refine prompts and evaluators, and document before/after outcomes. Champions don’t just approve pilots; they co-author the business case and defend it.

    To win the enterprise, trust architecture matters as much as model architecture. I lead with clear answers on data residency, encryption, SSO, RBAC, DLP, and retention policies; I address whether customer data trains models, default behaviors, and opt-in controls. I offer flexible deployment (VPC or private networking when needed), transparent pricing, and SLAs with real teeth. I also integrate where work already happens—CRM, help desk, knowledge bases—so value shows up in the flow of work.

    Signs of healthy product-market fit are unmistakable: pull from lookalike buyers, multi-threaded expansions, champions who present results internally without me in the room, and usage that moves from experimentation to business-critical. I watch for weekly active usage above pilot thresholds, POCs converting to multi-year deals, and adjacent teams (Support, Marketing, Legal, RevOps) asking to onboard with minimal push. PMF feels less like persuasion and more like coordination.

    Scaling large language models for specific use cases requires ruthless focus. I constrain scope to tightly defined workflows, pair retrieval with structured knowledge, and mix model strategies (base models, fine-tunes, tools, and function calling) based on cost and latency budgets. I codify policy-as-code and deploy guardrails at the orchestration layer, not just the model layer. Continuous evaluation—both automatic and human—is the heartbeat of quality.

    My advice to AI founders in 2024 is pragmatic. Start with outcomes, not demos. Establish outcomes vs output OKRs that tie directly to revenue, cost, risk, or customer experience. Use gen AI for product prototyping to shorten discovery cycles, but graduate quickly to instrumented workflows in production. Align early with InfoSec and Legal; your speed will be gated by trust, not code. And when in doubt, ship smaller, safer increments faster.

    Healthy co-founder relationships look the same across winning companies: clear domains, fast escalation, and a shared appetite for “disagree and commit.” I keep a decision log, time-box debates, and make moments-of-truth visible to the team and board. You’ll know it’s working when you have more energy after hard conversations than before.

    The future of agentic AI is deeply enterprise: multi-agent workflows that plan, act, and verify with human oversight where it matters. The winners will combine reasoning, tool use, retrieval, and policy with audit trails that satisfy compliance while keeping velocity high. Think of it as re-engineering business processes around AI-native steps, not sprinkling AI on top of legacy workflows.

    Culture turns strategy into reality. I anchor my teams on “connect, challenge, and own.” Connect means obsess over the customer problem and internal alignment. Challenge means we red-team our ideas, run experiments, and measure impact. Own means we accept outcomes, not just output, and we iterate until the business moves. This is how a customer support ai strategy becomes a durable moat, not a slide.

    If you’re a product creator or product management leader, the above playbooks are meant to be lifted and adapted. Start where the pain is loudest, quantify the win, and let champions carry the story. The compound interest of disciplined product discovery, strong governance, and relentless evaluation is a generative AI business that sells itself—and scales.


    Book a consult png image
  • DevTools at Scale: Hard-Won Lessons on PMF, AI, and Culture from Apple, AWS, Microsoft

    DevTools at Scale: Hard-Won Lessons on PMF, AI, and Culture from Apple, AWS, Microsoft

    Building and scaling DevTools has taught me that world-class culture and relentless product focus are non-negotiable. Drawing on experiences across Amazon, Apple, and Microsoft—and hard-won lessons from startups like Unblocked and Buddybuild—I’m sharing the principles I rely on to ship great developer products at scale.

    Why building for developers is different: developers are discerning, allergic to friction, and quick to churn if the DX isn’t exceptional. That means fast setup, clear docs, ergonomic APIs, sane defaults, and deep integrations with GitHub, GitLab, Bitbucket, Confluence, AWS, and Microsoft Azure.

    I benchmark teams against gold-standard platforms like Stripe, Twilio, and Looker—tools that reward mastery, never bury the lede, and make success observable in minutes, not days.

    From the early days of Buddybuild, the signal was unmistakable: remove toil from CI/CD, shorten feedback loops, and teams will expand usage without a sales nudge. The pattern holds across DevTools: when time-to-value approaches zero, the product sells itself.

    Early signs of product market fit: organic team-to-team adoption, repeatable setup success, contribution from power users, and inbound demand you cannot keep up with. When these show up, “Why great product is everything” stops sounding like a platitude and starts reading like a P&L.

    Monetizing product market fit is straightforward if you align value and pricing units. Seat-based maps to collaboration; usage-based maps to compute, API calls, or storage; hybrid models reduce edge-case friction. Keep the packaging simple and double down on “The power of positioning.”

    AI is complicating product market fit. Gen AI accelerates gen ai for product prototyping, but it also introduces instability: model drift, hallucinations, and evaluation blind spots. I build an evaluation harness, human-in-the-loop review for risky flows, and a clear customer support ai strategy before scaling.

    Being customer-obsessed is the moat. I embed forward deployed engineers with key customers to translate real workflows into product decisions, close the empathy gap, and validate behavior in production environments.

    On decision-making, I blend product discovery with crisp documents and measurable bets: PRFAQs or design docs to clarify intent, guardrails in analytics, and outcomes vs output OKRs to keep teams aligned to impact.

    Unblocked, a developer tool that lets you talk to your codebase, points toward a future where code search, context, and refactoring converge into conversational workflows. I’m bullish on the pattern, but I stay sober about failure modes and cost-to-serve.

    Here’s my cautious take on AI: latency, privacy, and provenance matter as much as model quality. The best teams treat prompts as product, training data as liability, and evaluation as a first-class release gate.

    Hiring is where many teams stumble. Don’t over-index on competency when hiring. I optimize for learning velocity, ownership, and kindness under pressure. Competency scales output; character scales organizations.

    As a second-time founder and operator, I treat mental health like uptime. I schedule recovery, define non-negotiables, and surround myself with peers who normalize the hard days. Burnout is a systems failure, not an individual weakness.

    I don’t do demos. I prefer self-serve trials with instrumented onboarding, sample projects, and guardrails that let the product do the talking. If a prospect can’t succeed in 15 minutes, we fix the product, not the deck.

    On customer feedback, I separate noise from signal with cohorts and context. I prioritize requests that reduce time-to-value, unblock integrations, or meaningfully expand the surface area of successful use cases. That’s how to deal with customer feedback without losing strategic focus.

    To build and scale DevTools, keep the bar high and the loop tight: ship small, watch usage, learn fast. Invest in platform reliability, rock-solid SDKs and CLIs, and a developer experience that earns trust release after release.

    Resources and touchstones I revisit often:

    Apple’s acquisition of Buddybuild: https://www.cnbc.com/2018/01/02/apple-agrees-to-buy-buddybuild.html

    AWS: https://aws.amazon.com

    Bitbucket: https://bitbucket.org

    Confluence: https://www.atlassian.com/software/confluence

    GitHub: https://github.com

    GitLab: https://gitlab.com

    Looker: https://looker.com

    Microsoft Azure: https://azure.microsoft.com

    Stewart Butterfield: https://www.linkedin.com/in/butterfield/

    Stripe: https://stripe.com

    Twilio: https://twilio.com

    Unblocked: https://getunblocked.com/

    If you’re building for developers, stay ruthless about simplicity, respectful of their time, and obsessed with proof in production. That’s how durable product-market fit is earned—and monetized.


    Book a consult png image
  • Build Platforms, Not Apps: My Playbook to Delight Customers and Scale Product Strategy

    Build Platforms, Not Apps: My Playbook to Delight Customers and Scale Product Strategy

    I’ve been reflecting on the product lessons behind a career arc that has reshaped multiple industries. Adam Nash is the co-founder and CEO at Daffy, a platform that makes it easier to donate to charities and non-profits. Before Daffy, Adam was the President and CEO at Wealthfront, where he scaled the company’s assets under management from $100M to over $4B. Adam has also held leadership and technical roles at Dropbox, LinkedIn, eBay, and Apple. As a VP of Product Management, I see enduring patterns in these experiences that every product creator can apply. Over the last decade, many teams have felt that the world is less disruptive than expected. In my view, this “slowness” is less about a lack of innovation and more about the compounding dominance of distribution and platform effects. When platforms harden, apps struggle to break through. That’s why I coach my teams to design for platform leverage from day one—assume the game is about ecosystems, not just features—and to build product discovery loops that create new access, not just new interfaces. We’ve also tended to think about luck incorrectly. What looks like luck is often preparation meeting a catalyzing platform moment. The most resilient companies build the capacity to take advantage of inflection points when they arrive—technically, organizationally, and with a clear point of view on where customer value is migrating. This is product management leadership in practice: orchestrating readiness for the inevitable change while staying grounded in outcomes vs output OKRs. Consider how eBay survived the dot com bubble. The lesson I carry forward is simple but powerful: when your core product creates real network utility and trust, shocks can prune the market and strengthen your position. Liquidity, clear incentives, and disciplined execution make a marketplace anti-fragile. I’ve applied this mindset by prioritizing durability over novelty, especially in critical user flows where reliability trumps speed of iteration. Founders should build platforms, not apps. Platforms create compounding advantages: data network effects, extensibility, and a value surface that invites others to build with you. Apps often cap out at feature parity; platforms unlock a persistent widening of the moat. My test: if your roadmap doesn’t include APIs, a partner strategy, and a value-creation flywheel that improves with every user and contributor, you’re likely shipping an app. If it does, you’re on a platform path. What made LinkedIn successful offers a crisp strategy lesson: good company strategy = good product strategy. When the company’s mission, business model, and product bets align around a clear customer job-to-be-done, execution accelerates. Setting strategy isn’t a document; it’s a cascade of decisions that translates into what we ship, how we measure, and which trade-offs we make. In 2009, that meant focusing on the highest-leverage network use cases and aligning metrics with durable member and ecosystem value. Not every great idea finds its market on the first try. Why KaChing didn’t work and pivoting to Wealthfront underscores core product-market fit lessons: you can’t will a market into existence, but you can iterate into it if you listen to customer behavior, not just customer requests. One universal lesson on customer acquisition I’ve seen repeatedly: the most efficient growth happens when the product itself reduces anxiety and increases clarity at the precise moment of decision. That’s why I treat growth like a product problem—friction maps, value timing, and onboarding narratives are as strategic as any feature release. Leadership transitions are inevitable in growing companies. My advice on successful leadership transitions is to plan them early, be explicit about decision rights, and make “how we decide” a visible artifact across the org. How to delegate moral authority is just as critical as delegating operational authority; teams move faster when they understand not only what to do, but why it is the right thing to do for customers and the company. There’s a real problem with metrics and customer requests when they become the only signals that matter. Metrics are rear-view mirrors and customer requests are often local optima. The craft is to synthesize signals into convictions—and then to earn trust by shipping the right things. Apple’s approach to “delighting” customers is a reminder that delight is not random whimsy; it’s a disciplined practice of removing cognitive load and amplifying emotion at key moments. I use the 70/20/10 rule you’ve never heard about to balance roadmaps: 70% on core commitments, 20% on accelerants, 10% on bold, “delight” experiments. How Daffy ships “delight features” shows how even financial and charitable products can surprise and delight without sacrificing clarity or compliance. Here’s the playbook I carry forward: build platforms, not apps; align company strategy with product strategy; treat growth as a product problem; make leadership transitions a strength, not a risk; and systematize delight so it shows up predictably, not accidentally. Above all, keep your OKRs centered on outcomes, not outputs, and let product discovery be the engine that finds truth faster. Referenced resources I keep handy for deeper study: Andy Rachleff: https://www.linkedin.com/in/rachleff/ Bill Gates: https://www.linkedin.com/in/williamhgates/ Daffy: https://www.daffy.org/ Daffy’s 2023 Year in Review: https://www.daffy.org/resources/year-in-review-2023 eBay: https://www.ebay.com/ Jeff Weiner: https://www.linkedin.com/in/jeffweiner08/ Reid Hoffman: https://www.linkedin.com/in/reidhoffman/ Robinhood: https://robinhood.com/ Ryan Roslansky: https://www.linkedin.com/in/ryanroslansky/ The Innovator’s Dilemma: https://www.amazon.com/Innovators-Dilemma-Clayton-M-Christensen/dp/0062060244 Tim Cook: https://www.apple.com/leadership/tim-cook/ Wealthfront: https://www.wealthfront.com/
    Book a consult png image
  • Build Enduring Software: Minimum Remarkable Products, Customer-First Culture, and Org Design Lessons

    Build Enduring Software: Minimum Remarkable Products, Customer-First Culture, and Org Design Lessons

    Some software companies endure and compound while others flash and fade. As a product leader, I’m constantly studying why, and I keep returning to a set of timeless principles that bridge strategy, culture, and execution. In this personal reflection, I synthesize lessons that help teams build software companies that last—and products customers love—while sharing how I apply them day to day. Alyssa Henry is the former CEO of Square, a financial services company providing products and services used by over 4 million merchants. Formerly at Amazon, Alyssa led the development and growth of Simple Storage Service (S3) at AWS. Alyssa now serves as an Independent Director at Intel and Confluent. Here’s the lens I use to unpack durable product leadership: Lessons from Amazon, Microsoft, and Square; “Minimum Remarkable Products” versus Minimum Viable Products; Navigating different work cultures in big tech; Insider reactions to the disruptive launch of AWS; “Pioneer” versus “fast-follower” companies. Across companies and stages, I’ve found “Noticeable consistencies in the human condition” that matter far more than we admit: people seek meaning, clarity, and momentum. “Differences in culture at Amazon, Microsoft and Square” are real, but the constants are trust, ownership, and a shared definition of excellence. When those are explicit, performance scales; when they’re implicit, friction compounds. One lesson that’s both provocative and practical is why “customers come first,” even above employees and community. In my teams, this doesn’t license burnout or disregard for stakeholders; it creates a north star that aligns trade-offs. We use customer impact as the tie-breaker, and we protect teams with smart scoping, pacing, and support. It’s also why “Why fast-followers can be less customer-focused” resonates—if your compass is your competitor, you’ll under-index on original customer insight. On product craft, I favor “Minimum Remarkable Products” versus Minimum Viable Products. Viable ships; remarkable endures. “Building Minimal Remarkable Products at Square” highlights the bar: a crisp, opinionated slice that is usable, lovable, and unmistakably on-brand. To get there, we obsess over the first-use moment, default choices, and the shortest path to value. Then we “How to scale an aesthetic” without creating a design monoculture—by codifying principles, not just patterns. Companies that last operationalize culture. “The importance of effective communication systems” can’t be overstated: single sources of truth, clear decision records, and explicit ownership reduce entropy. Next, “How to operationalize company values” means translating beliefs into behaviors (interview rubrics, launch checklists, escalation paths). Finally, “Why shared beliefs are crucial for good company culture” reminds me to ask: do our rituals reward the behaviors we claim to value? Org design is strategy in slow motion. From “Org design lessons from Square,” I’ve learned to align structure to the customer journey and the business model, not to personalities. “How to align different teams behind business priorities” requires ruthless clarity on outcomes, not tasks—this is where outcomes vs output OKRs keep us honest. When incentives, metrics, and roadmaps point at the same target, coordination costs fall and velocity rises. Competition is the crucible for focus. “Lessons learned from fierce competition” taught me to pick our battles and compound strengths. The “fast follower” vs “pioneer” playbook isn’t binary; it’s a portfolio. Pioneer when you have a unique insight or distribution advantage; fast-follow when the category is proven but customer dissatisfaction remains high. Either way, anchor to the customer’s job-to-be-done. I’m also inspired by platform thinking at scale. “The original thinking behind AWS” and “The unlikely origin of Amazon CloudFront and other products” illustrate how small, well-defined primitives become ecosystems when coupled with relentless customer feedback. “How Jeff Bezos influenced Alyssa” underscores the power of mechanisms over slogans—leaders who institutionalize their bar raise everyone’s game. When joining a new company, I start with “Joining Square and “building a picture” of the org.” I map decision flows, interfaces, and dependencies before proposing changes. Then “Knowing what to replicate from past companies” and “Questioning norms in new companies” become complementary moves: borrow proven mechanisms, but stress-test assumptions against the current context. That’s how you avoid cargo culting and create fit-for-purpose systems. Timestamps: (00:00) Introduction; (02:20) Lessons from Microsoft and Amazon; (08:29) Noticeable consistencies in the human condition; (10:50) Differences in culture at Amazon, Microsoft and Square; (13:27) Why “customers come first,” even above employees and community; (14:01) Why fast-followers can be less customer-focused; (15:50) The challenge of commercializing research projects; (18:58) Joining Square and “building a picture” of the org; (24:55) Knowing what to replicate from past companies; (27:45) Questioning norms in new companies; (28:41) The importance of effective communication systems; (31:31) How to operationalize company values; (33:38) Why shared beliefs are crucial for good company culture; (37:05) Building Minimal Remarkable Products at Square; (38:13) How to scale an aesthetic; (42:46) Org design lessons from Square; (50:06) How to align different teams behind business priorities; (52:57) Lessons learned from fierce competition; (57:39) The “fast follower” vs “pioneer” playbook; (61:05) The original thinking behind AWS; (66:08) The unlikely origin of Amazon CloudFront and other products; (73:47) How Jeff Bezos influenced Alyssa. Referenced: Amazon: https://www.amazon.com; Amazon Web Services: https://aws.amazon.com; Bill Gates: https://www.linkedin.com/in/williamhgates; Block, Inc: https://block.xyz; Cash App: https://cash.app; Fast Company – Back To Square One: https://www.fastcompany.com/3033412/back-to-square-one; Gokul Rajaram: https://www.linkedin.com/in/gokulrajaram1; Jack Dorsey: https://twitter.com/Jack; James Hamilton: https://www.linkedin.com/in/jameshamilton4; Jeff Bezos: https://twitter.com/jeffbezos; Microsoft: https://www.microsoft.com; Oracle Corporation: https://www.oracle.com; Sarah Friar: https://www.linkedin.com/in/sarah-friar; Square: https://squareup.com; Tom Szkutak: https://www.linkedin.com/in/tom-szkutak-4b59817; WSJ – Mobile-Payments Startup Square Discusses Possible Sale: https://www.wsj.com/articles/SB10001424052702303825604579513882989476424. If you lead product or aspire to, my challenge is simple: pick one mechanism to strengthen this week—tighten your communication system, raise your MRP bar, or sharpen your outcome metrics. Enduring companies are built the same way enduring products are: one remarkable, customer-centric decision at a time.
    Book a consult png image
  • Leading Up, Down, and Across the Org: Hard-Won Lessons in Executive Effectiveness, Culture, and Speed

    Leading Up, Down, and Across the Org: Hard-Won Lessons in Executive Effectiveness, Culture, and Speed

    Effectiveness up and down the org chart isn’t about playing to every stakeholder—it’s about setting a clear bar, moving fast, and creating a culture that scales good judgment. Recently, I revisited a rich set of leadership insights drawn from the journey of a seasoned operator whose path runs through Rippling, Inkling, and Apple. Rippling, an all-in-one HR, IT, and finance platform for businesses, which last raised $500M at a $11.25B valuation. Before Rippling, Matt was the co-founder and CEO at Inkling, a mobile learning platform that was acquired in 2018. He also held several management roles at Apple.

    Here are the themes I’ve internalized and applied in my own product management leadership practice: Lessons on culture, org-design, and product from Rippling; Characteristics of great CEOs; how to be a better executive leader; leading with kindness and impatience; and how to fight entropy. Each one ladders up to a practical playbook for leading across functions and layers with clarity and conviction.

    Culture, org-design, and product execution are inseparable. I bias toward first principles thinking and clean lines of responsibility—small, accountable teams with unambiguous owners. When culture is clear, org design gets simpler, and product velocity increases. I’ve learned to articulate the non-negotiables (what “great” looks like) and to make tradeoffs explicit so teams can move without waiting for permission.

    On CEO (and exec) craft, a few truths consistently show up in high performers: Great CEOs don’t worry about their weaknesses; they double down on their spike and build complementary teams around it. Why every great CEO is impatient: time kills options, learning, and morale. Yet the best leaders hold impatience in tension with kindness—high standards, delivered with respect. The result is the paradox many top executives describe: why execs are “tortured but happy.”

    Fighting entropy is a core job of executive leadership. How executives fight entropy: instrument the business, shrink feedback loops, obsess over interfaces (between teams and systems), and reduce decision latency. Experience ≠ wisdom; unexamined repetition calcifies bad patterns. I look for leaders who can separate signal from noise, manage workplace politics without feeding it, and continuously refresh their mental models as the company scales.

    Operationally, I’m unapologetic about dogfooding and financial hygiene. Why all businesses should dogfood: it builds empathy, surfaces edge cases, and accelerates product-market fit. Overseeing employee expenses isn’t micromanagement; it’s culture-setting around stewardship. The best CEOs don’t need coaching is a provocative line; my take is they actively coach themselves—by seeking disconfirming evidence, cultivating truth-tellers, and measuring outcomes. Beware the hidden cost of advice: misapplied pattern-matching and borrowed conviction can slow teams and erode accountability.

    Hiring and interviewing are leverage points for culture. Don’t make this mistake when interviewing: over-indexing on brand names or “years of experience” without probing for first principles reasoning and rate of learning. I explicitly define anti-patterns (behaviors we do not hire for), then test for them. Finding first principles thinkers means asking for the derivation, not the conclusion; I want to see how candidates reduce ambiguity and navigate tradeoffs without relying on playbooks.

    On outcomes and operating cadence, I keep the bar simple: clear direction, fast cycles, and measurable impact. Outcomes vs output OKRs is not a semantic debate; it’s a leadership stance. How I think about output: measure the rate of learning and the quality of decisions, not just the volume of launches. Rippling’s key leadership principle resonates with me: insist on clarity—of goals, ownership, interfaces, and timelines. Why kindness matters: people move faster when they feel safe telling the truth. Freeing yourself from self-doubt isn’t about bravado; it’s about anchoring to first principles, writing decisions down, and letting data—not anxiety—close the loop.

    Referenced:

    Andy Roddick: https://www.atptour.com/en/players/andy-roddick/r485/overview

    Apple: https://www.apple.com

    Bain & Company: https://www.bain.com/

    Bill Campbell: https://en.wikipedia.org/wiki/Bill_Campbell_(business_executive)

    Conscious Business: https://www.amazon.com.au/Conscious-Business-Build-Value-Through/dp/1622032020

    Google: https://www.google.com

    Inkling: https://www.inkling.com/

    McCaw Cellular: https://en.wikipedia.org/wiki/McCaw_Cellular_Communications

    McKinsey: https://www.mckinsey.com/

    Microsoft: https://www.microsoft.com

    Oracle: https://www.oracle.com

    Parker Conrad: https://www.linkedin.com/in/parkerconrad/

    Peter Currie: https://en.wikipedia.org/wiki/Peter_Currie_(businessman)

    Rippling: https://www.rippling.com

    The Effective Executive: https://www.amazon.com.au/Effective-Executive-Peter-Ferdinand-Drucker/dp/0060833459

    Timestamps:

    (00:00) Introduction

    (02:14) Great CEOs don’t worry about their weaknesses

    (06:31) The third-time founder mindset

    (08:09) Why every great CEO is impatient

    (11:54) How executives fight entropy

    (19:11) Experience ≠ wisdom

    (21:26) Managing workplace politics

    (24:02) Why all businesses should dogfood

    (26:20) Overseeing employee expenses

    (27:43) The best CEOs don’t need coaching

    (29:55) The hidden cost of advice

    (40:40) Why execs are “tortured but happy”

    (44:16) Clear versus first principles thinking

    (51:09) Finding first principles thinkers

    (53:13) Why people overcomplicate culture

    (55:53) Don’t make this mistake when interviewing

    (59:26) The importance of anti-patterns

    (61:27) Important business values

    (63:28) How Matt thinks about output

    (66:33) Rippling’s key leadership principle

    (71:02) Why kindness matters

    (72:03) Freeing yourself from self-doubt


    Book a consult png image
  • Developing Technical Taste: My Playbook for Next‑Gen Engineers, AI Strategy, and 2024 Scaling

    Developing Technical Taste: My Playbook for Next‑Gen Engineers, AI Strategy, and 2024 Scaling

    When I think about the next generation of engineers and product creators, one capability consistently separates the great from the good: technical taste. It’s the intuition to choose the simplest viable path, the humility to iterate, and the courage to ask “what if” before everyone else. In this piece, I share how I frame technical taste, what it means for AI strategy, and how to scale software teams in 2024 without losing speed or product-market fit.

    Sam Schillace is the CVP and Deputy CTO at Microsoft. Before Microsoft, Sam held prominent engineering roles at Google and Box. He has also founded six startups, including Writely, which was acquired by Google and became Google Docs.

    In this deep dive, I explore themes like “Sam’s advice for future engineers,” “What’s next for AI,” “How to develop technical taste,” “The importance of asking ‘what if’ questions,” “Lessons on market timing,” and “Scaling a software company in 2024.” My lens is product management leadership at scale, with a bias toward clear decision-making, rapid learning, and compounding leverage.

    On market timing, my experience echoes the principle that momentum compounds only after you align product insight with the market’s inflection point. “The Innovator’s Dilemma” reminds us that the very systems designed to protect current value can block new value. The smartest move I’ve seen is to treat disruptive bets like venture portfolios inside the company—small, time-boxed, outcome-driven, and shielded from legacy KPIs. That’s how you preserve execution excellence while creating space for the next S-curve.

    Technical taste is developable. I look for three signals: first, engineers who reduce a problem to its essence and deliver a working slice quickly; second, product creators who anchor on outcomes vs output OKRs; third, teams who habitually ask “what if” questions to surface non-obvious constraints and new leverage. When this mindset meets strong product discovery, you get faster cycles, fewer dead ends, and clearer product-market fit lessons.

    “Building Google Docs” is a case study in choosing the web as the platform before it was fashionable—an act of taste under uncertainty. It’s also a reminder that what looks inevitable in hindsight was controversial in real time. Discussions about “The decline of Google apps” are less about any one company and more about the drift that occurs when focus fragments; taste is how you steer back to the core job-to-be-done.

    On “The Innovator’s Dilemma facing Microsoft” and “The differences between Google and Microsoft,” I’ve seen how culture shapes product motion. One optimizes for experimentation at massive consumer scale; the other, for enterprise trust and durability. The playbook to reconcile both: define two operating modes—explore and exploit—and make the seams explicit. Use forward deployed engineers to learn with customers, while platform teams industrialize the wins.

    “How to build a winning product” in 2024 is straightforward to say and hard to do: shorten the distance between insight and impact. I prioritize gen AI for product prototyping to test feasibility early, pair it with real-user loops from day one, and instrument everything to learn faster than competitors. Ruthlessly prune scope to ship a lovable slice, then iterate. That’s how you scale software in 2024 without bloating teams or code.

    On “Becoming an optimist,” I’ve learned optimism is a practice: assume better solutions exist, then run experiments to find them. “What makes a great engineer” and “One thing the best engineers do” often collapse into the same behavior—holding high standards while moving fast. The best engineers I know ask precise “what if” questions, surface edge cases early, and translate ambiguity into a plan the team can execute.

    “Sam’s prediction about AI,” “Capturing the value of AI,” and “How you should think about AI” all converge on a few product truths. Co-pilots and agents will become table stakes; differentiation will come from domain-specific data, workflow depth, and trust. Value accrues where AI is closest to the decision or outcome—embedded in the flow of work, not bolted on. For customer support AI strategy, the win isn’t a clever bot; it’s reducing time-to-resolution with explainability, guardrails, and continuous learning from real tickets.

    “Microsoft’s new leverage,” “Scaling software in 2024,” and “The future of AI across several sectors” point to a broader shift: platforms that combine distribution, identity, and compliance will set the rules of engagement. But even in that world, local excellence matters—tight loops with customers, forward deployed engineers, and outcome-centric roadmaps will out-execute feature factories. The teams that treat gen AI as a capability—not a feature—will capture durable advantage.

    Referenced:

    Amazon: https://amazon.com

    Box: https://www.box.com/

    Elon Musk: https://twitter.com/elonmusk

    Google Docs: https://docs.google.com

    Itzhak Perlman: https://itzhakperlman.com/

    Microsoft: https://www.microsoft.com

    Netflix: https://www.netflix.com

    Tesla: https://www.tesla.com/

    The Innovator’s Dilemma: https://www.amazon.com.au/Innovators-Dilemma-Clayton-M-Christensen/dp/0062060244

    TurboTax: https://turbotax.intuit.com/

    Uber: https://www.uber.com/

    Walmart: https://www.walmart.com/

    Workday: https://www.workday.com/

    Writely: https://techcrunch.com/2005/08/31/writely-process-words-with-your-browser/

    Where to find Sam Schillace:

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

    Newsletter: https://sundaylettersfromsam.substack.com/

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

    Timestamps:

    (00:00) Introduction

    (02:54) Lessons on market timing

    (07:30) Developing technical taste

    (09:51) Asking “what if” questions

    (14:03) Building Google Docs

    (19:32) The decline of Google apps

    (20:57) The Innovator’s Dilemma facing Microsoft

    (22:53) The differences between Google and Microsoft

    (24:42) How to build a winning product

    (27:46) Becoming an optimist

    (29:12) Why engineering teams aren’t smaller

    (32:00) Sam’s prediction about AI

    (34:11) Capturing the value of AI

    (37:43) How you should think about AI

    (45:33) Advice for future engineers

    (48:18) What makes a great engineer

    (49:45) One thing the best engineers do

    (51:37) Microsoft’s new leverage

    (56:01) Scaling software in 2024

    (59:50) The future of AI across several sectors

    (64:28) What Sam and a violinist have in common


    Book a consult png image
  • Mastering Altitude Shifts: Hard‑Won Product Leadership Lessons from Anneka Gupta’s Journey

    Mastering Altitude Shifts: Hard‑Won Product Leadership Lessons from Anneka Gupta’s Journey

    I’m endlessly fascinated by leaders who can operate at every altitude—zooming out on strategy one minute and diving into the weeds the next. That’s why Anneka Gupta’s journey resonated so strongly with me, because it crystallizes how multi-disciplinary leadership accelerates product outcomes and go-to-market execution.

    Anneka Gupta is the Chief Product Officer at Rubrik, a cloud management and data security company with a US$6B market cap. Before Rubrik, Anneka spent 11 years leading various teams at LiveRamp, including product, go-to-market, and operations.

    One proof point that leapt off the page for me: LiveRamp went from $30M to $200M ARR in 3 years. That kind of growth rarely comes from product alone—it’s the compounding effect of crisp customer segmentation, tight GTM alignment, and a culture that prioritizes outcomes over output. In my own teams, anchoring OKRs to business outcomes rather than feature counts has been the most reliable way to unlock this momentum.

    What I admire most is Anneka’s jack-of-all-trades career. Rotating through product, operations, and GTM builds a powerful intuition for how systems interact. I’ve seen the same benefit at scale: PMs who have shipped, sold, and supported the product make sharper tradeoffs because they integrate customer value, revenue mechanics, and operational feasibility in real time.

    There’s a counterintuitive hiring lesson here too—why specialist hires can backfire. When the product or market is still evolving, over-optimized specialists often struggle without mature processes and stable interfaces. Early on, I bias toward adaptable builders who can define the playbook, not just run it. Specialists shine once the motion is proven and repeatable.

    Altitude control matters. Knowing when leaders should get in the weeds is a differentiator. I’ve found three triggers: existential risk (security, reliability, or reputation), pivotal zero-to-one bets, and repeated cross-functional misalignment. Step in, diagnose at the system level, model the behavior you expect, and then step back out quickly so the team retains ownership.

    There’s also one area every PM can improve in: customer-facing fluency. I agree with the principle that PMs should undergo the same training as sales reps. Shadow discovery calls, rehearse objection handling, and learn to speak to value drivers by persona. When PMs can authentically sell the problem and the solution narrative, product discovery gets faster and win rates improve.

    Crafting products for different personas is another thread I pull on constantly. Buyers care about ROI, risk, and roadmap; users care about speed, clarity, and control. Great product discovery bridges the two by validating problem severity and adoption friction in parallel. That’s how you avoid building “the best product” that still loses because the buying committee can’t align on value.

    I’m also struck by how deftly LiveRamp navigated enterprise shifts like transitioning Acxiom’s customers to LiveRamp and the broader dynamics of why Acxiom chose to buy not build. These moves demand rigorous change management—backwards compatibility, data governance guarantees, and clear migration value propositions. When the incentives align for customers and field teams, integrations become accelerants rather than tax.

    Rubrik’s approach to building product underscores the same fundamentals: focus on critical customer outcomes, connect roadmap to go-to-market reality, and measure what matters. In practice, that means linking product bets to explicit revenue or retention hypotheses and setting guardrails so teams can run fast without creating long-term complexity debt.

    I also appreciate the humility in reflecting on mistakes and the outsized impact of mentors and peers. The best leaders I’ve worked with narrate their decision-making—what they knew, what they assumed, and what they’d do differently—which compounds organizational learning. It’s the difference between isolated wins and a repeatable operating system.

    If I distill my own playbook from these themes, it looks like this: hire for adaptability early, specialize later; anchor to outcomes vs output to avoid local maxima; keep PMs close to the sales and support edges of the system; and practice altitude shifting as a daily discipline. The result is a product organization that learns faster than the market changes—arguably the only durable advantage.


    Book a consult png image
  • Inside Figma’s Product Playbook: Taste, Simplicity, and Storytelling for Extraordinary PMs

    Inside Figma’s Product Playbook: Taste, Simplicity, and Storytelling for Extraordinary PMs

    I’ve long believed the best products come from a careful blend of taste, simplicity, and storytelling. Studying how Figma operationalizes these principles has sharpened my own playbook for building, launching, and scaling products. In this piece, I distill the patterns I use and teach: how to approach new products, how to prioritize without losing the plot, and how to use narrative as a force multiplier for teams and customers.

    At a high level, here’s the arc I focus on: approaching new products with a strong point of view, shaping product culture that balances craft with outcomes, understanding when to change course, tying business goals to product expansion, going multi‑product deliberately, recognizing the differences between “0 to 1” and “1 to 10” talent, and elevating storytelling from launch polish to a core build-time practice. Along the way, I’ll highlight why taste and simplicity aren’t luxuries—they’re strategy.

    When I explore how to build from zero, I start with a crisp customer promise and a single, testable magic moment. The early days demand ruthless focus: one job-to-be-done, one path to value, one reason to share. As teams expand scope, the risk is layering utility without coherence. The countermeasure is systematic simplicity—every addition must make the core value faster, clearer, or more extensible. If it doesn’t, it’s noise.

    Product culture is the scaffolding that makes this discipline stick. Speed and operational excellence drive the right kind of urgency; experimentation at scale validates hypotheses without cargo-culting metrics; and rigor in reviews ensures we’re prioritizing outcomes over output. The best cultures pair evidence with taste—data guides, but the bar for quality, narrative, and craft is set by humans with conviction.

    Knowing when to change things is both an art and a system. I look for signal in stubborn user friction, plateauing activation, a long tail of workarounds, and moments when a new platform or workflow unlocks 10x value. The framework I use: if a change can simplify the path to the promise, or unlock a whole new class of users without diluting the core, it deserves energy. Change the defaults before changing the philosophy.

    Business goals should sharpen, not overshadow, product expansion. Before adding surfaces or SKUs, I insist on clarity around the ICP, the premium moment worthy of pricing, the extensibility story for developers, and the narrative that unifies everything. Multi‑product strategy works best when each product is a chapter in the same book, not a pile of features. That’s why I appreciate how the ecosystem comes together across Figjam: https://www.figma.com/figjam/, Figma: https://www.figma.com/, Figma Dev Mode: https://www.figma.com/dev-mode/, and Figma Slides: https://www.figma.com/slides/—distinct entry points, shared language, and compounding value.

    For “0 to 1” product work, I hire for curiosity, taste, and velocity. I want builders who can reduce ambiguity quickly, prototype with whatever tools are at hand, and tell a clear story about why their version of the problem matters. My favorite interview signal is a non-obvious customer insight that changed their roadmap. Entrepreneurial talent shows up in the questions they ask about distribution, pricing, and adoption—not just the feature.

    I’m often asked why there aren’t more designer founders. My take: the gap is less about capability and more about exposure to distribution, pricing, and finance. Practical fixes help—give design leaders P&L ownership, put them on customer calls that include procurement, and pair them with GTM partners early. When designers are fluent in business mechanics, their advantage in taste and narrative becomes a superpower.

    New product launches work best when the story is built in from day one. I like to “slow-cook” with tight, cross-functional squads, private betas with power users, and an explicit before/after narrative that connects the dots across product, docs, community, and developer ecosystem. As teams scale, I match talent to stage: “0 to 1” thrives in uncertainty; “1 to 10” excels at repeatability, quality, and operational excellence. Both are essential; mixing them at the wrong time creates drag.

    Storytelling is not veneer—it’s how we align teams, earn stakeholder trust, and help users see themselves in the product. I anchor roadmaps to a one-sentence promise, show the painful “before,” demonstrate the “after,” and name the magic mechanic that makes it possible. Then I translate that story into prioritization. I stack-rank by value, confidence, and cost, and I’m explicit about what we won’t do. Strategy is as much the boundary as the plan.

    If you’re refining your product storytelling, a quick checklist helps: articulate the promise in plain language, show rather than tell with a demo that lands the magic moment in 30 seconds, connect to measurable outcomes, and make the first-run experience feel like the narrative come to life. Don’t bury the lead. If a user can’t explain your product to a teammate after one minute, the story isn’t ready.

    The difference between “good” and “extraordinary” product managers is simple to say and hard to do. Good PMs coordinate and ship on time. Extraordinary PMs set a higher bar for taste, simplify relentlessly, and move teams from consensus to conviction. They connect craft to outcomes, use narrative to create momentum, and make decisions that age well because the logic is legible.

    Simplicity is a growth strategy. It shortens time-to-value, reduces error surface, and raises retention by making products feel learnable and trustworthy. Tactics I lean on: one hard thing at a time, remove to improve, defaults are design, and compress choices until the right path is the easy path. Simplicity isn’t less—it’s the right less.

    Taste, in product and design, is not innate; it’s a practiced sensitivity to what feels inevitable. I cultivate it by collecting exemplars, writing and revisiting product principles, insisting on weekly critiques, and sweating the narrative as much as the pixel. The best teams hold two truths: quality you can feel and outcomes you can measure.

    If you want to explore the ecosystem I referenced, here are direct links: Figjam: https://www.figma.com/figjam/, Figma: https://www.figma.com/, Figma Dev Mode: https://www.figma.com/dev-mode/, Figma Slides: https://www.figma.com/slides/.

    Whether you’re building your first product or scaling a platform, the throughline remains: lead with taste, ship with simplicity, and align everyone with a story worth rallying around. That combination turns good teams into extraordinary ones—and products into movements.


    Book a consult png image
  • Just Now Possible Preview: How Real Teams Ship AI—Workflows, RAG, Agents, Evaluation

    Just Now Possible Preview: How Real Teams Ship AI—Workflows, RAG, Agents, Evaluation

    I’m excited to share a preview of Just Now Possible, a show where I sit down with the builders who are shipping meaningful AI features in the real world. My goal is simple: pull back the curtain on how AI products actually get made—messy problems, rapid prototyping, and the leadership decisions that move teams from concept to customer value.

    Watch the preview on YouTube: https://www.youtube.com/embed/Kb2HbuPbfR8?feature=oembed. Prefer audio? Listen on Spotify: https://open.spotify.com/episode/5xM0pDnqR0JpKmW6aZ0pj6?ref=producttalk.org or Apple Podcasts: https://podcasts.apple.com/us/podcast/podcast-preview/id1838832993?i=1000725807029&ref=producttalk.org. Want a text version? Read the transcript ($): #full-transcript.

    How AI products come to life—straight from the builders themselves. In each episode, we dive deep into how teams spotted a customer problem, experimented with AI, prototyped solutions, and shipped real features. We dig into everything from workflows and agents to RAG and evaluation strategies, and explore how their products keep evolving. If you’re building with AI, these are the stories for you.

    From my own experience leading product teams, I’ve seen that the real unlocks come from disciplined product discovery, clear outcomes vs output OKRs, and smart use of gen ai for product prototyping. We’ll talk about the tradeoffs between speed and safety, when to bring in forward deployed engineers, and how to validate product-market fit lessons before scaling. Along the way, we’ll unpack practical patterns—like when to use RAG vs fine-tuning, how to evaluate agents in production workflows, and what great product management leadership looks like in AI-first environments.

    The first full episode drops on Thursday, September 18th. Don't miss it!

    Full transcripts are available to paid subscribers.


    Inspired by this post on Product Talk.


    Book a consult png image