I recently dug into a conversation with Marco Zappacosta, co-founder and CEO of Thumbtack, who has spent the last 13 years building the company into a billion-dollar business — and it’s his first and only job after graduating college. As someone who lives at the intersection of product management leadership and company-building, I was struck by how deliberately he navigates the deluge of advice that comes with being a first-time founder.
What resonated most was the way he differentiates between moments that demand a return to first principles and those that benefit from a tested playbook. In my own practice, I’ve found that product strategy and organizational design often require first-principles thinking, while operational cadence and execution rituals tend to scale best with proven patterns. The key is recognizing which game you’re playing — invention versus optimization — and applying the right mental models to filter input without losing velocity.
Marco’s approach to parsing counsel as a first-time CEO is refreshingly pragmatic. Rather than treating advice as binary, he triangulates from multiple data points, looks for invariants, and pressure-tests assumptions against the company’s unique context. I use a similar lens: anchor on the problem, map potential solutions to risk/return, and calibrate decisions with base rates where possible. It’s a disciplined way to turn a mountain of opinion into actionable signal — especially when stakes are high.
He also connects this discipline to stakeholder management, particularly in how he runs Thumbtack’s board so quarterly meetings become a critical resource, not just a time suck — and why he shares the board deck with the entire company. I’ve found this level of transparency to be a force multiplier: it aligns teams on priorities, elevates product roadmapping and sprint planning, and empowers leaders to make trade-offs with clarity. When the narrative is shared, accountability scales.
Marco candidly reflects on Thumbtack’s COVID-related layoff last year, and what he specifically did as CEO to ensure the folks who remained still had confidence in the company and his leadership moving forward. In hard moments like these, consistent communication, explicit prioritization, and a clear framework for decision-making matter more than ever. Trust is built by showing your work — why choices were made, what changes now, and how success will be measured.
Finally, he opens up his playbook for choosing what to spend his time on as a busy CEO with only so many hours in the day — and perhaps more importantly, how he stays accountable for these priorities. I’ve learned to pair outcome-oriented OKRs with a ruthless weekly schedule audit: if the calendar doesn’t reflect the strategy, the strategy won’t happen. This discipline creates focus, accelerates learning loops, and keeps leaders from becoming the bottleneck.
For builders at any growth stage, there’s a powerful takeaway here: cultivate a repeatable way to distill advice, clarify when to use first principles versus a playbook, operationalize board relationships as strategic assets, and turn time into your sharpest instrument. The result is a more resilient company — and a leadership practice that compounds.
AI has changed the tempo of product management, but not the timeless fundamentals. I’m living that paradox daily: the technology reshapes how we plan, build, and ship—yet the way we find real customer value hasn’t budged. Here’s how I reconcile both truths in practice.
At their core, large language models predict the next token. That’s it. Consider the prompt, “The cat sat on the ____.” Mat is most likely. Chair is pretty likely. Floor, roof, piano—all possible, just less probable. When you give an LLM a prompt, it runs through a neural network—billions of parameters making calculations—to predict the most likely next word, then the next, then the next. That neural net represents not just facts, but relationships, patterns, context—and some might even argue reasoning capabilities—that all influence the probabilities of different outputs. So LLMs don’t just predict the next token. They predict the next token by drawing upon a vast amount of knowledge. LLMs are transformational.
Behind the magic, LLMs don’t “know”—they rank what likely comes next. This slide’s cat sentence with weighted options underscores how generative AI reshapes work while remaining probability-driven.
And yet, AI makes silly mistakes. The kind that make you wonder how it could be so smart and so dumb at the same time. No matter how hard I tried, I could not get ChatGPT-5 to fix the closing quote on an image. And it took 12 seconds of thinking to figure out that I asked for a meeting summary but didn’t include any meeting notes. Why do LLMs make these mistakes? Well, it’s because all the LLM is doing is predicting the next token based on patterns. And sometimes those predictions are wrong. And when it’s wrong, it can be confidently wrong. So what do we do?
A side-by-side visual pits an optimistic AGI rocket against a frowning skeptic with a thumbs-down, ending with the prompt 'Which is it?'—capturing the debate over whether generative AI is transformative progress or overhyped.
To build reliable AI features, I focus my team on four core skills: prompt engineering, context engineering, orchestration, and evaluation (evals). Together, they let us harness what’s powerful about generative AI while reducing unforced errors.
Generative AI isn’t magic—it’s inputs, training data, and models. This visual invites readers to examine how predictions are produced and why transparency, bias checks, and ethics shape responsible outcomes.
First, prompt engineering. With LLMs, the quality of the input determines the quality of the output. An LLM can’t guess what you want. You have to specify what you want in a language the LLM understands. In a chat, you can iterate with multiple turns. In a product, you get one shot. When we ship a meeting summarizer, for example, I design a production-ready prompt that assigns a role (“You are a chief of staff for a busy executive…”), specifies output format (e.g., a structured list of action items), and clarifies exactly what to include and how to structure it. This is prompt engineering. It’s like writing a really good product spec—but for an AI.
A simple sentence becomes a window into generative AI: a neural network weighs options and selects 'mat,' showing how models rank likely words to produce fluent text—and why outputs feel confident yet probabilistic.
Second, context engineering. LLMs know a lot, but not everything. Imagine a takeaway reads, “Send the pipeline report to John by Friday.” When is Friday? Which John? What is the pipeline report? The model lacks today’s date, the roles of participants, and the specifics of our reporting vocabulary. If you dump every possible detail into the prompt, the model gets noisy input and the quality drops. The key is to add only the context the LLM needs to do the task at hand and nothing more. This is where techniques like RAG (Retrieval Augmented Generation) shine: retrieve just the relevant snippets—e.g., attendee roles, the precise definition of “pipeline report,” and the calendar context for “Friday”—and include only those in the prompt.
A minimalist slide demystifies how LLMs choose words: given 'The cat sat on the ____', the model ranks options by probability, showing that AI outputs are weighted predictions, not facts, which matters for ethics and product decisions.
Third, orchestration. LLMs are better at simpler tasks. If you try to do everything in one prompt—identify action items, summarize the meeting, categorize by urgency, match to owners, check for clarity—the quality goes down. But if you break it into steps, each focused on one thing, the quality goes up. I design a workflow of multiple LLM calls that work together. For example: First call: identify action items from the transcript. Second call: categorize by urgency using lightweight project context. Third call: match to owners with a minimal team directory. Fourth call: generate calendar events via an API. Each step is simple. But together, they create something sophisticated.
From building apps by chatting to auto-cleaning video and translating comments, AI compresses complex tasks into simple prompts. This scene shows why it feels transformative—while nudging us to weigh its limits and ethics.
Fourth, evaluation (evals). Otherwise known as: Is my AI product any good? At the heart of evals is this question: Given the input, did we get the expected output? I use several approaches. Datasets: I collect 20–100 real examples, define expected outputs, run the prompt, and measure the success rate. Code assertions: I enforce rules the output must follow (for example, “Every action item must have a task, owner, and deadline”) and fail the test when they’re violated. LLM-as-Judge: I use a model to verify factuality (e.g., “Is each item in this summary in the meeting transcript? Yes or no.”). Human evals: I track whether users need to edit the output and by how much. Start simple; get more sophisticated as the stakes rise.
From “AI Changes Everything (And Nothing At All),” this slide contrasts bold promises with everyday glitches: optimism about LLMs and AGI on the left, and a meeting-summarizer that can’t find content on the right—reminding us AI still errs.
Here’s the hard truth: you can master all four skills and still ship the wrong thing. Why? Because you chose the wrong problem to solve. Who needs yet another meeting summarizer? The ease of building with generative AI tempts us to jump straight to solutions. Resist it.
A keynote slide from AI Changes Everything (And Nothing At All) urges teams to master AI by harnessing its power while minimizing errors, framing a practical, ethical approach to building trustworthy products.
Discovery matters more than ever. Before writing your first prompt, be explicit about the impact you want and set a clear outcome. Talk to your customers and ensure you understand their needs; choose the right opportunity before you chase a cool solution. Explore multiple options and use assumption testing to converge on what will actually move the needle.
Clear prompts shape better AI. This slide shows how explicit, well-structured instructions lead to stronger LLM responses, reminding builders that inputs drive outcomes—and that responsible prompting begins with clarity.
Prototype, test, and build iteratively. With AI products, it’s easy to get to a great demo and hard to get to a production-grade experience. I validated feasibility before I wrote a line of production code by experimenting directly in a model’s UI, pasting real transcripts, and shaping the system instructions and output format. Only after I had a repeatable prompt and useful feedback did I worry about deployment.
Designing prompts is product design. This visual pairs common meeting requests with a rigorous summary framework, reminding teams that when prompts are embedded in products, accuracy matters because you get one shot.
From there, I tested deployment paths with the smallest viable investment. I tried a custom chat in Replit and embedded it. It wasn’t the right interaction model for targeted feedback. I switched to a submission flow using a homework-style pattern: students upload their transcript, the system processes it, they get detailed feedback. Done. That worked—until automation reliability lagged. I wired it up in Zapier, then rebuilt it on AWS Step Function for robust retries and better error handling when scale introduced edge cases.
A reminder that AI needs context: a simple instruction becomes ambiguous without dates, roles, recipients, and report details, highlighting the limits of LLM knowledge and the value of precise, shared prompts.
Each iteration tested a different assumption. Iteration 1 (Claude): Can AI even do this? What makes good feedback? Iteration 2 (Replit chat): How should people interact with it? Iteration 3 (Zapier): Can I integrate this into the existing workflow with minimal engineering? Iteration 4 (Step Functions): How do I make it reliable at scale when things inevitably go wrong? I didn’t know the answers up front; I learned by building, shipping, and observing.
From AI Changes Everything (And Nothing At All), this visual reminds builders that curated, high‑quality prompts yield better LLM responses, while overloaded, noisy inputs derail reasoning and reduce reliability.
Ethical data practices are non-negotiable. Improving AI products requires inspecting traces—the user input, system prompts, tool calls, and LLM responses. For a coaching flow, that includes the uploaded transcript, the system prompts that define evaluation criteria, and the AI’s feedback. To fix issues, I look at traces where things went wrong—but only with explicit user permission. Too many AI products collect everything by default and review traces without clear consent. Don’t do this.
A visual explainer showing how structured inputs—documents, verified code, roles, metrics, and timelines—flow into a network to shape a single, clear LLM response, underscoring the power of context in generative AI.
In my products, users must explicitly grant permission for me to review their data. The consent is clear and specific. If they say no, I don’t see their data. Full stop. That forces me to rely on synthetic data for many tests and to engineer privacy into the architecture from day one rather than bolt it on later. It’s the right thing to do, and increasingly, it’s required.
A visual guide to orchestration: break a complex meeting recap into smaller LLM calls, gather action items, bullet points, and a detailed summary, then aggregate the outputs to boost accuracy and reliability.
Everything changes—and nothing changes. Yes, there are new skills you should master: prompt engineering to get the right output the first time; context engineering to give the LLM exactly what it needs; orchestration to decompose complex tasks into simpler steps; and evals to systematically measure quality. And the fundamentals still rule: solve the right customer problems with strong discovery; prototype and iterate to de-risk; and uphold ethical data practices as a design constraint, not an afterthought. The teams that win with AI will master both the new technical craft and the timeless product fundamentals.
A presentation slide visualizes AI orchestration: user prompts generate meeting summaries while a graph of RAG and LLM calls routes tasks to the best sources, underscoring that retrieving the right context drives better outputs.
If this resonates, pick one active workflow, apply the four AI skills end-to-end, and run a short discovery and eval cycle against a clear outcome. Then ship. You’ll learn faster than any slide deck could ever teach you.
This presentation slide maps how to assess AI: link inputs to outputs with datasets, code assertions, LLM-as-judge checks, and human reviews—centering the question, "Given the input, did we get the expected output?"
I’ve led and observed AI initiatives across fast-moving product organizations, and one pattern is unmistakable: “The AI revolution needs a departmental leader.” When that leader is unclear, pilots stall, risk mounts, and value gets trapped in proof-of-concept purgatory. When it’s clear, AI moves from demos to durable outcomes.
In my experience, IT is uniquely positioned to play that leadership role. IT sits at the nexus of data, identity, security, and infrastructure—exactly where scalable AI capabilities live. IT also has the vantage point to connect use cases across teams, manage risk, and operationalize change without derailing core systems.
Put simply, this is the promise: “Learn the key reasons why IT teams are uniquely positioned to be the strategic leaders of your company’s AI projects.” The reasons are pragmatic—access to systems of record, stewardship of data governance, ownership of integration patterns, and accountability for reliability and compliance—yet the impact is strategic.
Here’s how I frame the operating model. IT provides strategic leadership and platform stewardship; Product owns the outcomes; Engineering delivers services and integrations; Security and Legal codify guardrails; and Finance supports cost modeling. We establish tight collaboration through product trios (Product, Design, Engineering) that plug into an IT-led AI platform, enabling empowered product teams to ship safely and quickly.
Governance turns intent into repeatable action. I use outcomes vs output OKRs to force clarity on value, pair them with lightweight QBR cadences for course correction, and require architecture reviews that cover model/data governance, observability, privacy, and vendor risk. This ensures we can scale gen ai without surprise failures or compliance gaps.
On the delivery side, forward deployed engineers embedded with business units accelerate discovery and reduce translation loss. We leverage gen ai for product prototyping to validate desirability and feasibility early, then harden solutions on our shared AI platform. This keeps experimentation fast while maintaining an enterprise-grade backbone.
Roadmapping balances ambition with throughput. I tie product roadmapping and sprint planning to value streams, not just features, and I make stakeholder management explicit—especially with customer support, finance, and operations—so we design for adoption. For example, a customer support ai strategy isn’t a chatbot alone; it’s an outcome-driven service redesign, with training, playbooks, and measurable deflection and CSAT targets.
Success demands the right metrics. Beyond typical velocity measures, I track time-to-first-value, model quality and drift, cost-to-serve, and risk posture. These roll into OKRs that link frontline improvements (e.g., resolution time) to enterprise outcomes (e.g., gross margin, retention), giving executives confidence and teams a clear definition of done.
If you lead IT, this is your moment to step into strategic ownership and elevate AI from scattered experiments to a coherent platform. If you lead Product, partner with IT to align discovery, outcomes, and guardrails so empowered teams can move fast and responsibly. Together, we can turn AI from a buzzword into a durable advantage.
I keep seeing the same pattern: when people leaders try to be the “CEO of culture,” they stall. When they act like product managers, culture scales. In a recent deep-dive with Colleen McCreary, the Chief People Officer at Credit Karma, I explored exactly how to operationalize that mindset to drive durable results and employee retention at startups.
With more than 20 years of experience in HR, operations, recruiting and M&A, Colleen has headed up the people function at companies such as Vevo, The Climate Corporation, and Zynga. She’s also seen the early-stages and scaled through multiple IPOs and acquisitions, which means she has a great perspective on the people problems founders tend to run into as their businesses grow.
What stood out immediately is her operating system: she designs for the 80% and focuses on clarity, context, and consistency when building people organizations and crafting culture. As a product management leader, this resonates deeply with how we approach product roadmapping and sprint planning, as well as outcomes vs output OKRs — optimize for the majority use cases, make intent unambiguous, and deliver predictably.
She walks us through some really tactical examples of that work, including how her team approaches compensation at Credit Karma and the reason they do promotions quarterly. In my experience, this cadence functions like a product release train for your startup compensation strategy — reducing ad-hoc exceptions, creating transparent expectations, and reinforcing fairness. The result is higher trust and healthier decision velocity when headcount scales.
Equally powerful is her reframing of the role itself: she views the Chief People Officer not as the CEO of culture, but rather the product manager of the systems and tools that run the company. That shift unlocks rigorous thinking — requirements, trade-offs, user research, and iterative launches — for everything from onboarding and performance to recognition programs. Treating culture as a portfolio of interdependent systems turns soft notions into measurable, improvable products.
We also examined how rewards and recognition were incredibly different at Zynga and Credit Karma, and why career growth isn’t just about a promotion. I’ve seen teams accelerate growth by expanding scope, deepening skills, and enabling lateral moves — especially during the IC to manager transition — instead of over-indexing on title changes. When you define multiple growth paths, you give top performers more ways to win without distorting your org design.
Finally, we discussed whether to double down on strengths or focus on correcting weaknesses when it comes to performance. My playbook mirrors hers: set outcomes, coach to amplify superpowers, and shore up only the critical deficits that block those outcomes. This keeps the conversation anchored in impact rather than activity and aligns incentives across managers and teams.
If you’re a first-time founder or an early people leader, the takeaway is clear: stop looking for a cultural silver bullet. Build an operating system for people the same way you’d build a great product — define the problems, prioritize, ship incrementally, and measure what matters. When you do, culture stops being a slogan and starts becoming your most reliable growth engine.
Building a startup is equal parts craft and discipline. In my product leadership work, I’ve honed a repeatable approach for going from raw idea to real traction—and I often cross-check that playbook against the battle-tested experience of leaders I respect. I frequently reference insights from Gagan Biyani, co-founder and CEO of Maven, a company that empowers the world’s experts to offer cohort-based courses directly to their audience.
After being early at 3 startups that achieved over $1 million in run-rate in their first six months of going live, Gagan has learned some valuable lessons and seen a wide range of outcomes — from Udemy going on to IPO in 2021, to Sprig shutting down in 2017.
When I’m generating startup ideas, I start with open-ended exploration and a rigorous “problem inventory.” I look for founder–market fit, persistent pain points, and market signals that indicate urgency and willingness-to-pay. I also study competition to spot under-served segments or a wedge where a differentiated product discovery approach can win. The most common mistakes I see aspiring founders make are solution-first thinking, overvaluing total addressable market over real problems, and staying in stealth too long instead of testing in the wild.
Validation is where discipline pays off. I rely on minimum viable tests to rapidly de-risk assumptions and avoid false positives. My process mirrors the spirit of his “Minimum Viable Testing Process.” I define falsifiable hypotheses, run one-channel traction experiments, test willingness-to-pay early, and favor concierge or manual workflows before writing heavy code. These tight, timeboxed sprints force clarity on product-market fit signals while keeping burn low and learning velocity high.
Once the signals look promising, execution becomes a game of thoughtful sequencing. I explore multiple business models in parallel (subscriptions, usage-based, hybrid) while keeping the core value proposition crisp. Early go-to-market is founder-led GTM by design; I talk to customers daily, tune messaging, and iterate on onboarding until activation and retention curves stabilize. On the product side, I prioritize outcomes over output, set clear guardrails for roadmapping and sprint planning, and instrument the product to learn from every user interaction.
Co-founder selection and operating cadence matter as much as the idea. I look for complementary skills, shared values, and a bias for transparent conflict resolution. Before committing, we pressure-test collaboration with small, high-stakes projects, align on decision-making frameworks, and codify roles, equity, and vesting. As the company grows, I revisit these agreements to keep pace with evolving responsibilities and minimize execution drag.
If you’re eager to hear even more on finding startup ideas from Gagan, he’s teaming up with The Hustle’s Sam Parr to run an Ideation Bootcamp on the Maven platform — learn more and sign up here by May 2nd if you’re interested.
My takeaway: winning startups don’t depend on a eureka moment. They emerge from a disciplined loop—curious exploration, fast and falsifiable validation, and focused execution. If you apply these principles with persistence and empathy for the customer, you’ll increase your odds of finding product-market fit faster—and building something that endures.
I recently sat down with Melissa Tan to unpack the nuances between two PLG businesses and how growth strategy changes for a more complex product like Webflow. As I reflected on our conversation through the lens of product management leadership, I focused on what it really takes to design a high-impact growth organization, set rigorous goals, and evolve pricing and packaging without losing sight of customer value.
I spoke with Melissa Tan, GM of Self-Service and Head of Growth at Webflow and formerly Head of Growth and Monetization for Dropbox Business. Her experience scaling PLG motions across very different product surfaces offered practical signals on where to double down, what to sequence, and how to balance experimentation with long-term strategy.
Designing and structuring a growth org starts with mapping ownership to the user journey. I anchor cross-functional squads on outcomes across acquisition, activation, conversion, and expansion, with a shared platform and data foundation. Clear swimlanes, crisp interfaces with core product and marketing, and a consistent experimentation cadence keep velocity high while avoiding thrash. For PLG, I also recommend an embedded analytics function and strong partnerships with sales-assist and support to translate signals from self-serve to sales-led opportunities.
The right way to tackle goal-setting is outcomes-first. I favor outcomes vs output OKRs that ladder to a North Star and a small set of controllable, leading indicators (for example, activation rate, time-to-value, or successful workspace creation). I pair these with guardrail metrics to protect user experience and brand trust. Weekly reviews focus on decision quality and learning velocity, not just hit rates, so the team compounds insight even when experiments miss.
How Webflow’s pricing and packaging has evolved is a reminder that complex products require value-based packaging that clarifies who each plan is for and what milestones justify upgrade. When complexity rises, I encourage teams to simplify the fences, align packaging to clear value axes (usage, collaboration, security, or advanced workflows), and ensure in-product prompts communicate that value at the right moment in the journey.
How to calibrate pricing feedback comes down to triangulation. I segment qualitative input by customer size and use case, balance loud feedback with behavioral data (conversion by plan, downgrade reasons, add-on attach), and validate with structured research and live price tests. The aim is not to chase every request, but to isolate willingness-to-pay drivers, reduce friction for the majority, and preserve premium features that genuinely anchor expansion.
In this piece, I cover the essentials: designing and structuring a growth org, the right way to tackle goal-setting, how Webflow’s pricing and packaging has evolved, and how to calibrate pricing feedback. My goal is to leave you with a practical blueprint you can adapt to your PLG startup—one that aligns teams, accelerates learning, and translates product value into durable growth.
Org design is one of the highest-leverage tools I have as a product leader. When structure, incentives, and decision rights align, execution compounds. When they don’t, even great people and strategy stall. In this narrative, I share how I approach company structure, drawing on hard-won lessons from complex re-orgs, “GM-led” models, and the realities of pricing, packaging, and planning at scale.
Here’s the backbone of my philosophy. First, the principles of effective org design matter more than any single chart. I relentlessly return to five anchors: #1 Align on goals; #2 Separate design considerations from human considerations; #3 Define clear reasons each team exists; #4 Design for durability; #5 Be very intentional with comms. These make tradeoffs explicit, reduce churn, and clarify ownership so we can move faster with more confidence.
On timing, there are clear signs your company needs a re-org. When multiple teams chase overlapping goals, when decision latency rises, when cross-functional friction becomes the norm, or when strategy evolves but responsibilities don’t, it’s time to revisit the design. I look for outcome drift in OKRs, blurry escalations, and too many “two owners” problems as leading indicators.
Tradeoffs are inevitable. I surface them early: speed vs. cohesion, specialization vs. customer journey continuity, centralization vs. autonomy. I make the tradeoffs explicit in a one-page brief and tie them back to company goals. This keeps us honest about why we are changing the system—and what we expect to get in return.
Square’s “GM-led” structure offers a useful reference point. The core idea: give a single accountable owner end-to-end responsibility for a business (product, P&L, and cross-functional performance), then architect adjacent teams to enable—not dilute—that accountability. In my practice, I define crisp swimlanes, escalation paths, and shared principles for collaboration at the seams so GMs move fast without fragmenting the customer experience.
Why Square centralized GTM speaks to a broader truth I’ve seen across SaaS: fragmentation in go-to-market creates inconsistent messaging, pricing confusion, and channel conflict. Centralizing GTM can raise the quality bar on positioning, funnel health, and field enablement—while GMs retain the voice of the customer and set product priorities. The key is a tight contract: who owns narrative, who owns quota, and how we arbitrate tradeoffs.
Managing pricing and packaging across a complex org is a system design problem. I establish a single authority for pricing strategy and guardrails, with clear input rights from GMs and Finance. We define canonical metrics for willingness to pay, price elasticity, bundle attach, and churn. This lets us run structured experiments while protecting long-term brand trust and ARR quality.
I put real weight on written principles. Examples of Square’s written principles remind me that great organizations reduce ambiguity by codifying how decisions get made. In my teams, we document decision rights (DACI/RACI), escalation patterns, and what “good” looks like for roadmaps, customer research, and launch criteria—so we don’t reinvent governance in every meeting.
How Square determines what each GM owns maps well to a pattern I use: define the customer journey first, then assign ownership in contiguous slices that minimize handoffs. If an interface is high-traffic or monetization-critical, it deserves a single accountable GM. Shared platforms (data, identity, payments) live in enablement groups with SLAs and portfolio-level success metrics.
Collaboration across GMs and products improves when we create durable seams. I use recurring GM councils, shared north-star metrics, and documented interface contracts. We align on joint bets for the year, budget for cross-org work, and maintain escalation rituals so debates are fast, respectful, and final.
Key lessons on planning and decision-making at scale: time-bound strategy, principle-led tradeoffs, and ruthless clarity on who decides. I anchor annual and quarterly planning in a brief that includes goals, constraints, risks, and assumptions. When we disagree, we escalate once, decide once, and document why—so we can move on without reopening settled questions.
Designing incentives across a massive org means aligning pay, promotions, and recognition to the outcomes we claim to value. I tie variable comp to a balanced scorecard: growth and retention, customer satisfaction, quality of execution, and platform health. If incentives reward only top-line ARR, we’ll get short-term wins at the expense of durability.
Two reasons GM structures go wrong: ambiguous decision rights and platform underinvestment. If GMs can’t tell what they truly own, or if shared services don’t meet their needs, the model will fail. I fix this by clarifying ownership in writing and by setting platform SLAs backed by leadership enforcement.
When it’s time to change the structure, I follow a disciplined playbook. 6 Step re-org walkthrough: Step 1: Triggering the re-org—document the triggers and the goals; Step 2: Sketching a proposed org design—present two to three viable options with tradeoffs; Step 3: Checking against key criteria—stress-test against strategy, customer journey, incentives, and interfaces; Step 4: Finalizing approach with leadership—drive alignment and decision in a single forum; Step 5: Planning comms—sequence messaging for managers, then teams, then partners; Step 6: Executing comms—deliver clear narratives, FAQs, and next steps on the same day.
Signals a re-org worked vs failed show up quickly: decision speed rises, escalations drop, and outcomes improve without heroics. If confusion persists, shadow processes form, or engagement declines, the design needs another pass. I run 30/60/90-day health checks and tune incentives or interfaces before small issues calcify.
I continue to learn from industry operators, including 5 lessons from Alyssa Henry, CEO at Square, that reinforce my own approach: design for clarity, empower accountable owners, write down how we work, invest in platforms early, and communicate like the strategy depends on it—because it does. When we treat org design as a product, we earn compounding execution and a culture built to scale.
Every startup has a few hidden levers that, when pulled at the right time, deliver outsized results. As a product leader, I focus on finding those levers fast—by zeroing in on what truly drives customer behavior and by structuring experiments that compound learning. In this playbook, I share how I identify the key drivers of startup success, apply the Growth Lever framework, and adapt tactics across different business models without wasting cycles on vanity metrics or premature paid acquisition.
First, I anchor the strategy in a simple truth: the customer’s mindset is the ultimate growth driver. When I deeply understand why someone tries a product, what outcome they expect, and when they decide to trust it (or churn), growth stops being guesswork. That’s why I obsess over the customer journey—awareness, activation, retention, revenue, and referral—and use it to pinpoint bottlenecks that matter.
To operationalize this, I apply the Growth Lever framework. I map each step of the journey, quantify drop-offs, and prioritize interventions where a small improvement unlocks big gains. Instead of scattering effort across dozens of tactics, I concentrate experiments at the tightest constraint—whether that’s a broken onboarding moment, unclear value messaging, or a slow path to first value. The impact comes from focus, not volume.
Case studies reinforce this approach. For instance, when I analyze companies like Popsa: https://popsa.com/ and Shopify: https://www.shopify.com/, I look for the same pattern: where did customers first experience undeniable value, how quickly did they get there, and what changed when friction was removed? The lesson is consistent—clarifying the value moment and accelerating time-to-value often moves the needle more than any top-of-funnel push.
Customer research is my unfair advantage. I run structured interviews to uncover language, triggers, anxieties, and “jobs to be done.” I avoid leading questions, ask for concrete stories instead of opinions, and probe for the exact moment of conversion or abandonment. Then I translate those insights into product copy, onboarding flows, and pricing tests that align with how customers already think and decide.
I also watch for the triple threat of founder failure modes: chasing growth channels before product-market fit, optimizing local maxima instead of diagnosing constraints, and delegating growth too early. Founder-led growth strategies counteract this by keeping discovery, positioning, and early sales close to the founder until the core motion is repeatable. It’s the fastest way to learn, and it prevents premature scaling.
Unlocking growth bottlenecks requires sequencing. I time interventions deliberately: first tighten the ideal customer profile (ICP), then sharpen the value proposition, then smooth activation, and only then scale acquisition. When the sequence is right, each next step amplifies the last. When it’s wrong, spend increases while conversion and retention stagnate.
On experimentation, I prefer simple, falsifiable tests that isolate a single hypothesis—especially around activation and pricing. I predefine success criteria, run lean tests, and document learning rigorously. The goal is to make decision quality compounding: over time, the team gets faster at seeing what works and why.
Early on, I rarely recommend paid marketing. Most startups don’t need it to find traction; in fact, it often masks core issues and delays the hard work. Instead, I rely on customer interviews, founder-led sales, direct outreach, and product-led loops to validate whether the core value resonates. Paid channels become multipliers only after the core engine is efficient.
For sales-driven companies, I treat the sales process itself as a lever. I tighten ICP, refine discovery questions, align messaging to the buying triggers, and shorten the path to a compelling demo. In B2B sales, this often means proving value with a wedge use case, anchoring on outcomes instead of features, and engineering fast wins that build internal champions.
One concept I return to repeatedly is finding customer “locksmith moments”—those specific instances when the product unlocks a stubborn pain with surprising ease. Once I isolate that moment, I redesign onboarding, messaging, and pricing to get customers there faster and more reliably. That shift alone can transform activation and retention.
The power law of business reminds me to prioritize ruthlessly: a handful of decisions and experiments will drive most of the growth. I measure aggressively, kill distractions quickly, and double down on what demonstrably works. Momentum comes from stacking these wins in sequence.
Referenced examples and resources that often inform my thinking include benchmarks and patterns from companies across categories:
Airbnb: https://www.airbnb.com/
Bold Commerce: https://boldcommerce.com/
Calm: https://www.calm.com/
Caribou: https://www.usecaribou.com/
eBay: https://www.ebay.com/
FATMAP: https://fatmap.com/
PayPal: https://www.paypal.com/
Popsa: https://popsa.com/
Shopify: https://www.shopify.com/
Sonic Jobs: https://www.sonicjobs.com/
If you’re leading product or growth, my advice is simple: get uncomfortably close to your customers, trace their journey moment by moment, and pull the few levers that change behavior at scale. When you do, growth stops being mysterious—and starts being methodical.
I’m endlessly curious about what really moves the needle in product management—what separates a good developer tool from a beloved platform, and a growing company from a market-defining one. Sentry’s story is a blueprint I return to often, because it proves that focus, speed, and a healthy disregard for conventional wisdom can compound into outsized outcomes.
David Cramer is the co-founder of Sentry, the leading open-source error monitoring tool used by over 90,000 companies. A self-taught engineer, he went from 9th grade high school dropout and Burger King manager to building one of the most widely adopted developer tools in the world — by working hard and rejecting conventional wisdom. As of 2022, Sentry is valued at over $3 billion. David now serves as Chief Product Officer, after previously holding roles as CEO and CTO.
Here’s how I translate that journey into a practical playbook for product leaders. The non-linear start matters. “Learning to code through gaming” and “Dropping out of high school” may sound like detours, but they underscore a truth I’ve seen repeatedly: capability compounds fastest when you bias to action. “Building infrastructure at Disqus” sharpened the instincts that later shaped Sentry’s architecture and developer experience. And the remark “Software is not that hard” isn’t flippant—it’s a provocation to simplify aggressively, ship faster, and let real usage drive prioritization.
The origin story is a masterclass in bottoms-up product discovery. “Early interest in open source” created a natural surface area for feedback and trust. “The birth of Sentry” traces back to “How an code snippet grew into a ubiquitous monitoring platform”—a reminder that the best products often start as specific, useful utilities that earn their right to expand. And yes, “Why open source is an underrated distribution hack”: developers discover, adopt, and advocate when the product solves a painful problem with minimal friction. In my own roadmap decisions, I anchor on the same sequence—useful utility, instant setup, visible value, and a path to depth without forcing it.
Founders and product leaders stumble in predictable ways. “Two common founder mistakes” I see and Cramer’s story echoes: chasing novelty over necessity, and over-complicating early scope. “David’s unwavering focus” and “Finding conviction in decisions” show up as disciplined pruning—saying no to adjacent opportunities to win the core use case first. Equally, “More confidence, less ego” and the candid truth that “You’re gonna mess up” are cultural guardrails. Build mechanisms for fast feedback, reversible decisions, and postmortems that tighten the loop between signal and response.
On growth and go-to-market, Sentry reinforces principles I rely on. “Sentry’s journey to venture backing” followed traction, not the other way around; financing amplified momentum rather than manufacturing it. “How Sentry found PMF” came from obsessive product quality and clear value, not a clever pitch. The debate “Is sales valuable?” is resolved by context: high-velocity PLG can coexist with targeted sales when the product already sells itself. “Money is not the hardest problem”—focus and prioritization are. And the timeless warning, “Marketing won’t fix a bad product,” keeps the team oriented around durable value creation. “What makes Sentry’s market unique”—a critical, always-on workflow with near-universal developer demand—meant that “Why brand will always matter” wasn’t about polish for its own sake; it was about trust, clarity, and credibility with developers. Finally, “Eliminating all competition” is less about adversaries and more about erasing reasons a user would choose anything else: lower time-to-value, better signal-to-noise, and relentless polish where it counts.
The broader ecosystem threads are instructive, too. Touchpoints with Heroku, Dropbox, Stripe, Datadog, Okta, Oracle, Uber, Y Combinator, VS Code, Cursor, WindSurf, Yandex—and the perspectives of leaders like Aaron Levie, Max Levchin, Omar Johnson, and Satya Nadella—map to a shared pattern: build for developers, reduce cognitive overhead, and compound trust through consistent execution.
My distilled playbook for product leaders: prioritize clarity of problem and ruthless scope reduction; ship fast to earn trust, then deepen the product only where usage demands; use open source or frictionless entry as an adoption wedge when the audience is developer-first; layer brand on top of truth—signal speed, reliability, and craftsmanship; and design an operating cadence that turns mistakes into momentum. These aren’t slogans; they are operating constraints that consistently convert attention into advocacy.
When I look at Sentry’s trajectory, I’m reminded that the most durable products are built at the intersection of utility and taste. Utility earns adoption; taste earns loyalty. Do both, and you don’t just acquire users—you build an enduring market position that compounds, one excellent decision at a time.
The product operating model is getting a lot of airtime for good reason. In my experience leading product and driving change across complex organizations, it offers a pragmatic way to build technology-powered solutions that customers love while delivering measurable business results.
What is the product operating model? I anchor teams on first principles: it’s not a process checklist—it’s a way of operating. As one leading thinker puts it, “The product operating model, also referred to as the product model, is a conceptual model based on a set of first principles that leading product companies believe to be true about creating products.” It’s “about consistently creating technology-powered solutions that deliver value to customers and that also drive results for the business. It’s about achieving outcomes versus merely producing output.” That framing matches exactly what I’ve seen separate high performers from the rest.
A clean visual distills the product operating model—covering how products are built, how problems are solved, and how to choose which problems to tackle—ideal for teams moving from pilots to enterprise-wide transformation.
Why adopt it? Because too many organizations swing between two extremes—beloved products that can’t sustain the business, or hard-charging business tactics that burn customer trust. The product model forces a both/and mindset: customer value and business outcomes. The biggest triggers I see for making the shift are heightened competition, visible frustration with the status quo (lots of spend, little impact), and a clear view of the upside when you manage by outcomes instead of deliverables.
Clean, modern visual underscores a core promise of the product operating model: delight customers and deliver measurable business outcomes. A timely teaser for organizational change content on scaling from pilot teams to full transformation.
How is it different from the project model? Projects start and stop; products evolve. When you manage by projects, you optimize for scope, budget, and dates—often at the expense of learning. When you operate as a product organization, cross-functional leaders (product, design, engineering) own the problem space and decide which customer problems to prioritize, in continuous conversation with stakeholders about business context and constraints. The litmus test: are teams funded and measured by outcomes, or by a backlog of features and deadlines?
A crisp reminder that projects end while products evolve—the mindset shift at the core of a product operating model. Great for posts on moving from pilot teams to enterprise adoption and delivering continuous customer value.
Can a hybrid approach work? Early on, yes—and it’s often the smart path. I strongly recommend piloting with a small number of teams while the rest of the organization continues working in the project model. Use pilots to learn, de-risk, and build internal proof points. That said, some work will remain project-based (e.g., regulatory, compliance, or one-off migrations). The goal isn’t purity; it’s pragmatism.
Change works best in waves, not a tidal surge. This visual champions pilot teams and staged rollout, showing how a product operating model scales successfully when leaders avoid all-at-once transformation.
How does continuous discovery fit? Continuous discovery is the operating system for deciding which problems to solve and how to solve them. Practically, that means weekly customer touchpoints by the team building the product, lightweight research to learn fast, mapping opportunities, and testing assumptions to reduce risk—all in pursuit of a clearly defined outcome. If you don’t learn continuously, you default to guessing continuously.
Continuous discovery helps teams choose the right problems and solutions. Explore how the Product Operating Model moves from pilot teams to enterprise-wide adoption—and why discovery is the engine of transformation.
How long does transformation take? Longer than most leaders think. Changing funding models, planning rituals, decision rights, and team habits is measured in years, not months. Pace yourself, stage the rollout, and expect to iterate on org design, coaching, and governance.
Big change isn’t overnight. This visual from our Product Operating Model series highlights the reality: scaling from pilot teams to full transformation takes time, steady learning loops, and aligned leadership.
Is your organization ready? I look for two CEO-level signals: a genuine belief that how you operate today won’t win tomorrow, and felt pain with the current results (missed targets, margin pressure, slipping share). Transformation is hard; without executive conviction, resistance will stall progress.
Even in heavily regulated sectors, a product operating model can thrive. Learn how to adapt governance and compliance without losing speed—from pilot teams to enterprise-wide scale.
What are signs it’s working? During planning, you fund teams and outcomes—not projects. Day to day, outcomes trump outputs. Product teams are empowered to solve customer problems (not merely deliver requests). Stakeholders contribute context and constraints, not solutions. Most importantly, your outcome metrics improve over time.
A side-by-side snapshot of how product work changes from early startups to large enterprises—shifting from directional outcomes to transparent processes, stakeholder management, and accountable leadership.
Will it work in regulated industries? Yes. Constraints shape the solution space, but the underlying truth remains: products are never done. In highly regulated environments, continuous discovery, tight risk management, and fast feedback loops are even more critical.
Shift from big-bang training to smart scaling. Start with pilot teams, learn fast, and extend practices that work. This post explores how a phased product operating model reduces risk and builds lasting capability.
Startups vs. enterprises: Early-stage teams can start with a directional outcome (who you serve and what you aim to change) and evolve to measurable outcomes as signal strengthens. The anti-pattern is “idea-first” debates that devolve into whether-or-not arguments. Even with an idea in hand, interview customers, map the opportunity space, story-map solutions, and surface assumptions to test. In large enterprises, the challenge shifts to scale: more stakeholders and gatekeepers, a greater need to show your work concisely, and stronger accountability rituals so leaders can manage by outcomes without dictating outputs.
To scale a product operating model, leaders must be all-in. This graphic spotlights two CEO mindset shifts: accepting that the old operating mode fails and recognizing the real cost of the status quo.
What does failure look like? A narrow transformation that trains product managers but leaves funding, planning, decision rights, and stakeholder behaviors unchanged. If you spot this pattern, pause and reset: recommit at the executive level to outcomes-based funding, change the operating cadence, and invest in coaching for leaders and teams.
In a product operating model, managers are coaches first. This quote underscores that real transformation starts by developing people's skills, building capable teams before scaling from pilot initiatives to enterprise-wide change.
The biggest mistake I see is trying to roll out to everyone at once. Broad, simultaneous training creates confusion, fuels resistance, and overwhelms your enablement capacity. Start small, prove value, fix systemic blockers, and then scale.
Meet the Product Trio—product manager, designer, and software engineer—the nucleus for moving from pilot teams to full transformation, aligning collaboration across discovery and delivery.
How does remote or distributed work affect the model? It raises the bar on clarity and connection. Define core collaboration hours, codify working norms, and be explicit about when to switch from async to live. Build lightweight rituals—discovery reviews, outcome check-ins, assumption-test demos—that create trust and fast feedback across time zones.
Pilot teams prove the product operating model can work. This clean visual highlights the first step of transformation—start small, validate results, and build momentum toward organization-wide change.
Roles and responsibilities change in meaningful ways. The CEO must champion outcomes-based funding and empower teams to own the problem space. Product leadership’s primary job is coaching—developing skills, modeling outcome management, and making strategic context accessible. Teams operate as small, cross-functional units (often a product manager, designer, and engineer, plus data or product marketing when needed). Keep the group as small as possible while still making informed decisions; bigger groups slow decisions and dilute ownership.
Pilot teams expose the friction and blockers you’ll face on the path to a full product operating model. This clean visual underscores the message: surface resistance early so transformation can progress.
Empowerment doesn’t mean teams do whatever they want. It means they own figuring out the best way to achieve an outcome within clear business constraints. Leaders provide the why and the guardrails; teams own the how.
Launching a product operating model starts with the right pilots. This graphic spotlights five factors to weigh—relationships, learning mindset, existing skills, access to customers, and the product's lifecycle stage.
Pilot teams are your change engine. I select a handful of teams most likely to become bright spots—familiar with each other, hungry to learn, fully cross-functional, with reliable customer access, and working on products in an “explore” or “invest” lifecycle stage. Small organizations might start with one pilot; mid-size with two to four; large with up to five. The point is to learn, not to boil the ocean.
Kickstart your product operating model with pilot teams set up to win: align on business context, ensure customer access, equip the right tools, remove friction so they move fast, and foster cross-functional collaboration.
How do I set pilots up for success? First, give them a clear outcome and rich business context. Second, insist on regular customer conversations to uncover unmet needs and prioritize opportunities. Third, build the muscle for evaluating whether they built the right thing through quick, targeted assumption tests. Fourth, shorten delivery cycles by right-sizing work to accelerate learning. Fifth, teach collaboration skills—show your work, externalize your thinking, and respect each discipline’s expertise—so the team can storm and reform productively.
Kickstart your product operating model with pilot teams. This visual spotlights three musts: back their outcomes, understand outcome‑focused work, and foster transparency and collaborative decision‑making.
What should leaders do differently during pilots? Align on the team’s outcome and invite relevant stakeholders into outcome definition and context-sharing. Learn to manage by outcomes, not outputs, and clarify when feedback is a suggestion versus a decision. Create predictable rituals where teams share what they’re learning, what they’ll learn next, and what’s blocking them. Transparency builds trust; trust enables speed.
Scale your product operating model by making learning public. Encourage forums, demos, and showcases where teams share insights, turning pilot wins into organization-wide momentum.
Which rituals help pilots share progress? I like “discovery-delivery demos” where teams show the latest insights, the opportunity space they’re focusing on, the assumptions they’re testing, early signals from tests, and the decision implications. Keep it concise and outcome-linked so leaders and peers can coach effectively.
Before taking a product operating model beyond pilot teams, fix the patterns you've found. Resolve recurring issues early to reduce risk, build confidence, and enable a smoother, organization-wide transformation.
How do you scale beyond pilots? Start by fixing systemic issues that surfaced across pilots: upgrade planning and funding to outcomes, standardize access to customers, invest in capability building, and clarify decision rights. Then expand in waves, pairing newer teams with experienced coaches and reusing the same operating cadence that worked in pilots.
Leaders can boost pilot teams by setting rituals, reducing bias, and making communication explicit. This quick checklist shares four habits that keep work visible and aligned during a product operating model transformation.
Expect and manage resistance. From pilot teams, you’ll hear, “We don’t have time,” “I don’t want to be a beginner again,” or “That will never work here.” Treat these like objections to understand. Unpack delivery pressures, normalize the discomfort of learning, and make the case for change by contrasting current pain with desired outcomes. From leaders and stakeholders, expect attachment to favored solutions, discomfort with reduced control, and update bottlenecks. Address this by sharpening outcome definitions, making strategic context accessible, and committing to clear check-in points.
Pilot teams often push back with time, comfort, and context concerns. Naming these patterns sparks constructive dialogue and clears the path from experimental pilots to a durable, organization-wide product operating model.
The mindset shift that unlocks everything is outcomes over outputs. Success isn’t shipping; success is impact. Without a clear, meaningful outcome, teams stay busy but struggle to move the needle—and they can’t tell what’s working. Tie work to outcomes, instrument the experience, and let evidence guide decisions.
Leaders can stall a product operating model by clinging to old habits—prescribing solutions, holding tight to control, and demanding every decision cross their desk. Use this prompt to spark dialogue and reset expectations.
Collaboration is the other non-negotiable. When product, design, and engineering collaborate from the start, you reduce rework, make smarter trade-offs, and ship solutions that are valuable, usable, and feasible within your constraints. Silos optimize individuals; collaboration optimizes outcomes.
Move from shipping more to achieving more. This visual underscores the product truth: prioritize measurable outcomes over busywork outputs to steer teams from early pilots to scalable, organization-wide transformation.
If you’re embarking on this journey, start small, learn loudly, coach relentlessly, and scale what works. That’s how you move from pilot teams to full transformation without losing momentum—or your people.
I’m endlessly fascinated by products that start as simple, personal tools and then break into the mainstream on the strength of real user pull. Abhinav Asthana is the co-founder and CEO of Postman, the world’s leading API collaboration platform used by millions of developers and thousands of companies. What began as a personal itch, a simple Chrome extension Abhinav built to make his own API work easier, became a global phenomenon within weeks. Studying this trajectory through a product management lens reveals a masterclass in building for developers, layering capabilities with intention, and scaling from utility to platform.
What struck me first is the courage and clarity required to move from India to Silicon Valley in pursuit of scale, paired with the discipline to recognize the exact moment a product can win. That inflection point is rarely about vanity metrics; it’s about unmistakable patterns in activation, retention, and community pull. Postman exemplified this with an early, authentic focus on developer experience—then widened the aperture to serve adjacent non-developer workflows without diluting its core value. That balance between focus and expansion is the heartbeat of platform strategy.
I see the early chapters of this story as a deliberate stacking of advantages. Early exposure to computers created compounding curiosity. The first entrepreneurial experiments—and the ones that didn’t make it—sharpened taste for what matters. Building BITS360 in college fostered an instinct for community, distribution, and bottoms-up adoption. Before Postman, there were real problems worth solving: fragmented API tools, inconsistent collaboration, and brittle handoffs across teams. The Chrome extension was the simplest surface area for solving a high-friction workflow, and its rapid adoption validated both the problem and the approach.
Team formation followed the same product logic: reduce ambiguity, increase velocity. Clear roles prevented chaos, especially in the messy middle between early traction and repeatable growth. The transition from a beloved free tool to a sustainable SaaS model didn’t hinge on a single pricing move; it emerged from a series of monetization experiments aligned to usage, collaboration needs, and security requirements. By treating pricing and packaging as iterative product design, the team found a path that worked for individual developers, small teams, and eventually enterprises.
The platform leap came from building true collaboration into the product’s DNA, not bolting it on. That meant designing progressive complexity: let users start with something intuitive and powerful, and then reveal deeper capabilities as their use cases evolve. This principle is especially potent in developer tooling, where simplicity earns trust and extensibility unlocks scale. Navigating market and customer needs required a constant dialogue between bottoms-up signals and top-down requirements, culminating in a go-to-market motion that could bridge the developer-enterprise divide without sacrificing usability.
Community became a growth engine because it wasn’t treated as marketing theater; it was treated as product. Documentation, collections, templates, and shared workspaces formed a living knowledge graph that accelerated onboarding and cross-team collaboration. The so-called open-source dilemma wasn’t resolved by dogma, but by clarity: lead with value, integrate with the ecosystem, and differentiate where the product’s opinionated approach matters most. Along the way, the team honored the initial promise to developers while steadily expanding the surface area for product, security, and business stakeholders.
My takeaways for product leaders are refreshingly actionable. Start with a narrow, undeniable use case and instrument for activation and retention before scaling. Design for progressive complexity so the product grows with users rather than overwhelming them. Treat community as a first-class product surface. Use monetization experiments to learn, not to guess. Establish crisp roles to preserve speed as the team grows. And build a go-to-market strategy that respects developer autonomy while meeting enterprise standards for governance, compliance, and collaboration.
Postman’s journey underscores a timeless pattern in product discovery and platform building: when you solve the right problem with a deceptively simple experience, you earn the right to expand. From there, the craft is in sequencing—what you add, when you add it, and how you keep the product’s center of gravity rooted in real user value. That’s the difference between a useful tool and a category-defining platform.
AI Agents are reshaping how businesses deliver service, earn loyalty, and create measurable value. From my vantage point leading product management, I see this shift accelerating across support and CX as organizations move from experiments to production-grade systems.
Very soon, I believe AI Agents will handle the majority of customer service – and eventually, every customer interaction. Human teams won’t disappear, but their roles will evolve from answering questions to analyzing performance, improving systems, and designing better customer experiences.
The pressure to adopt AI is real. So is the opportunity. The leaders who win won’t just add technology; they’ll redesign operations to capture durable value while safeguarding customer trust.
But for many support leaders, the path forward is still unclear. Where do you start? What should success look like? How do you actually test and deploy these solutions? I hear these questions every week, and I’ve seen promising initiatives stall without a clear roadmap, evaluation framework, or governance model.
That’s why we created The AI Agent Blueprint: a strategic map for support, CX, and AI transformation leaders. It’s designed to help you launch fast, scale with confidence, and achieve meaningful business transformation with AI.
1. Launch it. Go from zero to a successful deployment. Get immediate value from an AI Agent. 2. Scale it. Rewire your organization to sustain and expand impact.
Part 1 – “Launch it”
Learn how to unlock immediate efficiency and value from an AI Agent. We cover how to build a business case, evaluate and deploy an AI Agent, and prove its impact, fast.
You’ll learn how to:
Launch it. Scale it. The AI Agent Blueprint lays out a clear framework to deploy and grow automation in customer service. Explore the step-by-step guide at fin.ai/blueprint and turn pilots into production results.
Get clear on what an AI Agent is: Discover why they’re different from chatbots and how they work. Build a business case: Prove the basic economics of AI, decide whether to buy or build, and get the buy-in and budget you need to move forward. Evaluate an AI Agent: Learn how to define success, choose the right evaluation criteria, and run a focused, high-impact assessment with our four-step framework. Deploy with confidence: Build a deployment plan that balances speed with safety. Learn what to expect at each stage. Continuously improve performance: After launch, your AI Agent becomes a system to manage. We’ll show you how to implement a repeatable process to train, test, deploy, and optimize.
Part 2 – “Scale it”
Launching AI is only the beginning. To unlock its full potential, you need to rewire your systems across three core pillars: → Customer experience → Organizational and system design → Economics
If you stop at launch, results will plateau. Your team won’t transform how they work. The system won’t evolve – and neither will the value.
The second part of the Blueprint shows you how to scale AI intentionally and sustainably. That means:
Designing AI-first customer journeys and building trust with AI. Embedding new roles, AI-first systems, governance structures, and ownership models. Rethinking how support is measured and funded in an AI-first world by exploring new metrics, ROI models, and reinvestment strategies to elevate your support function from a cost center to a strategic growth lever.
This is where AI becomes infrastructure and support becomes a lever for growth.
In practice, this is how I recommend teams approach their customer support AI strategy: start with a narrow, high-value use case, define your success metrics and guardrails, and iterate quickly with human-in-the-loop quality reviews. Once you establish confidence, expand coverage, evolve your organizational design and governance, and update your ROI model to reinvest efficiency gains into customer experience. This blueprint distills the lessons I’ve learned guiding gen AI programs from pilot to platform—so you can accelerate time-to-value and de-risk deployment.
