What happens when an AI starts giving advice in your voice—advice you’d never actually give? I’ve been thinking a lot about that question, and this conversation hit home for me as a product leader navigating the fast-evolving reality of AI “clones.”
Listen to this episode on: https://open.spotify.com/episode/7DNDIlIimwbbMOytArewRp?ref=producttalk.org | https://podcasts.apple.com/kh/podcast/bad-advice/id1794203808?i=1000756914818&ref=producttalk.org. Prefer video? Watch on YouTube: https://www.youtube.com/embed/RF4BwaeMMlg?feature=oembed
The episode examines AI “clones” built from podcast transcripts and public content—where the experimentation feels exciting, where it crosses ethical lines, and what happens when mediocre AI outputs get attributed to real people. The tension is real: when a bot confidently answers in your style but misses the nuance, “it’s not me” becomes more than a disclaimer—it’s a reputational defense.
We dig into the messy parts: IP ownership of open-sourced transcripts, the role of pirated books in LLM training sets, rising inference costs, and the uncomfortable economic question: if anyone can prompt “act like Teresa,” how do creators make a living? In my own decision-making, I look for clear consent, guardrails that prevent impersonation, and transparent UX that never confuses a synthetic perspective with a human expert.
This isn’t anti-AI. It’s a nuanced conversation about quality, consent, and remembering there are real humans behind the ideas.
Here’s how I translate the key takeaways into practice. Using AI for perspective is fine—equating it to the real person isn’t. Free-feeling AI outputs still rely on someone’s work. Expertise is more than past content—it’s context, judgment, and evolution. If someone’s work influences you, find a way to support them. These principles help teams benefit from gen ai without eroding trust or the creator ecosystem.
“Technically possible” doesn’t mean “ethically okay.” My AI Strategy playbook includes privacy-by-design, clear data governance on training materials, and a bright line between inspiration and impersonation. When we ship AI features, we label synthetic outputs, avoid mimicking living experts without permission, and create paths to compensate or promote the humans whose thinking underpins the experience.
I’ve also tested the “act like X” pattern to stress-test product quality. Even when outputs sound plausible, they rarely capture the expert’s mental models, trade-offs, or the evolution of their thinking—especially in complex product discovery work. That gap is the difference between average AI text and expert product management leadership.
If you listen, consider a few reflection prompts: Have you ever used AI to “act like” someone you admire? Could you tell whether the output matched that person’s actual thinking? How do you decide what’s ethically okay when using public content in LLMs? And how can we support creators while still embracing new tools?
Have thoughts on this episode or practices that have worked in your org? Share them below—I’m keen to learn how other teams are balancing innovation with integrity.
Note: This is part of the product creator series of articles, based on the overview article, The Era of the Product Creator. This series is for anyone who wants to create a successful product—whether or not you’ve had formal training or experience in product management, product design, or engineering.
Over the years, I’ve watched smart teams stumble because they treated a prototype like a product. The distinction is simple but vital: prototypes exist to learn; products exist to earn trust by delivering value reliably at scale. When we blur that line, we ship avoidable risk to customers and slow ourselves down later with rework.
When I build a prototype, I’m testing assumptions as quickly and cheaply as possible. It might be a clickable Figma mock, a Wizard‑of‑Oz demo, or a quick script stitching together a ChatGPT connector with a CustomGPT workflow. It’s intentionally disposable. I expect missing edge cases, fake data, hand‑waving on latency, and limited attention to security or privacy. The only goal is to answer the riskiest questions fast.
A product is a promise. It’s hardened for reliability, performance, security, and privacy‑by‑design. It’s observable with real analytics, supports CI/CD and rollback, meets accessibility guidelines, and can be maintained by empowered product teams. It has clear SLAs, incident management runbooks, and instrumentation that lets me track outcomes vs output OKRs and DORA metrics.
Keeping prototypes and products separate makes us faster and safer. Prototypes accelerate discovery; products operationalize value. If I catch myself “polishing” a prototype, I pause and either discard it or define the path to production with the right engineering rigor, data governance, and stakeholder management.
Here’s how I decide. In prototype mode, I timebox learning to days, not weeks, and focus on a single risky assumption—value, usability, or feasibility. I validate through qualitative research and usability tests, not vanity metrics. To graduate to product work, I require a crisp problem statement, evidence of problem‑solution fit, a technical plan for scale and observability, a privacy and threat modeling review, and a measurement plan (including minimum detectable effect) for upcoming A/B testing.
AI adds new wrinkles. For gen AI and agentic AI, I evaluate model behavior offline before exposing anything to customers. That includes prompt design, context window management, guardrails to minimize hallucinations, and clear fallback strategies. I define red‑team scenarios, logging for auditability, and policies for data retention and encryption as part of AI risk management.
A recent example: we prototyped an agent workflow in a day that felt magical in demos. We resisted the urge to ship. Instead, we added authentication, rate limiting, PII redaction, human‑in‑the‑loop review, observability, and in‑app guides and product tours for onboarding. Only then did we move to a limited release with a well‑defined go‑to‑market strategy and support readiness.
One more trap to avoid: calling a prototype an MVP. An MVP is still a product—minimal in scope but complete enough to deliver value, gather trustworthy data, and support customers. If you wouldn’t put your name on it or support it in production, it’s a prototype, not an MVP.
If you’re a product creator, align your product trios around this discipline. Use prototypes to learn quickly in discovery, and use products to deliver outcomes in delivery. That mindset protects customer trust, speeds iteration, and moves you toward product‑market fit with far less waste.
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.
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.
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.
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.
“Start with the story” isn’t a slogan for me—it’s a daily operating principle. As I guide product strategy and align go-to-market with product discovery, I’ve seen how a clear narrative unlocks focus, speeds decisions, and lifts execution. That’s why David Cancel’s perspective resonates so strongly: when you build from the story, you build momentum.
David has been a CEO and founder of multiple different companies throughout his career. He’s also been a software engineer, a serial CTO, and the Chief Product Officer at Hubspot, giving him a unique lens into company building and leadership at different levels. That combination of product, engineering, and executive leadership creates the kind of pattern recognition I rely on when coaching PMs and shaping product management leadership practices across teams.
In my experience, the fastest way to align product, marketing, and sales is to anchor everyone in the same narrative. David’s framing around storytelling at Drift, a conversational marketing and sales platform, crystallizes this. From screenplay writing inspiration, to how storytelling training is part of their onboarding, David shares how they teach storytelling and drive narrative internally at Drift. I’ve adopted a similar approach—story-first onboarding for product creators and PMs, so every spec, roadmap, and customer interaction reinforces the same promise and positioning.
The leadership muscle here isn’t just crafting a compelling story—it’s keeping altitude discipline. He also shares tactical advice for engaging with exec teams and getting better at zooming in and out as CEO, as well as some really tactical frameworks, including Charlie Munger’s practice of inversion, the weekly rituals Drift relies on, and how they use asynchronous video communication. I use these same moves: inversion to pressure-test roadmaps and risks, weekly rituals to reinforce priorities, and async video to scale clear, human communication without meeting sprawl.
On my teams, inversion clarifies trade-offs: before we pursue a bet, we ask, “If this fails, what will have been the likely causes?” That simple prompt improves product discovery, sharpens founder-led GTM motions, and accelerates product-market fit lessons. When we meet, we start with a crisp narrative—who the customer is, what their struggle looks like, and why our solution is the inevitable next step. Outcomes replace output, and teams rally around impact.
I’ve also found that storytelling is a coachable skill, not an innate talent. We run lightweight workshops where PMs deconstruct great narratives (including screenplay structures) and rebuild their own. The effect is immediate: clearer problem statements, tighter product roadmapping and sprint planning, and better executive readouts that move decisions forward instead of sideways.
If you want to dive deeper into David’s perspective, you’ll find practical resources worth bookmarking. You can follow David on Twitter at @dcancel. He also pens a popular newsletter called “The One Thing,” and hosts a great podcast called “Seeking Wisdom.” For reference, the books he mentioned in the episode include Jon Kabat-Zinn’s work on mindful meditation, and “The Passion Paradox” by Brad Stulberg.
To learn more about how Drift approaches storytelling, check out this article David wrote for Inc:
To learn more about Charlie Munger’s concept of inversion that David mentioned, check out this Farnam Street post: https://fs.blog/2013/10/inversion/
If you’re leading teams, think of story as a system: a shared language for product, marketing, and sales; a filter for priorities; and a mechanism for speed. It’s a must-listen for current founders and CEOs, and anyone looking to level up their leadership skills. When we start with the story, we don’t just communicate better—we build better.
I’m constantly looking for systems that outlast leaders and market cycles. When I picked up “Working Backwards,” which provides an inside look at the leadership principles and business processes that have made the company so successful, I recognized a playbook product teams can trust when the stakes are high and ambiguity is higher.
Bill Carr and Colin Bryar bring rare operator credibility to the topic. Bill started at Amazon in 1999, and went on to launch and run the Prime Video, Amazon Studios, and Amazon Music businesses before he left the company in 2014. Colin joined Amazon in 1998, as the Director for Amazon Associates and Amazon Web Services Programs. He also spent two years as Jeff Bezos’ technical advisor or “shadow,” and later served as the COO for IMDb.com.
Their stories illuminate Amazon’s culture of innovation and the origin stories of the Kindle, AWS, and Prime businesses. From granular details about the “working backwards” process, to an inside look at how players like Jeff Bezos and incoming CEO Andy Jassy operated up close, the lessons sharpen what “dive deep” and operational excellence look like in practice.
Several ideas have become mantras for my product management leadership practice: why innovation can’t be a part-time job, the perils of taking a “skills-forward” approach to exploring new opportunities, and why mechanisms are more important than good intentions. These principles reinforce the shift from outputs to outcomes and bring needed rigor to outcomes vs output OKRs.
At HighLevel, we apply a working-backwards mindset to product discovery: we start from the customer benefit, pressure-test the narrative with real users, and map success metrics before we write a line of code. This discipline accelerates product-market fit lessons, reduces thrash in product roadmapping and sprint planning, and clarifies trade-offs when timelines and resources are tight.
Mechanisms turn intent into results. For us, that means single-threaded ownership for critical bets, decision logs that preserve context, lightweight written narratives that force clear thinking, and weekly business reviews that highlight leading indicators. These habits create the tight feedback loops needed to dive deep, course-correct quickly, and scale operational excellence.
If you’re a founder, product creator, or operator scaling a SaaS platform, the throughline is simple: make innovation a full-time commitment, resist “skills-forward” biases when exploring new opportunities, and demand mechanisms that institutionalize good judgment. That’s how durable systems outlast any single leader.
I rarely get to trace a consumer product’s journey from a blank slate to one billion users, end to end. In reflecting on my conversation with David Lieb, Director of Google Photos, I was struck by how deliberate product discovery, clear problem framing, and thoughtful org design compounded into outsized impact.
David’s arc is instructive. Previously, he was the founder/CEO of Bump, an app that allowed users to swap contact information by physically bumping phones. Bump was acquired by Google in 2013, and formed the basis for the design of Google Photos, which launched in 2015 and passed the 1 billion users mark in 2019.
He walked me through building a consumer product from scratch and scaling it to over a billion users in just four years. What resonated most was the candid recounting of early mistakes at Bump, the realities of navigating big company politics at Google, and the methodical way the team pinpointed the core problem in the photo-sharing space.
The rigor of product discovery stood out. From the precise questions they asked in user interviews, to how they stack ranked for the canonical users, the team built conviction by prioritizing the right people and the right jobs to be done. I’ve seen too many teams spread thin across edge cases; this approach forces clarity on who you serve first and what you ship next.
We also dug into what it takes to operate at Google’s scale: planning discipline, org design that minimizes cognitive overhead, and mechanisms that keep outcomes ahead of output. For me, the difference between motion and progress is how crisply goals are defined and how tightly execution aligns to them—especially when the stakes and surface area grow.
On org design, I appreciated the practical nods to models like the Spotify “squads’ model, emphasizing cross-functional accountability and autonomy calibrated for speed without sacrificing cohesion. The key is empowering teams to ship independently while keeping a shared strategy and metrics that ladder up.
My playbook takeaways are direct. Narrow the problem statement until it becomes unambiguous. Use user interviews to validate the problem, not to seek applause for your solution. Stack rank canonical users and ruthlessly prioritize. Translate that focus into product roadmapping and sprint planning tied to measurable outcomes—not vanity metrics. And as you scale, evolve the structure so teams can move fast while the product narrative stays singular.
Whether you’re an early product builder or leading a mature platform, this blend of founder scrappiness and big-company craftsmanship is a blueprint. The path to one billion users isn’t a growth hack; it’s clarity of problem, empathy for users, and organizational design that compounds over time.
I recently sat down with Jane Davis, the Director of UX Research and UX Writing at Zoom. She previously led UX Research and Content Design at Zapier, and managed the growth research team at Dropbox. I set out to distill a practical playbook any product team can apply — even if you don’t have a formal UX research function.
Jane tackles the thorniest customer development questions and walks through an end-to-end research process that works in the real world: clarifying your goals, asking the right questions, selecting participants, and synthesizing insights. I translate these steps into repeatable product discovery rituals that drive better decisions and faster product-market fit.
We start by applying her playbook in the early-stage startup context — when you’re shipping the first version of your product and don’t yet have the resources to invest in a full research team. I share how I scope lean studies, use founder-led GTM interviews to deeply understand the problem we’re solving, and shape hypotheses for competitive versus greenfield markets, including how to size demand and figure out willingness to pay for SaaS pricing.
We also dig into best practices for prototyping and iterating. I show how I pair lightweight prototypes with clear research questions, time-box sprints, and convert insights into product roadmapping and sprint planning that truly move the needle.
Later, we confront common roadblocks: building for multiple users, aligning personas, and what to do when people aren’t excited about your product or using it frequently. I outline tactics to diagnose the gap — value proposition, onboarding, activation, and retention — then adjust the solution, messaging, or usage triggers to rebuild momentum.
Whether you’re talking to potential customers before you start a company or looking to get better feedback from your current users, this conversation is packed with field-tested practices for founders, product-builders, and design folks alike. Use it as your starting point to run credible UX research, de-risk decisions, and accelerate product-market fit without a dedicated team.
I sat down with Sandra Oh Lin, founder and CEO of KiwiCo, which creates hands-on learning kits for children. After executive roles at PayPal and eBay, she started KiwiCo over ten years ago to give her own kids more hands-on projects to exercise their creativity — a spark that led to entrepreneurship. Today, KiwiCo has expanded to include 8 different lines of crates that are shipped out monthly. As a product creator, I was eager to unpack how she turned a personal need into a scalable, beloved physical product line.
We dug into the thornier challenges of building physical products and her biggest aha moments as a first-time founder. She described creating the first KiwiCo crate — from the product development process to spinning up a supply chain and shipping department. We discussed how KiwiCo approaches new product lines, particularly in the last year when KiwiCo demand skyrocketed. She also shared how the team gathers quality consumer feedback when your customer is often a toddler — an audience that demands observational research, short feedback loops, and thoughtful proxies through parents and caregivers.
From a product discovery perspective, I found KiwiCo’s approach refreshingly pragmatic: iterative prototyping, tight learning cycles, and early validation that inform product roadmapping and sprint planning. When demand surges, operational excellence becomes a product feature — and Sandra’s experience reinforced that product-market fit lessons don’t end at the moment of traction; they expand into forecasting, inventory strategy, and resilience across partners. The throughline is an outcomes-over-output mindset that keeps the team anchored on value delivered to families rather than feature velocity.
We then shifted to culture — the often overlooked engine behind durable execution. Sandra is a strong believer in manager training for everyone, from folks that manage just one person to executives that have been managing for decades. She outlined the specific management training modules they leverage at KiwiCo and made the case for having everyone at the company fill out a motivations spreadsheet. For leaders navigating the IC to manager transition, these guardrails accelerate consistency, empathy, and decision quality across teams.
Finally, we explored how she creates a feedback-rich environment for herself as a CEO. I appreciated the intentionality — structured forums, explicit invitations for critique, and clear norms that make feedback safer and more actionable. Whether you’re shipping crates or software, the lesson holds: sustained product management leadership depends on mechanisms that convert diverse signals into aligned action. If you’re building physical products or scaling a product organization, these practices offer a blueprint for learning faster, de-risking complexity, and keeping customers — even the tiniest ones — at the center.
