Tag: product discovery

  • UX Product Management Career Playbook: Build Proof, Not Polish

    UX Product Management Career Playbook: Build Proof, Not Polish

    You are probably not wondering whether UX matters. You are trying to decide whether to move closer to design, how to make that move without becoming a second designer, and what evidence will convince a hiring manager that you can own the work.

    The answer is not another UX certificate or a more polished portfolio. You need proof that you can connect customer friction to a product decision, shape an experience with design and engineering, and measure whether the resulting behavior creates business value. This playbook shows you how to build that proof.

    Decide whether you want the work, not just the title

    A UX product manager owns the customer experience end to end while steering toward measurable outcomes. That does not mean producing every wireframe, conducting every research session, or making every interface decision. It means remaining accountable for the connection between a user’s problem, the experience the team ships, and the behavior that follows.

    The distinction matters because the role sits in an overlap, not in a gap. A designer should not need a product manager to practice design. A product team does need someone who can turn customer evidence into a prioritized problem, make trade-offs explicit, and keep discovery connected to delivery.

    Role emphasisPrimary questionStrong evidence
    Product designHow should this experience work for the user?Research synthesis, flows, interaction decisions, usability findings, and design-system judgment
    Product managementWhich problem should the team solve, for whom, and why now?Prioritization, value proposition, outcome definition, trade-offs, and business impact
    UX-oriented product managementWhich experience change will help a defined user reach value, and how will the team know?Customer evidence, experience strategy, cross-functional decisions, instrumentation, and behavioral outcomes

    You are likely suited to the overlap if you want to do all of the following:

    • Investigate why users struggle before debating what the team should build.
    • Move comfortably between a journey-level problem and a specific piece of microcopy.
    • Accept accountability for an outcome even though design, engineering, marketing, support, and the user all affect it.
    • Use qualitative evidence to explain behavior and quantitative evidence to establish its scale.
    • Partner closely with a designer without treating collaboration as permission to direct every screen.

    If those are not the decisions you want to own, do not force a title change. A product manager can deepen UX judgment without becoming a UX product manager, and a designer can develop product sense without leaving design. Choose the work you want to be accountable for.

    Build the three capabilities around one real user problem

    The fastest way to look shallow is to collect disconnected skills: a research course, an analytics dashboard, a prototype, and a prioritization framework that never touch the same decision. Build customer insight, product strategy, and experience design around one observable problem instead.

    Onboarding is a useful practice field because it exposes the whole system. You must identify the user’s intended value, find where progress breaks, decide what not to explain yet, shape guidance, and measure whether people reach a meaningful action. If onboarding is not relevant to your product, choose a core workflow with a clear start, a meaningful completion event, and visible friction.

    Customer insight: explain the friction before proposing a fix

    Start with a defined segment and a job the user is trying to complete. Then combine behavioral evidence with direct customer evidence. Funnel data can show where people leave; interviews, support conversations, and usability observation can help explain why.

    Create a compact evidence packet containing:

    • The target segment and the situation that brings the user into the experience.
    • The job the user believes they are completing, stated in the user’s terms.
    • The current critical path from entry to value.
    • Observed drop-off, delay, confusion, or repeated support demand.
    • Direct evidence behind the suspected cause, separated from your interpretation.
    • Assumptions that remain untested.

    That last distinction is career evidence. A strong UX product manager can say, “Users leave at this step” as an observation, “They may not understand the permission request” as a hypothesis, and “Changing the explanation should improve completion” as a testable prediction. Blending those statements into one confident story makes weak discovery look stronger than it is.

    Product strategy: turn the insight into a choice

    Customer pain is not automatically a priority. Connect it to a value proposition and an outcome. A useful framing is: “For this segment, improve this meaningful behavior by removing this verified barrier, because the behavior is part of reaching product value.”

    Now compare problem-level alternatives. The team might remove a step, change its sequence, defer a decision through progressive disclosure, clarify the value with UX writing, or provide contextual guidance. Do not jump from “users are confused” to “build a product tour.” A tour, an in-app guide, and a tooltip are interventions, not strategies. Each is appropriate only when it addresses the cause of the friction.

    Record what you will not pursue and why. This is where prioritization becomes visible. A hiring manager learns more from a rejected alternative with a sound trade-off than from a long feature list with no decision logic.

    Experience design: make the hypothesis concrete enough to test

    Work with design and engineering to turn the chosen problem into a testable flow. Trace the happy path, but also inspect empty states, errors, permission requests, loading behavior, recovery paths, and the moment when the user must make a consequential choice.

    Treat language as product behavior. A vague button label, an unexplained requirement, or a tooltip shown without context can create the same friction as a poor interaction. Good UX writing tells the user what will happen, why an input is needed, and how to recover when something goes wrong.

    Your artifact does not need visual polish. It needs enough fidelity to expose assumptions. Annotate the flow with the user question each step must answer, the behavior you expect, and the event required to measure it. That turns a prototype into a decision instrument rather than a gallery piece.

    Use activation as a diagnostic system, not a vanity metric

    Activation is a strong practice area because it forces you to define what “reaching value” means. It can also mislead you. Account creation, a completed tour, or a clicked button is not necessarily activation. The event should represent meaningful progress toward the reason the user adopted the product.

    Use this sequence for an activation project:

    1. Choose the segment. Different users may enter with different jobs, permissions, data, or expectations. Do not let an overall average hide a segment-specific failure.
    2. Define the value event. Name the behavior that indicates the user has experienced a meaningful part of the product’s promise. Explain why it matters rather than selecting the easiest event to count.
    3. Map the critical path. Identify the necessary steps between entry and value. Separate required complexity from friction the product has introduced.
    4. Locate the barrier. Combine funnel behavior with usability observation, customer language, and support evidence. A drop-off identifies a location, not a cause.
    5. Write the hypothesis. State the segment, barrier, intervention, expected behavioral change, and reason the change should occur.
    6. Define the read before launch. Specify the primary outcome, relevant guardrails, instrumentation, segments, and the decision you will make under each plausible result.

    Your tooling might include Amplitude, Pendo, or Intercom for funnels, product behavior, experiments, and customer signals. The brand matters less than the discipline: events must represent the intended behavior, properties must support the relevant segmentation, and exposure to an experiment must be distinguishable from eligibility for it.

    If you run an A/B test, set the minimum detectable effect before interpreting the result. Without an explicit MDE, an inconclusive read is easy to recast as success or failure after the fact. The purpose is not to make experimentation look scientific. It is to decide what size of change would matter and whether the test can detect it.

    Read activation alongside time-to-value and adoption of the core capability. Then inspect retention rather than assuming an early lift created durable value. If activation improves while retention does not, you may have accelerated an action without improving the underlying experience. If usability feedback improves but the behavioral metric does not, the altered friction may not have been the limiting factor. Both outcomes are useful when they lead to a sharper next decision.

    A practical experiment brief should answer these questions before delivery begins:

    • Which user segment is eligible?
    • What verified barrier are you addressing?
    • Which behavior should change, and why?
    • What is the smallest experience change that can test the causal assumption?
    • What is the primary outcome, and what must not degrade?
    • Which events and properties are required?
    • What MDE makes the test worthwhile?
    • What decision follows a positive, negative, mixed, or inconclusive result?

    This is how you keep discovery attached to delivery. A sprint should carry a learning goal or an outcome, not merely a collection of screens to complete.

    Build a portfolio that exposes your decisions

    A UX product management portfolio is not a design portfolio with extra charts. Its job is to make your reasoning inspectable. A reviewer should be able to see what you knew, what you assumed, which choices were available, why you selected one, and how evidence changed the next decision.

    Structure each case study as a decision journal:

    1. Context: Identify the segment, user job, product state, business relevance, and constraints.
    2. Problem evidence: Show the qualitative and quantitative signals. Distinguish observations from interpretations.
    3. Outcome: Define the behavior the team intended to change. Explain why it represented customer and business value.
    4. Alternatives: Present the credible options, including a smaller intervention and the option to do nothing.
    5. Decision: Explain the trade-off, who contributed, and which uncertainty the team accepted.
    6. Validation: Describe the prototype, usability work, production experiment, instrumentation, or retention analysis used.
    7. Result and next move: Report what the evidence justified. If it was ambiguous, explain what remained unresolved and what you changed next.

    Include screens only when they help the reader understand a decision. An annotated flow showing where a hypothesis enters the experience is more valuable than a polished sequence with no explanation. Likewise, a metric screenshot is not evidence of impact unless you define the segment, behavior, comparison, and decision attached to it.

    If the work was exploratory or self-directed, label it clearly. Do not imply that a concept shipped, that users were interviewed, or that business impact occurred when it did not. You can still demonstrate strong judgment by showing how you would instrument the experience, which assumptions require validation, and what evidence would cause you to stop.

    Your starting discipline determines which gaps the portfolio must close:

    • If you are a designer: make prioritization, value proposition, business trade-offs, outcome definition, and sequencing visible. Do not let the quality of the screens carry the case.
    • If you are a product manager: make the research plan, critical path, journey decisions, usability evidence, UX writing, and interaction trade-offs visible. Do not reduce UX to a feature requirement handed to design.

    Prepare interview stories around consequential decisions, not project tours. Start with the tension. Name the alternatives. Explain the riskiest assumption and how you tested it. Then state what you decided and what the evidence changed. This gives the interviewer material to assess your judgment under uncertainty.

    A strong resume bullet follows the same logic: “Changed [behavior] for [segment] through [experience decision], using [evidence or method], which informed [product or business decision].” Replace every bracket with facts you can defend. If you cannot name the behavior or the decision, the bullet is probably describing output.

    Lead the product trio without taking over another craft

    Your career will stall if UX fluency turns into design control. The useful version of the role creates a tighter product trio: product keeps the segment, problem, priority, and outcome visible; design leads the coherence and usability of the experience; engineering brings feasibility, system constraints, delivery insight, and instrumentation into the decision early. Important choices are shaped together.

    Use a lightweight operating loop:

    • Before planning: align on the user problem, current evidence, target behavior, unresolved assumptions, and the next learning goal.
    • During discovery: pair customer evidence with prototypes and technical investigation. Involve engineering before the team commits to a flow whose cost or constraints are unknown.
    • During delivery: preserve the hypothesis in the acceptance criteria and instrumentation. Do not let the ticket retain the interface while losing the reason for it.
    • After release: review behavior and customer signals together. Decide whether to continue, adjust, investigate, or stop.

    Tailor the decision narrative to the audience. Executives need the trade-off, business consequence, evidence strength, and decision required. Engineers need constraints, sequencing, edge cases, event definitions, and the reason behind the behavior. Designers need the user job, journey context, friction evidence, and experience assumptions. Other stakeholders need to know what changed, why it changed, how success will be judged, and which new evidence could alter the plan.

    A reusable update can stay simple: “For [segment], we are trying to change [behavior] because [evidence] indicates [barrier]. We chose [intervention] over [alternative] because [trade-off]. We will judge it through [outcome and guardrail]. The next decision occurs when [evidence condition].” That format reduces status theater because it keeps the decision and its evidence in view.

    Key takeaways

    • A UX product manager connects customer insight, experience decisions, and measurable product outcomes; the role is not a substitute for product design.
    • Build customer insight, product strategy, and experience design around the same real problem so your skills form a coherent body of evidence.
    • Use activation to diagnose the path to value, but verify downstream adoption and retention before claiming durable impact.
    • Define segments, events, guardrails, MDE, and decision rules before reading an experiment.
    • Make your portfolio a decision journal that includes constraints, alternatives, ambiguous evidence, and rejected ideas.
    • Demonstrate leadership by improving the product trio’s decisions, not by absorbing the responsibilities of design or engineering.

    Choose one experience in your current product and build the full evidence chain: segment, problem, critical path, hypothesis, experience change, instrumentation, outcome, and next decision. When you can show that chain clearly, you are no longer asking a hiring manager to infer your UX product judgment. You are giving them proof.

    References

  • From KPIs to Comebacks: How I Lead Through Setbacks with Curiosity, Care, and Discovery

    From KPIs to Comebacks: How I Lead Through Setbacks with Curiosity, Care, and Discovery

    Setbacks are the tax we pay for doing meaningful product work. As a VP of Product Management, I’ve learned that what separates resilient teams from the rest isn’t a lack of failures—it’s how we metabolize them. This episode of All Things Product with Teresa Torres and Petra Wille is a powerful reminder that recovery, reflection, and rigorous product discovery are as essential as speed and execution.

    Listen to this episode on: Spotify https://open.spotify.com/episode/10LYRya7boYJBHTYBnE79E?ref=producttalk.org | Apple Podcasts https://podcasts.apple.com/kh/podcast/dealing-with-setbacks/id1794203808?i=1000737190520&ref=producttalk.org

    What struck me most is how Teresa shares a deeply personal story about her long recovery from an injury—and how that journey mirrors the nonlinear reality of product development. In product, just like in healing, progress is rarely a straight line. We have surges, stalls, and moments that feel like reversals. Yet with the right mindset and rituals, we still move forward.

    Professionally, we all face moments when your product fails to move a single KPI, when a launch falls flat, or when you just feel stuck. I’ve been there—in quarterly reviews, post-launch standups, and board prep. The instinct is to sprint straight into solutions. The wiser move is to respond with curiosity, emotional honesty, and resilience, then re-engage our discovery habits with intention.

    If you’re a PM, designer, or researcher, consider this an invitation to rebalance. Recovery and reflection are just as important as velocity and success. That’s not soft talk—it’s how empowered product teams build durable performance without burning out.

    On the emotional reality of setbacks, I’ve learned to normalize naming the loss. We put immense pressure on ourselves, and it’s okay (and necessary) to grieve product failures. When we acknowledge the disappointment, we regain the ability to observe clearly—and to learn.

    Leaders play a crucial role here. I create space for teams to recover before jumping into post-mortems. We don’t whiteboard over feelings; we schedule time for decompression, then conduct a crisp, blameless review. That sequencing transforms the quality of insights and strengthens psychological safety.

    Another lesson that resonates is the danger of tying performance too tightly to outcomes. Outcomes matter, but they are lagging indicators influenced by many externalities. I evaluate performance on behaviors: clarity of problem framing, rigor in discovery, quality of decision-making, and stakeholder alignment. This aligns with outcomes vs output OKRs and keeps us focused on controllable excellence.

    How do we build resilience? Continuous discovery builds resilience by normalizing failure. When we test assumptions routinely with customers and data, we turn large, risky bets into a series of small, learnable steps. Teams recover faster because failure becomes feedback—frequent, cheap, and informative.

    For perspective, I often use the 10–10–10 framework (from Decisive by Chip & Dan Heath). I ask: How will this setback feel in 10 minutes, 10 months, and 10 years? The answers de-escalate urgency, expand our time horizon, and produce better, calmer decisions.

    Here are the key takeaways I’m carrying forward. Setbacks are not just inevitable—they’re part of doing meaningful product work. Giving teams time and space to process failure builds long-term resilience. Mourning losses is just as important as celebrating wins.

    Healthy discovery cultures embrace reflection, psychological safety, and emotional honesty. And most importantly, staying consistent with discovery habits helps teams recover faster and learn more deeply.

    Notable moments that stood out for me include: [00:02:00] Teresa shares the story of her injury and what it’s taught her about patience and setbacks. The parallel to product cadence is both humbling and motivating.

    [00:10:00] Petra talks about a team whose carefully planned launch didn’t move a single KPI. I’ve led similar debriefs; when we anchor on customer insight gaps rather than blame, the next iteration improves dramatically.

    [00:20:00] Discussion on allowing space for grief and frustration after failure. In my teams, we time-box “emotional processing” before we enter analysis mode—it humanizes the work and sharpens the learning.

    [00:30:00] Why organizations must decouple performance reviews from short-term outcomes. I align evaluations to strategy execution quality, hypothesis discipline, and cross-functional collaboration.

    [00:40:00] How continuous discovery can help teams normalize—and even learn to appreciate—setbacks. When discovery is weekly, momentum becomes self-healing.

    If you want to dig deeper, here are useful links from the episode. Follow Teresa Torres: https://ProductTalk.org

    Follow Petra Wille: https://Petra-Wille.com

    Mentioned in the episode: Decisive by Chip & Dan Heath — The 10–10–10 framework for perspective in decision-making https://heathbrothers.com/books/decisive/?ref=producttalk.org

    Teresa Torres’ Continuous Discovery Habits — Building resilience through ongoing discovery practices. https://www.amazon.com/Continuous-Discovery-Habits-Discover-Products/dp/1736633309?dchild=1&keywords=continuous+discovery+habits&qid=1621385051&sr=8-2&linkCode=sl1&tag=teresatorres-20&linkId=34bc439ac78da06e1398f7bf069b219e&language=en_US&ref_=as_li_ss_tl&ref=producttalk.org

    Join the Conversation: Have thoughts on this episode? Leave a comment below. I’d love to hear how you create space for recovery while sustaining product velocity.

    Full Transcript: Full transcripts are only available for paid subscribers.

    Inspired by this post on Product Talk.

    Book a consult png image
  • How I Use ChatGPT to Supercharge PM: Smart Workflows, Killer Prompts, and Real-World Wins

    How I Use ChatGPT to Supercharge PM: Smart Workflows, Killer Prompts, and Real-World Wins

    Every week, I lean on ChatGPT to cut through noise, reduce rework, and move faster with more confidence. It’s not a silver bullet, but it has become an unfair advantage in my day-to-day leadership of product strategy, discovery, and delivery. Unlock workflows, prompts, and real PM tips showing how ChatGPT quietly reshapes product management behind the scenes.

    Here’s my stance: ChatGPT doesn’t replace product judgment. It amplifies it. Used well, it accelerates product discovery, clarifies roadmaps, sharpens positioning, and strengthens stakeholder management. Used poorly, it creates noise and risk. What follows are the specific workflows and prompts that reliably save me hours while protecting quality and trust.

    Discovery and research are where I see the biggest upside. I use ChatGPT to draft interview guides, transform raw notes into theme clusters, and generate “Jobs to Be Done” problem statements—then I validate them with customers. I anonymize inputs to protect privacy and follow privacy-by-design and data governance commitments; AI risk management matters more than ever when we’re handling real user data.

    When I move from insight to definition, ChatGPT helps me spin up crisp PRDs and user stories. I provide context about our users, constraints, and success metrics and ask for structured outputs: goals, non-goals, acceptance criteria, and risks. This keeps our product trios aligned and focused on outcomes vs output OKRs, not just shipping features.

    For competitive analysis and positioning, I feed in public information and ask for points of parity, points of differentiation, and potential messaging angles. I treat the output as a starting point for my value proposition and battlecards—not the final word. It’s a fast way to surface hypotheses and pressure-test our product-led growth narrative.

    Roadmapping and sprint planning also benefit. I use ChatGPT to map dependencies, draft milestone narratives, and transform epics into well-formed backlogs. When we align quarterly plans, I ask for risk scenarios and contingency options so we can make trade-offs explicit before we commit.

    On analytics and experiments, ChatGPT is my drafting partner. It helps me define A/B testing plans, clarify the minimum detectable effect (MDE), and outline instrumentation requirements. I still verify numbers in our analytics stack, but the scaffolding is done in minutes, not hours—freeing me to focus on retention analysis and activation levers.

    Stakeholder communication is where the time savings compound. I use ChatGPT to produce executive summaries, QBRs vs OKRs comparisons, and board-ready narratives that highlight outcomes, risks, and next steps. It’s a powerful way to stay crisp and consistent across leadership updates without losing the nuance that matters.

    Prompt patterns make or break results. I keep four rules: set the role, provide rich context, define constraints, and specify the output format. For example: “You are a senior PM advisor. Context: [user, market, problem]. Constraints: [privacy, timeline, budget]. Output: PRD with goals, acceptance criteria, and risks.” With larger inputs, I use context window management by chunking content and asking for summaries before synthesis.

    For internal knowledge, I lean on a retrieval-first pipeline. Instead of pasting long docs, I reference curated, approved sources so answers track to current reality. CustomGPT workflows and a simple ChatGPT connector help with governance: they increase speed while reducing the chance of hallucinations and stale information.

    Guardrails are non-negotiable. We never paste sensitive data into prompts; we redact PII, spot-check against source-of-truth systems, and red-team important outputs. AI risk management isn’t just a checkbox—it’s how we maintain trust while scaling productivity with gen ai.

    Finally, enablement turns personal productivity into team capability. I run short playbooks for empowered product teams: discovery synthesis, PRD drafting, roadmap storytelling, and stakeholder-ready updates. The result is higher-quality thinking, faster cycles, and fewer meetings to align on the essentials.

    ChatGPT for product managers isn’t hype; it’s a practical edge when you apply discipline. Start with one workflow that drains your time, add a prompt template, and measure the outcome. In a week, you’ll have proof. In a quarter, you’ll have a new operating system for how your team learns, decides, and ships.

    Inspired by this post on Product School.

    Book a consult png image
  • A Quality System for Trustworthy AI-Assisted UX Research

    A Quality System for Trustworthy AI-Assisted UX Research

    Your AI-generated synthesis can be polished, plausible, and wrong. The dangerous failures are rarely obvious fabrications. They are quieter: a biased sample becomes a universal claim, a participant’s opinion becomes a product need, or a tidy theme loses the contradiction that should have changed the roadmap.

    If you are deciding whether to trust AI-assisted UX research, do not judge the fluency of the summary. Judge the evidence chain behind it. You need to see how a product decision connects to the participants recruited, the questions asked, the underlying observations, the analytical interpretation, and the behavioral data used to check it.

    Key takeaways

    • Research quality is mostly determined before an AI tool sees a transcript. Start with the decision, learning question, and hypothesis.
    • Use AI to accelerate transcription, extraction, tagging, clustering, and contradiction searches. Keep interpretation, confidence, and product judgment under human control.
    • Require every theme to retain its participant coverage, supporting evidence, counterexamples, and unresolved uncertainty.
    • Pair qualitative findings with funnels, cohorts, session evidence, and CRM data when those signals are relevant. Neither qualitative nor quantitative evidence should carry the decision alone.
    • Finish with an atomic insight and a recorded choice. A summary that does not change a decision, test, or learning priority is not finished research.

    Define quality at the decision boundary

    Many teams begin AI-assisted research by asking which model should summarize their transcripts. That is too late in the process. The first quality control is the decision the research must inform.

    Strong discovery begins with a decision statement, an explicit learning goal, and a hypothesis the team is willing to falsify. Without those constraints, an AI system can generate an impressive taxonomy of themes while leaving the actual product question untouched.

    Before recruiting participants or writing prompts, create a short research contract:

    • Decision: Name the choice that is genuinely open. Examples include whether to pursue an opportunity, which problem to solve first, or whether a proposed workflow deserves further testing.
    • Decision condition: State what you would need to learn to proceed, pause, narrow the audience, or reject the current direction.
    • Learning question: Ask about the behavior, context, constraint, or unmet need that makes the decision uncertain.
    • Hypothesis: Write the current belief in a form that evidence could disprove. If every possible interview result would support it, it is not a useful hypothesis.
    • Relevant population: Specify whose behavior matters to this decision and which segments could experience the problem differently.
    • Evidence plan: Identify what interviews can reveal and which behavioral or operational signals could challenge the interpretation.
    • Data boundary: Decide what the AI tool is allowed to receive, what must be removed, and who may review the resulting artifacts.

    This contract changes how you evaluate the output. You are no longer asking whether the summary sounds reasonable. You are asking whether the evidence changes a named choice under stated conditions.

    My standard is simple: a decision-grade insight must survive a skeptical review without relying on the model’s authority. A reviewer should be able to inspect the underlying evidence, see which participants and segments it covers, understand the interpretation applied to it, and identify what remains unknown.

    Keep one distinction visible throughout the work:

    • Observation: What the participant did, described, showed, or failed to complete.
    • Interpretation: What that behavior may mean about a goal, anxiety, constraint, or job.
    • Implication: What the product team may choose to change, test, or leave alone.

    AI can help produce all three, but it should never blur them into a single sentence. Once an inference is written as if it were an observed fact, the rest of the synthesis becomes difficult to audit.

    Protect the signal before AI touches it

    An LLM cannot repair a convenient sample or a leading interview guide. It can only reorganize the resulting bias, often in language that makes the bias look more certain.

    Recruit for the decision, not for convenience

    If you interview only power users, you risk treating advanced workflows as mainstream needs. If you interview only vocal detractors, the roadmap can become a queue of complaints. A more useful recruiting frame includes new users, churned users, people who evaluated but did not convert, and adjacent personas where the decision calls for them.

    Build a participant matrix before outreach. Use rows for the segments that could materially change the decision and columns for relevant states, such as adoption stage, conversion outcome, or workflow maturity. The matrix is not a quota formula. It is a visibility tool. It should make overrepresented groups and missing perspectives obvious.

    Carry that segment metadata into synthesis. A theme that appears among established customers should not silently become a claim about evaluators. When a segment is absent, write that limitation into the insight rather than hiding it in an appendix.

    Ask for behavior before interpretation

    Questions about whether someone likes an idea invite speculation, politeness, and solution theater. Ask about the last relevant event instead. Have the participant reconstruct what triggered it, what they tried, where they hesitated, who else became involved, what workaround they used, and what happened next.

    Neutral, behavior-first questions become stronger when participants can support the account with artifacts such as screenshots or workflow examples. The artifact does not automatically prove the interpretation, but it helps distinguish remembered behavior from a general opinion.

    Pilot the guide with the product trio. Remove product terminology that telegraphs the preferred answer. Check whether each question could produce evidence against the working hypothesis. If the guide repeatedly asks participants to react to your solution, it is a concept evaluation guide, not an open discovery guide. Label it accordingly.

    Set privacy boundaries before uploading transcripts

    Consent to an interview does not automatically settle how AI will be used in transcription, analysis, storage, or sharing. Tell participants how their material will be handled, follow your organization’s data governance requirements, and remove identifiers that are not needed for the decision.

    Do not place sensitive participant data into an unapproved prompt workflow. If the tool’s handling, retention, or access controls have not been approved, keep raw transcripts out of it and work with appropriately de-identified material in an authorized environment. The downside is not merely a poor synthesis; it is unnecessary exposure of participant and customer information.

    De-identification should not erase the context required for analysis. Preserve non-identifying segment labels, workflow stage, and participant codes when they are relevant. The goal is to minimize sensitive data while retaining enough context to audit coverage and interpretation.

    Make AI produce an auditable synthesis

    The most reliable workflow separates extraction from clustering and clustering from judgment. Asking for findings, recommendations, sentiment, and a roadmap in one prompt encourages the model to fill gaps and compress uncertainty.

    1. Prepare the evidence set. Preserve the original transcript or recording, assign a participant code, attach relevant segment metadata, and remove unnecessary identifiers. Do not let an AI-generated summary replace the underlying material.
    2. Extract participant-level observations. Ask the model to work through each participant separately. Capture the behavior or event, its context, the supporting excerpt or evidence location, and any missing information. Do not ask for themes yet.
    3. Review the extraction. Check whether the observation is grounded in the transcript and whether the model has converted an opinion into behavior or inferred a motive the participant did not provide.
    4. Cluster reviewed observations. Group similar evidence only after the participant-level pass. Require each cluster to retain the contributing participant codes, segment coverage, supporting evidence, and meaningful variations.
    5. Search for contradictions. Ask which observations do not fit the cluster, which participants experienced the situation differently, and which alternative explanations remain plausible. Do not treat dissent as noise merely because it makes the summary less tidy.
    6. Draft atomic insights. Turn a defensible pattern into a small evidence packet containing the finding, evidence, coverage, contradictions, confidence rationale, product implication, and unresolved question.
    7. Triangulate relevant claims. Compare the qualitative interpretation with funnels, cohorts, session evidence, in-product paths, or CRM data when those systems contain a useful signal.
    8. Conduct the decision review. A person accountable for the product choice inspects the evidence chain, challenges the interpretation, and records what the team will do or learn next.

    You can make the separation explicit with narrowly scoped prompts.

    Extraction prompt: Use only the supplied transcript. For each relevant event, return the participant code, observed or reported behavior, context, supporting excerpt, evidence location, and uncertainty. Do not merge participants, infer motives, or recommend a solution. Flag information that is missing.

    Clustering prompt: Use only the reviewed observations. Group evidence by shared behavior and context. For every cluster, retain participant codes, represented segments, supporting observations, material variations, counterexamples, and plausible alternative explanations. Do not use repetition in the transcript as a substitute for participant coverage.

    Challenge prompt: Review the proposed themes as a skeptical researcher. Identify unsupported generalizations, segment differences that were flattened, interpretations written as observations, contradictory evidence, and claims that cannot be traced to the supplied material. Do not invent missing evidence.

    Prompt design helps, but it does not replace review. Keep the prompt, relevant tool or model information, input scope, and human corrections with the research artifact. If the synthesis later changes, you should be able to determine whether the cause was new evidence, a different analytical instruction, or a human judgment.

    AI is well suited to accelerating transcription, tagging, theme clustering, Jobs to Be Done extraction, and searches for hesitation or sentiment. Treat the latter outputs as interpretations to validate, not measurements generated by an objective instrument. A sentiment label is useful only when a reviewer can return to the behavior and language that produced it.

    Validate the insight, then record the decision

    A good synthesis review is not a copy-edit. It is an attempt to break the claim before the claim influences a roadmap.

    Run a quality review against the evidence chain

    • Traceability: Can a reviewer move from the insight to the contributing participants and the exact supporting material?
    • Coverage: Does the claim name the segments represented, and does it disclose relevant segments that are missing?
    • Construct validity: Is the finding about the behavior the study intended to understand, or has a nearby opinion been used as a proxy?
    • Separation: Are observation, interpretation, and product implication visibly distinct?
    • Contradiction: Does the artifact preserve disconfirming cases and material variations instead of forcing consensus?
    • Triangulation: Where behavioral data is relevant, does it support, narrow, or challenge the qualitative account?
    • Decision relevance: Does the finding change a live choice, a test, or the next learning priority?

    Do not outsource confidence to the model. A confident tone is a language property, not an evidence assessment. Record confidence as a human rationale based on the clarity of the underlying behavior, the relevance and coverage of participants, consistency and counterexamples, and any corroborating behavioral evidence.

    Quantitative and qualitative signals answer different parts of the question. Funnels, cohorts, and retention analysis can show where behavior changes or where people leave. Interviews and artifacts can expose the goals, anxieties, organizational constraints, and workarounds behind that behavior. Pairing those signals is how a team moves from observing what happened to developing a testable account of why.

    When the signals disagree, do not average them into a vague conclusion. Check whether the interview sample represents the population in the analytics, whether the event instrumentation reflects the behavior being discussed, whether segments have been combined, and whether the evidence refers to the same stage of the journey. A contradiction is often the next research question.

    Use an atomic insight format

    A reusable insight should be small enough to inspect and complete enough to guide a choice. Use this structure:

    • Decision: The product choice this evidence informs.
    • Finding: The observed behavioral pattern and the context in which it occurs.
    • Evidence: Participant codes, excerpts or artifact locations, and any relevant behavioral signal.
    • Coverage: The represented segments and known gaps.
    • Interpretation: The best current explanation, clearly labeled as an inference.
    • Contradictions: Cases or data that weaken, narrow, or complicate the interpretation.
    • Confidence: A short rationale grounded in evidence quality, coverage, consistency, and triangulation.
    • Product implication: The opportunity, risk, constraint, or tradeoff the team should consider.
    • Disposition: Act, test further, monitor, or take no action.
    • Next unknown: The uncertainty most likely to change the decision.

    Useful insight records also prevent familiar synthesis mistakes. Replace a broad label such as onboarding friction with the specific behavior, actor, context, and consequence. Do not let a memorable quotation stand in for a pattern. Do not describe a participant’s requested feature as the underlying need. Do not convert an AI-generated cluster into a roadmap item until the evidence packet survives review.

    Bring the atomic insights to a decision review with the product trio. Record the choice, its rationale, what the team is deliberately not doing, and the evidence that could reopen the decision. Connect the chosen action to an outcome or learning objective rather than treating delivery of a feature as proof that the research was correct.

    For your next study, start with one live decision and run the evidence through this chain. If a theme cannot be traced, mark it as a hypothesis. If participant coverage is lopsided, narrow the claim. If qualitative and behavioral evidence conflict, investigate the conflict before committing the roadmap. That is how AI becomes a fast, inspectable research assistant instead of an unaccountable author of customer truth.

    References

  • Global Invoicing Nightmares: Hard-Won Product Lessons on EU Tax, Compliance, and Customer Value

    Global Invoicing Nightmares: Hard-Won Product Lessons on EU Tax, Compliance, and Customer Value

    I hit play on Global Invoicing – All Things Product Podcast with Teresa Torres & Petra Wille and felt an immediate jolt of recognition. We’ve all launched a feature that looked solid—until a small, overlooked detail broke everything. Their stories about global invoicing and taxes echoed challenges I’ve faced leading product for international customers: if you don’t design for the last mile of compliance, you can accidentally block the very "moment of value creation" your product promises.

    Listen to this episode on: Spotify | Apple Podcasts

    The conversation starts as a candid rant about EU tax compliance and quickly becomes a precise product management lesson: when we fail to map the entire path to customer value—down to the tiniest regulatory requirement—we can ship something “done” that still doesn’t work in the real world. That gap between intention and outcome is where good product teams live or die.

    In my experience, the nightmare of global invoicing for small online businesses is very real. Even big platforms (like Squarespace and Teachable) miss the mark on EU tax compliance, and when they do, customers feel it immediately. It’s the kind of edge case that doesn’t show up in a demo but absolutely shows up in revenue. Or as Teresa put it, “It’s not a little detail when your client won’t pay the invoice.” — Teresa Torres

    I appreciated how the episode digs into the difference between passing a regulatory checklist and actually meeting customer needs. Put plainly: the product isn’t “done” when the ticket moves to Done; it’s done when the customer completes the job—receives an acceptable invoice, pays successfully, and can reconcile it without friction. That’s why I lean hard on story mapping for regulatory work; it exposes the invisible steps where value creation can silently fail.

    Here’s how the episode resonates with my own playbook: the nightmare of global invoicing for small online businesses is a systems problem; why even big platforms (like Squarespace and Teachable) miss the mark on EU tax compliance is a prioritization and discovery problem; how Petra and Teresa navigated invoicing across borders with Ableify and LearnWorlds highlights pragmatic tool choices and trade-offs; the key difference between meeting regulations and meeting customer needs is an outcomes-over-output mindset; what product teams can learn from regulatory edge cases is how to find the seams where markets, laws, and workflows collide; how missing a single detail can block the "moment of value creation" is a reminder that value is defined by customers; and why story mapping is critical for finding gaps between "we shipped it" and "customers got value" is the method that connects all of the above.

    Practically, that means I treat regulatory features like any other high-stakes product surface: do real product discovery with affected users; co-design the happy path and the ugly edge cases; write acceptance criteria that include jurisdictional and document-level specifics (e.g., VAT numbers, invoice formats, timing rules); align with finance and legal early; and instrument the journey from invoice issued to invoice paid so we can see where real customers get stuck. This is outcomes vs output OKRs in action, and it’s one of the fastest ways to earn trust with stakeholders.

    Key takeaways worth bookmarking: Customers define value, not your compliance checklist. Regulatory work still requires discovery—you can’t skip understanding user needs. The path to value doesn’t end when your feature works; it ends when your customer succeeds. “Sweating the details” isn’t micromanagement—it’s good product management.

    Memorable quotes to bring back to your team: “If you don’t sweat the details, people choose other platforms.” — Petra Wille. “It’s not a little detail when your client won’t pay the invoice.” — Teresa Torres.

    Follow Teresa Torres: https://ProductTalk.org | Follow Petra Wille: https://Petra-Wille.com

    Mentioned in the episode: Squarespace | Stripe | Product at Heart | Teachable | LearnWorlds | Ablefy | Become a Better Product Leader: A 52-Week Transformation Journey | Product Talk Academy

    Have thoughts on this episode? Leave a comment below.

    Full transcripts are only available for paid subscribers.

    Inspired by this post on Product Talk.

    Book a consult png image
  • From Sketch to Clickable Demo: My AI Prototyping Playbook to Build Apps in Hours

    From Sketch to Clickable Demo: My AI Prototyping Playbook to Build Apps in Hours

    I’ve spent much of my career compressing the distance between a napkin sketch and something real customers can touch. At HighLevel, my product teams use generative AI to validate ideas faster, reduce risk earlier, and win stakeholder trust with evidence instead of slides. The goal isn’t to be flashy—it’s to be precise, testable, and repeatable.

    Today, you can build it before you pitch it. AI prototyping can turn ideas into clickable demos in hours. Here are some tools to try and steps to follow.

    I start every AI prototyping sprint by sharpening the problem statement and the outcome we care about. That means being explicit about the target user, jobs-to-be-done, and the riskiest assumptions. I define a minimum detectable effect (MDE) and tie it to outcomes vs output OKRs so everyone aligns on what “good” looks like before we touch a tool.

    From there, I move from sketch to interface. I capture a rough flow (whiteboard, tablet, or even paper) and generate UI variations with my AI product toolbox—tools that translate structure into components and screens. I’ll iterate on information hierarchy and copy until the narrative supports the core job, borrowing techniques from UX writing. For product managers leaning into LLMs for product managers, this phase is about speed to feedback, not perfection.

    Next, I wire data and logic. I connect a lightweight backend or spreadsheet, stitch in a CRM integration if needed, and add LLM calls through a ChatGPT connector or Claude Code. If the concept benefits from multi-step autonomy, I introduce agentic AI to orchestrate tasks across APIs. CustomGPT workflows help me encapsulate business rules so the demo behaves consistently in user paths we care about.

    Governance is not optional at this stage. I apply privacy-by-design defaults, document data governance decisions, and run a quick AI risk management pass: input validation, prompt safety, rate limits, and fallback responses. This keeps the prototype credible and prevents false positives from polluting stakeholder perception.

    With a click-through in hand, I instrument the experience so learning compounds. I drop in Amplitude analytics to track activation, task completion, and drop-off, and set up simple A/B testing when there’s a meaningful design or copy choice. This makes the prototype a learning vehicle, not just a demo.

    Then I get it in front of users—fast. Five targeted conversations will beat fifty internal opinions. I run structured product discovery interviews, observe time-to-value, and capture objections. This is where empowered product teams shine: we make changes in real time, re-run the flow, and document what moves the needle for product-led growth.

    When speed matters, I use a four-hour cadence: Hour 1 for problem framing and MDE; Hour 2 for sketch-to-UI generation; Hour 3 for data wiring and AI logic; Hour 4 for instrumentation and user walkthroughs. By the end, we have a clickable demo, preliminary analytics, and a clear decision on whether to advance, pivot, or park.

    Finally, I translate insights into a concise artifact: the hypothesis we tested, the signal we observed, the trade-offs we made, and the next sprint plan for product roadmapping and sprint planning. The point is not to be right on the first try; it’s to learn precisely, cheaply, and quickly enough to invest with conviction.

    If you adopt this approach, you’ll find that stakeholder management becomes easier, team energy rises, and your roadmap earns credibility. Build it before you pitch it, and let real interactions—not wishful thinking—do the heavy lifting.

    Inspired by this post on Product School.

    Book a consult png image
  • Cut Time to Value, Boost Retention: My Proven Playbook for Activation, Growth, and Loyalty

    Cut Time to Value, Boost Retention: My Proven Playbook for Activation, Growth, and Loyalty

    Time to value is the most reliable early indicator of long-term user retention I know. When customers experience meaningful product impact fast, they stick around, expand, advocate, and cost less to support. Over the years leading product teams, I’ve learned that speed-to-impact isn’t a nice-to-have—it’s the engine behind sustainable product-led growth and efficient go-to-market.

    Accelerate retention by reducing time to value. Learn how faster product impact drives growth, reduces costs, and keeps users engaged in the long term.

    Practically, I define time to value as the duration from first touch (or first login) to the moment a user achieves their “aha” outcome—something tangibly useful aligned to their job-to-be-done. The shorter that journey, the higher the likelihood of user activation, trial conversion, and durable engagement. This is why I obsess over onboarding, in-app guides, product tours, and the clarity of our value proposition.

    My first move is to map the Minimum Path to Value (MPV): the smallest set of actions needed to deliver a real result for a new user. I strip away everything non-essential in that path—fields, clicks, choices, and jargon. Opinionated defaults, smart templates, sample data, and single-player workflows let customers succeed in minutes, not days. The goal is to reduce cognitive load while making the next best action unmistakably clear.

    Instrumentation turns TTV from a hunch into a system. I track activation events, cohort retention, and conversion using platforms like Amplitude analytics and Pendo, with timely nudges through Intercom when users stall. I look at the distribution of TTV (not just the average), correlate it with retention analysis, and set explicit targets such as “new users reach first value within 10 minutes.” Those targets become team-level outcomes—not outputs—and we review them weekly.

    Experimentation is how we iterate toward the fastest path to value. I rely on A/B testing to compare onboarding flows, progressive profiling to delay non-critical inputs, and opinionated setup wizards to remove guesswork. Auto-generated example projects, pre-configured integrations, and guided checklists accelerate user activation without sacrificing flexibility for advanced users.

    Content and guidance matter as much as UX. Tooltips, contextual in-app guides, and short product tours should be timely, skippable, and laser-focused on the outcome, not the feature. I pair these with a concise knowledge base and short explainer videos that reinforce the same value narrative a user sees inside the product.

    Cross-functional alignment is essential. Product, marketing, sales, and customer success must rally around the same activation metric and TTV target. That alignment ensures our trial messaging, onboarding emails, and CS playbooks don’t compete—they compound. When everyone points to the same first-value moment, friction drops and adoption rises.

    Pricing and packaging can also accelerate time to value. Free trials should be long enough for users to credibly reach first value; usage-based gates should never block the MPV. I prefer to unlock everything needed to hit the “aha” moment, then meter after the value is viscerally felt—this respects the user’s time and reinforces trust.

    There’s a cost story, too. Faster time to value reduces tickets, shortens onboarding cycles, and lowers cost-to-serve. It also clarifies product discovery: when we see where users stall, we don’t guess at roadmap priorities—we let the data guide our next bet.

    In my experience at HighLevel, I’ve repeatedly seen activation rates jump when we cut time to value from days to minutes. The specific tactics vary by product, but the pattern holds: when the first outcome is undeniable and fast, retention follows—and so does efficient growth.

    If you’re looking for a starting point, try this: define one activation event that clearly signals value, instrument it end-to-end, design a Minimum Path to Value that gets new users there in under 10 minutes, and run weekly experiments until you consistently hit the target. Do that, and you won’t just improve onboarding—you’ll build a product that earns loyalty from the very first session.

    Inspired by this post on Amplitude – Best Practices.

    Book a consult png image
  • Prototypes vs Products: How I De-risk Ideas Fast and Ship Reliable Value at Scale

    Prototypes vs Products: How I De-risk Ideas Fast and Ship Reliable Value at Scale

    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.

    Inspired by this post on SVPG.

    Book a consult png image
  • Build a Company You’ll Run Forever: Bootstrapping vs VC, PMF, and the Art of ‘Eating Glass’

    Build a Company You’ll Run Forever: Bootstrapping vs VC, PMF, and the Art of ‘Eating Glass’

    I’ve spent my career building products and teams that I intend to steward for the long haul, and I’m drawn to founders who treat company-building as a craft you can practice forever. In this analysis, I break down a journey that crystallizes what it takes: going from a teenage wholesale hustle to an API-first healthcare clearinghouse, and in the process, learning why execution isn’t a moat, why venture capital is “going pro,” and how “eating glass” can become a durable advantage.

    Here’s the arc that anchored my thinking: a founder who, at 16, turned $2,500 into a wholesale empire; later bootstrapped a wildly profitable auto-parts business; then sold it to tackle “the most complicated problem” he’d ever encountered: business-to-business transaction exchange. He spent years building EDI infrastructure, threw away the entire codebase eight times, and found extraordinary traction in healthcare. The company recently raised a $70M Series B co-led by Stripe and Addition. The throughline is a consistent, high-agency approach to product management and go-to-market strategy, guided by first principles decision making.

    The first customer is often the trickiest—not because demand doesn’t exist, but because the product’s value proposition, points of parity, and competitive differentiation are still coalescing. I push teams to do founder-led GTM early, speak in the user’s language, and orchestrate high-signal conversations that expose real switching costs. That’s how we avoid mistaking polite interest for product-market fit.

    Bootstrapping forces rigor, but it also means being “constrained by capital.” There’s a ceiling to the speed at which you can iterate, validate, and scale. Venture capital, in the right context, is like “going pro”: you trade a bit of optionality for time, talent density, and a faster feedback loop. I often see confusion between ownership vs. control; structurally, you can design for alignment while still moving with the urgency a competitive market demands.

    One theme I return to with my own teams: execution is never actually a moat. Processes can be copied. Culture can be mimicked superficially. What can’t be easily replicated is the willingness to do the unglamorous, compounding work—what the founder here called “eating glass.” It’s the daily discipline of simplifying the system, instrumenting the edge cases, and standing up operational excellence that compounds into true competitive differentiation.

    When product-market fit hits in enterprise infrastructure, it can feel like “the snake swallowing a deer.” Capacity, process, and architecture are stretched to their limits all at once. I’ve experienced the same pattern: everything slows down so the organization can re-architect for scale. The trick is to make those constraints visible—measure service levels, queuing, and error budgets like you would in a production system—so you’re not flying blind.

    Some of the strongest product-management instincts I’ve seen borrow from discount retail and Toyota. From discount retail, we learn to obsess over unit economics, operational throughput, and ruthless simplification. From the Toyota production system, we adopt Kanban / TPS (Toyota), continuous improvement, and respect for constraints. In software terms, this becomes fast deployment frequency, small batch sizes, and defect prevention at the source—because “All software is a cascade of miracles.”

    Scaling decision-making is where most teams stall. I favor clear ownership, lightweight written narratives, and a bias for first principles decision making over committee compromise. That structure lets high-agency individuals move quickly while keeping cross-functional stakeholders aligned on outcomes vs output OKRs. It’s how you build empowered product teams without sacrificing focus.

    Hiring is where philosophy becomes practice. I resonate with the onboarding mantra “everything’s your fault now”—not as blame, but as an invitation to own outcomes end to end. I look for high-agency people who demonstrate systems thinking and the capacity to simplify. Manager hiring should lag role clarity; bring in managers when coordination overhead is the limiting factor, not when it merely feels uncomfortable.

    Longevity comes from founder-approach fit as much as product-market fit. Build a company you don’t want to leave by aligning operating cadence, decision rights, and cultural norms with how you actually work best. Maintain conviction in unconventional practice when the evidence supports it, while remembering that “Reality has a surprising amount of detail.” The more I zoom in on the real work—interfaces, edge cases, workflows—the more the right design emerges.

    In healthcare EDI, that realism matters. HIPAA overview (HHS) sets the compliance baseline. Payer integrations with Aetna, Blue Cross Blue Shield, and Cigna demand reliability and deep domain fidelity. Cloud and back-office ecosystems—from AWS and NetSuite to Slack, Microsoft Teams, Zapier, and Clay—shape the surrounding workflow. Lessons from Amazon, Target, Walmart, and Costco inform operational rigor; supply chain analogies from Ford Motor Company and GM clarify interface contracts. Porter’s five forces helps frame market structure; perspectives from Jeff Bezos and Peter Thiel sharpen strategic posture.

    If you’re building for the long run, here’s the blueprint I use with product leaders: validate painfully specific jobs-to-be-done before you scale; prefer founder-led GTM until messaging closes the intent-to-adoption gap; instrument throughput and quality like a production system; invest in people who treat ambiguity as a chance to lead; and don’t confuse speed with hurry. When the “snake swallowing a deer” moment arrives, re-architect deliberately, protect your margins, and let operational excellence carry you from product discovery to durable product-led growth.

    References and resources: Aetna: https://www.aetna.com/, Amazon: https://www.amazon.com/, AWS: https://aws.amazon.com/, Blue Cross Blue Shield: https://www.bcbs.com/, Change Healthcare: https://www.changehealthcare.com/, Cigna: https://www.cigna.com/, Clay: https://www.clay.com/, Costco: https://www.costco.com/, Ford Motor Company: https://www.ford.com/, GM: https://www.gm.com/, HIPAA overview (HHS): https://www.hhs.gov/hipaa/index.html, Jeff Bezos: https://x.com/JeffBezos, Kanban / TPS (Toyota): https://global.toyota/en/company/vision-and-philosophy/production-system, Microsoft Teams: https://www.microsoft.com/microsoft-teams, NetSuite: https://www.netsuite.com/, O’Reilly Auto Parts: https://www.oreillyauto.com/, Peter Thiel: https://x.com/peterthiel, Porter’s five forces: https://www.isc.hbs.edu/strategy/pages/the-five-forces.aspx, “Reality has a surprising amount of detail”: https://johnsalvatier.org/blog/2017/reality-has-a-surprising-amount-of-detail, Slack: https://slack.com/, Stedi: https://www.stedi.com/, Summit Racing: https://www.summitracing.com/, Target: https://www.target.com/, Walmart: https://www.walmart.com/, Zapier: https://zapier.com/

    Book a consult png image
  • Turn Claude Code Into a Trusted Teammate: My 3-Layer Memory System You Can Copy

    Turn Claude Code Into a Trusted Teammate: My 3-Layer Memory System You Can Copy

    "Can you critique the landing page for my new Story-Based Customer Interviews course?" That simple ask used to kick off hours of back-and-forth where I fed an AI the same context over and over—only to get generic feedback that wouldn’t land with my audience or fit my products. As a product leader, that inefficiency was unacceptable; as a writer, it was just plain frustrating.

    Not anymore. Today, Claude not only critiques my work, it helps me produce it. It generates marketing copy—in my voice. It helps me write blog posts. It knows what search terms are relevant to my business and helps me optimize my articles for SEO and now AEO. It helps me with competitive research, academic research, and discovery research. And it does all of this with little prompting from me.

    I don’t upload files to a web-based project. I don’t manage elaborate prompt libraries. I don’t repeat myself. I ask for help and Claude knows exactly what to do. The shift happened when I learned how to give Claude Code a memory. Claude now knows who my target customer is, the key value propositions I focus on, the specific opportunities each product addresses, my revenue model, my marketing channels, and so much more.

    Dark-mode slide with monospaced white text outlining an SEO plan: add CLAUDE.md to an AI glossary as the entry point, with bullets on article focus, audience, and search architecture for Give Claude Code a Memory.
    A dark-themed strategy slide for the post Stop Repeating Yourself: Give Claude Code a Memory, showing how to lead with a CLAUDE.md glossary page, write clearly for nontechnical readers, and link glossary and article to boost discovery and engagement.

    With that memory, I consistently get high-quality output tailored to my audience and aligned to my products and services. I don’t retype the same context; Claude just remembers. In this article, I’ll show you exactly how I set up that memory. It relies on Claude Code (which requires a Pro subscription), and it’s worth it. If you’re new to Claude Code, start with "Claude Code: What It Is, How It’s Different, and Why Non-Technical People Should Use It."

    Here’s the underlying problem: with large language models, every conversation starts from scratch. Yes, ChatGPT can remember some things and Claude can search past conversations, but practically speaking each new thread wipes the slate clean. If I were working on a new landing page, I’d normally need to upload target customer context, product details, primary and secondary value propositions, FAQ questions and answers, plus testimonials and logos for social proof—every single time.

    Dark-theme screenshot of the Claude interface with a large prompt field, model selector set to Sonnet 4.5, and quick-action buttons for Write, Learn, Code, Life stuff, and Claude’s choice on the home screen.
    Start fast with Claude’s home screen: Sonnet 4.5 is ready, and quick actions for writing, learning, and coding sit beneath a clean prompt box—ideal for showing how memory cuts repetition and streamlines daily development.

    Projects in web-based tools help a bit, but they introduce a new dilemma. When I move to the next landing page targeting the same customer but a different product and value proposition, do I start a new Project (tedious) or keep expanding the old one (which muddies the context window and degrades output quality)? The good news: Claude Code solves this by giving the model a precise, durable memory without overloading any single conversation.

    Claude Code can read files on my local machine, which is an understated superpower. I use those files to create a persistent, reusable memory that works across all chats and Projects. Files can be mixed and matched, so I give Claude exactly what it needs for the task at hand—and nothing more. For a first landing page, I reference the target customer and the relevant product; for the second, I reuse the same target customer file and point to the new product file.

    Screenshot of a macOS Notes window in dark mode showing an AI-assisted review of producttalk.org, listing Fetch and Read steps and a "Homepage Evaluation" for a first-time B2C visitor.
    Dark-mode Notes screenshot captures Claude Code in action: it fetches producttalk.org, reads context files, and delivers a concise homepage evaluation—showing how memory streamlines repeated analysis tasks.

    When you give an LLM the exact right context, output quality jumps. More context only helps if it’s the right context. For a landing page, Claude needs to know about the current product and perhaps related products for differentiation—but it doesn’t need to know about unrelated offerings. Structure your memory so Claude gets precisely what’s required.

    Once I did this, Claude shifted from “intern who needs handholding” to trusted advisor and capable teammate. It doesn’t guess at my value propositions—I’ve already told it. It writes in my voice because it has my writing guide and samples. It knows who owns which course and which use cases map to which features. The setup takes a bit of upfront work, but it compounds: update a file when something changes and you’re done. Most of this information already lives in your system; the trick is making it easy for Claude to use.

    Diagram of the Claude Code interface with a terminal-style dashboard. Arrows show Global Preferences (~/.claude/CLAUDE.md), Project Preferences (Project/CLAUDE.md), and Custom Files feeding memory into the coding chat.
    See how Claude Code stops repetition: global and project CLAUDE.md files, plus custom reference docs, flow into the editor so the assistant remembers your preferences and context while you code and run commands.

    Because the files live on my machine, I own the system. No vendor or device lock-in. I decide when and who to share with. I can work with Claude on one project and ChatGPT on another—both can rely on the same file-based memory strategy. It’s an AI strategy that scales with product discovery, accelerates go-to-market content, sharpens competitive differentiation, and supports product-led growth.

    Here’s how I design the memory: I use three layers. Claude Code already encourages global preferences and Project-specific instructions, but the third layer—reference context—is where the real power lives.

    Dark-mode screenshot of a macOS editor showing a 'Claude Code Preferences' markdown file with sections on writing conventions, planning protocol, and feedback for collaborating with Claude.
    Peek inside a markdown playbook for Claude Code: concise rules for writing, multi-level planning, and clear feedback that turn repeated reminders into reusable memory and smoother, faster coding sessions.

    Layer 1: Global Preferences (Always on). The first time I launched Claude Code, I created a CLAUDE.md file at ~/.claude/CLAUDE.md. This is where I keep the cross-project rules of engagement—how I like to work with Claude. Mine includes: Always create a plan for me to review before you start any work; Give me direct feedback (no hedging, no gentle suggestions); Use bullet points for summaries; Ask clarifying questions one at a time so I can give complete answers; No emojis unless I explicitly ask for them. Claude Code automatically loads this file at the start of every session, so I never restate my preferences.

    Layer 2: Project-Specific Instructions. Different projects have different rules. In my writing workspace, the Project CLAUDE.md sets the roles (I’m the primary writer; Claude is my thought partner and editor), defines a multi-round review flow (content → structure → accuracy → typos), prioritizes human readability over SEO, and points to my writing style guide. In my task management system, I include how my Trello integration works, file naming conventions for tasks, and how to process research papers into summaries. In my code projects, I specify the technology stack (Node.js vs. Python), testing framework (Jest for Node.js, pytest for Python), code style and conventions, project architecture and directory structure, and which dependencies and libraries to use. Each project directory has its own CLAUDE.md, and Claude automatically loads the relevant file when I’m working there.

    Dark-themed text editor screenshot of a markdown file titled 'Claude Instructions,' featuring sections for session setup, working relationship, editor responsibilities, and research and development guidelines.
    Peek inside a markdown playbook for collaborating with Claude—covering session setup, roles, editorial standards, and research steps—to show how saved instructions create consistent results without repeating yourself.

    Layer 3: Reference Context (Pull as Needed)—the real power. LLMs have a context window—a limit to how much they can process at once. Even within that limit, loading too much degrades performance due to “context rot.” The remedy is ruthless context management: small, targeted files that load only when needed. Keep CLAUDE.md files concise and focused on rules and workflows. For detailed knowledge, create separate reference files and list them in your CLAUDE.md so Claude knows they exist and when to fetch them. When I ask for help creating a landing page, Claude knows to use my business profile, the product file, and my target customers context.

    Here’s what most people miss: you don’t cram everything into global or Project files. You maintain small, reusable reference files that Claude only loads on demand. In my walkthrough, I share exactly which context files I created and why; how I got Claude Code to help me create them; how I break them into small, reusable components so Claude gets precisely what it needs; how I keep everything up to date; and step-by-step instructions so you can set up a similar memory system.

    Diagram of three markdown files (business-profile.md, story-based-customer-interviews.md, target-customers.md) feeding into a Claude Code IDE panel, showing context files powering an AI assistant.
    Three project notes funnel into Claude Code, turning reusable context into working output. This visual shows how saving key docs as memory lets the AI pick up where you left off and skip repetitive prompting across tasks.

    Let’s dive in.

    Inspired by this post on Product Talk.

    Book a consult png image
  • AI at Home, Impact at Work: Experiments That Supercharged My Product Leadership

    AI at Home, Impact at Work: Experiments That Supercharged My Product Leadership

    I recently tuned into an insightful All Things Product episode featuring Teresa Torres and Petra Wille on how experimenting with AI in everyday life sharpens how we build AI-powered products at work. The core premise resonated deeply with my AI Strategy: low-stakes, personal experiments accelerate confidence, clarify limitations, and build an AI product toolbox we can bring into the office with rigor.

    If you want to dive in, you can listen on Spotify or Apple Podcasts. I found the conversation especially relevant for product trios and anyone shaping LLMs for product managers in high-stakes environments.

    The idea is simple but powerful: when I prototype with AI at home—where the stakes are low—I learn faster, make safer mistakes, and internalize critical product patterns. Over time, those patterns transfer directly to work: tighter context management, sharper bias awareness, clearer human-in-the-loop guardrails, and a more nuanced view of when to use AI as a thought partner versus when to consider agentic AI.

    In my own practice, I’ve mirrored many of the scenarios discussed: using ChatGPT by OpenAI to plan meals, analyze public data sets like school budgets, and even sanity-check real estate evaluations. These seemingly mundane tasks are fertile ground for learning about context window limits, hallucination (artificial intelligence), AI bias, and privacy-by-design trade-offs. Each experiment helps me craft better prompts, structure data for clarity, and decide when a human review step is non-negotiable—core habits for AI risk management.

    At work, I treat AI as a thought partner for writing, research synthesis, and contract review. I also explore when and how to responsibly evolve toward agentic AI for repeatable workflows. The distinction matters: a thought partner augments judgment; an agent automates execution. Building the right scaffolding—data governance, auditability, constraints, and escalation paths—ensures we unlock speed without compromising safety.

    Three lines from the episode stayed with me: “I’m trying to write things that only I can write — that’s my guiding writing light right now.” — Teresa. “The more we use AI, the more we learn what it’s good at, what it’s not good at, and where context becomes a limitation.” — Teresa. “It’s a safer playground — we can build our toolbox at home before bringing those lessons to work.” — Petra. These are practical north stars for product management leadership in the GenAI era.

    For anyone getting started, here’s what worked for me: begin with “low-stakes” personal experiments, write down your prompts and outcomes, and reflect on failure modes. Treat each activity as product discovery: What problem am I solving? What outcome matters? What data and context does the model need? Which decisions must stay human-in-the-loop? This discipline builds an AI product toolbox you can confidently apply to real customer problems.

    I also keep a running toolkit of references and tools that inform my practice: Context window as a concept helps me size and sequence information. Visual and video tools like Midjourney and Sora expand how I think about multimodal experiences. I rotate between Claude by Anthropic and ChatGPT by OpenAI depending on task fit, and I’ve used Claude Code when I need structured assistance with code review. For knowledge capture and workflow, Readwise and Ghost help me structure insights and ship content.

    If you want more structured learning paths, I found Josh Seiden’s Learn AI With Me, A 30-Day Sprint to be a practical primer, and the broader community conversation at Product at Heart Conference is invaluable. For a deeper grounding in risk, I recommend reviewing topics like Hallucination (artificial intelligence), AI bias, and Agentic AI—and revisiting the complementary episode, Context is King.

    I’d love to hear how you’re experimenting: Where have you seen AI meaningfully reduce toil? Where does it still struggle? How are you balancing creativity, data safety, and compliance as you scale? Drop a comment below and let’s compare notes—especially on patterns that help product trios move faster without sacrificing trust.

    Bottom line: start small at home, carry lessons into the office, and build with curiosity and intentionality. That’s how we level up our product discovery, sharpen our value proposition, and lead teams confidently through the GenAI transition.

    Inspired by this post on Product Talk.

    Book a consult png image
  • From Engineer to Product Manager: A Practical Transition Plan

    From Engineer to Product Manager: A Practical Transition Plan

    You may already be doing the parts of engineering that sit closest to product management: questioning a requirement, clarifying the user problem, challenging an unnecessary feature, or helping design and product make a difficult trade-off. The uncertainty is whether those moments add up to PM readiness – and whether changing careers means discarding the technical credibility you worked hard to earn.

    They don’t prove that you’re ready, but they give you a strong starting point. The safest path is to test the role before you depend on the title. Own a bounded customer problem, work through discovery and prioritization, ship a small bet, and make the resulting evidence visible. That gives you a transition plan based on demonstrated product judgment rather than potential alone.

    Change the scoreboard from implementation to impact

    Engineering and product management overlap, but they aren’t measured the same way. An engineer is expected to make a solution reliable, maintainable, secure, and feasible. A PM is expected to determine which problem deserves attention, why it matters now, what evidence supports the decision, and how the team will know whether its bet worked.

    The first transition is therefore moving from shipping outputs to driving measurable user or business outcomes. That doesn’t make delivery unimportant. It changes the role delivery plays: a feature becomes a hypothesis about how to create value, not the finish line.

    When you encounter a request such as “build bulk editing,” don’t start by turning it into tickets. Rewrite it as a product decision:

    • User and context: Which segment encounters the problem, and during which workflow?
    • Observed problem: What are people trying to accomplish, and where does the current experience fail them?
    • Current behavior: What workaround or alternative do they use now?
    • Desired outcome: Which user or business measure should change if the problem is solved?
    • Hypothesis: Why should this particular intervention change that measure?
    • Smallest useful test: What can you ship or simulate to reduce the most important uncertainty?
    • Decision rule: What evidence would make you continue, change direction, or stop?

    This framing exposes weak roadmap items quickly. If you can’t identify the affected segment, current behavior, baseline signal, or decision rule, the team doesn’t yet have a product bet. It has a solution looking for justification.

    Technical depth remains useful. You can detect hidden dependencies, challenge unrealistic scope, and understand where platform choices restrict future options. The trap is allowing feasibility to dominate desirability and business value. A solution can be technically elegant, delivered on time, and still leave the customer problem untouched.

    Run a 90-day transition experiment in your current role

    An internal move is usually easier to de-risk because you already understand the product, architecture, delivery process, and organizational context. Instead of asking your manager to approve a permanent career change based on intent, propose a bounded 90-day product experiment with an outcomes dashboard and a weekly stakeholder update.

    Choose a problem that matters but doesn’t require control of the entire roadmap. It should have an identifiable user, an observable pain point, a plausible measure of success, and enough room for a small intervention. Avoid a project whose scope is already fixed. Coordinating predetermined delivery may demonstrate execution, but it gives you little opportunity to show discovery, prioritization, or product judgment.

    PhaseWork to ownEvidence to preserve
    First 30 daysMap the users, workflow, current alternatives, relevant metrics, stakeholders, and decision process. Define the problem boundary and establish the baseline signal.A one-page problem brief, workflow map, initial dashboard, interview plan, and written scope.
    By day 60Run focused discovery, combine interview patterns with quantitative signals, compare possible interventions, and build a hypothesis-led roadmap.Discovery notes, customer language, an opportunity tree, rejected options, trade-offs, and a prioritized experiment.
    By day 90Deliver a thin slice, observe the result, follow up with affected users, and recommend whether to continue, revise, or stop.A before-and-after dashboard, decision log, updated roadmap, outcome narrative, and lessons that change the next decision.

    Set the operating agreement before the trial begins. Write down what you own, which decisions you can make, who remains accountable for the broader roadmap, and how much engineering work you will retain. A minimal engineering contribution can reduce the immediate staffing risk, but minimal must be explicit. Otherwise, you can end up carrying a full engineering workload while attempting a second full-time role.

    Your weekly update should be short enough that leaders will read it and structured enough that they can intervene:

    • The outcome you are trying to influence.
    • What you learned from users or data.
    • Which assumption became stronger or weaker.
    • The decision made and the trade-off accepted.
    • The next uncertainty to reduce.
    • Any decision or support needed from the recipient.

    This cadence does more than report activity. It demonstrates that you can turn incomplete information into a clear decision without hiding uncertainty. It also prevents the trial from becoming invisible work that everyone appreciates but nobody recognizes as product ownership.

    Practice the three skills engineering may not have forced you to build

    Technical competence can help you enter the conversation, but it won’t compensate for weak discovery, vague positioning, or poor stakeholder management. Those are the areas to practice deliberately during the transition.

    Product discovery: investigate behavior before proposing a solution

    Engineers are trained to solve well-defined problems. Product discovery tests whether the apparent problem is real, important, and worth solving for a particular segment. The distinction matters because confident solution design can make a weak assumption look mature.

    Use interviews to reconstruct actual behavior rather than solicit approval for an idea. Useful prompts include:

    • Walk me through the last time you tried to complete this task.
    • What triggered the need?
    • Where did the workflow slow down or break?
    • What did you do next?
    • What workaround have you adopted?
    • What was the consequence of leaving the problem unresolved?

    Avoid leading with a proposed feature or asking whether someone would use it. People can be polite, imaginative, and optimistic about hypothetical behavior. Recent examples, current workarounds, and actual consequences give you firmer evidence.

    Don’t turn each interview into a roadmap vote. Look for repeated situations, motivations, obstacles, and alternatives. Then check those patterns against quantitative signals such as activation, conversion, retention behavior, or support volume. Qualitative evidence explains what may be happening; quantitative evidence helps you understand its reach and movement.

    Product positioning: make the value segment-specific

    A technically capable product can still fail to communicate why anyone should change behavior. Positioning forces you to choose whose problem matters and why your approach is preferable to the status quo.

    Draft a simple statement: For [specific segment] struggling with [observable problem], this capability helps them achieve [meaningful outcome], unlike [current alternative], because [relevant distinction].

    Each bracket requires evidence. If you describe the user as everyone, the segment is too broad. If the outcome is easier or better, it is too vague. If you can’t name the current alternative, you may not understand the real competition, which is often an established workaround rather than another product.

    Stakeholder management: communicate decisions, not activity

    A PM rarely controls every team needed to produce an outcome. You must create alignment through context, evidence, and explicit trade-offs. That is different from satisfying every stakeholder request. Stakeholder agreement can help delivery, but it does not prove customer value.

    Build updates around the decision:

    • What decision is required?
    • Which outcome does it affect?
    • What evidence is relevant?
    • Which viable options were considered?
    • What does each option trade away?
    • What do you recommend, and why?
    • Who owns the next action?

    Remove implementation jargon unless it materially changes the decision. Executives need the consequence of a dependency, not a tour of the dependency graph. Engineers need constraints and reasoning, not a priority handed down without context.

    Practice these skills inside a product trio involving product, design, and engineering. The trio gives you access to different forms of judgment while preventing product discovery from becoming a solo PM exercise. Agree on decision rights and sponsorship at the start so you don’t become an unofficial PM with responsibility but no authority.

    Turn the work into evidence that survives an interview

    A long ticket history doesn’t demonstrate product judgment. Your portfolio has to show how you reduced uncertainty, made a choice under constraints, aligned the people needed to act, and learned from the result.

    Build each case study around a decision rather than a feature:

    • Context: Who was the user, what were they trying to do, and why did the problem matter?
    • Uncertainty: What did the team not know at the beginning?
    • Evidence: Which customer and product signals changed your understanding?
    • Alternatives: What other options were credible, including doing nothing?
    • Choice: What did you prioritize, and what did you deliberately decline?
    • Delivery: How did you reduce scope while preserving a useful test?
    • Outcome: What changed in activation, conversion, support demand, or another relevant measure?
    • Learning: What did the result change about the next roadmap decision?

    Attach the supporting artifacts only after the narrative is clear. Useful evidence includes a one-page problem brief, anonymized discovery notes, customer language, an opportunity solution tree, a hypothesis-led roadmap, an outcomes dashboard, and a before-and-after roadmap snapshot. The artifacts support your judgment; they shouldn’t force the interviewer to reconstruct it.

    Be precise about causality. If several initiatives were running at once, say that your work influenced an outcome rather than claiming it caused the entire change. If the target metric didn’t move, don’t bury the result. Explain which assumption failed, what you stopped doing, and how the evidence improved the next decision. Honest learning is a stronger PM signal than a polished success story with implausibly clean attribution.

    For an internal transfer

    Package your trial as a proposal your manager and product leader can evaluate. Include the problem boundary, success measure, product trio, weekly update rhythm, retained engineering commitment, artifacts you will produce, and the decision to be made at the end of the 90 days. This turns a vague request for a chance into a controlled staffing and product experiment.

    For an external search

    Prepare two deep case studies: one centered on discovery and another on delivery. The discovery case should show how you challenged the initial framing and reduced uncertainty. The delivery case should show how you handled constraints, aligned stakeholders, protected the outcome while reducing scope, and shipped.

    Expect follow-up questions about trade-offs: What did you say no to? Which assumption worried you most? Why was the thin slice sufficient? What evidence would have reversed your decision? What did you do when stakeholders disagreed? If your answer is only that the team completed the roadmap, you are still presenting yourself as a delivery coordinator. The stronger signal is that a decision changed because you understood the customer, business, and system more clearly.

    Key takeaways

    • Your engineering background is an advantage, not proof of PM readiness. Use it to improve decisions, not to dominate the solution.
    • Replace feature completion as your scoreboard with a clearly defined user or business outcome.
    • Build experience before changing titles by owning one bounded problem through a 90-day internal trial.
    • Use a weekly update to expose evidence, assumptions, trade-offs, decisions, and requests for help.
    • Practice discovery, positioning, and stakeholder management deliberately; technical fluency won’t substitute for them.
    • Make your portfolio decision-centered, quantify the outcomes you influenced, and represent causality honestly.
    • Prepare one discovery-led case and one delivery-led case for external interviews.

    Your next move isn’t rewriting your resume. Choose one user pain in a product you already understand. Write a one-page problem brief, identify the product and design partners you need, define the outcome you will track, and ask a sponsor to support a bounded trial. Let the title follow the evidence.

    References