Generative media is no longer a curiosity on the edges of product roadmaps—it’s fast becoming a core capability. Watching one company sprint from uncertainty to undeniable traction reminded me how much a decisive pivot, a developer-first brand, and ruthless focus can bend a growth curve. This is a story about finding product-market fit in real time, scaling with intention, and staying lean while the category accelerates beneath your feet.
Gorkem Yurtseven is the co-founder and CEO of fal, the generative media platform powering the next wave of image, video, and audio applications. In less than two years, fal has scaled from $2M to over $100M in ARR, serving over 2 million developers and more than 300 enterprises, including Adobe, Canva, and Shopify. In this conversation, Gorkem shares the inside story of fal’s pivot into explosive growth, the technical and cultural philosophies driving its success, and his predictions for the future of AI-generated media.
What stood out to me first was the clarity of the pivot: “How fal pivoted from data infrastructure to generative inference.” The hardest decisions often feel like abandonment—of code, roadmap, and even identity—but the right pivot reframes everything around a higher-signal customer need. That decision, described as “The hardest decision that saved the company,” unlocked a new trajectory and set a crisp north star for the team.
Equally important was the market intuition. As they put it, “Why ‘generative media’ is a greenfield new market.” Greenfield means pattern-breaking strategy: prioritize outcomes over parity, embrace new workflows rather than retrofit old ones, and measure value in quality, latency, and unit economics—not just features. In my experience, this is where product teams win or lose: you either build the new default or get trapped perfecting the old one.
fal’s “explosive year” wasn’t luck; it was systems thinking applied to a developer platform. The team stayed small—”lean <50-person team” and “Staying nimble as a 45-person company”—and built a brand that feels genuinely for builders: “Building a brand that resonates with developers.” That shows up in everything from docs and SDKs to the cultural quirks that scale signal, like “Why fal has 500 Slack channels.” Velocity and clarity compound when communication is designed for ownership.
Early traction came from sharp use cases and fast feedback loops. I loved the transition arc from “The early adopters of the first fal product” to “The transition from toy to tool.” In a new category, the fastest path to durable usage is making something delightful and then relentlessly hardening it for production: uptime targets, deterministic APIs, transparent pricing, and repeatable performance. That’s how you move from demos to dependable workflows.
The timing call is bold and specific: “Why 2025 is the year of AI-generated video” and “Predicting AI-generated film in 2027.” If you build in gen AI, this matters. Video will force teams to optimize for cost per second, temporal coherence, and developer ergonomics across long-running jobs. The winners will combine model choice (OpenAI, Anthropic, Google DeepMind, Stability AI; “Stable Diffusion XL (SDXL)”, “Sora”, “DALL-E”, “LLaMA”) with world-class inference, smart caching, and autoscaling that feels invisible to the developer.
On the go-to-market side, I see a masterclass in founder-led GTM and developer evangelism. “Competing in a fast-moving, fragmented market” requires sharp messaging and distinctive ideas. The story behind “GPU Rich / GPU Poor” is a perfect example: a memorable narrative that encodes a real infrastructure advantage. Pair that with “fal’s greatest optimization wins” and you get a brand promise rooted in measurable performance, not just clever copy.
Culture and team design are the force multipliers. “How to build a world-class team” and “fal’s unique hiring philosophy” emphasize high-slope talent, ownership, and speed over headcount. The result is a product org that ships, learns, and iterates without bureaucratic drag. For technical founders, “Learning sales as a technical founder” is a reminder that the best sales motion often emerges from the same instincts as great product discovery: ask better questions, observe real workflows, and sell through outcomes.
Here’s how I translate these lessons into a practical playbook for product leaders working in gen ai and developer platforms: double down on developer experience (time-to-first-output, clear pricing, robust SDKs), make latency and reliability your product features, sequence the roadmap from delightful demos to dependable production tools, and stay lean enough to pivot as models and use cases evolve. Above all, treat “Why generative media is a greenfield market” as a call to invent the defaults others will copy.
Looking ahead, the path is clear: as AI-generated video normalizes in 2025 and professional-grade content follows by 2027, the products that win will combine inference excellence with a brand developers trust. If you’re building in this space, now is the moment to ship fast, optimize relentlessly, and meet creators and developers where they already work.
You have found a painful customer problem, the prototype is convincing, and the commercial case looks real. Then the diligence begins. A seemingly simple workflow turns out to depend on eligibility rules, data permissions, human review, recordkeeping, partner obligations, exception handling, and a decision about who carries the residual risk.
The answer is not to bolt compliance onto the roadmap or make every release slower. You need to understand the regulated system deeply enough to choose a narrow, valuable problem that can actually be operated. In financial services and healthcare, constraints understood in enough detail can reveal product opportunities, not merely reasons to stop. That shift changes problem selection, discovery, architecture, metrics, and launch readiness.
Start with the regulated event, not the feature
A feature describes what appears on a screen. A regulated event describes what changes in the real world.
A form may collect information, but the important event could be an eligibility decision. A dashboard may display an alert, but the important event could be restricting access to funds. An AI assistant may draft text, but the risk changes if it sends the text, changes a record, recommends care, approves an application, or initiates an irreversible action.
This distinction matters because regulation usually attaches to an actor, action, decision, data use, or outcome. If discovery remains at the feature level, the team can validate demand while missing the conditions that determine whether the product is viable.
Before prioritizing a solution, trace one customer journey through these questions:
What consequential event occurs? Name the decision or action that changes access, money, care, rights, obligations, or an official record.
Who performs it? Separate the customer, your company, a licensed or authorized professional, a partner, an automated system, and any downstream institution.
What must be true beforehand? Identify required information, consent, eligibility, review, authorization, disclosures, and dependencies.
What must the product prevent? Describe prohibited actions and unsafe states, not just the intended happy path.
What must be provable afterward? Identify the decision, inputs, versioned rules, approvals, notices, and other evidence that may need to be reconstructed.
How can the outcome be challenged or corrected? Define the appeal, escalation, correction, reversal, and notification paths.
Write the initial product boundary as one sentence: “For this customer segment, the product will perform this action, under these conditions, through this channel, within this jurisdiction, while explicitly excluding these adjacent actions.” The exclusions are part of the strategy. Without them, reviewers are forced to reason about an abstract universe of possible uses, and the roadmap expands before the first bet has been proven.
Do not ask a product manager to make a legal determination. Qualified legal and compliance owners should determine which obligations apply and approve the resulting interpretations. Product’s responsibility is different: translate those interpretations into explicit system states, customer flows, operating procedures, evidence, and scope decisions. “Legal owns it” is not a product strategy.
Separate actual obligations from accumulated company habit
Regulated organizations often use the word “requirement” for several different things. That creates unnecessary complexity because a legal obligation, a defensible interpretation, a company risk preference, and an inherited manual process are not equally fixed.
Classify every constraint before designing around it:
Binding obligation: A law, regulation, license condition, contractual commitment, or other external rule that applies to the defined product boundary.
Interpretation: A documented conclusion about how an obligation applies to this product, customer, jurisdiction, channel, or operating model.
Risk posture: A choice the company makes about exposure, review, thresholds, eligible customers, or prohibited uses. It may be prudent without being legally mandatory.
Implementation constraint: A limitation created by current software, staffing, partner capabilities, data quality, or process design.
Organizational habit: A step that exists because it has always existed, even though nobody can identify the obligation or risk decision behind it.
The distinction gives you design room. You cannot wish away a binding obligation. You can, however, revisit an interpretation when the product boundary changes, ask an authorized risk owner to reconsider a company policy, automate an implementation constraint, or remove an unsupported habit.
Use a constraint ledger with one row per regulatory proposition or risk decision. Avoid a single row called “be compliant”; it cannot be designed, tested, or owned.
Layer
Question to answer
Useful output
Applicability
Which obligation or commitment applies to which actor, action, customer, and jurisdiction?
A scoped proposition with an authorized interpretation owner
Product rule
What must the system permit, require, block, disclose, or route?
An explicit rule tied to product states
Control
How will the rule be prevented, detected, or corrected?
A testable control with an owner
Evidence
How will you demonstrate that the control operated for a particular event?
A defined record with access and retention rules
Exception
What happens when the control fails, information conflicts, or a customer challenges the outcome?
An escalation and correction path
Mark unresolved items explicitly. Give each one an owner, a decision needed, a planned decision point, and a classification of whether it blocks discovery, build, launch, or scale. An unanswered interpretation should never hide inside an engineering estimate. That only converts legal uncertainty into schedule risk.
Choose a narrow wedge where regulatory depth compounds
The biggest market is not automatically the right starting point. Neither is the workflow with the easiest interface. A strong initial wedge combines meaningful customer pain with a bounded regulatory surface and at least one capability that will remain valuable as the product expands.
Evaluate candidate problems against six questions:
Customer consequence: Is the problem important enough that customers will change behavior, provide the necessary information, and tolerate the required safeguards?
Boundary clarity: Can you define the segment, action, channel, jurisdiction, and exclusions precisely enough to obtain decisions from legal, compliance, security, privacy, and operations?
Capability reuse: Will solving the problem create reusable identity, permissions, policy, review, evidence, monitoring, or exception-handling capabilities?
Observable value: Can you see whether the workflow improved a real customer outcome without waiting for broad market expansion?
Failure containment: Can the initial release limit exposure when an input is wrong, a dependency fails, or a decision is challenged?
Strategic fit: Do you have a credible reason to earn trust, distribute the product, operate the controls, and improve the system over time?
I would rather fund a narrow bet that proves the complete value-and-control loop than a broad bet whose feasibility depends on several unresolved interpretations. The first produces reusable knowledge. The second often produces a polished interface around an unproven operating model.
Reject or reshape a candidate when its value appears only after a wide launch, every customer requires a bespoke exception, the system cannot generate evidence of its own operation, or several independent regulatory assumptions must all be favorable. Those are not reasons to abandon the market. They are signals that the first wedge is carrying too much uncertainty.
Write the bet in a form that exposes the strategy:
For a defined customer and regulated event, I believe this workflow will produce a specific customer outcome. The bet depends on these interpretations, controls, and operating capabilities. It earns the right to expand when both customer value and control performance are observable.
Regulated product strategy template
If you cannot fill in the dependencies without using phrases such as “compliance will handle it” or “operations can review it,” the bet is not yet deep enough.
Design the product as a control system
In an ordinary feature roadmap, policy and operations can appear as supporting work. In a regulated product, they are part of the product. The customer experience, decision policy, runtime controls, evidence trail, and recovery path must describe one coherent system.
Design every consequential journey with four paths:
You are watching growth stall, customers hesitate, or revenue fall, and the team wants an answer: Is the strategy wrong, or are you simply failing to execute it? That is the decision underneath most founder pivots. Get it wrong and you either abandon a viable business or spend your remaining runway perfecting one that cannot work.
The answer is not a more inspiring vision. You need a way to isolate the broken assumption, test a narrower direction, stop work that no longer matters, and protect the judgment of the people making the calls. The goal is not to make a pivot painless. It is to make it legible and executable.
Prove that the strategy, not the execution, is broken
A pivot changes a foundational belief about the customer, problem, solution, distribution model, or method of capturing value. An execution reset keeps those beliefs intact and changes how the company delivers against them. Founders often blur the two because an abrupt revenue decline makes every weakness look strategic.
That distinction has financial consequences. If you treat poor execution as proof that the market is wrong, you discard learning, customer trust, and product assets that may still have value. If you treat a broken thesis as a productivity problem, you consume cash while asking the team to work harder against weak demand.
Before you announce a new direction, run this diagnosis:
Write the current thesis in one sentence. Name the customer, the important problem, the behavior your product changes, and why that change creates enough value to support the business.
Name the observed break without explaining it. Use a customer behavior such as weak adoption, low repeat use, stalled expansion, long sales cycles, or resistance to paying. “The market does not understand us” is an explanation, not an observation.
Separate demand from delivery. Ask whether customers reject the promised outcome, value the outcome but dislike the solution, or want the solution but cannot discover, buy, trust, or implement it.
Look for uneven pull. Find the customer segment, use case, channel, or workflow that performs differently from the rest. A pocket of pull may support a focused pivot even when the blended result looks poor.
State what would preserve the existing strategy. If a specific product, pricing, positioning, or go-to-market change could plausibly remove the blockage, test that before rebuilding the company around a different premise.
Set a decision window that respects both behavior and runway. It must be long enough to observe the relevant buying or usage cycle but short enough to leave the company a viable next move. Do not spend the entire runway proving that the current direction failed.
Signal you observe
Interpretation to test first
Lowest-cost next check
Customers value the outcome but struggle to find or buy the product
Distribution or sales friction
Test one narrow channel, message, or founder-led sales motion
Prospects show interest, but the core behavior does not repeat
Weak problem intensity or an incomplete solution
Review actual usage and interview people who tried but stopped
Usage is healthy, but the economics do not support delivery
Business-model or cost-to-serve problem
Test willingness to pay and a lower-cost delivery model before expanding
One segment adopts with less persuasion than the rest
Customer or use-case focus may be too broad
Concentrate discovery, onboarding, and sales on that segment
The same strategy produces inconsistent results across teams
Ownership, capability, or operating-system failure
Clarify decision rights, reduce work in progress, and rerun the motion
Do not mistake a promising segment for confirmed product-market fit. Treat it as a reason to focus the next test. The most useful crisis questions are still which customers are pulling the product and what small test can validate the next bet. Those questions force evidence into a conversation that otherwise becomes dominated by confidence, seniority, and fear.
Write a pivot thesis that is allowed to be wrong
A vague pivot sounds like “move upmarket,” “become a platform,” or “add AI.” It creates motion without establishing what the company expects to learn. Teams then reinterpret every result as support for the new direction.
Use a short pivot memo as a decision contract. It should contain:
The failed assumption: what the company previously believed and what evidence now makes that belief doubtful.
The new thesis: the customer, problem, behavior, and value-capture model you now intend to test.
The invariant: the assets or beliefs that remain useful, such as customer relationships, proprietary workflows, distribution, technical capabilities, or domain knowledge.
The leading indicator: the behavior that should change before revenue or broad retention can confirm the direction.
The disconfirming evidence: the result that would cause you to stop, revise, or reject the new thesis.
The boundary: the people, roadmap capacity, and cash exposure authorized for the test.
The decision owner: the person who will interpret the evidence and make the call when opinions remain divided.
The invariant matters because a pivot should not automatically become a restart. If you change the customer, problem, product, channel, and revenue model at the same time, you will not know which decision produced the result. Preserve what still has evidence behind it and change the smallest set of assumptions necessary.
Match the experiment to the type of pivot
Customer pivot: sell the current value proposition manually to the narrower segment before rebuilding onboarding, permissions, or architecture for it.
Problem pivot: verify that the newly prioritized problem is important enough to change behavior, budget, or workflow. Interest in an interview is not enough; look for an existing workaround, committed time, or a willingness to participate in a real trial.
Solution pivot: deliver the outcome through a manual or constrained workflow before investing in automation. The test is whether the outcome matters, not whether the final system is elegant.
Business-model pivot: test the buying unit, willingness to pay, and delivery economics separately from feature demand. High usage does not establish that the business can capture enough value.
Go-to-market pivot: keep the core product stable while changing the message, channel, sales motion, or implementation path. This protects the product signal from simultaneous distribution changes.
In regulated or high-trust categories, a fast test cannot ignore the conditions under which the product would actually operate. A prototype that bypasses required controls may validate an unusable experience. Involve qualified legal, compliance, security, or risk specialists before exposing customers, moving money, or handling sensitive data.
Define the stop condition before the test begins. Otherwise, a founder can keep changing the target, expanding the scope, or explaining away weak results. Resilience does not mean giving every idea unlimited time. It means preserving enough capacity to respond intelligently when an idea fails.
Convert the new direction into an execution system
The operational failure in many pivots is not the choice of direction. It is the handoff from the new thesis to the old company. Existing projects continue, teams keep their previous goals, and the pivot becomes additional work instead of a change in priorities.
Create three explicit work queues:
Continue: commitments required to protect customers, revenue, safety, compliance, or the assets the new thesis still needs.
Pause or stop: roadmap items, campaigns, partnerships, and internal projects that depend on the old thesis.
Learn: the smallest set of experiments required to accept, reject, or refine the pivot.
The stop queue is the test of strategic seriousness. If the pivot changes what matters but nothing loses funding, staffing, or leadership attention, the company has added a theme rather than changed direction. Carrying the full legacy roadmap also makes the new bet look slower and more expensive than it is.
Use an operating cadence that reduces decision latency without turning the founder into the approval layer for everything:
Weekly priorities: each pivot workstream names the decision it is trying to unlock, the evidence due next, and the owner accountable for obtaining it.
Exception review: leaders discuss only material changes, crossed guardrails, blocked decisions, and evidence that challenges the thesis. Routine execution remains with the accountable team.
Monthly retrospective: inspect which assumptions changed, which experiments produced interpretable evidence, and where process friction slowed learning.
Strategic resource review: revisit staffing and investment on the normal business-review cadence, but do not wait for a quarterly meeting when runway, customer safety, or a critical commitment requires an earlier decision.
Management by exception is particularly useful here. Give teams the thesis, decision boundaries, metric definitions, and escalation thresholds. When a threshold is crossed, the owner brings the evidence, the consequence, and a proposed response. When it is not, the team continues without waiting for central approval. That preserves speed while keeping risk visible.
Do not hire your way around an unclear thesis
A pivot can create genuine capability gaps, but it also makes confused leadership look like understaffing. Before opening a role, write the outcome the person must own, the decisions they will control, and the evidence that the existing team cannot cover the gap. If those points are unclear, the hire will inherit ambiguity rather than remove it.
When hiring is necessary, test the work the pivot actually requires. Give candidates a realistic problem with incomplete information and inspect how they frame it, find evidence, make tradeoffs, and revise their view. That reveals learning velocity and ownership more reliably than resume prestige or presentation polish. For executive roles, references and evidence of performance in ambiguity should carry substantial weight; interviews alone are unusually easy to rehearse.
Build resilience into the company, not the founder’s stamina
Founder resilience is often described as the ability to keep going. That definition is incomplete. A company needs the ability to keep making sound decisions as information changes. Working indefinitely, centralizing every call, and treating recovery as optional can preserve activity while degrading judgment.
Keep a decision log. Record the assumption, evidence, owner, decision, and condition that would reopen it. This stops the leadership team from relitigating the same question without new information.
Pre-commit to evidence. Write down what would change your mind before results arrive. This makes it harder to move the standard whenever the outcome conflicts with the preferred narrative.
Limit work in progress. Every leader should be able to name the decisions and experiments currently in motion. If new urgent work enters, something else pauses.
Protect uninterrupted work. Product discovery, technical investigation, customer analysis, and strategic writing need blocks without meetings or reactive approvals.
Put an expiry on emergency rules. Temporary approval paths, extra meetings, and founder interventions should end or be deliberately renewed. Otherwise, crisis behavior becomes the permanent operating model.
Schedule recovery as capacity management. Time away from the decision stream protects attention and reduces dependence on heroic effort. If exhaustion is affecting sleep, health, or basic functioning, operating changes are not a substitute for support from a qualified medical or mental-health professional.
Cofounder trust also needs explicit mechanisms when the company changes direction. Agree on who decides when consensus fails, which information must be shared, how financial risk will be surfaced, and how concerns can be raised without reopening every settled choice. Trust becomes more durable when people do not have to guess how disagreement will work under pressure.
Watch for operational warnings: routine reversible decisions waiting on the founder, experiments being added without old work stopping, goals changing after results arrive, the same disagreement recurring without new evidence, and critical execution depending on nights or weekends. Each one points to a system that is consuming resilience faster than it rebuilds it.
Key takeaways for your next pivot
Diagnose the failing layer before changing direction: demand, solution, distribution, economics, or execution.
Write the failed assumption, new thesis, leading indicator, disconfirming evidence, investment boundary, and decision owner before building.
Change as few foundational variables as possible so the result remains interpretable.
Translate the pivot into continue, stop, and learn queues; a strategy change without a stop list is usually just more work.
Push context and boundaries to teams, then pull only exceptions into leadership review.
Treat recovery, decision rights, work-in-progress limits, and pre-committed evidence as execution infrastructure.
At your next leadership meeting, leave with a written thesis, a bounded test, and a visible stop list. If the team cannot produce those artifacts, do not announce the pivot yet. You are still reacting to pressure, and the next useful move is to turn that pressure into a decision the company can execute.
Your pipeline can look busy long before you have product-market fit. Friendly prospects take meetings, ask for features, and agree to proofs of concept. None of that, by itself, proves the problem is urgent, funded, or repeatable. If every opportunity needs a different story and a different product, you are collecting interest rather than finding a market.
At zero to one, founder-led GTM is not temporary sales coverage. It is the learning system that connects customer discovery, product decisions, positioning, pricing, and qualification. You need that system to answer a hard question: are you seeing a market pull the same product from you, or are you pushing a custom solution into each account?
Write a market thesis that can be proven wrong
Product-market fit becomes easier to reason about when you stop treating it as a general feeling of momentum. I use a stricter working definition for the zero-to-one stage: the same kind of customer repeatedly prioritizes the same problem, commits to the same outcome, and succeeds without pulling the product in a different direction every time.
The strongest starting point is a hair-on-fire problem with a committed buyer, not a broad market with many theoretically relevant use cases. A narrow thesis gives you something you can test. A broad thesis lets almost every conversation sound encouraging.
Before outreach begins, complete this sentence in customer language: This type of customer encounters this problem when this trigger occurs, the problem causes this consequence, and this buyer will commit money, time, access, or workflow change to achieve this outcome.
A usable thesis identifies each of the following:
Ideal customer profile: the operating characteristics that make the problem likely, not just an industry or company-size label.
Trigger: the event that turns a background inconvenience into a current priority, such as a failed process, a new obligation, a scale threshold, or an executive mandate.
Critical job: what the customer is trying to accomplish, independent of your proposed feature.
Consequence: what becomes slower, riskier, more expensive, or impossible when the job is not completed.
Current workaround: the people, tools, manual steps, or compromises already absorbing the problem.
Economic buyer: the person accountable for the result and able to authorize a purchase.
Required commitment: the observable action that would demonstrate priority rather than politeness.
Disconfirming evidence: what you would have to observe to conclude that the customer, problem, buyer, or product thesis is wrong.
Do not leave the last item until the end. Run a pre-mortem before you build. Assume the product fails to earn adoption and list the most plausible causes: the pain is tolerable, the trigger is rare, the buyer is wrong, implementation is too disruptive, an incumbent workaround is good enough, or the product requires services that cannot be repeated.
Then create an anti-ICP alongside the ICP. An anti-ICP may understand the problem and enjoy the demo but lack the urgency, authority, operating conditions, or implementation appetite required to buy. This prevents your team from using weak interest to validate a strong claim. It also forces you to seek skeptical and disconfirming input while the cost of changing direction is still low.
Separate problem evidence from purchase evidence
A customer can describe real pain without being a viable buyer. Another can have budget but no urgent reason to act. A third can sponsor a pilot without intending to purchase anything afterward. Those are different conditions, and a useful discovery process records them separately.
Observed evidence
What it helps you learn
What it does not establish
The prospect describes a recent instance of the problem in specific terms
The problem exists in the customer’s real workflow
That solving it is a current buying priority
The prospect has assembled a manual workaround or tried another solution
The problem has been important enough to prompt action
That your approach is better enough to justify switching
The economic buyer joins the process and explains the desired outcome
Accountability and decision authority are becoming visible
That budget and implementation approval are secured
The customer funds a pilot or commits meaningful people, data, access, and time
The customer is willing to incur a cost to evaluate the outcome
That the product will deliver durable value after the evaluation
The customer reaches the agreed outcome and makes the commercial or adoption decision defined in advance
Value and willingness to proceed are connected
That the motion is repeatable across an ICP
This distinction protects you from the most common false positive in founder-led GTM: mistaking access for demand. A well-known logo, an enthusiastic user, or a long list of feature requests can consume months without producing a buying decision.
Before accepting bespoke work or a proof of concept, require a qualification record that answers:
What happened that made the problem important now?
Who experiences the problem, and who owns its business consequence?
What is the customer doing instead?
What happens if the customer makes no change?
Who can approve budget and implementation?
What product scope is actually being evaluated?
What observable outcome will count as success?
What will the customer decide if that outcome is reached?
When and by whom will that decision be made?
If the prospect cannot answer the buying questions, do not pretend that more product work will create authority or urgency. Move the opportunity to nurture, continue lightweight discovery, or disqualify it. Disqualification is not a declaration that the account will never buy. It is a decision not to spend scarce founder and engineering attention until the missing evidence changes.
A proof of concept needs a boundary. Time-box the evaluation and connect it to a real decision. Put the hypothesis, product scope, customer responsibilities, required inputs, success criteria, end condition, and next commercial decision in writing. Without those terms, a proof of concept can become unpaid custom development with no mechanism for learning whether a purchase will follow.
Run founder-led sales as a product learning loop
Founder-led GTM does not mean the founder must perform every demo forever. It means the people making product and company decisions stay close enough to buyer reality that important signals are not compressed into a CRM note, a feature request, or a salesperson’s interpretation.
The loop should connect targeting, discovery, commitment, delivery, and a product decision:
Select accounts from the thesis. Do not mix unrelated personas and use cases merely to fill the calendar. If the target varies, you will not know whether differences in response came from the problem, buyer, message, or product.
Discover before demonstrating. Reconstruct the customer’s last encounter with the problem. Learn the trigger, sequence of work, workaround, consequence, and failed attempts before showing your solution.
Speak with users and the economic buyer. Users reveal workflow detail and adoption friction. The economic buyer reveals priority, budget logic, risk tolerance, and the decision process. One perspective cannot substitute for the other.
Ask for an appropriate commitment. That may be payment, implementation resources, access to data, an introduction to the buyer, or a written evaluation plan. Choose a commitment that would be inconvenient for a merely curious prospect to make.
Deliver a narrow outcome. Keep the evaluation tied to the core thesis. Do not hide a weak result by expanding the scope or promising unrelated roadmap items.
Record evidence and make a decision. Update the ICP, positioning, product, qualification rules, or kill criteria. A conversation that changes none of them may have generated activity without generating learning.
Use questions that recover behavior, not opinions
Hypothetical questions make it easy for a prospect to be agreeable. Questions about a recent event force the conversation into actual behavior. Start with the workflow:
What triggered the last instance of this problem?
What did you do first, and what happened next?
Which people and systems became involved?
Where did the process fail, slow down, or require manual judgment?
Who noticed the consequence?
What have you already tried to change?
Why was the current workaround accepted until now?
Then test the buying path:
Why does this need to change now?
Who is accountable for the outcome?
Which budget or existing expense would support the purchase?
What security, integration, procurement, or workflow change could block adoption?
What would a successful evaluation allow you to decide?
What would make no decision the rational choice?
Avoid treating Would you use this? as validation. Replace it with questions about what the customer has done, what the customer will commit, and what decision follows.
Let builders hear objections without a relay
Bring product and engineering into selected outreach, discovery, and implementation conversations. Giving engineers direct exposure to prospects and objections shortens the distance between a customer’s constraint and a technical decision. It also helps the team distinguish a missing feature from a missing value proposition, a workflow problem, or a qualification failure.
Direct access does not mean every prospect gets to steer the roadmap. Capture each request with the customer type, trigger, underlying job, consequence, buyer, and promised outcome. A request that cannot be connected to the core job is evidence about an account, not yet evidence about the market.
Keep a written decision log after each batch of conversations. Record what changed, the evidence behind the change, and what would reverse the decision. This prevents the loudest recent call from overwriting the accumulated pattern and makes disagreements about the roadmap inspectable.
Build the smallest complete outcome, not the smallest feature
An early product can be small without being incomplete. The distinction is whether the customer can reach a valuable end state. A narrow feature that leaves the hardest part of the job with the customer may be easy to ship but impossible to evaluate. A complete wedge solves one important job end to end, even if some steps behind the interface are still manual.
Manual work is legitimate when it tests whether the outcome matters or teaches you how delivery should work. A human-plus-software model can deliberately combine automation with expert service where precision, context, or trust still requires judgment. The danger is not manual work itself. The danger is hiding account-specific consulting inside product economics while assuming the motion is repeatable.
Order the roadmap around the riskiest unresolved assumption:
Demand risk: will a qualified buyer prioritize the outcome and make a meaningful commitment? If this is unknown, more feature development is unlikely to answer it.
Outcome risk: can the product and operating model reliably produce the result the buyer expects? Build the thinnest end-to-end path that tests that result.
Workflow risk: will users provide the inputs, change behavior, and integrate the product into real work? Test the handoffs and implementation burden, not only the interface.
Repeatability risk: can another customer in the same ICP succeed with substantially the same product, message, and delivery model? Remove one-off work only after you understand why it recurs.
This ordering keeps the team from automating an unproven workflow or polishing a capability that buyers will not prioritize. It also provides a clear kill criterion for each build: if the experiment resolves no important uncertainty, it should not outrank work that does.
Treat pricing and packaging as product decisions
Willingness to pay is not a final-stage sales detail. It is evidence about value, buyer ownership, and the shape of the offering. Define what the customer is buying, which outcome or usage unit carries value, what is included, what requires additional scope, and what would cause the account to expand.
Early discounts can conceal a weak value proposition, while custom packages can conceal the absence of a repeatable product. Set guardrails and document every exception. If the same exception keeps appearing among otherwise qualified buyers, investigate whether the package is wrong. If each account needs a different exception, question the ICP or the core offer.
Do not postpone this work until a sales team arrives. Pricing, packaging, ICP, and the move toward larger customers reshape both the product and the business. The founder-led stage is where you learn which value can be sold repeatedly before organizational scale makes every change more expensive.
Read the evidence before you scale the motion
No single enthusiastic customer, revenue event, usage chart, or product survey settles product-market fit. Look for reinforcing evidence across demand, buying, delivery, and continued value. The question is not whether every signal is perfect. It is whether the signals increasingly describe the same market and the same product.
Use a compact product-market fit scoreboard:
Problem recognition: qualified prospects independently describe a similar high-stakes problem and trigger.
Buying urgency: opportunities are connected to active decisions rather than open-ended exploration.
Commitment: prospects provide money, authority, data, access, implementation effort, or another meaningful resource.
Product repeatability: customers reach the core outcome without requiring a new product strategy for each account.
Value realization: the agreed success condition is observable, and the customer can connect it to the original consequence.
Continued pull: customers keep using the product, renew, expand, or advocate because the underlying job persists.
GTM repeatability: the target, trigger, buyer, promise, objections, and path to a decision become more predictable.
Strategic focus: wins cluster around a coherent wedge instead of a collection of unrelated exceptions.
Read combinations of signals rather than averaging them into a vague score. Repeated pain with little commitment usually points to weak urgency, the wrong buyer, or a value proposition that is not strong enough. Strong commitment followed by failed delivery points toward an outcome or implementation problem. Successful pilots that never reach a buying decision point toward poor qualification or an evaluation with no commercial consequence. Customer success that depends on substantial account-specific work points toward repeatability risk.
A cluster of wins around one trigger is not a reason to broaden immediately. It is a reason to narrow the ICP and deepen the wedge. Earn the right to add adjacent products after the core job, buyer, and delivery model are clear. Expansion should compound an existing advantage for the same customer, not compensate for a core offer that has not yet become necessary.
Hand off a system, not the founder’s intuition
A founder should stop being the only person who can sell before founder availability becomes the company’s growth ceiling. But hiring sales because the founder is tired is not evidence that the motion is ready. The handoff becomes sensible when another capable person can identify the same target, discover the same problem, tell the same value story, apply the same qualification rules, and reach a decision using substantially the same product.
Document the motion before transferring it:
ICP and anti-ICP criteria
Trigger events that create urgency
User, champion, economic buyer, and approver roles
Core problem statement and value proposition
Discovery questions and observable qualification evidence
Reasons to disqualify or nurture an account
Common objections and what each objection reveals
Demo path tied to the customer’s job
Pilot scope, success criteria, end condition, and decision
Pricing, packaging, and discount guardrails
Implementation dependencies and recurring failure modes
Win-loss and product feedback loops
The founder can then move from running every ordinary opportunity to reviewing patterns, joining high-learning exceptions, and changing the system when the market changes. That preserves customer contact without making founder heroics the operating model.
Key takeaways
Define product-market fit as repeatability across customer, problem, commitment, outcome, and product – not as general excitement.
Write an ICP, anti-ICP, trigger, economic buyer, required commitment, and disconfirming condition before outreach.
Treat interviews, feature requests, pilots, purchases, and continued use as different levels of evidence.
Require every proof of concept to have written scope, success criteria, an end condition, and a decision that follows.
Keep founders, product leaders, and builders close to buyer objections until the learning can be encoded into a repeatable motion.
Use manual work to test an outcome, but expose the work clearly enough to judge whether delivery can become repeatable.
Scale GTM only after another person can apply the same targeting, qualification, story, product, and path to a decision.
Before your next prospect conversation, write the market thesis and the evidence that would invalidate it. After the conversation, record what you observed about the problem, trigger, authority, urgency, commitment, delivery risk, and buying decision. Once a pattern emerges, make one explicit choice: narrow the ICP, change the promise, change the product, change the buying path, or stop. That is how founder activity becomes product-market fit evidence.
Your customer interviews point toward one problem. The largest deal in the pipeline demands another. Meanwhile, the activation data says the real constraint sits somewhere else. All three signals may be valid, but they are not interchangeable.
This is where many roadmap debates go wrong. Discovery, strategy, and growth are treated as competing sources of requirements instead of distinct parts of the same decision system. Discovery reduces uncertainty. Strategy determines which customers and problems deserve commitment. Growth defines the behavior and business outcome that must change. You need all three, in that order, to make a defensible product bet.
Decide which uncertainty you are resolving
A request can sound urgent while leaving the underlying decision undefined. Build this feature. Improve onboarding. Move upmarket. Add another product. Increase conversion. Each statement proposes activity without identifying the uncertainty that could make the activity wrong.
Before discussing solutions, classify the decision:
Problem uncertainty: Do the intended users experience the problem often enough, with enough consequence, to change their behavior?
User uncertainty: Which customer is canonical for this decision, and which adjacent users are explicitly not driving it?
Solution uncertainty: Can the proposed experience deliver the intended benefit without introducing unacceptable effort, risk, or switching friction?
Strategy uncertainty: Does solving this problem reinforce the position and capabilities the company has chosen to build?
Growth uncertainty: Is acquisition, activation, retention, expansion, or monetization the actual constraint?
The canonical user matters because an average customer is usually a fiction. A new account evaluating the product, an active individual user, a team administrator, and an enterprise buyer can encounter different problems and define value differently. Narrowing the problem and stack-ranking canonical users keeps edge cases from acquiring the same weight as the core job.
Write the decision as a falsifiable statement:
For [canonical user] trying to [make specific progress], the current [behavior or workaround] causes [meaningful consequence]. If the product enables [new behavior], then [leading indicator] should change because [reason]. I will reconsider the bet if [counter-signal] appears.
This statement forces several useful distinctions. The job is not the feature. The customer benefit is not the company’s revenue target. The leading indicator is not a delivery milestone. The counter-signal is not a failed launch; it is evidence that could invalidate the reasoning before the company spends more.
If the team cannot complete the statement without using broad phrases such as improve engagement or serve enterprise customers, discovery is not finished. Do not hide that ambiguity inside a prioritization score.
Turn discovery inputs into decision evidence
Discovery is useful when it changes a decision. A large repository of interviews, feature requests, dashboards, and sales notes is only potential evidence. It becomes decision evidence when each input is connected to a canonical user, a job, a consequence, and a choice the team may make differently.
Different channels reveal different parts of the problem:
Signal
What it can reveal
What it cannot prove alone
Best use
Customer interviews
Context, language, workarounds, desired progress, and perceived consequences
How common the behavior is across the target segment
Problem framing and hypothesis formation
Usage telemetry
Observed paths, abandonment points, repeat behavior, and differences between cohorts
Why the behavior occurred or what the user expected
Locating activation and retention friction
Support and customer experience
Recurring confusion, broken workflows, and the consequence of unresolved problems
The needs of users who never contact support
Finding high-friction moments and improving the feedback loop
Sales and win-loss feedback
Buying objections, competitive pressure, procurement needs, and expansion blockers
Whether buyers will adopt the product successfully after purchase
Enterprise requirements, packaging, and positioning
Interviews should test whether the problem is real, consequential, and poorly served. They should not ask customers to endorse a proposed solution. Questions about the last time the problem occurred, what the customer did, what failed, and what the failure cost produce stronger evidence than asking whether someone would use a feature.
Operational consistency matters just as much as interview quality. A 700-tag feedback system at Notion illustrates how seriously a product organization can classify customer needs across dimensions. You do not need to copy that volume. You do need a stable taxonomy that prevents login difficulty, missing workflow, buyer objection, and pricing concern from collapsing into a generic feedback bucket.
At minimum, tag each meaningful signal by:
Canonical user or customer segment
Job the customer is trying to complete
Lifecycle stage where the problem occurs
Observed behavior or current workaround
Consequence of the problem
Requested solution, kept separate from the underlying need
Signal channel, such as usage, interview, support, sales, or win-loss
Strategic theme and growth constraint
Confidence and relevant counterevidence
Sales deserves particular care. It can be a high-value listening post when field observations are paired with usage patterns and win-loss analysis. It becomes a roadmap distortion when every deal request is treated as market truth. A disciplined sales-product feedback loop separates the buyer’s objection from the product capability that may solve it.
Bring an evidence packet, not a vote count, to the decision. It should contain the problem statement, supporting behavior, customer context, counterevidence, affected segment, strategic relevance, recommended action, and the least expensive next test. One high-consequence signal from the intended market may matter more than a long list of low-consequence requests. The reason should be visible, not implied.
Make strategy visible in a written trade-off memo
Strategy is not another score added to the backlog. It is the set of constraints that prevents the backlog from becoming the strategy.
My rule is simple: a roadmap candidate earns commitment only when the team can explain why this customer, this problem, and this outcome matter more than the credible alternatives. A weighted score cannot rescue a bet aimed at the wrong customer or growth constraint.
Customer benefit: What becomes meaningfully easier, faster, safer, or more effective?
Canonical user and job: Who is driving the decision, what progress are they seeking, and who is outside the initial scope?
Evidence: What behavior, customer context, field signal, and counterevidence support the problem?
Strategic fit: Which chosen market, capability, or product position does this strengthen?
Growth hypothesis: Which lifecycle behavior should change, and how should that contribute to the business outcome?
Measures: What leading indicator can move early, and what lagging outcome confirms durable value?
Non-goals: Which adjacent requests will not be solved by this bet?
Dependencies and risks: What has to be true across product, engineering, design, data, sales, support, or operations?
Opportunity cost: Which credible alternative will wait if this proceeds?
Stop or reconsider condition: Which evidence would cause the team to adjust, pause, or stop?
Decision owner: Who resolves disagreement and remains accountable for the outcome?
Evaluate the memo through gates rather than blending every factor into one score. Strategic fit comes first. Customer evidence follows. Then test the growth logic, feasibility, ownership, and opportunity cost. A bet that fails an early gate should return to discovery or leave the roadmap; it should not survive because easy engineering or executive enthusiasm inflated its total.
This becomes especially important in familiar portfolio conflicts:
A large customer request versus a canonical-user problem: Favor the customer request when it reveals a repeatable capability needed by the chosen segment, not merely because the account is large.
A second product versus deeper investment in the core: Expansion can be rational when customer signal is strong, the new surface is adjacent, ownership is clear, and the cost to the core is explicit. Twilio’s early decision to launch a second product is a useful reminder that focus does not always mean maintaining a single product; it means making the portfolio logic explicit.
Self-serve activation versus enterprise readiness: Both may matter, but they solve different customer and growth constraints. Name the shared platform work and the motion-specific work separately.
Feature parity versus differentiation: Build parity only where its absence blocks consideration. Invest beyond parity where the product can produce distinctive customer progress.
Install mechanisms that preserve the decision
A good memo can still disappear beneath delivery activity. Preserve the reasoning with a single-threaded owner, a decision log, and a weekly business review focused on leading indicators. These mechanisms make judgment repeatable and keep context from vanishing when people, conditions, or plans change.
The decision log should record the decision, owner, options considered, evidence used, trade-off accepted, and condition for revisiting it. The weekly review should answer: What changed in the leading indicator? What new evidence arrived? Which assumption weakened? What decision is now required? Status reporting belongs elsewhere unless it changes one of those answers.
Run post-mortems on wins as well as misses. A successful launch can hide whether the result came from the intended mechanism, an unusually strong cohort, a sales push, or a temporary market condition. Writing decisions down, examining successes, and allowing principled executive debate make it easier to distinguish a repeatable operating advantage from a fortunate result.
Connect the growth motion to the customer job
Growth pressure often arrives as a target and quickly turns into a feature list. Reverse that sequence. Identify the behavior constraining growth, then determine which customer job, product change, packaging decision, or go-to-market motion could move it.
Revenue is a business outcome, not a product behavior. A useful growth hypothesis identifies the behavior beneath it: reaching the first meaningful outcome, repeating the core job, inviting collaborators, adopting another workflow, expanding across a team, or crossing a value threshold that justifies payment.
For self-serve growth, design around value realization
Self-serve works when the intended user can understand the promise, begin without heavy assistance, encounter meaningful value, and keep progressing. That means onboarding, activation, trial design, pricing, and packaging are one connected system.
Define activation as evidence that the customer experienced the product’s core benefit, not merely that an account was created or setup steps were completed. Then inspect whether activated users return to the job. A conversion gain paired with weaker retention may indicate that the paywall moved, not that customer value improved.
A trial does not have to expire according to the calendar. Notion’s trial is not time based, which demonstrates an alternative: connect evaluation and packaging more closely to value realization. The relevant question is not whether every company should copy the mechanism. It is whether your trial gives the intended customer a fair path to the aha moment while preserving a clear reason to pay.
For sales-led or hybrid growth, separate signal from deal pressure
Human assistance is often appropriate when value spans many stakeholders, implementation is complex, or buying introduces administration and procurement requirements. The mistake is allowing the sales motion to turn account-specific requests into an unexamined product strategy.
Classify every material field request as an isolated account need, a repeated segment need, a buying requirement, an adoption barrier, a platform capability, or a packaging issue. Then connect it to product usage and post-sale outcomes. A requirement that repeatedly unlocks purchase but produces weak adoption is not automatically a successful roadmap choice.
Customer concentration also changes the decision. When Uber significantly reduced its investment in Twilio products, the downside of depending heavily on a major customer became visible across growth planning. Review product and revenue dependencies before an account’s priorities become your de facto roadmap.
Make positioning carry the same strategic choice
A product cannot target one job in discovery, optimize another in onboarding, and promise a third in the market. Positioning should express the same customer progress that the roadmap and growth model are built to deliver.
Slack’s where work happens positioning shows the value of anchoring a competitive story in the customer’s job rather than a catalogue of features. In a crowded market, that narrative must also survive the product experience: champions need credible proof, new users need a clear path to value, and switching friction must be deliberately reduced. Differentiation has to be engineered as well as communicated.
Capture the complete growth choice in a decision card:
Target customer and buyer
Customer job and value moment
Constrained lifecycle behavior
Product and go-to-market hypothesis
Leading indicator and durable outcome
Guardrail for retention, support burden, or another adjacent consequence
Critical discovery uncertainty
Packaging or pricing implication
Evidence that would trigger adjustment or stop the bet
This card prevents a growth target from floating above the product decisions expected to deliver it. It also gives product, marketing, sales, and customer experience a shared hypothesis without pretending their signals are identical.
Key takeaways
Separate problem, user, solution, strategy, and growth uncertainty before discussing priority.
Choose a canonical user and name who is outside the initial scope; otherwise edge cases will quietly become roadmap commitments.
Combine interviews, behavior, support, sales, and win-loss signals according to what each channel can actually prove.
Require a written trade-off memo that includes strategic fit, growth logic, non-goals, opportunity cost, counterevidence, and a stop condition.
Treat self-serve, sales-led, and hybrid growth as consequences of how customers experience, buy, adopt, and expand value, not as company identities.
Use a decision log, single-threaded ownership, and a weekly review of leading indicators to keep the original reasoning alive.
Study wins and misses so the organization learns whether the intended mechanism worked, not merely whether the metric moved.
At your next roadmap discussion, take the most disputed bet and complete the decision statement, trade-off memo, and growth card before arguing about sequence. The missing field will usually reveal whether you need more discovery, a sharper strategic choice, or a different growth hypothesis. Name the decision owner, record what would change the decision, and let the evidence drive the next commitment.
Your team can lose months on an idea that customers describe as useful. The warning sign is not criticism. It is polite enthusiasm with no change in behavior: no workflow shared, no buyer involved, and no commitment made.
Pre-build validation should tell you whether software is the next necessary experiment. It cannot establish product-market fit (PMF); only real adoption, repeated use, retention, and continued willingness to choose the product can do that. What it can do is replace a vague bet with an evidence-backed decision about whom to serve, which problem to solve, what outcome to promise, and what must be built first.
Key takeaways
Pre-build validation earns permission to build. It does not prove product-market fit.
Start with a narrowly defined customer, a recurring trigger, a consequential problem, and an observable desired outcome.
Past behavior, current workarounds, shared artifacts, and concrete next steps carry more weight than praise or feature requests.
Match each prototype to one uncertainty. A concept can test comprehension; a workflow can test usability; a manual service can test whether the outcome matters.
Willingness to pay becomes credible only when a real buyer considers a specific offer and advances the buying process.
Build when the most important remaining uncertainty requires a functioning product in the customer’s hands.
Define the evidence you need before you build
I treat pre-build validation as a decision gate, not a claim of PMF. The useful question is not whether people like the idea. It is: What must be true for building this product to be the most sensible next test?
Write the hypothesis before scheduling interviews or drawing screens. A practical version looks like this:
For [specific customer], when [trigger occurs], completing [job] is difficult because [constraint]. They currently use [workaround], which creates [consequence]. A solution that produces [observable outcome] should earn [concrete commitment] from [buyer] through [reachable channel].
Every bracket is an assumption. Validation consists of replacing those assumptions with evidence or discovering that they do not hold.
Specific customer: Define the segment by its situation, workflow, constraints, and reason for acting. A broad persona such as small businesses or operations leaders hides more variation than it explains.
Trigger and job: Identify what starts the workflow and what the customer is trying to accomplish. A problem without a recognizable trigger is difficult to find, message, and measure.
Existing workaround: Look for what people already do, including spreadsheets, manual coordination, another product, an outsourced service, or deliberate inaction. The workaround tells you what your product must displace.
Consequence: Determine what gets delayed, lost, duplicated, exposed to risk, or made harder. If leaving the problem alone has no meaningful consequence, urgency will remain weak.
Observable outcome: Describe the changed state, not the feature. Customers buy a completed job, reduced burden, or improved result; they do not buy your roadmap vocabulary.
Economic actor: Separate the user, champion, buyer, approver, and anyone who can block adoption. In some products one person fills every role. In B2B products they often do not.
Reachable channel: State how you expect to find qualified customers. A real problem in a segment you cannot identify or reach is not yet a workable market hypothesis.
Adjust the test to the shape of the market
A competitive market and a greenfield market require different proof.
In a competitive market, existing alternatives indicate that a category and buying behavior may already exist. Your harder questions concern switching: What is broken in the current solution? Why is that gap important now? What cost, migration effort, integration, or trust barrier would stop a change? A list of desired features is not a switching case.
In a greenfield market, the customer may have a problem without a budget, category name, or familiar buying process. Test whether the customer recognizes the problem in your language, connects it to a meaningful outcome, and can identify where a purchase decision would live. Novelty can produce curiosity without producing demand.
Recruit people because they have encountered the situation you are studying, not merely because they match a demographic or job title. If your hypothesis concerns a workflow, screen for recent participation in that workflow. If it concerns a buying problem, include people who understand how that purchase is approved.
Start each conversation with a real event. Ask the participant to reconstruct the last relevant occurrence from trigger to outcome. Useful prompts include:
What happened that caused you to begin?
What did you do first, and what happened next?
Which people, tools, documents, or systems were involved?
Where did the process slow down, fail, or require manual recovery?
What did you do instead?
What consequence did the problem create?
Who noticed or cared about that consequence?
What have you already tried to change?
Why has the current approach survived?
When appropriate, ask the participant to show a sanitized artifact, screen, template, or process map. An artifact anchors the account in what actually happens. Respect confidentiality and do not request sensitive customer, employee, financial, or regulated data merely to make an interview feel concrete.
Delay the pitch until you understand the current behavior. Questions about what someone might do encourage invention. Questions about the last occurrence expose priorities, constraints, and trade-offs that already exist.
Translate feature requests back into outcomes
A feature request is a clue, not a requirement. When someone asks for a dashboard, integration, export, approval step, or AI assistant, move backward through the request:
Which situation caused you to want this?
What outcome is blocked without it?
How do you handle that situation now?
What is the consequence of the current approach?
Why does changing it matter now?
If several participants request different features but describe the same blocked outcome, the outcome may be the stable signal. If one participant proposes many features without a recent example or consequence, you have design input, not evidence of demand.
Separate evidence from interpretation
Record what happened before deciding what it means. A compact evidence log should capture the segment, trigger, workflow, workaround, consequence, desired outcome, buying roles, direct observations, contradictions, and next uncertainty. Keep verbatim customer language separate from your interpretation so the team can challenge the conclusion without rewriting the underlying evidence.
What you hear or observe
What it can support
What it does not establish
The idea sounds interesting
The concept may be understandable or relevant
Urgency, purchase intent, or adoption
A recent event is reconstructed in detail
The problem exists in the participant’s real workflow
That the problem is common or commercially important
A workaround, artifact, or internal process is shown
The customer already invests effort in handling the problem
That your proposed solution will replace it
A prototype task is completed and the outcome is valued
The proposed interaction and result may be useful
Production use, retention, or willingness to pay
An agreed buying step is completed
The offer has enough value to justify organizational effort
Product-market fit before real use
The product is used repeatedly after launch
The product may be serving a recurring job
That the fit extends beyond the observed segment
Treat this as an evidence ladder, not a scoring formula. One enthusiastic participant should not outweigh repeated contrary behavior. At the same time, repetition alone is not enough if every participant comes from a segment you cannot reach, a use case you cannot serve, or a buyer without authority.
Test the solution, price, and buying motion without production code
A prototype is useful only when its fidelity matches the question. A polished mockup can conceal a weak value proposition because participants spend the session discussing colors, navigation, and controls. Start with the least elaborate artifact that can expose the uncertainty.
Test the value claim. Present a short description of the situation, outcome, and intended customer. Ask the participant to explain what it means, who it is for, and when it would matter. Confusion here is a positioning or problem-framing issue, not a missing-feature problem.
Test the workflow. Give the participant a realistic task in a lightweight prototype. Watch what they try to do before explaining the interface. This tests comprehension, sequence, required inputs, and whether the result fits the surrounding workflow.
Test the outcome manually. Where feasible, provide the intended result through a concierge or human-assisted process. Disclose what is manual. For an AI product, handcrafted output can test whether the outcome is valuable, but it cannot prove model feasibility, production quality, reliability, latency, or economics.
Test the offer. Put a defined scope, intended outcome, responsibilities, limits, price, and next decision in front of the actual buyer. Ask for movement in the real buying process, not a hypothetical rating.
Before a test, write down the belief being tested, the behavior you expect to observe, what would weaken the belief, and the decision that follows. If every possible result leads to the same roadmap, the exercise is not a test.
Make willingness to pay a buying-process question
Asking what someone would pay produces a number without its operating context. You need to know what budget or existing cost the offer competes with, who owns the decision, which approvals are required, what implementation work the customer expects, and which unresolved concern would prevent movement.
What would make this an absolute no-brainer for you in the next 30 days?
The value of that question is its constraint. It forces the participant to connect an outcome to a deadline and expose the remaining trade-offs. The answer is not proof by itself. Convert it into a next action: another stakeholder joins, a technical requirement is checked, a procurement step begins, a pilot scope is reviewed, or the buyer declines.
Praise: The participant says the idea is good. This costs nothing and carries little demand signal.
Participation: The participant gives time, completes a task, or returns for another session. This shows interest in the problem or process.
Access: The participant shares a workflow, provides permissible inputs, or helps define a pilot. This shows willingness to cooperate.
Organizational movement: The champion brings in a buyer, approver, security reviewer, or operational owner. This shows that the opportunity can survive beyond one person’s enthusiasm.
Economic movement: The buyer evaluates a priced offer or advances a real purchasing step. This is stronger evidence of demand, but it still does not demonstrate retention.
Not every product uses the same buying motion, and consumer products may not have visible approval steps. The principle still holds: seek behavior that costs the participant something meaningful, such as time, attention, data setup, workflow change, or money, while being honest about what that behavior proves.
Turn the evidence into a build, iterate, or stop decision
Validation becomes useful when it changes resource allocation. At the decision gate, choose one of three states:
Build. A specific segment repeatedly exposes the same consequential job; the current workaround is understood; the proposed outcome is valued; the buying roles and route to market are plausible; and customers take credible next steps. Most importantly, the largest remaining uncertainty now requires a functioning product in real use.
Iterate the validation. A real problem is visible, but the segment, trigger, language, workflow, buyer, differentiation, or offer remains unstable. Run the cheaper test that isolates that uncertainty before adding engineering cost.
Stop or resegment. Participants cannot produce recent examples, the status quo is acceptable, the consequence is negligible, no one owns the outcome, or interest repeatedly disappears when a concrete action is requested. Preserve the learning, but do not turn sunk discovery effort into a reason to build.
A build decision should not require certainty. It should require that code is now the most efficient way to learn something material. If another interview, workflow walkthrough, positioning test, or offer test can still answer the critical question, building is premature.
Build the smallest coherent loop
The first version is not the product with the fewest screens. It is the smallest solution that takes one well-defined customer from a recognizable trigger to the promised outcome. A thin experience that stops before the result cannot test the value thesis.
Reduce scope from the edges:
Serve one segment and one primary job before accommodating adjacent personas.
Support the main path before unusual exceptions.
Limit integrations to those required to complete the outcome.
Use transparent manual operations behind the product where automation is not the hypothesis.
Defer configuration and customization that do not affect adoption or the promised result.
Keep the instrumentation needed to observe activation and repeat behavior.
Do not remove the mechanism that would prove or disprove the product. If your thesis depends on collaboration, a single-user demonstration is insufficient. If it depends on repeated workflow use, a one-time output is insufficient. If it depends on trusted AI assistance, a carefully curated demo cannot substitute for evaluation on representative inputs.
A temporary product can still be rational when it has an explicit learning contract. One path toward PMF used a deliberate stepping-stone product that was not expected to be the final answer. Before making such a bet, name the uncertainty it will resolve, the behavior you will observe, the decision the result will trigger, and the investment boundary. Otherwise, temporary products have a habit of becoming permanent obligations.
Keep the organization lighter than the uncertainty
Use a small accountable group for discovery and the first coherent build. Contractors can supply specialized execution, but the product leader or founder should retain direct ownership of customer conversations, evidence synthesis, and the build decision. Outsourcing the learning loop separates the people making the bet from the evidence that should shape it.
Write the evidence memo before roadmap approval
Bring a one-page validation memo to the decision. It should contain:
The target segment and explicit disqualifiers.
The trigger, job, workaround, consequence, and desired outcome.
The user, champion, buyer, approver, and likely blockers.
The strongest behavioral evidence and the strongest counterevidence.
What each prototype tested and what changed afterward.
The offer presented and the concrete commitments received or refused.
The largest unresolved risk and why it now requires code, if it does.
The narrow product loop you intend to build and what remains manual.
The post-launch behavior that would support or weaken the PMF thesis.
Pre-build validation ends with permission to run a stronger test. Once the product is live, measure whether the customer reaches the promised value and returns at the natural cadence of the job. Do not confuse account creation, a successful demo, or one completed setup step with activation unless that event actually represents first value.
If usage is weak, separate the possible failures. The value proposition, onboarding, activation path, and retention loop require different diagnoses. Customers may not want the outcome, may want it but fail to reach it, may reach it once without developing a repeatable trigger, or may encounter a product failure after initial value. Treating every case as an onboarding problem only delays the harder conclusion.
At your next roadmap review, circle the riskiest claim in the evidence memo and design the cheapest test that could change your mind. If that test still does not require code, keep learning. If it does, build the complete narrow loop and name the customer behavior that will determine what happens next.
You probably aren’t choosing between an obviously good strategy and an obviously bad one. The harder situation is a product with encouraging customers, an expanding roadmap, a few stalled pilots, and no clean answer to whether you should stay the course or change direction.
Your job is not to manufacture certainty. It is to distinguish a product that needs more focused execution from one whose underlying mechanism no longer deserves investment. That requires a falsifiable product-market fit claim, evidence that goes beyond interest, and decision rules written before attachment takes over.
Make your product-market fit claim falsifiable
Product-market fit is not a launch milestone, a growth chart, or a feeling in the executive team. It is a repeatable relationship between a defined customer, an important problem, a product behavior that produces value, and a viable way to adopt and fund that behavior.
If your definition could describe most of the market, it cannot help you decide what to build. Replace the broad vision with a working claim:
Working claim: For [specific user] trying to [complete a specific job] in [a specific situation], the product replaces [the current workaround] through [the core mechanism], produces [an observable outcome], and can be adopted through [a credible buying or approval path]. We are not serving [an adjacent use case] yet.
Each part closes a common escape hatch:
Specific user: Name the person doing the work, not just an industry or company size. If the user, administrator, champion, and economic buyer differ, identify each one.
Specific job: Describe the recurring situation that causes action. A general aspiration such as better productivity is too elastic to test.
Current workaround: Identify what the customer does now, including manual work, another product, internal software, or simply tolerating the problem. Your real competitor is often inertia.
Core mechanism: State the part of the product that creates the advantage. If every feature appears essential, you have not found the mechanism yet.
Observable outcome: Choose evidence the user or buyer can recognize in their workflow. Feature delivery is not a customer outcome.
Adoption path: Include the budget, procurement, security, compliance, integration, or policy conditions that determine whether value can reach production.
Explicit boundary: Name an attractive adjacent use case you will defer. A strategy becomes useful when it excludes something.
For a technical enterprise product, the initial use case must also justify the cost and risk of switching. A useful test is not whether your product is somewhat better. Ask where its advantage is important enough for a customer to change architecture, pass security review, train operators, and trust it with critical work.
Write the claim on one page with the adjacent use cases you are deliberately postponing. Then use it in roadmap reviews, sales reviews, and product discovery. If an opportunity cannot strengthen or disprove the claim, it should not quietly redefine the strategy.
Build an evidence ladder that exposes false positives
Teams often declare product-market fit by combining unrelated weak signals: prospects like the demo, a respected company agreed to a pilot, usage increased after a launch, and the pipeline looks large. Each signal may be encouraging. None proves that customers repeatedly receive value through a viable business.
Separate the evidence into layers. A weakness at one layer should remain visible instead of being averaged away by strength elsewhere.
Evidence layer
What you need to learn
Common false positive
Problem
The target user encounters an important recurring problem and already spends time, money, or organizational effort on it.
People agree that the vision sounds valuable.
Use
The primary user reaches the intended value, returns to the workflow, and can use it without continuous intervention from your team.
Accounts log in, attend pilot meetings, or explore several features.
Outcome
The product changes a result the user and buyer care about.
The team ships the requested functionality on schedule.
Commercial
An economic buyer can fund the product through a durable budget or approval path and has a reason to renew or expand.
A champion is enthusiastic, or an innovation budget funds a temporary test.
Repeatability
Similar customers adopt for similar reasons through a delivery motion that becomes more predictable.
One prominent customer succeeds through exceptional executive attention and custom work.
Operability
Security, compliance, integration, support, and policy requirements can be met repeatedly without destroying the economics.
A pilot works in a protected environment that does not resemble production.
Do not wait for lagging revenue to learn everything, especially in enterprise or government markets. Regulated procurement can take quarters or years. That makes intermediate proof points more important, not optional: primary-user participation, completion of legal and security steps, access to a real funding path, production-like workflow validation, and an internal owner willing to carry the case through approval.
Design each pilot as a decision instrument. Before it begins, record:
The product-market fit hypothesis being tested.
The primary user, champion, economic buyer, and operational owner.
The baseline workflow and the outcome that should change.
The product, data, integration, compliance, and service constraints.
The point in the customer’s reporting cadence when a visible result should exist.
The evidence required to expand, run a targeted follow-up experiment, or stop.
A pilot that remains open because nobody wants to call it unsuccessful is not producing learning. Time-boxing creates a moment when evidence must be evaluated. It also protects the customer’s trust by making responsibilities and expected outcomes explicit.
Customer interviews should test behavior, not collect compliments. Ask about the last real occurrence of the problem, the sequence of work, who became involved, what failed, what the customer tried, and what approval would be needed to change the process. Then summarize what you heard and ask the customer to correct it. This clinical style makes interviews comparable and reduces the temptation to convert polite interest into demand.
For an enterprise product, your design partners should expose different risks. A visionary partner can stretch the product’s ambition. A pragmatic customer can test whether the use case repeats without founder mythology. A regulated enterprise can reveal security, compliance, and operating constraints that a friendly sandbox hides. Shared outcomes and exit criteria matter more than the prestige of the logos.
Turn focus into a system for managing commitments
Focus does not survive through persuasive strategy slides alone. It survives when the organization can see the cost of every promise and has a consistent way to reject work that does not strengthen the core use case.
Customer commitments behave like debt. The initial request may help close a deal, but the product team inherits delivery work, architectural constraints, support obligations, expectation management, and future compatibility. When those costs stay hidden, individual deals gradually become the roadmap.
Maintain a commitment ledger alongside the roadmap. For every external promise, record the customer, requested capability, strategic rationale, owner, estimated effort, dependencies, recurring support burden, target date, and work it displaces. Review the total load during each planning cycle. Any exception should require a written case, not an informal escalation from the loudest opportunity.
Use the same questions for proposed features, partnerships, and deal exceptions:
Does this deepen the non-negotiable use case or introduce a different one?
Have multiple customers in the target segment exposed the same underlying need?
Will it improve activation, recurring use, customer outcomes, renewal, or adoption risk?
Can the capability become part of a coherent product, or will it create a permanent customer-specific branch?
Does the request reveal a missing product capability, or a service and change-management need that software alone will not solve?
What committed work will move if this enters the roadmap?
What new evidence would justify revisiting a decision to defer it?
The displaced-work question is especially important. A roadmap exception is rarely free; it consumes the same engineering attention, customer trust, and leadership capacity assigned elsewhere. Naming the displacement turns an abstract opportunity into an explicit trade-off.
Founder-led or executive-led go-to-market work remains valuable before the motion is repeatable because it shortens the path from objection to learning. But proximity to customers should sharpen strategy, not allow every conversation to rewrite it. Classify each request as evidence for the core use case, evidence for a possible adjacency, or a one-customer exception. Do not place all three in the same backlog.
Product leadership also needs an explicit compact with the CEO: a shared explanation of why the company wins, a living strategy document describing how it will win, and a predictable cadence for resolving trade-offs. Add decision records that capture the evidence available, the choice made, the owner, and the condition that would trigger reconsideration. This gives teams permission to execute without reopening strategy whenever a new prospect appears.
My default is to keep the strategy page short enough to use during a live decision. It should contain the target customer, core use case, mechanism of advantage, non-goals, current evidence, largest unknowns, active commitments, and next decision checkpoint. If the page cannot help you decline work, it is describing ambition rather than directing resources.
Choose deliberately between doubling down, narrowing, pivoting, and stopping
Not every weak result calls for a pivot. Sometimes the use case is right and onboarding is poor. Sometimes one segment has genuine pull while a broad positioning strategy obscures it. Sometimes customers care deeply about the mission but cannot adopt the mechanism. These conditions require different decisions.
Double down when the same target customers repeatedly use the core workflow, receive the intended outcome, and show a credible path to continued funding. The remaining obstacles are execution problems you can name and test.
Narrow when one customer segment, workflow, or buying path works materially better than the others. Remove the weak adjacencies and make the successful path easier to understand, adopt, and repeat.
Pivot when the underlying need remains important but the current product mechanism, user, buyer, channel, delivery model, or economics cannot produce a repeatable business.
Stop when the target customer does not repeatedly act on the problem, the product does not create a meaningful outcome, or immovable constraints prevent that outcome from reaching production.
Evidence for changing course often accumulates in a recognizable pattern:
Deployment repeatedly stalls after a successful demo.
The executive champion remains enthusiastic while the primary user’s utilization stays weak.
Customers require continuing intervention from your team to reach ordinary value.
Pilots do not convert into a durable budget or production approval path.
Procurement, service, or support requirements make the intended economics untenable.
Policy, compliance, or data-sharing constraints cap the outcome rather than merely delaying it.
Every new customer requires a different use case and the supposedly shared product keeps fragmenting.
No single signal automatically demands a pivot. A failed launch may reflect positioning. Low activation may reflect onboarding. A delayed deal may reflect budgeting. The case becomes stronger when evidence stacks across use, outcome, commercial viability, repeatability, and operability, and when targeted attempts to remove the suspected friction do not change the pattern.
Write kill and commit criteria before the next experiment. Define what result would justify more investment, what result would force a strategic review, and who owns the decision. The initiative’s strongest advocate should contribute evidence but should not have unilateral authority to extend it indefinitely. As investment grows, raise the evidence bar.
A pivot memo should make the change inspectable. Include the mission that remains stable, the failed assumptions, the evidence that changed your view, the new product-market fit claim, the layers that will change, the risks created by the new direction, and the next kill-or-commit checkpoint.
Do not hide the scope of the change behind a new feature name. A genuine pivot may alter the user, problem, product mechanism, delivery model, buyer, budget source, or business model. A move from physical workspaces to virtual care, for example, affects the operating model, customer experience, economics, and expectations even if the enduring mission still serves the same community.
The metrics must change when the model changes. A marketplace needs evidence of supply, demand, liquidity, trust, and balanced incentives. A platform needs evidence of adoption, extensibility, integration, developer or partner participation, and ecosystem health. Continuing to use the old model’s scorecard can make a pivot look healthy while its new critical constraints remain invisible.
During the transition, keep senior decision-makers close to customers. Run weekly conversations until the patterns converge. Use the same interview structure, centralize what you learn, and distinguish observations from interpretations. Re-sequence go-to-market work around the budget that actually funds the problem, then redesign onboarding so the customer sees a meaningful result within a reporting cycle it already uses.
The team needs a concise pivot narrative: what changed in the environment or in your understanding, what customers demonstrated, what choice you are making, and how progress will be judged. This preserves continuity of purpose without pretending the previous mechanism still works.
Key takeaways
Define product-market fit as a falsifiable relationship between a specific user, recurring job, product mechanism, observable outcome, and viable adoption path.
Keep problem, use, outcome, commercial, repeatability, and operability evidence separate so enthusiasm cannot conceal a broken layer.
Protect focus with explicit non-goals, a ledger of customer promises, and a requirement to name the work every exception displaces.
Double down when the core relationship works, narrow when one segment clearly outperforms, pivot when the need survives but the mechanism fails, and stop when the underlying pull or achievable outcome is absent.
Pre-commit to kill and commit criteria, separate advocacy from decision authority, and raise the evidence bar as investment increases.
During a pivot, preserve the mission only if the evidence still supports it. Change the mechanism, buying path, operating model, and metrics as explicitly as the new hypothesis requires.
At your next roadmap review, choose one consequential bet and write its product-market fit claim in a single sentence. Place the evidence under each layer, mark what is still assumed, and set the next decision threshold before approving more work. If the team cannot say what would make it narrow, pivot, or stop, it is not managing a bet yet. It is protecting a preference.
References
Shivam.Consulting Blog — Cracking Government Sales: Lessons on Long Cycles, Risk, and Pivoting to Product-Market Fit
Shivam.Consulting Blog — How I Build Highly Technical Enterprise Products: Hard-Won Lessons from CockroachDB and Nate Stewart
You don’t need more evidence that your market is large. You need evidence that a specific customer has a painful job, recognizes your promise, changes behavior to try your solution, and keeps using it after the novelty is gone.
Those are separate tests. Startup teams get into trouble when they compress them into one vague question: Does this idea have potential? A yes at one stage does not carry forward automatically. By collecting evidence in the right order, you can tell whether to sharpen the message, change the product, narrow the customer, or begin scaling.
Treat validation as a chain of evidence
Product-market fit is not the first thing you validate. It sits at the end of a chain. Each link answers a different question and requires a different kind of evidence.
Problem evidence: Does a defined customer encounter this problem in a real workflow? Look for recent examples, consequences, workarounds, and a recognizable trigger.
Language-market evidence: Does that customer immediately understand the promise and see it as relevant? Landing-page responses, demo requests, and consistent customer language can help answer this.
Solution evidence: Can the customer reach the promised outcome with the product? Activation, time-to-first-value, workflow adoption, and willingness to invest effort matter here.
Product-market evidence: Does value persist? Retention, repeat use, referrals, expansion, and sustainable revenue indicate that the relationship is becoming durable.
A waitlist validates interest in a promise. It does not validate delivery of that promise. A successful pilot validates value in a controlled setting. It does not prove that acquisition, onboarding, and retention will work repeatedly across a market.
X1’s 600,000-person waitlist demonstrated exceptional consumer interest and narrative resonance. The remaining PMF questions still concerned waitlist conversion, activation, engagement, retention, and organic growth. Retool’s $2 million in annual recurring revenue before its public launch represented a different level of commitment: customers had crossed from attention into payment. Neither figure is a benchmark your startup must match. The useful distinction is the kind of uncertainty each signal removes.
Use the chain as a set of decision gates. If problem evidence is weak, more product work is premature. If the problem is strong but response to the message is weak, revisit positioning. If signups are strong but activation is poor, compare the promise with the first product experience. If customers activate but do not return on the natural cadence of the job, investigate whether the value is durable before buying more traffic.
Start narrow enough to hear a reliable pattern
An early ideal customer profile should be narrow enough that the people inside it share a job, context, trigger, and meaningful constraint. Industry and company size alone rarely provide that precision.
A useful hypothesis fits into one sentence: A specific user in a specific context needs to complete a specific job when a recognizable trigger occurs, but a constraint makes the current approach costly or unreliable.
For example, developers building internal tools are more coherent as an initial audience than everyone who builds software. Freelance designers trying to publish production websites are more coherent than everyone who needs a website. Narrowing the profile lets you detect repeated behavior instead of averaging incompatible feedback.
Run interviews as investigations of past behavior, not auditions for your idea. Select people who have encountered the job recently, own some part of its consequence, and can show or describe their current workflow. A friendly person with an opinion is less useful than a skeptical person with a real workaround.
Define the learning goal before the call. Write down what you need to learn, what evidence would weaken your belief, and which decision the answer will affect.
Anchor the conversation in a recent event. Ask the customer to reconstruct what happened rather than predict what might happen in an imagined future.
Synthesize immediately. Separate observed behavior from interpretation while the details are fresh, then compare patterns only within the same ICP and job.
Questions that expose useful evidence include:
Tell me about the last time you had to complete this job.
What triggered the work?
Walk me through what you did, including the tools and people involved.
Where did the process slow down, fail, or require rework?
What happened because of that friction?
What workaround have you already tried?
How did you decide whether the problem was worth fixing?
Who else cared about the outcome or had to approve a change?
What happened next?
Avoid asking whether someone likes the idea, whether they would use it, or which features they want. Those questions invite politeness and speculation. A requested feature is still useful, but only as the beginning of root-cause analysis. Trace it back through the underlying job, the triggering situation, the current workaround, and the consequence. That is how you distinguish a reusable problem from one customer’s preferred implementation.
After each interview, record the customer’s context, trigger, workflow, workaround, consequence, decision process, commitment, and exact vocabulary. Also record contradictory evidence. If a pattern appears only after combining unrelated roles or use cases, you have not found a pattern; you have hidden segmentation inside an average.
There is an important complication when the market is still forming. Vanta began pursuing SOC-2 compliance for startups in 2018, before many startups treated it as a requirement. Interviews about current demand alone could have understated the opportunity. In an emerging market, test the trajectory as well as the present pain: identify the earliest buyers who already feel the constraint, the event that makes it urgent, and the conditions under which others will follow. Strategic conviction should produce a falsifiable market thesis, not permission to ignore contrary evidence.
Ask the market to spend something before you build broadly
Compliments are cheap. Validation becomes stronger when a prospective customer gives up something scarce: attention, time, workflow access, reputation, data, or money. The appropriate commitment depends on the product and buying process, but the direction should move from passive interest toward consequential action.
Attention: The person stops, clicks, or reads.
Declared interest: The person joins a waitlist, replies, or requests a demonstration.
Effort: The person completes an interview, shares a workflow, or returns for another session.
Access: A design partner supplies representative data, involves colleagues, or makes room for implementation.
Economic commitment: The customer enters a paid pilot, signs a contract, or completes the real purchasing process.
Continuing commitment: The customer renews, expands, refers a peer, or repeatedly returns to the product.
This is not a universal funnel. An enterprise prospect may need security and procurement reviews before payment is possible. A consumer may reveal commitment through repeated voluntary behavior long before paying. The point is to request the strongest honest action that fits the current stage instead of treating positive words as equivalent to behavior.
You can test the narrative before building the full product. Write a landing-page promise that names the target customer, the triggering problem, the desired outcome, and the reason your approach is different. Pair it with a call to action that measures the next real commitment. A vague request to learn more produces vague evidence; a request to share a workflow, schedule an implementation discussion, or join a defined pilot reveals more.
For a B2B startup, founder-led sales should double as product discovery. After a demonstration, ask which existing workflow the product would replace, who must approve the change, what implementation or security constraints could block adoption, and what must be true for a pilot to begin. A scheduled next step with the right stakeholders is stronger evidence than an enthusiastic closing comment.
For a consumer startup, branding, positioning, referrals, and scarcity can establish emotional resonance and distribution potential. They cannot tell you whether the product creates a habit or a recurring outcome. Track how many interested people activate, what meaningful action they complete, whether they return when the need recurs, and whether they invite others after experiencing value.
Do not scale acquisition while most prospects stop at the weakest commitments. Diagnose the break first. If people click but do not sign up, the promise or targeting may be wrong. If they sign up but avoid setup, the expected benefit may not justify the effort. If they complete setup but never reach value, the product or onboarding is failing. More traffic will increase the volume of the same unresolved problem.
Turn design partners into a weekly evidence loop
A design partner is not simply an early customer who can request features. The best partners fit the same narrow ICP, face an active problem, expose the real workflow, respond quickly, and have a credible path to adoption. Their role is to help you find a repeatable solution, not fund a collection of unrelated custom projects.
Use one operating cadence from discovery through delivery
A lightweight weekly cadence keeps conversations, product changes, and behavioral evidence connected:
Choose the riskiest assumption. At the start of the week, name the belief that matters most to the next decision. Frame it around a customer outcome rather than a feature.
Observe the current workflow. Watch the partner attempt the job or reconstruct a recent attempt. Capture tools, handoffs, constraints, and failure points before discussing solutions.
Ship the smallest reusable improvement. Prefer a change that tests the underlying job across the target segment over a bespoke implementation for one account.
Measure the value path. Connect qualitative observations to activation, time-to-first-value, repeat use, referrals, and commercial progress.
Write a decision. At the end of the week, state whether the evidence supports continuing, adjusting the hypothesis, narrowing the ICP, or stopping that line of work.
Keep a one-page evidence log for each design partner. Record the triggering event, the first-value action, elapsed time to that action, blockers, the expected return event, observed return behavior, stakeholders involved, and the next commercial commitment. This makes it harder for a memorable conversation to outweigh actual product behavior.
Treat documentation, templates, examples, and implementation support as part of the value path. This is especially important for technical products. A user who understands the primitives but cannot assemble them into a working outcome has not activated. Improving the example or setup path can reduce time-to-value more than adding another capability.
Feature requests need the same discipline. Map each request through five questions: What job is the customer trying to complete? What triggers it? What do they do now? What is the consequence of the current approach? How many customers in the same target segment encounter the underlying problem? A loud customer is not automatically a market, and several similarly worded requests can still represent different jobs.
Retool’s early developer focus illustrates why this loop compounds. Tight collaboration with early customers, rapid delivery, and attention to developer-facing language reduced friction across discovery, onboarding, and activation. Webflow followed the same strategic shape from a different starting point: depth with designers came before broad adoption. In both cases, expansion was earned by solving a coherent user’s job well enough that the product could travel beyond its initial wedge.
Scale only after pull survives the launch
A launch changes who is paying attention. It does not necessarily change the value of the product. Review launch cohorts separately from later cohorts so a concentrated group of enthusiasts does not hide weaker behavior among ordinary customers.
What you observe
What it may mean
What to do next
People join the waitlist or start signup but do not activate
The story is stronger than the product experience, setup cost, or targeting
Compare the promise with the first session and remove the earliest value-path blocker before adding traffic
Customers activate but do not return
First-run value is not durable, or you are measuring on the wrong cadence
Identify the natural return trigger for the job and investigate what customers do when it occurs again
The core ICP retains while adjacent segments do not
You may have a valuable wedge rather than a broad market
Deepen the core workflow and resist premature expansion
Retained customers refer peers, renew, or expand
Value is beginning to generate organic and commercial pull
Test whether new cohorts from repeatable channels show similar behavior
The launch cohort performs well but later cohorts weaken
The initial audience or channel may have produced an unusually favorable sample
Reproduce acquisition and retention with less concentrated cohorts before increasing spend
Demand rises but every implementation requires founder intervention
Customer value may be real while delivery remains operationally fragile
Productize the repeated implementation steps before accelerating acquisition
There is no single metric that declares product-market fit across consumer products, developer tools, and enterprise software. Measure behavior on the cadence of the job. A product used when a periodic event occurs should not be judged as though its value requires daily use. A B2B product may show pull through recurring usage, renewal, account expansion, and champion-led referrals. A consumer product may show it through retained engagement, habit, word of mouth, and an organic referral loop.
The strongest PMF case triangulates three forms of evidence: customers describe an important job and recognizable consequence; behavioral data shows that they reach and repeat value; commercial or organic behavior shows that the product can grow without constant persuasion. Fundraising, press attention, a viral launch, and a large top-of-funnel number can support the company, but none substitutes for that combination.
Vanta’s decision to rely heavily on word of mouth and wait until it had hundreds of customers before building a proper website is a useful expression of this principle. The company prioritized customer outcomes and retained demand before investing heavily in its public top of funnel. You do not need to copy that tactic. You do need to know whether growth is amplifying demonstrated value or merely increasing exposure.
Key takeaways
Validate in sequence: problem, language, solution, and durable pull.
Define an ICP around a shared job, trigger, context, and constraint, not broad demographics alone.
Use interviews to reconstruct recent behavior and workarounds, not collect opinions about your idea.
Ask prospects for progressively stronger commitments that fit the product and buying process.
Run design partners through a weekly loop connecting observation, delivery, measurement, and a written decision.
Scale only when retention, repeat use, referrals, renewal, or expansion survive beyond the initial launch audience.
Before your next roadmap meeting, place every piece of evidence under the four validation gates. Circle the first gate that remains weak. Give the team one week to strengthen or disprove it, and postpone every proposed feature that does not help answer that question.
References
Shivam.Consulting Blog – How Retool Hit $2M ARR Pre-Launch: My Playbook on Developer Focus, Product-Market Fit, and GTM
Shivam.Consulting Blog – Inside X1’s Pivot: The Playbook Behind a 600K Waitlist and a $15 Million Raise
Shivam.Consulting Blog – From Narrow ICP to Broad Adoption: Customer Empathy That Fueled Webflow’s PMF
Shivam.Consulting Blog – From Doubt to Dominance: Vanta’s Bold Bet on Startup Security and Product-Market Fit
Shivam.Consulting Blog – Validate Your Startup Idea Fast: My Early User Research Playbook for High-Quality Interviews
Expanding from a single hero product to a resilient multi‑product portfolio is one of the most consequential moves a SaaS company can make. I’ve navigated this shift firsthand and studied how leaders approached it at companies like Stripe and Watershed. What follows is the playbook I use to assess new product ideas, structure teams for 0‑1 execution, and run rigorous product reviews without losing momentum on the core business.
I start by clarifying the type of multi‑product strategy we’re pursuing. Are we building adjacent features that deepen adoption, launching true net‑new products for new buyers, extending a platform with new primitives, or assembling a bundle that compounds customer value? That choice dictates everything else—resource allocation, hiring profiles, team topology, and the shape of our product discovery.
Stories from Stripe’s multi‑product success reinforce a principle I believe deeply: launch with small, high‑trust teams and a brutally clear problem statement, then iterate fast with real customers. When adding products like Stripe Billing and Stripe Treasury, the work required not only great execution but also adapting to new buyer profiles and purchasing motions. The lesson I apply is simple—don’t assume the new buyer is just a variant of the old one.
Resource allocation is where strategy meets courage. I protect the core product’s roadmap while ring‑fencing a few exceptional builders to pursue secondary bets. These squads operate with clear, outcome‑based goals and tight feedback loops, not sprawling OKR spreadsheets. The aim is to make small, reversible bets at first, then scale conviction with evidence—market pull, repeatable use cases, and early revenue signals.
Team structure matters even more than headcount. I form new‑product squads that behave like a startup within the company—full‑stack ownership, minimal dependencies, and direct access to customers. The early team must combine product discovery instincts with the ability to ship. Great early‑stage product thinkers show crisp problem framing, a bias for learning, and the humility to change course. One common fail‑case I watch for is hiring purely for potential over demonstrated ability to drive ambiguous work from zero to one.
Hiring the right people for 0‑1 work is its own craft. I look for signals of self‑direction, obsession with customer outcomes, and the ability to reason from first principles under uncertainty. I use five interview questions to unearth hidden talent among product candidates, all designed to reveal how they validate problems, reduce scope intelligently, earn trust with engineers, and handle the uncomfortable middle of product discovery.
Even the best teams stumble when product, packaging, and go‑to‑market are misaligned. I’ve seen what happens when an organization assumes the existing buyer will adopt the new product in the same way—pricing misses the mark, activation drops, and sales enablement lags. The fix is to revisit the buyer, refine the value proposition, and rebuild the path to value so the first‑run experience matches the new buying journey.
To keep new bets honest, I treat them with “definite optimism”—a clear, written view of what success looks like and a pragmatic path to get there. I focus on the sequence of proof: problem validation, consistent user pull, and evidence of repeatable adoption. In a new or early market, I combine a methodical approach (milestones, stages of validation) with analytical rigor (leading indicators, customer expansion patterns) to decide which products to prioritize and when to scale.
Goal‑setting for new products must be measurable yet forgiving of discovery. I favor outcome‑centric checkpoints over vanity metrics, and I evaluate bets by expected learning speed and cost of delay. This keeps us moving fast without confusing activity for progress.
My product reviews are anchored by 12 questions that force clarity on problem, user, value, and risk. I often share these questions as a pre‑read so teams can self‑diagnose and come in focused on decisions rather than updates. “The Enterprise Rent‑A‑Car Story” is a helpful reminder for me that distribution and execution are as decisive as the product idea itself. When building for net‑new‑customers, I re‑focus the questions on buyer change, activation friction, and early‑life cycle signals.
User feedback is the lifeblood of 0‑1. I collect inputs across interviews, product analytics, and support tickets, but I interpret them through the lens of the problem statement rather than raw feature requests. Product development must start with problem validation; otherwise, speed becomes a liability and discovery masquerades as delivery.
I also learn from builders who think in systems and act with urgency. Jack Dorsey: https://twitter.com/jack. Patrick Collison: https://twitter.com/patrickc. Shreyas Doshi: https://twitter.com/shreyas. Their public writing on product strategy, execution, and outcomes vs output informs how I evaluate talent, decide what not to build, and keep teams aligned as we scale beyond one product.
I’ve spent enough cycles scaling product organizations to know that leaders grow—or their companies stall. In this reflection, I distill the practices I rely on to scale an org, develop myself, and raise the performance ceiling across teams, especially when the economic environment demands sharper focus and better decisions.
To ground this discussion, I often point leaders to exemplary people-first operators. Jack Altman is the co-founder and CEO of Lattice, a people success platform for building engaged, high-performing teams. Lattice has raised over $330M, and was last valued at $3B. His work on culture and performance—captured in “People Strategy”—reinforces many of the principles I use daily.
I start with self-awareness because it’s the keystone. If I can’t see my own patterns—when I’m avoiding conflict, over-controlling, or confusing activity with outcomes—everything else degrades. I cultivate self-awareness by writing brutally honest weekly retros, asking my staff for one piece of constructive feedback every month, and running periodic 360s to reveal blind spots. The goal isn’t comfort; it’s truth. When I improve my signal on reality, my decisions get faster and my team gains confidence.
Difficult conversations are a gift to performance. I’ve learned to tackle them quickly, with empathy and specificity. I name the gap between expectation and outcome, share observable examples, state the impact on the team, and propose a clear path forward with timelines. If emotions run hot, I slow down, seek to understand, and stay on the behavior and results—not the person. Avoidance compounds culture debt; candor repays it with interest.
Scaling a company introduces predictable failure modes. I’ve seen leaders confuse hiring errors with management errors; it matters which you’re facing. A hiring error shows up as persistent gaps in role fundamentals even after clear expectations, coaching, and time-bound support. A management error usually stems from ambiguous goals, poor context, or inadequate resources. I assume management error first and fix the environment. If results still lag, I revisit the hire.
Delegation versus control is a healthy tension. Early, I’ll “micro-mentor” on critical work to teach quality, taste, and judgment—then expand autonomy as pattern recognition develops. My rule: delegate outcomes, keep ownership of standards and context. I never give up the responsibility to set the bar for the team and to protect the product vision; those are one-way doors that define the company’s trajectory.
Building a product organization that compounds requires clarity and context. I ensure every product trio understands the strategy, customer segments, and constraints. We anchor on outcomes vs output OKRs, maintain a living strategy doc, and write decision memos that document trade-offs. When context flows, people need fewer approvals and produce better work, faster.
On so-called micro-management, here’s my take: it’s a tool, not an identity. Early in a function or with a new leader, I may be intentionally hands-on to transfer judgment. The moment competence and trust are proven, I deliberately pull back. The mistake isn’t micro-managing; it’s forgetting to stop.
CEO-level context setting is non-negotiable. I articulate the narrative behind the plan—the why, the constraints, the risks, and what we’re not doing. Transparency isn’t oversharing; it’s sharing the right information at the right fidelity so people can make aligned decisions. I model this with written updates, open Q&A, and by explaining how major calls were made.
Some of the most valuable leadership work happens in uncomfortable conversations. I prepare by drafting the core message, testing it for clarity and fairness, and deciding what success looks like for the person and for the business. I also own the decision. When the stakes are high, I don’t outsource the final call or feedback to a proxy; accountability builds trust.
Speed versus accuracy in decision-making is situational. For reversible bets, I bias to speed, time-box the experiment, and set clear kill criteria. For one-way doors, I slow down, increase the sample of perspectives, and pressure-test assumptions. I counter hidden biases in group discussions by starting with silent written proposals and independent scoring before we debate out loud.
I’ve even experimented with removing myself from recurring meetings for a cycle. The outcome: decisions kept moving, and I learned where my presence added value versus created drag. Now I show up intentionally—for feedback on taste, to unblock cross-functional issues, or to deliver context—then get out of the way.
Here are four practices that consistently pay off for me: protect deep work blocks for strategic writing, conduct weekly customer calls, review hiring quality monthly, and keep a running list of hard problems only I can solve. This keeps me oriented toward leverage, not busyness.
Talking to customers is an art. I avoid solution-leading questions and ask about current workflows, pains, and the last time the problem showed up. I go five whys deep, quantify the value of a better outcome, and listen for language customers use to describe success. The best product discovery lives in those unpolished details.
Great leaders are constant learners. I rotate through books, operator peer groups, product management leadership communities, and curated newsletters. I also treat my own organization as a learning system—post-mortems, pre-mortems, and lightweight experiments build institutional knowledge faster than any single playbook.
To maximize employee performance, I use a simple model: Clarity x Capability x Motivation x Environment. Clarity means crisp expectations and definitions of done. Capability is skills and experience, which I grow via coaching and targeted practice. Motivation blends purpose, recognition, and meaningful goals. Environment covers tools, psychological safety, and focus time. If any factor is near zero, performance collapses; my job is to diagnose and raise the lowest one.
When long-time employees stop scaling with the company, I address it early. Sometimes a role redesign or releveling unlocks success. Other times, a dignified, well-supported transition is the right call for everyone. Avoiding the issue erodes trust; handling it with clarity and care strengthens culture.
Low-performing but well-liked employees create a leadership test. I separate likability from impact. If values are strong but performance lags, I set a time-bound plan with clear checkpoints. If progress doesn’t materialize, I act. Keeping someone in a role they’re not meeting hurts the team and the individual by delaying a better fit.
When someone is let go, I’m thoughtful about what to share. I communicate the change promptly, state the role-level rationale without gossip, thank the person for their contributions, and reinforce the plan going forward. The aim is to honor privacy while maintaining clarity about standards.
In today’s tougher macro environment, I refocus on capital efficiency, ROI-driven roadmaps, and slower, more deliberate hiring. I raise the bar for product bets, validate earlier with customers, and price for value. Constraints, when embraced, sharpen strategy and execution.
Aligning career goals with company goals is ongoing work. I use growth frameworks, individual development plans, and quarterly conversations that link business outcomes to skill-building. When people see a path to mastery and impact, performance accelerates.
Most leaders underestimate their team’s potential. I raise expectations with ambitious, outcome-based goals, ensure people have the context to operate like owners, and celebrate learning velocity as much as wins. When standards, support, and trust rise together, teams routinely outperform even optimistic forecasts.
I get asked constantly how I decide when to trust my gut, when to lean on data, and when to take a big swing versus iterate. As a product leader, my answer has been shaped by hard-won lessons building B2B SaaS, product-led funnels, and enterprise features. Recently, I revisited Slack’s approach to decision-making, product reviews, and balancing product-led vs sales-led growth—and distilled a set of practices I use with my teams today.
Noah Desai Weiss is the Chief Product Officer of Slack, and has an accomplished track record inside and outside of the company. He started Slack’s Search, Learning, and Intelligence division, led the Self-Service (SMB) Business, and led the Expansion and Virtual HQ product areas (responsible for Huddles, Clips, and more). Before joining Slack, Noah was the SVP of Product Management at Foursquare (raised over $390m), and was a Product Manager at Google.
The throughline for me starts with a simple truth: not all decisions should be data-driven. Early in a product’s life—or when exploring a novel experience—data is often either unavailable or misleading. That’s where intuition, taste, and judgment come in. I treat intuition as a hypothesis generator and momentum maker, then instrument quickly to validate direction. This blend of “When to use intuition vs data to drive decisions” has saved me from overfitting to small datasets and from analysis paralysis when speed was the real advantage.
I’ve learned that “Taste and judgment are learnable.” You can coach it. Review artifacts together. Run side-by-side comparisons of design explorations. Write down what “good” looks like and why. My teams keep a living gallery of exemplary UX patterns and empty-state copy that exemplifies our bar. Over time, this scales the craft of intuition across a larger org—just as “How Slack scales intuition across their product org” suggests.
Of course, there are “Challenges of intuition-led product building.” The biggest are founder or leader overreach and survivorship bias. I mitigate this with timeboxed discovery: we commit to a clear decision date, capture our priors in writing, and express our confidence as a range rather than a point estimate. This sets up a healthy dynamic for “Managing pace vs accuracy in decision-making.” We move fast when reversibility is high, we move slower when the blast radius is large.
Matching people to the work matters too. Some product problems are inherently ambiguous and benefit from researchers, designers, and PMs who derive energy from the unknown. Others are best led by optimization-oriented builders who light up when the metric moves. I’m explicit about “Matching people to data vs intuition-driven work,” and I rotate folks so they can build both muscles.
In remote and hybrid environments, I’ve found the most underrated traits are proactive context-sharing, crisp written communication, and the ability to create signal in Slack and docs. “Underrated qualities for remote workers” aren’t just stylistic preferences—they are execution speed ups. I look for people who make everyone around them smarter asynchronously.
On product process, I’m inspired by “How Slack runs product reviews.” My rubric: one problem statement, a tight narrative memo, the bet framing (assumptions, risks, kill criteria), and outcomes tied to “outcomes vs output OKRs.” We align on the decision owner, consent vs consensus, and the next irreversible checkpoint. This keeps reviews from becoming theater and pushes decisions to the right altitude.
Culture shows up in small moments. “The importance of a team’s ‘vibe’” is tangible: Do we demo early? Do we celebrate learned negatives as much as wins? Do engineers, designers, and PMs feel joint ownership of the experience, not just their function’s slice? When the vibe is right, latency from idea to insight collapses—and that compounding is everything in product discovery.
Portfolio balance matters. I aim for a mix that lets us keep shipping customer-visible improvements while reserving room for breakthroughs. “Balancing “big swings” with incremental improvements” requires explicit ring-fencing: 70/20/10 works well for many orgs. Big swings get stage gates and PR/FAQ-like artifacts; incremental bets get weekly ship cadence and tight measurement. When we miss, we run pre-mortems and decision journals, reinforcing “Rituals for good decision-making.”
Go-to-market is where strategy meets friction. My guidance on “Advice on product-led vs sales-led growth” is to design the handshake up front. Let product-led growth do the land—self-serve activation, collaborative aha, bottoms-up virality—and let sales-led growth do the expand—security, compliance, procurement, multi-workspace governance. Instrument the handoffs, define eligibility heuristics, and ensure pricing doesn’t punish adoption. This is also where “Which products should focus on end-users versus executives” gets real; optimize early journeys for end-user success while giving executives the portfolio-level control and analytics they require.
I’m continually impressed by “What Slack learns from Salesforce.” Enterprise trust, admin controls, and scalable GTM motions can coexist with consumer-grade product craft. That hybrid DNA is powerful. I’ve adopted similar patterns: build for end-user joy, layer enterprise-grade controls, and price to match value realization, not procurement theatrics.
Speaking of pricing, “Pricing lessons from Salesforce and Marc Andreessen” pushed me to keep pricing simple enough for PLG while being flexible enough for enterprise. Seat-based pricing remains intuitive for collaboration products, but usage and “SaaS pricing” add-ons can map value to heavy features without overcrowding your price page. The key is to test willingness to pay early, avoid grandfathering yourself into a corner, and treat packaging changes like product changes—with discovery, rollout plans, and success metrics.
Humility isn’t fluffy—it’s an execution advantage. “Slack’s humility and why it matters” resonates with how I try to lead: ruthlessly honest about what we don’t know, eager to learn from customers quickly, and unafraid to reverse course when the evidence changes. That humility turns into speed because we stop defending past decisions and start iterating toward truth.
When working with a strong product voice at the top, “How to build product with a product-focussed founder” comes down to mutually agreed principles. Capture the founder’s taste in explicit heuristics, define the moments where their judgment should overrule the process, and codify how dissent and disagree-and-commit work in practice. This protects clarity without stifling creativity.
Here are the topics I unpacked and continue to apply across teams: “When to use intuition vs data to drive decisions,” “The most underrated traits in a remote work environment,” “How Slack runs product reviews,” “The importance of a team’s ‘vibe’,” “Managing pace vs accuracy in decision-making,” “Balancing “big swings” with incremental improvements,” and “Advice on product-led vs sales-led growth.” Each one is a lever that compounds when used together.
Curious to learn more about Slack? You can try Slack Pro and get 50% off using this link.
I’m always looking for crisp, scalable ways to drive product strategy, organizational alignment, and cross-functional performance that actually ship outcomes. Studying Loom’s operating system—and the career arc behind it—offered a masterclass worth sharing. Anique Drumright is the COO at Loom, a video communication tool for streamlining workflows. Loom has raised over $200M, and was last valued at $1.5B. Anique has a proven track record across product development, executive leadership, and building high-performing organizations. Before joining Loom, Anique was the VP of Product at TripActions, where she scaled the team over 8x globally, and she has also held multiple roles at Uber.
In this breakdown, I dig into best-practice product management, how to achieve alignment at scale, the mechanics of cross-functional performance, Anique’s approach to finding top organizational talent, how to hire for roles outside your area of expertise, the most common fail cases with internal and external recruitment, and the specific interview tactics that actually surface the truth.
One theme I return to often is the transition from product management to executive leadership. As a PM, I optimize for customer insight, prioritization, and execution velocity. As an exec, I optimize for clarity, systems, and sustained energy across teams. The job shifts from owning a roadmap to owning the conditions under which many roadmaps thrive—organizing for outcomes, setting non-negotiable standards, and removing ambiguity.
Storytelling sits at the center of launch excellence. I love how Loom anchors launches in a human narrative: define the painful “before,” demonstrate the transformative “after,” and spotlight one memorable capability that makes the switch inevitable. I pair this with a crisp narrative memo, a demo-first internal review, and a simple, outcome-oriented success metric—so product, marketing, and sales sing the same chorus.
Managing cross-functional scope and performance requires ruthless role clarity and shared measures of success. I align on a single definition of the customer problem, agree on leading indicators we can move now, and assign one DRI per decision. When we use outcomes vs output OKRs, we unlock better trade-offs: fewer features shipped, more customer problems solved.
Organizational alignment is both essential and fragile. What looks like misalignment is usually mismatched time horizons, unclear ownership, or different definitions of success. The antidote is explicit agreements: who decides, how we decide, and what “good” looks like this quarter. When in doubt, I over-communicate context, not tasks.
I’ve seen at scale—Uber is a notable example—that alignment travels fastest through shared rituals, not longer documents. Weekly business reviews, lightweight decision logs, and a common operating cadence create a heartbeat the org can follow. The point isn’t ceremony; it’s repeatable clarity.
My go-to alignment rituals are simple. A Monday priorities memo sets the narrative and the week’s must-win outcomes. Midweek, a cross-functional stand-up surfaces risks and unblocks dependencies. Friday, we close the loop with a red-yellow-green on outcomes and a short retro on decisions—not just results—so we compound learning.
One-on-ones are performance multipliers when they’re designed well. My winning format: start with energy and focus (what’s giving or draining energy), review outcomes not activity, walk a single thorny decision to closure, and end with explicit asks in both directions. Over time, this builds trust and speed.
When and how to help functional leaders matters. I jump in when a decision is high-impact and ambiguous, when speed has stalled, or when the problem crosses multiple functions. Otherwise, I coach on principles and expect leaders to own the path. If I’m often in the weeds, we have a structure or talent gap—not a diligence problem.
Hiring outside my domain expertise starts with outcomes, not resumes. I write the first-90-day outcomes, name the decisions the role must own, and recruit with a structured case that mirrors the real job. I bring in a domain advisor to probe depth and run a work-sample test to reduce false positives from polished storytellers.
For senior leaders, my favorite interview questions are simple and hard to fake: Tell me about the last time you changed your mind on a critical decision—what evidence moved you? Walk me through your operating cadence—meetings, artifacts, and decisions—in a typical month. Describe your hardest cross-functional miss and the system you changed to prevent a repeat. The specificity of answers reveals the operator from the commentator.
I adjust the hiring process when I’m outside my depth: heavier emphasis on work samples, more structured rubrics, a domain expert panel, and reference checks that test for actual outcomes. When the role is pivotal, I’ll run a paid trial project with clear guardrails; reality is the best filter.
Common patterns of failed external hires: they manage optics over outcomes, never rewire the system, and don’t create leaders beneath them. Failed internal promotions often show up as scope growing faster than judgment, a reluctance to reset standards with former peers, or success limited to a familiar domain. Avoid over-promotion by decoupling recognition from scope; celebrate excellence without inflating title or span prematurely.
To get honest answers in interviews, I normalize candor and ask for receipts. I request artifacts—planning docs, dashboards, postmortems—and I probe for the counterfactual: what would you do differently if you had to do it again? In reference checks, I ask for moments of truth: the hardest feedback you gave them, a decision you disagreed with and how they handled it, and the exact conditions under which you would rehire them tomorrow.
Sustaining energy is an executive’s quiet superpower. I watch team energy levels as closely as metrics. What inspires people in a company is progress they can feel, standards that mean something, and leaders who tell the truth. If we keep those three alive, performance follows.
A month in the life of a COO (and frankly any executive operator) is a portfolio: setting the narrative and outcomes, running the operating cadence, calibrating talent, and clearing systemic blockers. The best leadership dynamics work because roles are explicit, trust is earned through delivery, and debates resolve into single-threaded ownership—not committee compromises.
Resources for further exploration: Loom (https://www.loom.com/), Navan (formerly TripActions): https://navan.com/, Teach for America: https://www.teachforamerica.org/, Uber: https://www.uber.com/.
Timestamps I mapped my notes to for quick scanning: [00:03:00] similarities and differences between PM and executive leadership roles; [00:06:53] storytelling in launches; [00:10:01] cross-functional scope and performance; [00:13:41] goal-setting with functional leads; [00:16:59] organizational alignment; [00:20:40] alignment at scale; [00:24:06] alignment rituals; [00:25:23] one-on-one format; [00:27:49] supporting functional leads; [00:29:13] hiring outside your expertise; [00:32:55] interview questions; [00:33:55] adapting the hiring process; [00:36:09] failed external hires; [00:37:40] failed internal hires; [00:39:05] avoiding over-promotion; [00:40:51] inspiration; [00:45:40] getting honest answers; [00:47:12] reference checks; [00:51:29] a month in the life of a COO; [00:52:52] energy levels; [00:54:53] leadership dynamics; [00:57:30] outsized career influences.
