Tag: try do consider framework

  • Why “Figma Is Not the Source of Truth”: My Playbook for Design Leadership That Scales

    Why “Figma Is Not the Source of Truth”: My Playbook for Design Leadership That Scales

    I keep a simple mantra front and center: Figma is not the source of truth. The customer is. In practice, that means the only thing that truly counts is what we ship, how it performs, and whether users come back for more. Mockups are hypotheses; production usage is evidence. When my teams adopt this lens, velocity improves, judgment sharpens, and quality rises where it matters most.

    So what does design actually do in a software company? At its best, design builds leverage for the whole system—engineering, product, and marketing—by clarifying problems, raising the quality bar, and making complex decisions legible. The standard I hold is ancient and still essential: products must be useful, usable, and desirable — and above all, used. When we calibrate around “used,” debates about pixels give way to outcomes, and cross-functional partners feel the difference.

    I often trace the roots of our craft back well beyond the digital era. The lineage from industrial design to software is real; constraints, ergonomics, affordances, and systems thinking didn’t start with screens. If you’ve ever mapped delight, performance, and reliability in a Kano Model, you’ve touched this lineage. The translation to software is simple: design the full journey, not just the interface—prioritize what improves time-to-value, reduces cognitive load, and earns habitual use.

    One lesson I’ve learned the hard way: why design leaders who stop designing stop leading. I still sketch flows, write UX copy, and prototype when it unblocks the team or sets a decisive quality bar. The altitude changes constantly—one hour I’m in a strategic roadmap review, the next I’m in a critique or poking at a prototype. Great design leaders jump up and down in altitude to connect vision to details without becoming a bottleneck.

    Over time, I’ve come to rely on four pillars every design manager must master: craft (raising taste and execution), product strategy (clarifying choices and trade-offs), people leadership (coaching, feedback, and hiring), and systems (processes, rituals, and design ops that scale). Neglect any one of these and either quality, speed, or team health will eventually falter.

    Perfectionism is a double-edged sword. Over-indexing on quality can paralyze decision-making, but lowering the bar indiscriminately is worse. I’ve seen moments where relaxing standards to “go faster” actually cost the business—rework piled up, trust eroded, and customer value stalled. The answer is principled delegation: I define what “must be true” at each milestone, delegate ownership with clear guardrails, and reserve my veto power for moments where product integrity is genuinely at risk.

    Measuring success as a design leader starts with outcomes vs output OKRs. I care about activation, retention, time-to-first-value, NPS verbatims tied to key journeys, and the operational metrics that earn the right to build the next thing. Design output is visible; design outcomes are durable. When trade-offs are needed, I optimize for the smallest shippable surface that still proves the core value proposition, then expand with data.

    Scaling judgment is the multiplier. I build it through pattern matching—studying enduring product systems from companies like Airbnb, Amazon, Apple, Asana, Notion, Stripe, Nest, and others—to distinguish where polish compels usage versus where it’s ornamental. Strong opinions matter, but so does being easy to convince with new evidence. I encourage designers to articulate the pattern they’re invoking, why it fits the job-to-be-done, and how we’ll know it worked.

    Operating cadence matters. My week is anchored around recruiting, crits, and staff meetings that actually make decisions. In critiques, I use the Do/Try/Consider framework to give actionable direction without micromanaging. On one-on-ones, the question isn’t “Should one-on-ones exist?” but “What are they for right now?”—coaching, performance, or clearing execution blockers. If a meeting doesn’t increase clarity or commitment, it gets redesigned or removed.

    Execution-wise, I’ve taken inspiration from Rippling’s operating system—especially its emphasis on speed, precise ownership, and hard commitments. The lesson is timeless: go fast on the right things, make clear promises, and instrument your work so you can see reality quickly. When speed is paired with crisp decision rights and observable outcomes, momentum compounds rather than frays trust.

    Hiring your first design leader? Look for someone who can set standards, scale judgment, and ship. They should be able to zoom from company narrative to interaction copy in a single afternoon, coach product trios, and build rituals that make taste and trade-offs explicit. Above all, they should have a point of view on where quality moves the business and where speed is the quality.

    Here’s how my team’s approach differs from many: Figma is not the source of truth. We design in Figma, but we learn from production. We pair designers with engineering early, prototype in code when it reduces risk, and wire telemetry into every critical path. Product trios use discovery to validate “useful, usable, desirable — and used,” then commit to outcomes with clear, testable definitions of success. The result is faster iteration, fewer surprises, and experiences customers actually adopt.

    If you want to deepen your own pattern library, study products and practices from leaders like Airbnb (https://www.airbnb.com/), Amazon (https://www.amazon.com/), Apple (https://www.apple.com/), Asana (https://www.asana.com/), CrossFit (https://www.crossfit.com/), Figma (https://www.figma.com/), Honeywell (https://www.honeywell.com/), Nest (https://store.google.com/category/google_nest), Notion (https://www.notion.so/), Retool (https://retool.com/), Rippling (https://www.rippling.com/), and Stripe (https://www.stripe.com/). Pay attention to how they balance versatility with clarity, defaults with flexibility, and speed with trust.

    The throughline is simple and demanding: design for reality, not for the board. Keep your standards where they create business value, scale judgment with explicit patterns, and instrument everything so learning never stops. When teams embrace that, the work gets better, customers feel it, and the roadmap starts to pull you forward.


    Book a consult png image
  • From Roadmaps to Sprints: Proven Tactics to Ship Software at Scale Without Chaos

    From Roadmaps to Sprints: Proven Tactics to Ship Software at Scale Without Chaos

    I recently sat down with Snir Kodesh, Head of Engineering at Retool, a development platform for building custom business tools. Before joining Retool, he spent six years as a Senior Director of Engineering at Lyft. Coming from my vantage point leading product at HighLevel, I was eager to compare notes on what it really takes to ship software at scale without losing clarity, customer focus, or team morale.

    We dug into the biggest differences between leading engineering teams for a consumer product versus an enterprise platform — and the patterns that hold true across both. Consumer surfaces demand rapid iteration loops and relentless UX polish; enterprise platforms demand configurability, security, reliability, and stakeholder alignment across buyers and users. In my experience, the constant across both worlds is crisp product management leadership: clear problem definition, tight feedback loops, and unambiguous ownership.

    We pulled back the curtain on the software development cycle, starting with setting the product roadmap while balancing a diverse set of customer needs. On roadmapping, I ensure we explicitly identify who’s in the room to represent product, engineering and design, as well as customer-facing teams like support and solutions. The most effective sessions make trade-offs visible: we quantify impact, risk, and effort; we surface dependencies; and we align on outcomes before timelines. The result is not just a list of features, but a sequenced narrative that earns the right to build.

    From there, we discussed how engineering takes that product roadmap and turns it into a concrete plan of action using the “try, do, consider” framework. I’ve found this framing incredibly practical: “try” creates space for low-risk experiments, “do” commits to high-confidence work, and “consider” tracks explorations that need more discovery. When sprint planning inherits this taxonomy, teams retain momentum without overcommitting — and leaders get a transparent view into where learning versus delivery is happening.

    He makes the case for leaning on QBRs instead of OKRs. I agree that quarterly business reviews calibrate teams on real outcomes, not vanity metrics, and they naturally force prioritization around customer value. When we do use OKRs, we emphasize outcomes vs output OKRs so teams aren’t incentivized to ship volume over impact. In practice, QBRs keep us honest: what shipped, what moved the needle, and what needs to change next quarter.

    We also tackled why scope creep gets a bad rap. In my experience, what’s labeled as “scope creep” is often legitimate learning uncovered through product discovery. The key is disciplined change management: time-box discovery, explicitly re-baseline when new information emerges, and separate must-haves from nice-to-haves. When done well, this turns surprises into strategic clarity rather than delivery risk.

    On estimation, we shared practical tactics for getting better at estimating how long a feature will actually take to complete. I lean on reference-class forecasting (compare to similar past work), risk burndown charts, explicit buffers for integration and QA, and a habit of capturing deltas between estimate and actuals. Over time, this creates a trustworthy velocity signal and sharpens intuition across both product and engineering.

    Translating the roadmap to sprint planning is where execution quality shows. We align on definitions of ready and done, maintain code review SLAs, budget a percentage for tech debt, and instrument everything so we can spot drift early. The “try, do, consider” framework maps cleanly to backlog hygiene, keeping discovery visible without derailing delivery. This is how we sustain speed and quality at scale.

    Finally, we zoomed out to essential advice for engineering leaders — especially folks scaling quickly from leading a small team to a much bigger one. Shift from direct control to leverage: clarify decision rights, invest in Staff+ ICs, and scale communication through operating cadences, decision logs, and crisp narratives. Pair autonomy with accountability using QBRs, and keep product discovery tight to preserve customer empathy as you add layers. The goal is the same at ten people or a thousand: ship valuable software predictably, learn fast, and keep the team energized.

    If you’re navigating the leap from product roadmapping to sprint planning, these patterns are battle-tested. Anchor on outcomes, use the “try, do, consider” lens to manage ambiguity, and treat scope as a living artifact informed by discovery. With the right rituals and metrics, you can ship software at scale — without chaos.


    Book a consult png image