Category: Uncategorized

21 Practical Ways I Use AI at Work to Move Faster, Cut Risk, and Build an AI Product Toolbox

I recently shared 15 ways I'm using AI at home—from fixing cooking disasters to researching school bonds—and those experiments turned into real skills: learning to chat with large language models (LLMs), providing the right context, verifying results, and more.

Now it’s time to apply those same skills at work. The stakes feel higher, the problems are more complex, and we have to navigate when and how AI is acceptable at work. But the foundation we built at home makes the leap far less intimidating.

My goal is to inspire you to start experimenting (if you aren’t already). Along the way, you’ll add practical techniques to your AI product toolbox.

A clean address form ready for automation: fields for Attention, Address, City, State, ZIP, and Country invite AI-driven autofill, validation, and routing, accelerating workflows and reducing manual typing at work.

Using AI at home taught the basics—prompting, context windows, and hallucinations. At work, I layer in orchestration and automation. Don’t worry; we’ll take it step by step.

To make this actionable, I organize my work use cases by complexity, so you can start at the top and move down as your confidence grows. I group them into five buckets: Translator, Do the Work, Researcher, Writing Partner, and Coding Partner. Everyone can access the first three categories; I reserve the last two for subscribers.

Clear course policies at a glance: switch cohorts up to 14 days before start, transfer a seat to another student until the day prior, and get scaled group discounts for Deep Dive courses, though Fundamentals is excluded.

Translator: I’ll start simple with low-stakes examples that build confidence and momentum.

1) Translate this email for me. My last name is common in both Spanish and Portuguese, so people often assume I speak both. I can get by in Spanish, but not Portuguese. When I get an email in another language, I ask ChatGPT for a translation. I used to use Google Translate, but ChatGPT tends to interpret context better. It’s a quick win that gets you comfortable with LLM interactions.

Curious which formats perform best? These heatmaps compare category averages for impressions, engagements, and new followers—spotlighting podcasts for reach and 'Other' for follower gains.

2) Parse this address for me. I live in the United States and work with companies around the world. In Xero, I have to enter addresses by street, city, state/region, country, and zip code. For international addresses, I’m not always sure how to parse fields. ChatGPT is great at this, so I created a CustomGPT to avoid rewriting the prompt. I paste the address, and it returns values mapped to Xero’s fields. If you’re new to CustomGPTs, think of them as reusable prompt-and-context bundles you can share with colleagues. Skills I built: when to use a CustomGPT versus an ad hoc prompt, and how to templatize repetitive formatting tasks.

Do the Work: This is where the magic shows up—AI accelerates execution—provided you set clear guardrails and keep humans in the loop where quality matters.

This concise social post tackles the “no differentiation” myth in B2B, highlighting how segmentation, team alignment, and a clear view of competitors reveal real product value—prompting readers to reflect and join the discussion.

3) Customer service assistant. My company offers a range of products and services, so we created a knowledge base with common questions and template answers to train support. But finding the right response in the moment is slow. I uploaded our content into a CustomGPT and instructed it to surface the most relevant templates, given an inbound email. The key decision: I did not let the model draft final replies. My admin uses suggestions to respond faster, but she remains responsible for the email content. Skills I built: discerning where human oversight is essential and using LLMs to speed up, not outsource, attention-intensive work.

4) Social media analysis. I share my work on social channels and want to know what resonates. LinkedIn lets me export analytics on top posts. Each month I export the last 30 days, ask a CustomGPT to create topic and category heat maps for impressions, engagements, and followers, and I chart trends over time. Patterns become obvious—personal stories drive impressions and engagement; short-form video drives followers. This workflow, inspired by Andy Crestodina at Orbit Media, turns raw analytics into actionable content strategy. Skills I built: using LLMs for data analysis and visualization, moving from exports to insights, and spotting outliers at a glance.

An AI-powered contract review snapshot flags risky clauses and where to push back. Clear labels—Dealbreaker, Needs Redlining, None Found—help teams tighten IP rights, social media controls, refund terms, and injunctive relief.

5) Article summaries. I used to share Worthy Reads—recommended articles—on LinkedIn and X, and I wanted stronger summaries. I asked Claude to generate them in the author’s voice, not “LLM voice.” I gave tone and style guidelines, writing samples, and a clear structure. Quality improved with each iteration. To save time, I automated the workflow with a Zapier zap: when I add a new article to my database, the Anthropic API generates a draft summary and emails it to me for a quick human review. If it looks good, I do nothing. If not, edits are one click away. Skills I built: providing precise context for tone and structure, creating a simple automation, and keeping a light human-in-the-loop review for quality.

6) ContractBot. I regularly review long legal documents and dislike every minute of it, so I built ContractBot as a CustomGPT. It started with a one-sided contract full of red flags—intellectual property, morality clauses, payment terms, and more. I asked ChatGPT to identify issues, we worked through them, and then I had ChatGPT write the reusable prompt that became ContractBot. Now I upload any new contract and get a summary of redlines tailored to my preferences. When new issues arise, I update the CustomGPT prompt, and it evolves with me. Skills I built: iterating preferences over time, using LLMs to translate and revise dense documents, and leveling information asymmetry during negotiations.

Need customer interview guidance fast? This snapshot rounds up five high-ranking guides with quick notes—perfect for scanning options and choosing the best how-to. Use it to kickstart research and structure your interview plan.

7) SEO keyword analyzer. “SEO is dead. People don’t use search engines. Now they just ask LLMs.” But LLMs still use search engines—so SEO is not dead. I still care about ranking for relevant terms, and I use ChatGPT to help. I give it a target keyword and one of my articles, then ask it to analyze the top ten Google results and highlight what they do that I don’t. I get a prioritized gap analysis. I don’t take every suggestion—I write for humans first—but many SEO improvements also boost readability, so it’s a win-win. This workflow, also inspired by Andy Crestodina, made me care about SEO because the effort is now minimal. Skills I built: competitive research and gap analysis, balancing SEO with human readability, and codifying a repeatable research pattern.

8) Landing page analyzer. I don’t love writing sales copy, but landing pages matter. I use ChatGPT to critique my course landing pages, with rich context: an ideal customer profile from real discovery interviews, a course syllabus, student testimonials, and the same knowledge base my support team uses. With all that context, I ask for a critique from the buyer’s point of view. Context is king—the more I provide, the sharper the feedback. I don’t accept every suggestion, and I still run demand and usability tests, but a second set of (virtual) eyes helps me move faster on a task I’d otherwise procrastinate. Skills I built: using LLMs to push through resistance, feeding the right context, and soliciting targeted “expert” feedback.

Messaging teardown in a sleek, dark theme shows how to turn interview findings into sharper copy: center ICP struggles with adoption and scaling, and rework the hero to speak directly to product leaders under pressure.

9) Podcast participation guide. I launched a new podcast, Just Now Possible, where I interview product teams about the AI products and features they’re building. Guests often need company approval to join, and I’d never had to ask for permission before. I set up a ChatGPT Project with background files—target listener, goals, and differentiation strategy—then asked it to draft a one-pager for executives explaining why their team should participate. It nailed the brief because the Project was already loaded with the right context. Skills I built: setting up Projects for ongoing domains and compounding context over time for higher-quality assistance.

10) Podcast episode titles, descriptions, show notes, and chapter marks. In the same Project, I paste episode transcripts and ask for titles, descriptions, show notes, and chapters. As volume grows, I’m transitioning this into a CustomGPT with actions so I can click “Generate episode metadata,” paste the transcript, and go. Later, I’ll add actions for social posts and more. I don’t need to design the full system upfront; I evolve it as needs emerge. Skills I built: when to move from Projects to CustomGPTs, how to define actions, and how to evolve LLM tools incrementally.

Explore how the Just Now Possible podcast turns real AI product work into practical guidance. This overview invites PMs, designers, and engineers to share decisions, showcase features, strengthen employer brand, and gain recruiting assets.

Researcher: If you’ve tried using LLMs as an expert researcher at home, the returns at work are even better. Here are two recent examples.

11) Choosing a new blogging/newsletter platform. After 14 years on WordPress, my site started breaking—plugin auto-updates caused critical errors, Google flagged 500s and performance issues, and I was over managing plugins. I’d also switched from Mailchimp to Kit and wasn’t thrilled. I considered Substack but had mixed feelings. I laid out constraints and goals in ChatGPT, compared options, and landed on Ghost. Before committing, I used ChatGPT to dive deep: theme customization, memberships, API documentation, and migration tasks. On a free trial, ChatGPT walked me through exporting from WordPress and importing into Ghost; Claude Code helped with theme tweaks. By the end of two weeks, I had imported data, customized the site, validated fit, and built confidence. We officially migrated in August 2025. Skills I built: tackling big projects with an AI guide on call, running structured vendor comparisons, and piloting major tech decisions with AI-assisted validation.

A draft episode description in dark mode outlines a talk on creating an AI Teacher Assistant for K–5 schools—covering post‑COVID pressures, why a chatbot interface failed, building a first RAG system, and lessons from real teacher use.

12) Academic research. I draw heavily from research on decision-making, problem-solving, and learning science, but I’m not an academic and can’t spend hours in journals. ChatGPT’s Deep Research changed that. Quarterly, I generate a report on topics like decision-making with parameters such as date ranges, peer-reviewed sources, and clear citations. I automated the pipeline so reports land in my Readwise inbox alongside other articles. I also seeded a course design Project in ChatGPT with Deep Research reports on scaffolding, modeling, and learning styles, so my course design support is evidence-based by default. Skills I built: running Deep Research on-demand and automating it so staying current is effortless.

Learning to use AI as a thought partner has been the biggest unlock for me. It’s hard to describe, so I’ll show you with detailed examples. I’ll start with how I write with AI—headline generation and copy editing—and quickly get to more advanced workflows. You’ll see how I set up subagents to review my writing from different perspectives, where I let LLMs draft versus where I insist on drafting myself, and why I now write in VS Code with Claude Code following along.

See how Ghost uses Handlebars to render posts and customize themes quickly. The screenshot highlights template helpers and a straightforward flow: download a theme, edit locally, upload in Ghost Admin, then activate.

These workflows helped me produce more, higher-quality content, and—unexpectedly—brought the joy back to writing.

I’ll also share how I use LLMs to help me code: how ChatGPT taught me to set up and use a Python Jupyter Notebook for eval data analysis, how I pair program with Claude Code, how I get Claude Code to generate high-quality unit and integration tests, and how I leveled up error handling with both Claude Code and ChatGPT. I have a light coding background; I couldn’t have done this without LLMs. Even if you don’t code today, there’s a lot here you can apply.

Evidence-backed scaffolding methods at a glance—gradual release, cognitive apprenticeship, task simplification, mentoring, and communities of practice—show how to teach AI skills, build confidence, and accelerate adoption at work.

As a reminder, those last two sections—my Writing Partner and Coding Partner playbooks—are for paid subscribers. I’ll also use comments to dig into your workflows. I hope you’ll join us.

I was initially reluctant to use LLMs as a writing partner. I’m not trying to outsource my thinking; writing is how I think. But staring at a blank page is real. I write, delete, and write again. The breakthrough was realizing the model doesn’t have to think for me—it can help me think more clearly. It can tell me when a draft is weak, offer structured feedback, and help me brainstorm ways to get unstuck. That’s how I began using LLMs as a true thought partner.

Inspired by this post on Product Talk.

October 25, 2025
Stop Being the ‘CEO of Culture’: Build Scalable People Systems Like a Product Manager

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.

Inspired by this post on First Round.

October 23, 2025
From Spark to Scale: My Playbook for Generating, Validating, and Executing Startup Ideas

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.

Inspired by this post on First Round.

October 23, 2025
Build a High-Impact PLG Growth Org: Structure, Goal-Setting, and Pricing with Melissa Tan

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.

October 23, 2025
Mastering Org Design at Scale: My GM-Led Blueprint, Re-Org Steps, and Pricing Signals

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.

October 23, 2025
How I Uncover Startup Growth Levers: Proven Customer-Led Tactics, B2B Plays, and Case Studies

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.

October 23, 2025
Defy Conventional Wisdom: Product Playbook from Sentry’s $3B Rise with David Cramer

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.

October 23, 2025
Proven Playbook: From Pilot Teams to Full Transformation with the Product Operating Model

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.

Inspired by this post on Product Talk.

October 23, 2025
From Chrome Extension to Global Platform: Product Lessons from Postman’s Breakout Journey

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.

October 23, 2025
Unveiling The AI Agent Blueprint: Launch Fast, Scale Smarter, Transform Customer Experience

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.

The AI Agent Blueprint is structured in two parts:

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.

The AI Agent Blueprint is live now.

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.

Inspired by this post on The Intercom Blog.

October 23, 2025
Master the Purpose of Prototypes: Proven Product Discovery Tactics for Breakthrough Results

Note: This is part of the product creator series of articles, based on the overview article, The Era of the Product Creator.

As a VP of Product Management at HighLevel, Inc., I’m constantly reminded that prototypes aren’t deliverables—they’re decisions. I recently revisited “The Purpose of Prototypes” from Silicon Valley Product Group, and it reinforced a belief I hold deeply: we prototype to learn faster than risk compounds. In product discovery, the right prototype at the right moment helps us surface assumptions, test them quickly, and focus our teams on evidence over opinions.

When I frame the purpose of a prototype, I anchor on four core risks: value (will anyone care?), usability (can they figure it out?), feasibility (can we build it with our constraints?), and viability (does the business model work?). Each prototype exists to retire a specific risk, not to approximate the final product. If we can’t name the risk and the assumption, we’re not ready to build anything—not even a prototype.

Here’s how I choose: I start with the lightest-weight artifact that can answer the next most important question. If I’m unsure about value, I’ll run a simple landing page, ad test, fake door, or concierge experience. If usability is unclear, I’ll move to paper sketches or a Figma click-through. If feasibility is in doubt, I’ll commission a quick engineering spike, an API mock, or a data model prototype. If viability is the concern, I’ll test pricing, packaging, or acquisition economics before writing a single production line of code.

In our practice, ai-based prototyping and gen ai are accelerants. We use AI to generate realistic UI states, draft microcopy, create test data, simulate edge cases, and scaffold throwaway services for feasibility spikes. This shortens cycles dramatically, especially when paired with disciplined product discovery methods and clear success criteria.

I’ve found that forward deployed engineers working hand-in-hand with design and product lead to our fastest learning loops. We timebox aggressively (often 24–72 hours), instrument every prototype for the signal we need, and refuse to promote ideas to the roadmap until the relevant risk is retired. The result is more confidence, less waste, and momentum that teams can feel.

One recent example: a deceptively simple pricing and messaging test revealed that what we thought was a killer feature didn’t drive willingness to pay—but the workflow time-savings did. A one-day value prototype saved us three sprints of build and a painful launch reversal. That’s the power of purposeful prototyping.

My operating cadence is straightforward: articulate the assumption, select the minimum viable prototype, define what success (and failure) looks like, run the test with the right users, then decide—proceed, pivot, or pause. Repeat until the key value, usability, feasibility, and viability risks are de-risked. Only then do we invest in production.

For product creators, this mindset is liberating. Prototypes are not about polish; they’re about progress. If you’re navigating the transition described in “The Era of the Product Creator,” leaning into focused, risk-targeted prototypes will transform your product discovery velocity and your product management leadership impact.

Inspired by this post on SVPG.

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

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

October 22, 2025