Month: October 2025

  • Build a Repeatable Startup GTM: Positioning, Sales, Pricing

    Build a Repeatable Startup GTM: Positioning, Sales, Pricing

    You have a product that can win customers, but the path to each win still feels improvised. The founder explains the product differently on every call. Pilots have different scopes. Pricing changes by prospect. Marketing wants a sharper story, sales wants more leads, and product wants cleaner evidence about what to build.

    The way out is not to add every go-to-market function at once. Build the system in sequence: diagnose the constraint, choose a narrow customer and problem, use founder-led sales to learn, turn pilots into repeatable customer outcomes, and price the value path you can actually prove. Scale only after those pieces reinforce one another.

    Find the constraint before you add another GTM motion

    Startups often call every growth problem a pipeline problem. That diagnosis is expensive. More demand magnifies weak positioning. More salespeople reproduce an unstructured founder pitch. More sign-ups increase support work when activation is broken. A pricing change creates noise when customers still cannot explain the value.

    Separate the customer journey into five stages and identify the first one that is failing:

    • Acquisition: Are the right people entering the funnel, or are you attracting accounts with no urgent reason to change?
    • Activation: Do new users reach a meaningful first outcome, or do they create an account and disappear?
    • Sales: Do qualified buyers advance through a clear decision process, or do conversations end with vague interest and no next step?
    • Value realization: Do customers achieve the outcome that justified the purchase, or does the product become another underused tool?
    • Monetization and expansion: Does what the customer pays grow with the value received, or do packaging and entitlements block a natural upgrade path?

    Use observed behavior, not departmental opinion, to select the constraint. If founder-led selling works but the story changes across calls, the immediate need is usually product marketing and enablement. If sign-ups are healthy but activation or conversion is weak, the problem belongs closer to product, onboarding, and growth. If customers buy but struggle to reach the promised outcome, acquisition is not the priority; customer success and product reliability are. These are different operating problems that require different early hires.

    Write the diagnosis in one sentence:

    For [specific customer], [observable stage] is breaking because [evidence], so the next test will change [one variable] and measure [one leading signal].

    “Growth is slow” is not a diagnosis. “Operations leaders attend a demo but do not involve the workflow owner or commit to a decision step” is. The second version tells you to investigate urgency, stakeholder access, and the sales process before buying more traffic.

    Agree on the meaning of qualified, activated, retained, and expanded before reviewing a dashboard. Otherwise, product, marketing, and sales can report improvement while describing different populations. Shared definitions are the first piece of GTM infrastructure.

    Position the product around one urgent job, not its full potential

    A capable product is not automatically an easy product to buy. This is especially true for horizontal platforms. The team sees dozens of use cases; the buyer needs to recognize one painful situation, understand why the product belongs there, and trust that changing the current workflow is worthwhile.

    Your initial ideal customer profile should be more than an industry and company size. Define five things:

    <!– wp:list {
  • Build a Leadership, Talent, and Culture System That Scales

    Build a Leadership, Talent, and Culture System That Scales

    You may recognize the failure pattern. The company hires stronger leaders, adds management layers, publishes values, and runs more surveys – yet decisions get slower, good people become uncertain about their future, and culture feels less consistent with every new team.

    Those are rarely three separate problems. They are usually one systems problem. Leadership defines who can decide. Talent determines which capabilities enter and grow inside the company. Culture shapes how people behave when the process cannot tell them exactly what to do. If those mechanisms send different signals, adding another program will create more noise. You need one operating system that connects the role you design, the person you hire, the way you onboard them, the behavior you reward, and the feedback you use to improve the system.

    Key takeaways

    • Design leadership roles backward from the business you expect to have in 12-24 months. A title is not a role definition; outcomes, decision rights, interfaces, and required capabilities are.
    • Use one evidence chain from the hiring scorecard through interviews, references, onboarding, and performance reviews. Changing the standard after someone joins is a common source of executive failure.
    • Define culture through difficult trade-offs and observable behavior. A value that cannot alter a hiring decision, product decision, or performance conversation is still only a slogan.
    • Treat conflict, 360 feedback, retention, and career development as signals from the same system. Each one can reveal unclear ownership, weak capabilities, misaligned incentives, or leadership behavior that needs to change.
    • Fix contradictions between mechanisms before launching new programs. Coherence compounds; disconnected rituals consume attention without building trust.

    Design the leadership role from the business trajectory

    A leadership search often starts too late in the reasoning process. Someone proposes a title, the title produces a familiar job description, and interviewers begin looking for people who have already held it. That sequence selects for resemblance. It does not establish what the business needs.

    Start with a 12-24 month view of the company. Identify the outcomes that must become possible, the organizational bottlenecks likely to emerge, and the decisions that currently depend on a founder or overloaded executive. Then work backward into the role.

    A useful leadership charter answers six questions:

    1. Why does the role exist now? Name the business constraint it removes, not the collection of functions it supervises.
    2. Which outcomes does it own? Choose results the leader can materially influence. Avoid activity lists disguised as accountability.
    3. Which capabilities must improve? Examples might include turning ambiguity into a product strategy, building an executive bench, connecting design to go-to-market execution, or creating a repeatable operating cadence.
    4. Which decisions belong to the role? Specify what the leader owns, recommends, shares, must consult on, and is merely informed about.
    5. Which interfaces must work? Name the peers and functions with whom the leader must repeatedly resolve trade-offs. An executive can perform well inside a function and still fail at its boundaries.
    6. What should be measurably better after the first year? Describe durable organizational changes, not the personal effort you expect to see.

    Compress the charter into a sentence that can survive repetition: "This role exists to [create an outcome] by [building capabilities], owns [critical decisions], and succeeds when [business and organizational evidence] changes." Use that sentence with candidates, peers, and the team. If those groups hear different explanations, the ambiguity will eventually surface as conflict.

    This exercise also exposes stage mismatch. A leader who is excellent at optimizing an established system may struggle when the system does not exist. A strong specialist may lose effectiveness when the job requires building across several functions. Conversely, hiring a celebrated executive far ahead of the company’s actual complexity can add process before there is enough repeatable work to support it. The right question is not whether a candidate is impressive. It is whether their operating range matches the next set of constraints.

    Use the same clarity when adding a leader above an early employee. Explain the business capability the new layer supplies, which decisions will move, what the current leader will continue to own, and which growth path remains open. Presenting the change as a vague need for "more experience" invites people to translate it into a judgment about their worth. Clear scope preserves dignity and gives both leaders a fair chance to work.

    Use one evidence chain from hiring through onboarding

    The best hiring process is not the one with the most interviews. It is the one in which each stage tests a defined requirement, produces comparable evidence, and prepares the company to support the person after the offer.

    Build the scorecard before selecting interviewers. For a product or functional leader, I would usually separate five kinds of evidence:

    • Stage outcomes: Has the person delivered work comparable to what this company needs next, under similar constraints?
    • Operating judgment: Can they frame choices, expose trade-offs, make a decision, and stay accountable for the result?
    • Learning velocity: Can they show where new evidence changed a strongly held view, including what they did after recognizing the mistake?
    • Cross-functional leverage: Do peers become more effective around them, or does the candidate succeed by absorbing every important decision?
    • Talent multiplication: Have they developed successors, expanded other people’s scope, and raised standards without making the organization dependent on them?

    Replace broad prompts such as "How do you lead?" with decision reconstruction. Ask the candidate to walk through a consequential choice from context to outcome: what they knew, which options they considered, who disagreed, which trade-off they accepted, what they measured, and what they would change. Ask what broke as their organization moved from one stage to another. Ask who could take over their previous role and what they did to prepare that person. Specific sequences are harder to manufacture than leadership philosophy.

    A work sample can add signal when it resembles the job. Use a real but sanitized problem, keep the exercise time-boxed, and tell the candidate what is being assessed. The useful evidence is how they clarify the problem, request missing context, prioritize, communicate uncertainty, and work with other people. A large take-home presentation often measures available time and presentation polish more than day-to-day operating ability.

    Score independently before the debrief. Require interviewers to attach examples to their ratings. "Strong culture fit" and "not strategic enough" are conclusions without evidence. Translate them into observed behavior tied to the scorecard. This makes disagreement discussable and reduces the chance that the most senior interviewer becomes the rubric.

    Run references with the same structure and with appropriate candidate permission. Ask what the leader improved that remained better after they moved on, how they responded to a miss, whether the reference would rehire them for this particular stage, and what is most likely to make the first 90 days difficult. Do not treat the predicted difficulty as automatic disqualification. Turn it into an onboarding guardrail and test whether your organization can provide the support it requires.

    Once the person accepts, do not replace rigor with a calendar full of introductions. A 30/60/90 plan should extend the hiring thesis:

    1. By day 30: Confirm the role charter, map the system, understand the customer and business context, and surface where actual decision rights differ from the documented ones.
    2. By day 60: Own a meaningful decision or operating problem with the relevant peers. The goal is not a theatrical quick win; it is evidence that the new leader can use the company’s interfaces.
    3. By day 90: Deliver an initial outcome and establish at least one mechanism that can repeat without personal heroics, such as a decision cadence, quality review, talent process, or customer feedback loop.

    Identify the first 10 relationships the leader needs to cement. For each one, clarify the shared outcome, recurring decisions, likely tension, and preferred escalation path. Include customer-facing partners, not only executives. Pairing product or design leaders with someone in solutions, sales, support, or implementation often compresses the time needed to understand how product choices meet the market.

    Schedule explicit feedback at weeks 2, 6, and 12. Early feedback should focus on integration signals: where the leader is importing assumptions, bypassing a decision owner, moving too slowly, or misunderstanding a cultural norm. Waiting for a formal review allows those behaviors to harden and turns correctable friction into a story about the person’s character.

    Give the new leader a living "Dear New Leader" document as well. Include how decisions actually get made, which forums serve which purpose, what good escalation looks like, how disagreement is handled, and which organizational history still shapes current behavior. Tribal knowledge will exist whether you document it or not. Writing it down makes it possible to challenge, update, and teach.

    Turn values into behavioral and operating rules

    Values become useful at the moment of tension: speed versus quality, autonomy versus consistency, candor versus harmony, customer urgency versus platform health. If a value only describes universally pleasant behavior, it cannot help someone choose between legitimate competing interests.

    I treat a value as unfinished until it has five parts:

    • The trade-off: What hard choice is this value meant to resolve?
    • The expected behavior: What would another person observe when someone applies it well?
    • The counterbehavior: What tempting action violates it, even if that action produces a short-term result?
    • The operating hooks: Where does it appear in hiring, onboarding, decisions, performance, recognition, product reviews, or roadmaps?
    • The evidence: How will you notice whether the behavior is becoming more or less common?

    Consider a value such as "Every minute counts". Repeating the phrase does not tell a team whether it permits skipping discovery, taking on quality risk, or escalating a blocked decision. The behavioral definition must explain which delays are waste, which forms of rigor prevent expensive rework, and who can accept a risk. That is where a memorable phrase becomes an operating rule.

    Embed the rule across the employee journey. Use scenario prompts in interviews. Tell a concrete values story during onboarding, including the cost or trade-off involved. Add the relevant value to decision records and postmortems. Recognize choices that uphold the value when doing so is inconvenient. Address violations even when the person delivered a desirable result. People learn culture from what leadership rewards and tolerates, not from what leadership publishes.

    Decision logs are especially useful because they make the invisible part of culture inspectable. A lightweight entry can capture the decision owner, context, options, criteria, dissent, choice, and revisit condition. Over time, the log reveals whether the company actually delegates, whether decisions repeatedly reopen without new evidence, and whether stated principles influence trade-offs.

    Measure culture with both broad and local signals. An engagement score or eNPS can reveal that something changed, but it rarely tells you which operating mechanism is responsible. Pair pulse surveys with skip-level conversations, anonymous asynchronous channels for difficult feedback, onboarding observations, exit themes, and decision postmortems. Segment the signal by context when you can: a behavior may work inside one team while breaking at cross-functional boundaries.

    Close the feedback loop publicly. State what was heard, what leadership has decided, what will not change, who owns the response, and when people can expect an update. Silence teaches employees that providing feedback is ceremonial. A visible decision – including a reasoned decision not to act – makes participation consequential.

    A useful way to lower the emotional temperature is to let anyone file a culture bug report. Keep the format concrete: expected behavior, observed behavior, context, impact, and the mechanism that may have produced the gap. The point is not to pretend people are software. It is to move the conversation from "this place is political" toward a condition that can be examined, reproduced, and assigned.

    Watch for drift when early employees and newcomers begin using different unwritten rules, when hierarchy overrides documented ownership, or when leaders become so cautious about micromanagement that teams receive no timely feedback. Hands-off leadership can feel like autonomy to the leader and abandonment to the team. Office hours, clear review points, and explicit quality standards create alignment without pulling every decision upward.

    When the company changes quickly, re-onboard existing employees to the current operating system. Explain which values have not changed, which behaviors must evolve, how decision rights have moved, and which old habits no longer fit. Otherwise, tenure becomes access to a private rulebook, and culture turns into a source of status instead of coordination.

    Make feedback, conflict, and growth one learning loop

    Leaders receive less candid information as their authority grows. People edit bad news, turn behavioral feedback into careful abstractions, or wait until a problem is too visible to ignore. A deliberate multi-source loop helps counter that effect.

    Ask peers, direct reports, and cross-functional partners for specific situations rather than personality judgments. Useful prompts include which behavior the leader should begin, stop, or preserve; when the leader was most and least effective; and which single change would most improve their impact. Ask for the setting and the respondent’s confidence in the observation. A behavior that appears across several close observers deserves more weight than an isolated comment from someone far from the work.

    When reviewing 360 feedback, separate four things: the observable event, the effect on the respondent, the respondent’s interpretation, and the requested change. Look for patterns across sources, but do not use frequency alone. One credible observation can matter when the potential impact is large. Conversely, repeated discomfort may reflect a necessary decision rather than a harmful behavior. The leader’s job is to understand the signal before accepting or rejecting the conclusion.

    Convert a theme into a small behavioral experiment. If people experience decisions as opaque, publish the criteria before the next consequential decision. If meetings suppress dissent, collect independent views before discussion. If urgency produces surprise, require earlier escalation when a commitment becomes uncertain. Name what another person should be able to observe and choose a point to review whether the change helped.

    A ten-minute end-of-day reflection can keep the loop active between formal reviews. Ask what mattered, what you learned, and what you will do differently the next day. The value is not introspection for its own sake. It is shortening the distance between recognizing a leadership pattern and testing a better behavior.

    Conflict needs its own lightweight protocol. Unstructured discussion often rewards speed, status, and verbal confidence. Use a sequence that gives the disagreement somewhere to go:

    1. State the shared outcome and the decision or working relationship that needs repair.
    2. Let each person describe observations, impact, and request without assigning a motive to the other person.
    3. Ask the listener to mirror what they heard before responding. Agreement is not required; accurate understanding is.
    4. Name any emotion or concern that is shaping the exchange before jumping to a solution. Unnamed fear about status, trust, or risk often reappears as an argument about process.
    5. Clarify the decision owner, the input still required, and what disagree-and-commit means in this case.
    6. Run a short retrospective after the decision. Repair the interface, not only the immediate issue.

    Shared norms such as assume positive intent and no surprises are helpful only when paired with accountability. Positive intent should not erase harmful impact. Disagree-and-commit should not become a way to avoid hearing dissent. No surprises should define when escalation is expected, not punish people for delivering unwelcome information.

    The same loop should feed career development. Retention depends less on adding perks than on preserving momentum, meaning, and mastery. Write a growth contract with each person that answers three questions: Which capability are they building during the current planning period? What scope becomes available if they demonstrate it? What support, practice, or feedback will the company provide? Add the evidence both sides will use, so advancement does not depend on a retrospective story.

    Do not make management the automatic reward for strong individual contribution. Before an IC becomes a manager, let them expand the size of the outcome they own and practice leading a cross-functional program without formal authority. Then determine whether the organization needs a manager and whether the person wants to create impact through coaching, coordination, and talent decisions. A strong IC path should offer meaningful scope, status, and leverage without requiring direct reports.

    Careers are not one-way doors. Someone can move from IC work into management and later return to deeper individual contribution as their strengths, energy, or organizational context changes. Treat the move as a change in the mechanism of impact, not a verdict on ambition.

    When a person is asked to hire or report to a more experienced leader, make the learning exchange explicit. Define what the new leader will teach, what scope the existing person retains, and which evidence would justify broader ownership later. Trading a title for a teacher can accelerate a career, but only when the promise is backed by real access, coaching, and opportunity.

    At each planning cycle, inspect the seams of the system. Does the role charter match the decisions the person actually owns? Does the interview scorecard match what performance reviews reward? Does onboarding teach the culture leaders enforce? Do feedback and conflict patterns identify a capability gap, an ownership gap, or an incentive problem? Does each high-performing person know what they can learn and own next?

    If you do one thing this week, choose the leadership role creating the most friction and place its charter, hiring scorecard, onboarding plan, values, and performance expectations side by side. Find the first contradiction and repair that seam. A coherent leadership, talent, and culture system will do more for trust and execution than another isolated initiative.

    References

  • Build a Startup Talent System That Scales With the Company

    Build a Startup Talent System That Scales With the Company

    If you are hiring a senior leader because the founder has become a bottleneck, adding managers because execution feels chaotic, or revisiting pay because exceptions keep accumulating, you do not have three separate problems. Your talent decisions have outgrown personal judgment.

    The answer is not a heavyweight HR program. You need a lightweight talent system that connects the company’s current constraint to role design, candidate evidence, manager expectations, compensation guardrails, and early performance signals. Build those connections before the next urgent hire, and you will make faster decisions without lowering the bar.

    Key takeaways

    • Define each important role around the business outcomes required over the next 18-24 months, not an imagined version of the company years from now.
    • Use the same scorecard for sourcing, interviews, reference checks, and onboarding. Changing the criteria between stages reintroduces bias and guesswork.
    • Promote people into management because they can create clarity, coach others, and raise collective performance – not because management is the only reward available to a strong individual contributor.
    • Establish broad levels, salary bands, equity guidelines, and an offer review process before negotiation creates a collection of indefensible exceptions.
    • Treat the 30-60-90 plan as an early-warning system. Look for decision velocity, operating cadence, hiring quality, and stronger manager layers before waiting for lagging business results.
    • Choose internal promotions and external hires as a portfolio. Preserve context where it is valuable, and import experience when the next company chapter demands a capability you do not have.

    Start with the company chapter, not the candidate profile

    A generic request for a world-class VP is not a hiring strategy. It is an invitation for everyone involved to project a different definition of excellence onto the same role. The founder imagines strategic relief, the team expects a better manager, and the board expects an executive who has already operated at scale. A candidate can impress all three groups while still being wrong for the work that matters now.

    Anchor the role in the next company chapter. For a startup, a practical planning horizon is often the next 18-24 months. That is long enough to require meaningful leadership and short enough to describe the actual problems the person will inherit.

    Write a short chapter brief before writing the job description. It should answer:

    • What is constrained now? Name the bottleneck in business terms: product bets are not being sequenced, managers cannot make decisions independently, the founder still owns every important customer escalation, or a single-channel go-to-market motion has stopped scaling.
    • What must be different by the end of this chapter? Describe observable outcomes, not activities. A functioning leadership layer is an outcome. Hiring a collection of people is an input.
    • What must this leader do personally? Separate hands-on work from work they can eventually delegate. Early-stage leaders who expect a large support structure may struggle when the company needs them to diagnose, decide, recruit, and operate.
    • Which capabilities are missing inside the company? Distinguish a true capability gap from a temporary capacity problem. A senior external hire may be unnecessary if the team already knows what to do and simply lacks focus or decision clarity.
    • What experience is attractive but irrelevant? Remove requirements added for status. A prestigious employer, a large former team, or a senior title is weak evidence unless it maps to the environment and outcomes in front of you.

    This exercise prevents a common mistake: hiring someone whose resume belongs to a later stage than the company. Big-company experience can be valuable, but scale alone does not prove that a leader can create the system they previously inherited. Ask what was already in place, what the candidate built, which decisions were truly theirs, and how much organizational support surrounded the result.

    I would rather see a candidate explain exactly how they will win in your constraints than rely on the halo of how they won somewhere else. The strongest answer connects strategy to weekly execution, makes trade-offs explicit, and identifies what must be learned before resources are committed.

    Use the chapter brief to decide between promotion and external hiring

    Internal and external candidates solve different risks. An internal promotion preserves context, trust, and momentum. An external hire can add a capability the company has never built. Neither route is inherently safer.

    Bias toward an internal candidate when the next chapter depends heavily on company-specific judgment and the person has already shown that they can elevate others. Bias toward an external search when the role must establish a motion nobody inside has led before, such as moving from founder-led selling to a repeatable multi-channel model.

    Do not turn this into an all-or-nothing philosophy. Think of the leadership team as a portfolio. You need builders who are comfortable creating from ambiguity, operators who can make good practices repeatable, and leaders who can develop the layer beneath them. A team composed entirely of experienced stabilizers may protect the current model but miss the next step-change. A team composed entirely of high-upside builders may create energy without enough operating discipline.

    Run one evidence path from sourcing through onboarding

    Hiring processes become unreliable when each stage answers a different question. Sourcing rewards recognizable backgrounds, interviews reward storytelling, references verify employment history, and onboarding introduces a new set of expectations. The company then wonders why a candidate who passed every step cannot succeed in the role.

    A single role scorecard should travel through the entire process. It does not need elaborate software. It needs stable criteria and explicit evidence.

    Build a scorecard that can survive a real debrief

    Include these fields:

    • Business outcomes: the changes this person must cause during the company chapter.
    • Leading indicators: evidence that the operating system is improving before lagging revenue or product results arrive.
    • Required capabilities: the few skills that are genuinely necessary to produce those outcomes.
    • Leadership behaviors: how the person creates clarity, handles pressure, develops managers, and makes trade-offs.
    • Context requirements: the pace, ambiguity, resources, and cross-functional dependencies the person must navigate.
    • Anti-signals: observable patterns that would make success unlikely, even if the candidate is otherwise impressive.

    Write anti-signals before meeting candidates. Useful examples include blaming the environment without diagnosing the system, speaking in abstractions without measures, leading with desired headcount before desired outcomes, or being unable to explain how managers become stronger under their leadership. Pre-committing matters because charisma makes red flags easier to rationalize after the fact.

    Assign each interviewer an evidence area. Give them the same definitions and require concrete observations in the debrief. Impressions such as strategic, senior, or cultural fit are too elastic to resolve disagreement. A useful note identifies what the candidate did, the conditions they faced, the trade-off they made, and the result they can substantiate.

    Treat sourcing like a disciplined go-to-market motion

    Early recruiting resembles founder-led sales because both depend on a defined target, relevant messaging, persistent follow-through, and learning from conversion. Start with operators who have solved an adjacent problem at comparable complexity. Adjacent is often more useful than identical: you want evidence that the person recognizes the problem pattern without assuming your company is a copy of their last one.

    Map second-degree connections through former colleagues, investors, advisors, and trusted customers. Ask for a specific introduction, not a broadcast request for good people. Give the connector a concise description of the role, the company chapter, and why this person is relevant. A two-sentence value proposition is more likely to survive forwarding than a long job description.

    Your candidate pitch should answer what talented operators actually need to evaluate: why the mission matters, what makes the company’s approach distinct, which problems they will own, and what success will look like in the first 90 days. Do not substitute inspirational language for scope. Passive candidates are often deciding whether the problem is worthy of a career move before they are deciding whether to accept an offer.

    Track response and progression by candidate segment and message. If relevant candidates do not respond, the problem may be the pitch or the outreach path. If they respond but leave after learning the scope, the role itself may be incoherent. A recruiting funnel should help you diagnose the system, not merely report how many names entered it.

    Replace hypothetical interviews with evidence-producing work

    Behavioral questions are most useful when they force specificity. Ask the candidate to reconstruct an actual decision: what was known, what was uncertain, who disagreed, what they chose not to do, and what changed afterward. Then use a practical session tied to your chapter brief.

    • Walk through how you would build this function from zero to ten without assuming the final organization in advance.
    • Model your first 90 days. What would you diagnose before changing, and which decisions should not wait?
    • Show the operating rhythms you have used to turn strategy into weekly execution.
    • Explain an outcome you owned with fewer resources than you initially wanted.
    • Describe how you identified and developed a manager who was not yet ready for broader scope.
    • Show how you distinguish output progress from business or customer outcomes.

    A work session should reveal prioritization and collaboration, not reward free consulting. Keep the problem scoped, tell the candidate what is being assessed, and avoid asking for production-ready work the company intends to use. If you use a longer trial arrangement, structure and compensate it appropriately, confirm that both sides understand the terms, and obtain qualified guidance for the employment and contractor rules that apply in the relevant location. An informal unpaid trial creates legal, fairness, and reputational risk.

    Use references to test patterns, not confirm your preference

    By the reference stage, the hiring team usually wants the candidate to succeed. That is exactly when confirmation bias becomes dangerous. Ask former managers, peers, reports, and cross-functional partners about the same scorecard dimensions from different vantage points.

    • What happened when the candidate’s original plan stopped working?
    • How did their leadership style change under pressure?
    • What kinds of decisions did they hold too long, and which did they delegate well?
    • How did managers improve while reporting to them?
    • Where did the candidate need unusually strong support from a founder or peer?
    • Which environment would make this person less effective?

    You are looking for consistency across stories, not perfection. A weakness can be manageable when the role, support, and candidate are aligned around it. A recurring ownership problem is different. Conduct reference and background checks with the candidate’s knowledge where required, respect confidentiality, and follow the rules that apply to hiring in the relevant jurisdiction.

    Turn the 30-60-90 plan into the final selection artifact

    Do not wait until the candidate starts to define success. Build the 30-60-90 plan from the same outcomes and indicators used in the scorecard, then discuss it before the offer closes. This exposes expectation gaps while both sides can still address them.

    • 30 days: What must the leader understand about the strategy, team, customers, decision rights, and unresolved risks? Which urgent decisions can they make without pretending to have complete context?
    • 60 days: Which operating cadence should be visible? How will priorities, product or functional reviews, hiring decisions, and cross-functional trade-offs be handled?
    • 90 days: Which leading indicators should have moved? Look for faster decisions, a credible talent plan, progress in the relevant funnel, clearer ownership, and healthier manager layers.

    These are not promises of final business impact. They are evidence that the leader is building the machinery capable of producing it. If the early signals do not appear, clarify the gap, provide direct coaching, and remove avoidable constraints. If the pattern still does not change, act decisively and fairly. Leaving a mismatched executive in place makes the entire team pay for leadership’s reluctance to revisit the decision.

    Build managers before the organization depends on them

    Startups often use management as a promotion prize. A high-performing individual contributor reaches the top of an informal ladder, so the company gives them reports. The person loses time for the work they do best, while the team receives a manager who may never have wanted – or been prepared for – the job.

    Management is a different product. The output is no longer mainly the manager’s individual work. It is a system in which other people understand the outcome, make sound decisions, improve their judgment, and deliver together. That shift is central to the move from contributing, to managing, to leading a function.

    Assess management readiness before granting the title. Look for three patterns in day-to-day work:

    • They elevate peers. They share context, improve the quality of other people’s thinking, and create room for colleagues to own visible outcomes.
    • They translate strategy into execution. They can turn an ambiguous goal into priorities, decisions, and a weekly operating rhythm without reducing the work to task tracking.
    • They combine accountability with empathy. They address performance gaps directly while remaining curious about the system, expectations, and support around the person.

    You can test these behaviors before a permanent promotion. Give the prospective manager responsibility for a planning session, a product review, onboarding a colleague, or coaching someone through a defined problem. State what good leadership looks like and observe whether they create clarity and ownership around them. Do not quietly add managerial labor to someone’s role and call it an audition; make the scope, support, recognition, and decision process explicit.

    Give every manager a minimum operating standard

    Leadership development fails when it consists of advice without mechanisms. A new manager needs a small set of repeatable expectations:

    • Hold weekly one-to-ones that cover priorities, obstacles, feedback, and growth rather than duplicating project status meetings.
    • Make role expectations and decision rights explicit. People cannot exercise autonomy if they do not know which decisions they own.
    • Have lightweight career conversations every quarter, not only when someone asks for a promotion or threatens to leave.
    • Recognize strengths by connecting them to outcomes. Generic praise is pleasant but does not teach the person which behavior to repeat.
    • Address underperformance with specific examples, a clear bar, relevant support, and a defined follow-through process.
    • Run product or functional reviews that improve decisions. The purpose is not to make every choice for the team.

    The manager’s own manager should inspect the quality of these mechanisms, not merely ask whether they happened. A calendar can show recurring one-to-ones while the team remains unclear about priorities and growth. Look for better decisions, stronger ownership, useful feedback, and fewer preventable escalations.

    Preserve a credible individual-contributor path as the company grows. Otherwise, people may accept management because it is the only route to greater scope, status, or compensation. That creates a selection problem before training has a chance to help.

    Change the leadership job as the company changes

    A functional executive cannot keep succeeding by being the most senior problem-solver in every room. At that level, treat the organization itself as a product. Define what it exists to produce, who depends on it, how decisions travel, and which feedback loops reveal failure.

    For a product leader, that means aligning with the CEO on the strategic narrative, business-model bets, and company outcomes; synchronizing product choices with go-to-market and financial constraints; and translating the portfolio into measurable progress and risk for the board. The job is not to present more roadmaps. It is to make choices, sequence them coherently, and build a leadership system that can execute without routing every conflict through the executive.

    Make compensation and operating signals part of the same system

    A rigorous hiring process can still produce a fragile organization if compensation is improvised. One-off offers do more than increase payroll. They create hidden comparisons, inconsistent promotion decisions, and promises that future managers must explain without knowing why they were made.

    Set guardrails before a candidate starts negotiating

    An early startup does not need a complex compensation bureaucracy. It does need an explicit philosophy that can guide decisions for the next 12-18 months. State how you position cash and equity, how level and scope affect an offer, what performance can change, and where flexibility is allowed.

    Turn that philosophy into a lightweight operating structure:

    • Define broad levels and salary bands that managers can explain.
    • Create equity grant guidelines tied to level, scope, and company stage.
    • Establish how refresh grants will be considered rather than waiting for retention pressure.
    • Review offers through a consistent decision owner or forum before commitments are made.
    • Record exceptions, the reason for them, and whether the underlying policy needs to change.
    • Audit outcomes for inequities rather than assuming consistent intent produced consistent results.

    Negotiation should happen inside these guardrails. If every confident negotiator receives a custom package, negotiation skill becomes an unofficial compensation factor. That can weaken internal equity and leave managers unable to defend differences later. Flexibility still has a place, but the company should know which elements can move and why.

    Give candidates a plain-language equity explanation covering vesting, dilution, the exercise window, major risks, and illustrative outcomes without presenting uncertain value as guaranteed. Equity and option decisions can have material tax and financial consequences that vary by location and individual circumstances. Provide accurate plan documents and access to qualified professional advice; do not position a recruiting explanation as personal tax or investment guidance.

    Design retention before a resignation forces the issue

    Retention is not a last-minute counteroffer process. It is the accumulated result of meaningful scope, capable management, understandable pay, credible growth paths, and trust in how decisions are made. Equity refreshes and bonuses can support that system, but they cannot repair persistent role confusion or weak management.

    Use refresh decisions to recognize sustained impact and respond to relevant market conditions within a consistent framework. Explain what the award means and what it does not mean. When salary adjustments or bonuses change, communicate the philosophy, the factors considered, and the decision process. Employees do not need access to every private data point, but their manager should be able to explain more than the final number.

    Quarterly career conversations are useful here because they surface changing aspirations before the only available signal is an external offer. The conversation should identify the kind of problems the person wants to own, the capabilities required for that scope, and the evidence that would support the next decision. A promotion should not be a vague promise exchanged for patience.

    Monitor the talent system through leading indicators

    The final step is to inspect whether the system works. Headcount is not a sufficient measure, and retention alone is a late signal. Review the mechanisms that should produce a healthy organization:

    • Role clarity: Can the hiring team state the outcomes and anti-signals without rereading the job description?
    • Decision quality: Are interview decisions supported by evidence from the scorecard, or by accumulated enthusiasm?
    • Funnel health: Where do relevant candidates disengage, and what does that reveal about the pitch, scope, process, or offer?
    • Hiring quality: Do new leaders establish the expected cadence and leading indicators in their 30-60-90 plan?
    • Manager health: Are managers creating clearer ownership, useful feedback, and stronger successors?
    • Compensation integrity: Are exceptions becoming a pattern, and can managers explain decisions consistently?
    • Internal mobility: Are people gaining scope through evidence-based development, or only when an urgent vacancy appears?

    Several patterns deserve intervention. If candidates perform well in conversational interviews but struggle in practical sessions, your early stages may reward polished narratives over operating ability. If leaders ask for headcount before defining outcomes, ownership is weak. If compensation exceptions cluster around aggressive negotiators, the guardrails are not doing their job. If managers hold every required meeting but decisions still rise upward, the cadence exists without the leadership behavior it was meant to create.

    Start with the next consequential role. Write the company chapter, convert it into a scorecard, decide what evidence each stage must produce, and draft the 30-60-90 plan before sourcing begins. If you cannot do those things clearly, you are not ready to evaluate candidates yet. Fixing that ambiguity now is cheaper than asking a new leader to discover after joining that the company never agreed on the job.

    References

  • Executive Alignment That Scales Beyond the Leadership Team

    Executive Alignment That Scales Beyond the Leadership Team

    You leave the executive planning session with apparent agreement. A week later, sales has translated the growth priority into customer commitments, product has translated it into adoption work, operations has translated it into margin improvement, and engineering has translated it into reliability. Nobody ignored the strategy. Each function filled in the decisions the executive team left implicit.

    You do not fix this with another alignment meeting. You fix it with an operating model that carries executive choices into everyday decisions: a compact strategy, explicit decision rights, a predictable review cadence, traceable delivery commitments, and learning mechanisms that change the system when reality changes.

    Replace executive agreement with a strategy contract

    Executives are aligned when they can make compatible trade-offs after they leave the room. Agreement inside the room is only an input. The real test comes when a leader must decline a customer request, move people between initiatives, delay a launch, protect reliability work, or stop a project that still has internal support.

    I use a simple test: can each executive explain what the company is choosing, what it is giving up, and which evidence would justify changing course? If the answers differ, the team has a shared aspiration, not a shared strategy.

    Turn the strategy into a short contract with these fields:

    • Outcome: What must be materially different over the next 12-18 months?
    • Choices: Which customers, problems, capabilities, or growth paths will receive disproportionate attention?
    • Non-goals: What attractive work will the company deliberately leave unfunded?
    • Constraints: Which limits involving capital, capacity, reliability, data, regulation, or timing are real?
    • Leading indicators: What evidence will show progress before the final business result arrives?
    • Critical seams: Where must product, engineering, operations, and go-to-market make coordinated decisions?
    • Revisit conditions: Which assumptions or signals would require the executive team to reconsider the choice?

    The non-goals are often the most revealing part. A strategy that adds priorities without removing anything is a demand for more output, not a choice about outcomes. Ask every executive to name the work that will stop, shrink, or wait because of the new direction. If nothing changes in resource allocation, roadmap sequencing, or customer commitments, the strategy has not reached the operating system.

    Keep outcomes separate from activity. Shipping a capability, hiring a team, migrating a platform, or launching an AI workflow may be necessary, but each is still an output. The contract should state the customer or business condition that output is expected to change. This gives the executive team a way to challenge the hypothesis without turning every review into a debate about whether people worked hard enough.

    Apply the same discipline to fluid executive roles. A COO mandate, for example, should not begin with a generic list of functions. Start with the outcomes the business needs, the CEO’s continuing responsibilities, and the seams where product, operations, and go-to-market meet. A role designed around the current constraint is easier to evaluate and less likely to become a second, ambiguous center of authority.

    Put decision rights where functions collide

    Most scaling friction lives between boxes on the organization chart. Product and sales disagree about a customer commitment. Product and engineering disagree about scope versus reliability. Operations and data teams disagree about whether a manual workflow is stable enough to automate. The CEO and COO both assume the other owns a transformation. Each function can be locally well managed while the company remains slow at the seams.

    Map decision rights around recurring decisions, not broad domains. Saying that product owns the roadmap is less useful than identifying who decides whether a strategic customer request displaces committed work, who decides launch readiness when reliability risk remains, and who decides when evidence is strong enough to move a bet from discovery into delivery.

    RACI, DACI, and RAPID can all work. The framework matters less than consistent use. Whatever vocabulary you choose, every consequential cross-functional decision needs an identifiable decision-maker, required contributors, a deadline, and a durable record.

    Use a decision record that prevents repeat debates

    A useful decision record answers these questions:

    • Decision: What exact choice must be made?
    • Decision owner: Which named person has authority to make it?
    • Required input: Whose expertise or evidence must be considered first?
    • Deadline: When does waiting become more costly than remaining uncertainty?
    • Choice and rationale: What was selected, and which trade-off was accepted?
    • Success signal: What result should follow if the reasoning is sound?
    • Revisit trigger: What new fact would justify reopening the decision?
    • Communication: Who needs the outcome and its implications?

    The decision owner is not automatically the most senior person, the project manager, or the function doing most of the work. It is the person accountable for integrating the relevant inputs and making the trade-off. Contributors have a duty to provide clear input on time; they do not each receive a veto.

    The revisit trigger is equally important. Without one, teams either treat every decision as permanent or reopen it whenever a disappointed stakeholder finds a new audience. Record the assumption that matters and the evidence that would invalidate it. This protects commitment without pretending the original decision was infallible.

    Use escalation for conflicts that exceed the owner’s authority: a company-level constraint, a collision between strategic outcomes, or a risk the strategy contract does not cover. Do not escalate merely because contributors disagree. If executives routinely resolve local, reversible choices, the organization learns that autonomy is ceremonial and that access to leadership is the real decision process.

    Build a cadence that moves context instead of status

    A scalable cadence gives each planning horizon a distinct job. When quarterly planning, business reviews, weekly updates, and sprint rituals all repeat the same status information, leaders spend more time communicating without improving a decision.

    CadenceQuestion it should answerDurable artifactDecision produced
    Quarterly planningWhich outcomes and bets deserve capacity now?Strategy contract, portfolio view, dependenciesFund, sequence, defer, or stop
    Monthly business reviewAre outcomes moving, and which assumptions changed?Outcome dashboard, decision log, risk viewContinue, adjust, escalate, or stop
    Weekly written updateWhat changed, what is blocked, and which decision is needed?Executive summary linked to current artifactsResolve an exception or leave the team moving
    Discovery and sprint planningWhat should the team learn or deliver next?Discovery log, backlog, definitions of ready and doneCommit work within the approved bet
    Change channelDoes new information justify disrupting committed work?Change record with displacement and rationaleRe-baseline or protect the commitment

    Quarterly planning should make portfolio choices visible. It is where leaders compare expected impact, risk, effort, dependencies, and strategic fit. The output is a sequenced set of bets tied to company outcomes, not a collection of departmental requests that survived negotiation.

    The monthly business review should test the reasoning behind those bets. Look at the intended outcome, leading indicators, actual movement, new evidence, and unresolved decisions. A red metric is not automatically a failure, and a green delivery plan is not automatically success. The useful question is whether current evidence still supports the allocation of attention and capacity.

    The weekly update exists to distribute context and surface exceptions. A practical update contains the outcome being pursued, what changed, the most important signal, the current risk, and any decision or help required. Link to the roadmap, dashboard, product requirement, discovery log, or decision record rather than reproducing each artifact. Consistent written updates make decisions and trade-offs searchable, allowing people in different functions or time zones to understand the work without waiting for another meeting.

    Meet live when ambiguity, disagreement, or interpersonal nuance requires interaction. Do not let the meeting become the only record. Write the resulting decision, owner, rationale, and revisit trigger into the authoritative system after the conversation. Otherwise, people who were absent inherit an outcome without the context needed to apply it.

    The change channel protects committed work from shadow reprioritization. Every emergent request should identify the new evidence, the strategic outcome affected, the decision owner, and the work that would move if the request is accepted. If nobody can name the displacement, the organization is hiding a priority change inside extra workload.

    Connect executive choices to roadmaps and sprints

    Alignment disappears when teams cannot trace delivery work back to an executive choice. Every material roadmap bet should carry the outcome it supports, the leading indicator it expects to move, its accountable owner, important dependencies, the core assumption, and the next decision point.

    This is not a demand for more roadmap detail. It is a demand for a visible chain of reasoning:

    • The strategy contract identifies the outcome and trade-offs.
    • The portfolio selects and sequences bets against that outcome.
    • The roadmap states the customer problem, hypothesis, and expected signal.
    • Discovery reduces the most consequential uncertainty.
    • Sprint planning turns sufficient evidence into executable work.
    • Business reviews compare the resulting evidence with the original hypothesis.

    When that chain breaks, teams compensate in predictable ways. A roadmap without an outcome becomes a feature list. Discovery without a decision becomes open-ended research. A sprint without strategic context rewards task completion. A review without the original hypothesis rewards persuasive storytelling after the fact.

    Use try, do, and consider to expose confidence

    The try, do, and consider framework gives executives and teams a shared language for uncertainty:

    • Try: A bounded experiment or discovery activity intended to resolve a meaningful uncertainty.
    • Do: Work with enough confidence and strategic importance to receive a delivery commitment.
    • Consider: A plausible option that remains visible but has not earned capacity.

    The labels prevent two common errors. Exploratory work no longer masquerades as a delivery promise, and ideas no longer enter the roadmap merely because an executive wants them remembered. Moving work between categories should require evidence and an explicit decision, not a quiet change in wording.

    Make scope changes pay a visible price

    New scope is not always poor discipline. Product discovery can reveal a missing requirement, an integration risk, or a customer need that changes the value of the original plan. The mistake is absorbing that learning without re-baselining the commitment.

    When scope changes, record what was learned, which decision it changes, what becomes more valuable, what moves out, and which outcome or date is affected. Separate a must-have condition for value or safety from a useful enhancement. This lets the team respond to reality without turning every new idea into compulsory work.

    Estimation should support the same transparency. Compare planned work with similar completed work, surface integration and quality risks early, track estimate-versus-actual differences, and preserve clear definitions of ready and done. The purpose is not to force certainty onto uncertain work. It is to expose where confidence is low before an external commitment depends on it.

    OKRs and business reviews serve different purposes here. An outcome-oriented OKR can state the intended change. A quarterly business review can test what shipped, what actually moved, and what should change next. Treating delivery volume as the result collapses both mechanisms into project reporting.

    Scale through learning, not tighter executive control

    As the organization adds people and layers, executives cannot preserve alignment by approving more decisions. They have to improve the quality of context, ownership, and learning available to everyone else.

    Use pre-mortems before high-risk launches and transformations. Ask the group to assume the initiative failed, then identify the conditions that most plausibly caused the failure. Convert credible risks into an owner, a mitigation, an early warning signal, or an explicit acceptance. This is especially useful when hierarchy or enthusiasm makes it difficult to challenge a plan directly.

    Use blameless postmortems after incidents and meaningful misses. Establish what happened, what the system made reasonable at the time, where detection or response failed, and which process or technical change will reduce recurrence. Accountability still matters: corrective actions need owners and follow-through. Blame is avoided because it narrows attention to the person nearest the failure and leaves the enabling conditions intact.

    Write down hypotheses before experiments and major bets. A prewritten expectation makes later learning harder to rewrite around the result. Maintain the discovery log, decision record, and outcome dashboard as connected artifacts so a new leader can follow how the current plan emerged without reconstructing it from meetings and private messages.

    Roles must evolve with the system. Rewrite executive and leadership role charters when responsibilities drift, recurring decisions lack an owner, or the same escalations keep returning. Strengthen senior individual-contributor leverage where technical or product judgment should scale without adding another approval layer. Evaluate clear writing, problem framing, trade-off judgment, and proactive risk documentation when hiring into an asynchronous or highly distributed model.

    You can usually notice a broken operating model before a major miss. Watch for these signals:

    • The same decision is debated in multiple forums because no record or owner is trusted.
    • Roadmap changes arrive through private messages without visible displacement.
    • Business reviews emphasize shipped work while avoiding movement in customer or business outcomes.
    • Executives attend team-level meetings because written context and local decision rights are weak.
    • Teams escalate reversible choices because prior autonomy was overridden without a clear rule.
    • Postmortems identify individual mistakes but produce no change to process, tooling, detection, or ownership.
    • Leadership roles accumulate responsibilities even after the organization has developed people who could own them.

    Each signal points to a specific repair. Repeated debates need a decision record and revisit rule. Hidden priority changes need a change channel. Output-heavy reviews need outcome measures. Excess executive involvement needs better context and narrower escalation criteria. Recurring incidents need system-level corrective action. Role accumulation needs delegation backed by explicit authority.

    Key takeaways

    • Test alignment by the consistency of trade-offs after the meeting, not agreement during it.
    • Write a strategy contract that names outcomes, choices, non-goals, constraints, indicators, critical seams, and revisit conditions.
    • Assign decision rights to recurring cross-functional choices and record the owner, rationale, and trigger for reopening them.
    • Give quarterly planning, monthly reviews, weekly updates, delivery rituals, and change control different jobs.
    • Trace roadmap and sprint work back to an outcome, hypothesis, and executive allocation decision.
    • Use try, do, and consider to distinguish learning, commitment, and possibility.
    • Scale autonomy with pre-mortems, blameless postmortems, written hypotheses, durable context, and evolving role charters.

    At your next executive review, bring the recurring decision causing the most rework. Write its strategic outcome, named owner, required inputs, success signal, and revisit trigger. Then place it into the appropriate cadence and let the designated owner make it. A scalable operating model takes hold when the organization can resolve its hardest seams without repeatedly pulling every decision back into the executive room.

    References

    • Shivam.Consulting Blog — Why the COO Role Is the C-Suite’s Most Fluid: Archetypes, No-Blame Culture, and CEO Guidance
    • Shivam.Consulting Blog — Go Totally Asynchronous: Inside Sidharth Kakkar’s Remote, Autonomous Culture That Scales
    • Shivam.Consulting Blog — Operations vs Algorithms: How I Scale Startups with Data Science, Team Design, and Pre-Mortems
    • Shivam.Consulting Blog — From Roadmaps to Sprints: Proven Tactics to Ship Software at Scale Without Chaos
    • Shivam.Consulting Blog — Scaling Your Co-Founder Relationship: Rituals, Decision Rights, and Trust Lessons from Labelbox
  • Product-Market Fit: When to Focus, Narrow, or Pivot

    Product-Market Fit: When to Focus, Narrow, or Pivot

    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.

    This discipline matters most when the product is horizontal. A flexible platform may eventually support many workflows, but it still needs a small set of canonical entry use cases and language customers can quickly understand. Broad capability does not excuse a vague starting point.

    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 layerWhat you need to learnCommon false positive
    ProblemThe target user encounters an important recurring problem and already spends time, money, or organizational effort on it.People agree that the vision sounds valuable.
    UseThe 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.
    OutcomeThe product changes a result the user and buyer care about.The team ships the requested functionality on schedule.
    CommercialAn 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.
    RepeatabilitySimilar customers adopt for similar reasons through a delivery motion that becomes more predictable.One prominent customer succeeds through exceptional executive attention and custom work.
    OperabilitySecurity, 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.

    Before reviewing an initiative, ask the team: If you were starting from zero with the evidence now available, would you choose this strategy? The question does not settle the decision. It exposes how much of the case depends on sunk cost, identity, previous promises, or fear of admitting that an assumption was wrong.

    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

  • How to Build a Narrative-Led GTM and Customer Growth Engine

    How to Build a Narrative-Led GTM and Customer Growth Engine

    Your homepage sounds polished. The sales deck makes a reasonable case. Onboarding explains the product. Customer success talks about adoption. Yet the customer has to reconstruct why any of it matters every time they move from one team to the next.

    That is not mainly a copy problem. It is a growth-system problem. Narrative-led go-to-market gives the customer one causal story from first touch through expansion: what changed, why the old approach is failing, what better outcome is possible, how your product enables it, and what evidence makes the claim credible.

    Start with a change your customer already feels

    A useful narrative is not a slogan, a category label, or a compressed product description. It is an explanation of change. It helps a specific customer understand why a familiar problem now deserves a different decision.

    Build that explanation by answering five questions in order:

    1. What changed in the customer’s world? Name the shift in behavior, technology, expectations, economics, or operating complexity that created new pressure.
    2. Why is the existing approach no longer sufficient? Identify the workaround, process, or assumption that breaks under the new conditions.
    3. What does staying the same cost? Describe the operational consequence the customer already recognizes, without inflating it into a generic crisis.
    4. What new behavior or outcome is now possible? Show the customer a better way to work, not merely a list of capabilities to buy.
    5. Why can your product credibly enable that change? Connect the outcome to a real mechanism and evidence.

    Use a working sentence before you touch the homepage: For [specific customer], [relevant change] has made [old approach] unreliable because [consequence]. Teams that [new behavior] can achieve [outcome]. [Product] enables that shift through [mechanism], supported by [evidence].

    This sentence will be inelegant at first. That is useful. It exposes gaps that a clever tagline can conceal. If you cannot name the change, you may have ordinary positioning rather than a timely reason to act. If the mechanism is vague, your promise is detached from the product. If the evidence field is empty, you have an aspiration rather than a market-ready claim.

    Start filling those fields in customer discovery. Do not ask customers which message they prefer; that turns them into copywriters. Ask them to reconstruct the decision that brought them to you:

    • What happened immediately before you began looking for a different approach?
    • What outcome did you expect this product to help you achieve?
    • Walk through the last time you attempted the job using the previous process.
    • Which part of that process felt unusually difficult or fragile?
    • What nearly stopped you from changing?
    • What would need to be true for this product to feel indispensable within 90 days?
    • What evidence would give you confidence to extend it to another team or use case?

    Listen for repeated nouns, verbs, triggers, and trade-offs. The phrase customers use to describe the moment their old process failed is often more valuable than the phrase they use when complimenting your product. One reveals the buying tension; the other may only describe satisfaction after the fact.

    Keep segments separate while you do this. A practitioner trying to complete a job, a leader accountable for an outcome, and an administrator managing risk may share a product but not the same entry point. Combining their language too early produces a story broad enough to sound relevant and too vague to guide a decision.

    Before moving on, pressure-test the draft. If you can replace your company name with a competitor’s and the sentence still works, it is not differentiated. If the problem disappears when you remove the product, it was manufactured from your features. If the customer has to sit through several capabilities before understanding the stakes, the sequence is company-first rather than customer-first.

    Turn the story into a narrative architecture

    The first usable artifact should fit on one page. A large messaging document may eventually help with execution, but it should be generated from a small set of decisions that leadership, product, marketing, sales, and customer success can remember.

    • Problem frame: the specific job, constraint, or risk the customer recognizes.
    • Company promise: the outcome you help create, stated above the feature level.
    • Three or four value pillars: the durable mechanisms that explain how the promise becomes true.
    • Proof: customer evidence, product behavior, implementation facts, or measured outcomes that support each pillar.
    • Boundary: the customers, use cases, or expectations the narrative should not attract.
    • Next action: the smallest credible step a customer can take to experience or evaluate the promise.

    The distinction between promise and pillar matters. The promise is the result a customer wants. A pillar explains how you help produce it. A feature is one implementation of a pillar. When these layers are collapsed, every product release forces a messaging rewrite and every sales conversation becomes a feature tour.

    A durable pillar should pass four tests. It should explain part of the mechanism behind the promise, influence real product or GTM decisions, carry specific proof, and remain understandable after an individual feature changes. If a pillar cannot guide a roadmap discussion, an onboarding decision, or a sales diagnosis, it is probably decorative language.

    Proof needs its own ledger. For every external claim, record the segment it applies to, the evidence available, the wording the evidence can support, and where the claim is used. This prevents an isolated customer result from becoming a universal promise. It also shows you where growth is blocked by missing evidence rather than weak copy.

    Do not create a separate corporate story for every audience. Keep the causal core stable and translate its edge. A practitioner may need workflow proof. An economic buyer may need an outcome and a credible path to value. An administrator may need governance and implementation clarity. Procurement may need commercial boundaries. They should encounter different evidence for the same promised change, not four unrelated reasons your company exists.

    Running communication with the same hypothesis-and-evidence discipline used in product development makes launches more useful. Each launch should add proof to an existing pillar, make the promised outcome easier to achieve, or deliberately change the narrative architecture. A launch that does none of those may create attention without strengthening market position.

    I would not approve a major message simply because it is memorable. It must also be true in the product, recognizable to the intended customer, useful in a buying decision, and supportable after the contract is signed.

    Make every customer stage add evidence to the same story

    Narrative consistency does not mean repeating the same sentence everywhere. The customer’s question changes as the relationship matures. Your story should become more concrete at each stage, while preserving the same problem, promise, and mechanism.

    Customer stageQuestion in the customer’s mindJob of the narrativeEvidence or next move
    DiscoveryIs this my problem, and why should I act?Name the external change, broken old approach, and consequence.A recognizable situation, a useful point of view, and a low-friction way to learn more.
    EvaluationCan this work in my context?Connect the promise and relevant pillars to the customer’s actual job.A demonstration of the critical path, applicable customer evidence, and clear implementation assumptions.
    ActivationDid I make the right decision?Turn the promised change into an observable first value moment.Completion of the critical workflow and confirmation that it maps to the agreed outcome.
    Adoption and retentionIs the value recurring?Show progress, expose friction, and reconnect usage to the original outcome.Outcome signals, useful adoption behavior, resolved blockers, and mutual commitments.
    ExpansionWhy should I add a team, use case, or spend?Use established value to explain the next constraint the product can remove.Credible proof from the current deployment, a defined next outcome, and accountable owners.

    At the top of the funnel, the narrative should help the right person recognize a problem. That is different from maximizing curiosity. A dramatic tension that attracts people outside your ideal customer profile may improve attention while making the rest of the funnel less efficient.

    In sales, the narrative becomes diagnostic. A representative should be able to ask which change the buyer is responding to, where the old approach is failing, which consequence matters, and what evidence is required. The deck then follows the buyer’s causal chain. It does not force every prospect through the same sequence of features.

    Onboarding is where the story incurs a debt or earns trust. The first-run path should deliver the earliest defensible version of the value promised during evaluation. If the sales narrative emphasizes speed but onboarding begins with a long configuration detour, the customer experiences a contradiction before they experience value.

    For the first 60-90 days, use recurring customer check-ins anchored on outcomes. Reconfirm the job and success criteria, inspect friction along the critical path, identify a value moment, and finish with one commitment for the customer and one for your company. This keeps customer success from becoming a polite status meeting and gives product a structured stream of evidence.

    Retention is not customer success’s narrative problem alone. Product owns whether value can be created and repeated. Sales owns deal quality and expectation setting. Marketing owns who the story attracts. Customer success owns the ongoing outcome conversation. Finance and revenue operations make the leading and lagging signals visible. Treating net revenue retention as a shared operating metric forces those responsibilities into the same room.

    Community can extend the narrative between company-managed touchpoints. Workflows, templates, and practitioner stories let prospective users see the product in a credible context. They also reduce the cost of a first useful session. The community is most effective when it helps customers demonstrate the promised behavior to one another, rather than acting as another channel for company announcements.

    Figma’s sequencing illustrates how patient that motion can be: it added a sales team four years after product launch and introduced a paid product tier another two years later. That timeline is not a rule for another company. It shows why commercial expansion should amplify demonstrated user value rather than substitute for it. Earn preference, make team-level value legible, and add the sales overlay when it has proof to carry.

    Pricing and trials also communicate the story. A promise based on realized value clashes with an open-ended trial that never directs the user toward a value moment. If you offer a trial, tie its time or usage boundary to the behavior that demonstrates the product’s mechanism. A trial should clarify activation, not postpone the question of whether activation exists.

    Test the narrative as a growth hypothesis, then refactor it

    A message test is not merely a contest between two headlines. The useful question is whether a specific problem frame, promise, or proof point helps the intended customer take a meaningful next step and later experience the value they were led to expect.

    1. Write a falsifiable hypothesis. State which customer, which narrative element, and which behavior you expect to change.
    2. Change one narrative variable. Test the problem frame, promise, proof, or call to action separately when practical. Changing all of them tells you only that two packages performed differently.
    3. Hold the audience and offer steady. A result is difficult to interpret if the segment, channel, price, and story all move at once.
    4. Track the downstream chain. Attention is a leading signal. Qualified response, sales progression, activation, retained use, and expansion tell you whether the message attracted a customer who could realize the promise.
    5. Pair behavior with customer language. Use sales objections, win-loss patterns, onboarding friction, and success conversations to explain why a metric moved.
    6. Decide what actually failed. Separate a narrative problem from a channel problem, an offer problem, missing proof, and a product gap.

    These failure patterns make that diagnosis more concrete:

    • Attention rises but qualified conversion falls: the tension is interesting but too broad, or the story is attracting people outside the intended segment. Tighten the customer and problem frame before increasing distribution.
    • Prospects engage but do not advance after evaluation: the problem may be real while the promise remains generic or unsupported. Identify the evidence required to make the mechanism believable.
    • Deals close but activation is weak: sales may be setting an expectation the first product experience does not fulfill. Compare the promise in the deal with the critical path in onboarding.
    • Activation is healthy but retention is weak: a first value moment may exist without recurring value. Investigate the product and operating workflow before rewriting the retention message.
    • Retention is healthy but expansion stalls: customers may see a useful tool without understanding the next outcome it can unlock. Quantify the value already created and identify the adjacent constraint before presenting a larger package.
    • Customer success hears objections that surprise sales: the learning loop is broken. Bring renewal, adoption, and expansion evidence back into qualification and expectation setting.

    Do not use stronger copy to conceal a weaker product path. If the promised outcome is not achievable for the intended customer, narrow the promise, change the product, or change the segment. Message optimization cannot repair a false causal claim.

    To make learning cumulative, maintain a small narrative operating system:

    • A one-page narrative brief containing the current problem, promise, pillars, boundaries, and next action.
    • An evidence ledger that maps every material claim to the segment and proof that support it.
    • An audience map showing which emphasis and evidence each participant in the buying process needs.
    • A journey map showing how marketing, sales, onboarding, customer success, community, and expansion advance the story.
    • A decision log recording what changed, why it changed, and which signal should confirm or challenge the decision.

    Feed this system from the work teams already do. Customer discovery contributes new language and problem evidence. Win-loss reviews reveal expectation and credibility gaps. Onboarding shows whether the promise maps to a reachable value moment. Customer success contributes recurring outcome evidence. Product planning determines whether upcoming work strengthens a pillar or changes the mechanism behind it.

    Run a scheduled GTM refactoring review rather than waiting for the funnel to stall. A quarterly cadence is practical for pruning claims that no longer matter, retiring channels that attract the wrong segment, consolidating confusing offers, and checking whether pricing still matches the value narrative. This is the commercial equivalent of paying down technical debt: the work removes accumulated exceptions that make the system harder to understand and scale.

    Change the core narrative when evidence shows that the ideal customer or priority problem has moved, repeated wins center on a different outcome, the product now enables a materially different behavior, or the available proof can no longer support the promise. Do not rewrite it because one prospect disliked a phrase or one campaign underperformed before channel, audience, offer, and execution have been examined.

    Someone must hold the final edit. At an early stage, that is often the founder. As the company grows, it may sit with product marketing, corporate marketing, or another GTM leader. The title matters less than the operating principle: one accountable editor, evidence contributed by every customer-facing function. When making the first communications hire, prioritize strategic clarity before narrow channel expertise. Distribution skill cannot rescue a story the company has not resolved.

    Key takeaways

    • A GTM narrative is a causal explanation of customer change, not a slogan or product description.
    • Build it from buying triggers, failed workarounds, desired outcomes, product mechanisms, and credible proof.
    • Keep one problem and promise across the journey, but change the evidence and next action as the customer moves from discovery to expansion.
    • Make onboarding deliver the earliest defensible version of the value promised in sales.
    • Judge message tests by qualified progression and realized value, not attention alone.
    • Treat narrative, product, customer success, pricing, and distribution as connected parts of one growth system.

    Your next move does not need to be a company-wide rebrand. Put the current problem-promise-proof sequence beside one live journey: homepage, sales conversation, onboarding path, and success agenda. Mark where the story resets, where evidence disappears, and where the product contradicts the promise. Repair that handoff, observe the downstream behavior, and extend the system from there.

    References

  • Startup Acquisition Process: A Founder’s Operating Playbook

    Startup Acquisition Process: A Founder’s Operating Playbook

    An acquisition inquiry creates two jobs at once. You must determine whether the buyer is serious, and you must keep building the company in case the deal disappears. Confusing interest with commitment can cost you customers, product momentum, and negotiating leverage.

    The right operating model protects both paths. You qualify the buyer before expanding access, define what a good outcome means before negotiating it, and prepare integration while you still have the leverage to shape it. The goal is not simply to get a transaction signed. It is to preserve your options and make sure the company can succeed whether the deal closes or not.

    Start by writing the acquisition thesis and walk-away conditions

    A founder can enter an acquisition process with a precise view of the company’s value and still be unprepared for the decision. Valuation is only one variable. You also need to decide what should happen to the product, customers, team, and mission after control changes hands.

    Treat M&A as an extension of product strategy. The buyer should be able to create a credible future for what you have built, not merely provide an acceptable exit. If you cannot explain why this company is a better owner, the process is running ahead of the strategy.

    Write a short acquisition brief before substantive negotiations begin. It should answer:

    • Why consider a sale now? State the constraint or opportunity the transaction could address. That might be distribution, product adjacency, operating scale, or a path to greater customer impact. Do not substitute general fatigue or flattering buyer attention for a strategic reason.
    • Why could this buyer be the right owner? Name the assets the buyer would contribute and the part of the business those assets could strengthen.
    • What must remain true after closing? Define the outcomes that matter for customers, the product, key builders, and your own role.
    • What would make you stop? Record the conditions that would invalidate the deal, such as the absence of an accountable operating owner, an incoherent integration plan, or terms that put unacceptable obligations on founders and employees.
    • What evidence would change your position? Decide what the buyer must demonstrate before you increase access, incur more diligence cost, or make a binding commitment.

    This brief prevents each new conversation from redefining success. It also gives you a concrete basis for aligning investors. Agree on valuation guardrails, who can negotiate which issues, and what information will be shared with whom. Investor disagreement is much harder to resolve after a buyer has created urgency around a particular outcome.

    Do not treat the brief as legal or financial analysis. An acquisition can create material tax, contractual, employment, and fiduciary consequences. Qualified M&A counsel and financial or tax advisers should evaluate your specific situation before you sign anything that commits the company or limits its alternatives.

    Qualify the buyer before you expose the company

    An interested company is not yet a qualified buyer. Approach it with the discipline you would apply to a large enterprise prospect: identify the economic owner, understand the use case, map the decision process, and look for evidence that the organization can implement what it says it wants.

    Corporate development may coordinate the transaction, but it usually cannot answer every operating question. You need access to the executives who would sponsor, fund, sell, integrate, and run the acquired business. A productive buyer map includes the executive sponsor, the general manager or P&L owner, product and engineering leaders, the sales leader responsible for the customer story, and the finance leader modeling the expected value.

    Qualification areaQuestion to askEvidence to look for
    Executive sponsorshipWho has the authority and incentive to get this transaction completed?Direct access to a named senior sponsor who can explain the strategic objective.
    Product adjacencyWhich existing product, customer need, or strategic priority does the acquisition advance?A concrete use case that connects your product to the buyer’s roadmap.
    Operating homeWhich leader and P&L will own the business after closing?A clear organizational destination, decision owner, and resourcing discussion.
    Integration pathHow would the organizations and technologies fit together?Participation from the product, engineering, security, and operating leaders who would do the work.
    Customer valueWhy will customers be better served after the transaction?A joint customer narrative that survives detailed questions from sales and customer-facing teams.
    Builder continuityWhich people are essential to the product’s future?Early, specific discussion of roles, reporting relationships, and retention.

    Separate buying signals from meeting activity

    The strongest buying signals require the buyer to spend political or operational capital. These include fast access to senior decision-makers, serious technical and security diligence, direct discussion of deal structure, work on an integration plan, and effort to develop a customer narrative. Those actions indicate that people beyond the deal team are preparing to own an outcome.

    Weak signals are easier to generate. Vague strategic interest, meetings without a decision owner, reluctance to explain organizational ownership, and a continuing sequence of introductory conversations can consume your attention without moving the buyer toward a commitment. Rapid senior access and substantive integration work are more meaningful than the number of meetings on the calendar.

    When the signal weakens, ask for the next decision rather than the next conversation:

    • What decision is the buyer trying to make now?
    • Who owns that decision?
    • What information is actually needed to make it?
    • What will happen if the answer is positive?
    • Which operating executive will participate in that next step?

    If the buyer cannot answer, narrow access or pause the process. That is not a negotiating stunt. It is focus management. Your company should not perform open-ended diligence for an organization that has not defined its own intent.

    Run diligence without starving the operating business

    Acquisition work expands quietly. A founder answers a request, invites a functional leader, and soon half the leadership team is preparing custom material for a deal that remains uncertain. The damage usually appears later: delayed product decisions, slower customer follow-up, employee speculation, and a weaker standalone plan.

    Set up a separate operating system for the transaction. Keep the early circle small, designate one deal lead, use a controlled data room as the single source of truth, and send a weekly update to the people who are authorized to know. The update should cover decisions made, open requests, major risks, next gates, and any work that could disrupt the core business.

    Make every diligence request earn its cost

    A data room is not an invitation to upload everything. Organize approved material by the questions a credible buyer must answer: the product and technology, security posture, commercial performance, customers, people, corporate records, and financial or contractual obligations. Have counsel control sensitive disclosure and any information affected by confidentiality, privacy, employment, or regulatory duties.

    Route new requests through the deal lead. For each request, record:

    • The buyer’s decision that the information supports.
    • The person on the buyer’s side responsible for reviewing it.
    • The least disruptive way to provide a reliable answer.
    • Whether the material is already available in the data room.
    • Any confidentiality, customer, employee, security, or legal constraint.

    This exposes duplicate and exploratory requests before they reach the team. It also prevents inconsistent answers from being created in separate email threads.

    Protect the company on three parallel tracks

    The work should remain visibly separated:

    • Standalone execution: Keep shipping, serving customers, managing cash, and pursuing the plan that makes the company viable without the transaction.
    • Transaction execution: Coordinate buyer communication, diligence, investor alignment, advisers, document control, and negotiation.
    • Post-close readiness: Develop the retention, customer communication, ownership, and integration plan needed if the transaction becomes likely.

    The first track is your source of optionality. If it degrades, your leverage becomes dependent on the buyer’s continued interest. Review transaction demands against operating commitments and move work away from product or customer owners when it can be handled by the deal lead or an adviser.

    Prepare for employee questions before rumors appear

    Broad disclosure too early can create anxiety and unnecessary distraction. Secrecy without a communication plan creates a different risk: managers improvise when employees notice unusual meetings, adviser activity, or information requests.

    Limit knowledge while uncertainty is high, but prepare an approved response for managers if questions surface. It should avoid confirming confidential negotiations, avoid making promises about jobs or roles, and tell employees how material information will be communicated. Have counsel review the wording when contractual or disclosure obligations could apply.

    Once a transaction becomes likely, expand the communication plan deliberately. Identify who needs to hear what, in what order, and from whom. Employees, customers, partners, and investors have different concerns; sending all of them the same generic announcement leaves the most important questions unanswered.

    Negotiate the operating future, not only the transaction

    A high headline value can conceal an unclear operating future. Deal structure, individual obligations, retention arrangements, decision rights, resourcing, and the buyer’s integration choices can materially change what the outcome means. Do not compare offers or commitments by headline value alone. Your legal, tax, and financial advisers need to assess the complete terms and the risks attached to them.

    At the same time, advisers cannot decide whether the strategic operating model makes sense. You need direct answers from the executives who will own the business:

    • Who is accountable for the acquired product after closing?
    • Where will the product and team sit in the organization?
    • Which decisions will remain with the current leaders, and which will move to the buyer?
    • How will success be measured?
    • What people, budget, distribution, and technical support will be committed?
    • Which builders are considered essential, and what roles will they have?
    • How will existing customers be supported through product and commercial changes?
    • What integration milestones must be completed before the strategic thesis can be tested?

    Push for names and commitments. Phrases such as “access to scale” or “strategic alignment” are aspirations, not an operating plan. A credible plan identifies an owner, a destination in the organization, a success measure, and resources. If no P&L will house the asset and no executive owns the outcome, assume the acquisition will compete with the buyer’s existing priorities after the negotiating attention disappears.

    Use diligence as joint problem-solving. Share relevant roadmap choices, customer wins, and integration hypotheses, then ask the buyer’s product, engineering, sales, finance, and operating leaders to challenge them. This does more than test strategic fit. It reveals how those leaders make trade-offs and whether the working relationship can survive post-close pressure.

    Plan day one while you still have negotiating leverage

    Do not wait for the signature to begin thinking about implementation. Retention, customer communication, and integration milestones should be developed as the deal becomes likely. Waiting until after closing turns unresolved assumptions into operating facts.

    Your readiness plan should specify:

    • The leader who will own the acquired product and the cadence for resolving integration decisions.
    • The success metrics that connect the transaction thesis to customer and business outcomes.
    • The first communication for employees, customers, and partners, including who will deliver each message.
    • The roles and reporting relationships of key builders.
    • The product, technical, security, and commercial integration milestones that require named owners.
    • The customer commitments that must remain visible during the transition.

    Where the buyer will not define these points before closing, record the uncertainty explicitly. An unresolved question is a risk to evaluate, not an empty box that optimism should fill.

    Key takeaways for your next buyer conversation

    • An acquisition inquiry is not an offer. Qualify intent before allowing the process to consume the company.
    • Define a successful outcome and your walk-away conditions before the buyer creates momentum around its preferred terms.
    • Look for an executive sponsor, product adjacency, an operating home, committed resources, and a credible integration path.
    • Treat senior access, technical and security depth, structural discussions, and joint customer planning as stronger signals than meeting volume.
    • Keep the early circle small, centralize approved information, and use a weekly update to control decisions and workload.
    • Maintain a standalone operating track. Product and customer execution are both business necessities and sources of negotiating leverage.
    • Evaluate the complete legal and financial structure with qualified advisers; headline valuation does not describe the full outcome.
    • Negotiate ownership, decision rights, success metrics, retention, customer communication, and integration before those assumptions become post-close problems.

    Before your next acquisition meeting, create an acquisition brief and a buyer qualification scorecard. Then ask the buyer to identify its next decision, the executive who owns it, and the operating leader who would own your product after closing. Those answers will tell you whether to invest further in the process or return your attention to building the company.

    References

  • How to Turn Product Adoption Into a Product-Led GTM System

    How to Turn Product Adoption Into a Product-Led GTM System

    Your signup chart is moving, but too few customers are changing how they work. Marketing wants more traffic, sales questions lead quality, and product points to a healthy activation rate. Each function may be reading its own dashboard correctly while the business still has an adoption problem.

    The way out is to make adoption the shared operating unit for product-led go-to-market. Define the behavior that proves durable value, identify what prevents customers from reaching it, route each account according to evidence, and measure the transitions between those states. That turns product-led growth from a collection of tactics into a system you can manage.

    Define adoption as a customer behavior, not a company milestone

    A signup is an acquisition event. A payment is a commercial event. Neither proves that the product has become part of the customer’s operating rhythm.

    Adoption occurs when the right customer repeatedly uses the product to complete a meaningful job. That definition needs to be observable in product data, specific to an ideal customer profile, and tied to the natural cadence of the work. A payroll workflow, a daily support queue, and a quarterly planning product should not share the same return window.

    Write an adoption contract before debating channels, onboarding screens, or product-qualified lead scores. It should answer five questions:

    1. Who must adopt? Name the account segment, role, use case, and relevant starting condition. New teams migrating from another system may face a different path from first-time users.
    2. What job must be completed? Describe the customer outcome rather than a feature interaction. Creating a project is weaker evidence than using that project to complete a real handoff.
    3. Which event proves first value? Select the smallest observable action that demonstrates the promised outcome. Avoid events chosen merely because they are easy to instrument.
    4. What repetition proves adoption? Require a return to the workflow within its normal operating cycle. Do not choose an arbitrary number of sessions because it produces a tidy chart.
    5. What scope makes the behavior durable? Depending on the product, that may involve live data, a teammate, a critical integration, a second workflow, or another signal that switching back would sacrifice real value.

    For a collaborative workspace, for example, account creation may be activation. Adoption may require an operations lead to import a live process, a teammate to complete a handoff inside it, and the account to repeat that workflow in the next normal cycle. The exact event is product-specific; the discipline of connecting it to a completed job is not.

    Keep the funnel states separate:

    • Acquisition: A relevant user or account arrives.
    • Activation: The customer experiences initial value.
    • Adoption: The customer incorporates the workflow into real work.
    • Retention: The behavior persists across later cycles.
    • Expansion: More people, workflows, usage, or spend accumulate around that value.

    This separation prevents two common misreads. A customer can pay before adopting because procurement moved faster than implementation. A user can also be highly engaged while the wider account remains untouched. For a B2B product, track both user-level behavior and account-level penetration so one enthusiastic champion does not conceal a stalled rollout.

    Diagnose the barrier before choosing the growth tactic

    When adoption stalls, teams often add another tooltip, email sequence, demo, or discount. Those tactics address different problems. Applying all of them at once increases noise and makes the result harder to interpret.

    A more precise diagnosis starts with five barriers: reactance, endowment, distance, uncertainty, and corroborating evidence. The practical question is not how to push the customer harder. It is which barrier makes the next behavior feel unattractive, unsafe, or unnecessarily difficult.

    BarrierWhat you may observeProduct responseGTM response
    ReactanceUsers resist a mandatory rollout, aggressive prompt, or seller-controlled process.Restore choice with opt-in paths, reversible actions, and control over timing.Offer a bounded pilot and a clear decision process. Use real trigger events instead of manufactured pressure.
    EndowmentThe current tool or manual workflow is familiar, connected, and politically safe.Support imports, integrations, saved state, and temporary coexistence with the incumbent workflow.Provide a migration plan and compare the cost of staying put with the cost of switching.
    DistanceThe target behavior asks for too much change before any value appears.Break setup into progressive steps, preconfigure sensible paths, and reveal advanced work later.Start with one use case, team, or milestone rather than asking for an organization-wide commitment.
    UncertaintyThe buyer cannot predict the result, effort, security implications, or reversibility.Use previews, sample states, validation, undo paths, and visible progress.Define pilot scope, success criteria, responsibilities, and the decision that follows the pilot.
    Corroborating evidenceA champion sees the value but cannot persuade peers, executives, security, or procurement.Surface relevant examples, completed outcomes, and artifacts the champion can share.Equip the account with credible customer evidence, an ROI model, references, and proof from comparable situations.

    The same funnel symptom can come from different barriers. A customer who abandons an integration may fear data risk, lack technical help, or see too little value to justify the effort. A customer who completes a pilot but does not expand may need peer evidence, procurement support, or a smaller second step. Conversion data tells you where the journey broke; interviews, support conversations, session evidence, and sales objections help explain why.

    Use a one-barrier test for each intervention:

    1. Name the blocked segment and the next behavior you expected.
    2. Write the barrier hypothesis in plain language.
    3. Change one part of the experience that directly lowers that barrier.
    4. Measure movement into the next funnel state, not clicks on the intervention itself.
    5. Check a guardrail such as errors, support demand, low-quality activation, or later retention.

    This also changes how you create urgency. If a seasonal event, contract renewal, operating milestone, or compounding benefit creates a real window, make it concrete. A false deadline may produce a response while increasing reactance. The goal is an informed next step the customer still experiences as their decision.

    Connect onboarding, intent signals, and human help

    Product-led GTM does not mean leaving the product to do every job. It means using product behavior to deliver value and decide what kind of assistance the customer needs next.

    Make onboarding complete the promised job

    The first product session should continue the promise that brought the customer in. If an acquisition page promises a faster client handoff, onboarding should help the user complete that handoff. A generic tour of navigation, settings, and unrelated features breaks the connection between intent and value.

    1. Preserve acquisition context. Pass the use case, role, template, or integration named before signup into the first-run path.
    2. Start with the smallest real input. Import live work, connect a relevant system, or create a realistic first object. Sample data can teach mechanics, but it should lead clearly to the customer’s own data.
    3. Delay nonessential requests. Ask for permissions, profile fields, configuration, and invitations when they become necessary for the next unit of value.
    4. Guide the next action in context. A prompt should help complete the workflow now, not advertise a feature that might matter later.
    5. Make value visible. Show the completed outcome, saved effort, collaborator response, or operational change the customer came to achieve.
    6. Provide a recovery path. Preserve progress, explain errors, expose remaining steps, and offer human help when the blocker cannot be solved safely in the interface.

    Migration deserves product ownership because it is often the adoption experience, not an implementation detail. Imports, mappings, validation, rollback, and phased rollout reduce both switching effort and the perceived loss of the old workflow. If the customer must reconstruct years of context before seeing value, a polished welcome screen will not rescue activation.

    Route accounts by fit, value, and complexity

    Intent models become useful when they combine customer fit with behavioral evidence. Useful inputs include acquisition-source quality, setup depth, completion of the first-value milestone, collaboration signals, and connection to a critical integration. A page view may show curiosity. Repeated use of a live workflow with teammates is stronger evidence that the account has something worth expanding.

    Do not assign permanent weights based on intuition. Start with an explicit model, then compare each signal with later adoption, conversion, and retention. Remove signals that create activity without predicting value.

    • Good fit, no first value: Route to use-case education, concierge onboarding, migration help, or a simpler setup path. A sales pitch is unlikely to solve an unfinished product experience.
    • Activated, low complexity: Keep the path self-serve. Use contextual guidance, transparent packaging, and a clear upgrade moment tied to value.
    • Activated, high complexity: Add sales assistance when security, procurement, integration design, rollout coordination, or a multi-stakeholder decision requires a person.
    • Adopted, limited breadth: Use customer education or customer success to introduce the next relevant team or workflow. Do not push an unrelated feature merely because it is available.
    • Strong usage, weak fit: Preserve an efficient self-serve experience and examine whether the segment belongs in the ideal customer profile before committing expensive assistance.

    A product-qualified lead should therefore mean more than an active user. It should combine account fit, evidence of realized value, and a buying or expansion condition that human involvement can improve. This definition gives sales a reason to trust the signal and gives product a standard beyond raw engagement.

    Marketing, product, sales, customer success, community, and communications each have a distinct role. Marketing attracts the right customer with the right problem and prepares that customer to succeed. Product owns the path to initial and repeated value. Sales resolves complexity and coordinates a consequential purchase. Customer success helps an adopted workflow spread and persist.

    Community and creator programs can extend education when customers benefit from templates, integrations, examples, and shared workflows. Start with tighter curation when quality or compliance matters; decentralize more as the operating rules become clear and capable users emerge. Executive communications can reinforce category clarity and trust, but it should support the product-led motion rather than be treated as predictable customer acquisition.

    Run adoption as a measurable operating loop

    A single top-line dashboard cannot tell you whether the company has an acquisition, activation, adoption, monetization, or retention problem. Build a scorecard around transitions between those states and keep each denominator stable.

    Measure the path to durable value

    • Qualified acquisition: The number of new users or accounts that match the segment and use case in the adoption contract.
    • Activation rate: Qualified new accounts that reach first value divided by qualified new accounts entering the path.
    • Time to first value: The elapsed time from the meaningful starting event to activation. Report the median and inspect the distribution so a small set of long implementations is not hidden.
    • Adoption conversion: Activated accounts that meet the repeated-behavior definition divided by activated accounts eligible to do so.
    • Depth: How much of the core workflow is completed inside the product, using live work rather than incidental activity.
    • Breadth: How far the adopted behavior has spread across the relevant users, roles, teams, or workflows in the account.
    • Behavioral retention: The share of adopted accounts still completing the core job in later natural usage cycles.
    • Monetization and expansion: Paid conversion, usage growth, additional seats, or wider workflow coverage that follows realized value.

    Segment every transition by ideal customer profile, use case, acquisition source, onboarding path, and assistance type. Aggregate numbers can improve simply because the mix changed. Cohorts show whether a product or GTM change helped comparable customers move further through the journey.

    The shape of the funnel gives you a practical diagnostic:

    • If qualified acquisition rises while activation stays flat, inspect message-to-product continuity, setup friction, and channel quality.
    • If activation improves while adoption does not, the first-value event may be too shallow or the second-use path may contain the real friction.
    • If adoption is strong while paid conversion is weak, inspect packaging, entitlement boundaries, pricing logic, and whether the buyer is distinct from the user.
    • If paid conversion is strong while behavioral retention is weak, commitment may be arriving before durable value. Inspect implementation and post-purchase cohorts.
    • If sales assistance increases without improving adoption or conversion, the handoff may be too early, the segment may be wrong, or the human motion may be repeating work the product should complete.

    Do not scale acquisition merely because one early-stage rate moved. More traffic magnifies whatever happens after signup. Scale a channel when the relevant cohort can activate, adopt, and retain at a level that supports the commercial model.

    Give every experiment a decision rule

    Use a one-page experiment brief with seven fields: target segment, blocked behavior, barrier hypothesis, proposed change, primary transition metric, guardrail, and decision date. Set the observation window from the natural usage cycle rather than the team’s meeting calendar.

    A practical cadence keeps learning fast without rewarding noise:

    • Daily: Check instrumentation, severe errors, broken routes, and unexpected funnel discontinuities.
    • Weekly: Review segmented transitions, active experiments, onboarding evidence, routed accounts, and objections heard in customer conversations.
    • Monthly: Revalidate the adoption contract, intent-model weights, segment definitions, lifecycle ownership, and whether the core metric still represents customer value.

    Qualitative evidence belongs in this loop. Tag customer-call snippets by objection, compare the language used by progressing and stalled accounts, and connect those patterns to segment and product behavior. If customers repeatedly describe the problem differently from the landing page or sales narrative, change the promise or the targeting. If they accept the promise but stall at the same product event, change the experience.

    Assign one accountable owner to each transition, even when several functions contribute. Shared contribution is necessary; shared ambiguity is not. Marketing can own qualified arrival, product can own first and repeated value, sales can own assisted commercial progression, and customer success can own durable rollout. The precise boundaries can vary, but every stalled account should have an identifiable system owner.

    Key takeaways

    • Define adoption as repeated completion of a meaningful customer job within its natural usage cycle.
    • Separate acquisition, activation, adoption, retention, and expansion so one healthy metric does not conceal a broken transition.
    • Diagnose reactance, endowment, distance, uncertainty, or missing corroboration before choosing a product or GTM intervention.
    • Route accounts using fit, realized value, and complexity rather than treating all active users as sales-ready.
    • Measure product-led GTM with stable cohorts, behavioral retention, explicit guardrails, and experiments that end in a decision.

    At your next GTM review, leave with five things: one sentence defining adoption for one segment, one blocked transition, one barrier hypothesis, one intervention, and one owner with a decision date. If the meeting produces more campaigns and features but cannot produce those five decisions, the operating system is still organized around activity rather than adoption.

    References

  • The Leadership Operating System for a Scaling Organization

    The Leadership Operating System for a Scaling Organization

    Your organization rarely announces that it has outgrown its leadership model. The evidence arrives indirectly: routine decisions climb to executives, teams leave the same meeting with different interpretations, managers spend their time relaying updates, and choices that seemed settled keep reopening.

    A reorganization may move those problems, but it will not necessarily solve them. What you need is a leadership operating system: explicit agreements about roles, decisions, communication, learning, talent, and changes in leadership mode. Build those mechanisms before adding more hierarchy, and the organization can grow without making senior attention the dependency behind every important outcome.

    Diagnose the coordination failure before changing the org chart

    Start with a decision that recently consumed more leadership attention than it should have. Reconstruct its path from the moment the issue appeared to the moment someone finally acted. This exposes the operating gap more reliably than a broad discussion about communication or accountability.

    • What decision actually needed to be made?
    • Where did progress pause, and what was the team waiting for?
    • Who believed they owned the recommendation, the final choice, and the execution?
    • What context was missing when the issue reached leadership?
    • Which assumption or trade-off caused the decision to reopen?
    • Where can a future team find the rationale now?

    The answers usually point to a missing mechanism, not a lack of effort. Treat each recurring symptom as a diagnostic clue.

    What you noticeLikely operating gapFirst mechanism to install
    Routine choices repeatedly climb the hierarchyDecision boundaries are unclearA written map of who recommends, decides, contributes, and must be informed
    Teams agree on the work but explain its purpose differentlyContext is not traveling with the planA kickoff document that connects the problem, outcome, trade-offs, and ownership
    Settled choices keep getting relitigatedThe rationale and assumptions were not preservedA decision log with explicit conditions for reopening the choice
    The same failure appears in multiple initiativesLearning stops at the retrospectiveA searchable retrospective with named changes and owners
    Strong managers behave mainly as coordinatorsThe role rewards escalation more than judgmentA role contract that defines autonomous decisions and expected outcomes
    New leaders recreate basic practices from scratchOperating principles are implicitOutcome-based onboarding linked to documented principles and rituals

    Do not install every mechanism at once. Choose the recurring failure creating the most delay, risk, or executive dependency. Fix that loop, observe how behavior changes, and then move to the next constraint. Process earns its place by removing friction; it is not valuable merely because it looks disciplined.

    Design leadership roles from the next phase backward

    A scaling role changes before its title does. The product leader who once made most roadmap choices may later need to build a portfolio process, coach leaders who own those choices, and represent product trade-offs at the executive level. If the role holder continues succeeding through personal intervention, the organization gets a capable bottleneck instead of a scalable leader.

    Keep a future job description that looks 18 to 24 months ahead and is revisited quarterly. This is not a promotion plan. It is a forecast of what the organization will need from the role when its current methods stop working.

    Write a future-back role contract

    For each leadership role, document these fields in plain language:

    • Owned outcomes: the business, customer, or organizational changes for which this role is accountable.
    • Decision rights: choices the leader can make independently, choices that require consultation, and choices reserved for another role.
    • Systems to build: mechanisms that must keep working without the leader’s constant presence.
    • Interfaces: recurring decisions shared with product, engineering, sales, finance, people, or other functions.
    • Capabilities to develop: knowledge and judgment the next phase will demand.
    • Responsibilities to transfer: work the leader must stop owning, including the person or role being prepared to take it.
    • Failure signals: observable evidence that the role design or leadership approach is no longer sufficient.

    Review the contract quarterly with the role holder and the people most affected by it. Ask what remains correctly owned, what should move, and what new system must exist before the next phase begins. Waiting until performance visibly breaks turns a role-design problem into a personal performance crisis.

    Build cross-functional fluency before you need executive leverage

    Leadership at scale requires you to understand constraints outside your function well enough to make credible trade-offs. One practical example is the habit of reading two books about every peer executive’s area after joining a leadership team. The number is less important than the discipline: learn the economics, vocabulary, incentives, and failure modes behind your peers’ decisions.

    You can test your fluency during disagreement. Before defending your proposal, state the other function’s constraint in terms that its leader would accept. Then explain which trade-off you are asking the company to make. If you cannot do that, more authority will not repair the gap; you need more context.

    Succession belongs in the same conversation. A leader who develops a successor is not making the role less important. They are proving that the value of the role comes from judgment and system design rather than exclusive possession of information. That is what makes the person available for the next problem the company will need them to solve.

    Make decisions visible, then change leadership modes deliberately

    Decision quality does not scale when the real process lives in private conversations and executive memory. The organization needs a visible path from intent to choice to learning. That path should be lightweight enough to use under normal conditions and strong enough to support the team when risk rises.

    Use the kickoff as a contract, not a ceremony

    Every consequential initiative should begin with a written kickoff that answers the questions people otherwise discover halfway through execution:

    • What customer or business problem is being solved?
    • Why does it deserve attention now?
    • Which outcome should change, and how will the team recognize that change?
    • Who is the directly responsible individual for moving the initiative forward?
    • Who has final decision authority when trade-offs cannot be resolved?
    • What is deliberately outside the scope?
    • Which assumptions, dependencies, and risks could invalidate the plan?
    • Which decisions have already been made, and where is their rationale recorded?

    Do not confuse the directly responsible individual with the final decider. The first owns momentum and coordination; the second holds authority for a defined choice. Combining those concepts implicitly is a common reason teams either escalate everything or discover too late that approval never existed.

    Make the success measure an outcome, not evidence of activity. Shipping, launching, migrating, and holding a training session are outputs. The kickoff must state the change those outputs are intended to produce. If the team cannot express that change, it is not ready to defend the initiative’s priority.

    Separate debate, decision, and distribution

    A decision meeting should not be the first time participants encounter the problem. Send a concise pre-read containing the decision required, relevant constraints, viable options, evidence, and the recommendation. Use the meeting to challenge assumptions and resolve trade-offs. End it by recording the decision, owner, unresolved dissent, immediate implication, and any trigger that would justify reconsideration.

    The decision log is institutional memory, not an executive diary. A useful entry preserves:

    • the decision and the person authorized to make it;
    • the options considered and the reason one was selected;
    • the assumptions that mattered most;
    • the consequences for affected teams;
    • the condition that would cause the organization to revisit the decision; and
    • links to the kickoff, supporting material, and eventual retrospective.

    Use chat as an index into this system, not as its only memory. Give important channels an explicit purpose, consistent name, pinned index, and links to current kickoffs, decisions, and retrospectives. Summaries can live in chat; durable reasoning should remain searchable after the conversation scrolls away.

    Declare when the leadership mode changes

    Autonomy should be the normal mode, but it is not the only responsible mode. A customer incident, safety-critical launch, or brand-defining bet can justify a temporary period of closer senior involvement. The failure is not becoming hands-on. The failure is changing the rules without naming the change, its scope, or its end.

    When risk requires a different mode, write down:

    • the condition that triggered the change;
    • which decisions temporarily move to senior leadership;
    • which decisions remain with the team;
    • the communication and review cadence;
    • the outcome or risk threshold that permits normal autonomy to return; and
    • who is responsible for explicitly closing the temporary mode.

    This turns hands-on leadership into a bounded response rather than a permanent management habit. It also protects the team from learning the wrong lesson – that ownership disappears whenever stakes rise.

    During broader volatility, increase the frequency of useful context. Weekly communication can cover goals, financial runway, scenario changes, recent decisions, and the next three priorities. At an all-hands meeting, lead with the hard issue people are already discussing, explain the trade-offs, connect priorities to customer outcomes, allow unscripted Q&A, and publish the decisions afterward. Transparency is not the indiscriminate release of every unfinished thought. It is timely access to the context people need at the altitude where they can act.

    Build learning into culture, feedback, and the talent system

    A scaling organization cannot depend on leaders noticing every problem personally. It needs loops that detect weak signals, turn them into changes, and teach those changes to new people. Culture, feedback, retrospectives, hiring, and onboarding are parts of that same learning system.

    Treat cultural change as product work

    Culture becomes actionable when it is expressed as observable behavior. Instead of declaring that the organization needs more accountability, define the situation in which accountability currently fails, the behavior you want to see, and the mechanism that should make it easier.

    Use a simple sequence: write a precise problem statement, identify the desired behavior, run a limited pilot, choose evidence of adoption and impact in advance, and review what changed. This product-like approach to culture uses explicit goals and feedback loops rather than treating values as finished once they have been announced.

    Suppose important risks first appear after a product commitment has been made. A vague response would be to ask for better collaboration. A testable response would change the review ritual: circulate the decision material before commitment, require affected functions to record risks in the same place, and observe whether consequential objections now surface while the decision is still reversible. That gives you behavior to inspect instead of sentiment to debate.

    Give high performers developmental tension

    Strong performance often attracts praise while reducing the amount of corrective feedback a person receives. That is a poor bargain. A leader can be delivering excellent results while relying on habits that will fail at the next level of scale.

    Make development a recurring part of one-to-ones for every performer. Ask:

    • Which behavior is creating disproportionate value right now?
    • Where could the same strength become limiting as the role expands?
    • What specific event or observation supports that view?
    • What should the person try before the next check-in?
    • What support or feedback does the manager need to provide?

    Require evidence and examples, not personality labels. Add upward feedback so managers experience the same standard they ask others to accept. When a leader feels certain about an interpretation, have them write the opposite hypothesis and identify evidence that could support it. This interrupts premature certainty without turning every decision into endless debate.

    Close initiatives with a structured, searchable retrospective. Record the intended outcome, actual result, useful choices, failed assumptions, deviations from the kickoff, and changes the team will make. Give each change an owner and connect it to the next relevant kickoff or operating-principle review. A lesson without a destination is documentation, not organizational learning.

    Make talent decisions produce comparable evidence

    Hiring becomes less reliable as role ambiguity grows. Executive polish, employer brands, and familiar career patterns can look like signal when the organization has not defined what success means. Write the role scorecard before meeting candidates. Anchor it in outcomes, essential competencies, and observable behaviors rather than resume proxies.

    Then make the evaluation process consistent:

    • Ask candidates to reconstruct real ambiguous decisions, including constraints, assumptions, disconfirming evidence, trade-offs, and measurable results.
    • Use consistent core prompts so different candidates generate comparable evidence.
    • Have interviewers score independently before discussing the candidate.
    • In the debrief, connect every claim to the scorecard and have the most senior participant speak last.
    • Use reference checks to test observed behavior, especially collaboration and judgment under pressure.
    • For an executive role, clarify the mandate and decision rights as rigorously as the candidate’s capabilities.

    Onboarding should continue the same logic. A 30-60-90 plan needs explicit outcomes, purposeful shadowing, and early relationship-building across functions. Give the new leader the operating principles, active decision logs, recent retrospectives, and future role contract. If onboarding teaches only current projects, the person learns the workload but not the system that gives the work meaning.

    Finally, connect your principles to the full talent lifecycle. The same observable behaviors should appear in hiring rubrics, onboarding, one-to-ones, performance conversations, and product or operating reviews. A principle scales when people repeatedly use it to make choices; repetition on a values page does not count.

    Key takeaways: install a minimum viable leadership system

    • Trace a real stalled or reopened decision before assuming the answer is a reorganization.
    • Define leadership roles through owned outcomes, decision rights, systems to build, interfaces, and responsibilities to transfer.
    • Maintain a future job description so leaders prepare for the role the next phase requires.
    • Connect every consequential initiative through a kickoff, decision log, written communication, and searchable retrospective.
    • Make autonomy the default, but declare the scope and exit conditions whenever risk requires a more hands-on mode.
    • Treat culture as observable behavior that can be piloted, measured, reviewed, and changed.
    • Use structured hiring and onboarding to preserve standards without relying on pedigree, charisma, or organizational folklore.
    • Judge every new ritual by whether it improves decisions, distributes context, or converts experience into reusable learning.

    Start with one operating cycle

    At your next leadership meeting, bring one decision that required repeated escalation. Trace where it failed, choose the smallest missing mechanism, name its owner, and attach it to an existing cadence. Run the full loop through decision and retrospective before adding another process.

    At the end of the cycle, ask whether the decision boundary became clearer, whether the rationale reached affected teams, and whether the learning changed subsequent work. Keep the mechanism if it changes behavior. Revise or remove it if people maintain the artifact without using it to decide.

    The practical test of a leadership system is simple: sound decisions and useful context should travel farther than any individual leader can. Build that capability one recurring failure at a time, and growth becomes less dependent on heroic attention from the top.

    References

  • Startup Validation: A Practical Path to Product-Market Fit

    Startup Validation: A Practical Path to Product-Market Fit

    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.

    1. Problem evidence: Does a defined customer encounter this problem in a real workflow? Look for recent examples, consequences, workarounds, and a recognizable trigger.
    2. 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.
    3. 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.
    4. 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.

    1. 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.
    2. Anchor the conversation in a recent event. Ask the customer to reconstruct what happened rather than predict what might happen in an imagined future.
    3. 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.

    1. Attention: The person stops, clicks, or reads.
    2. Declared interest: The person joins a waitlist, replies, or requests a demonstration.
    3. Effort: The person completes an interview, shares a workflow, or returns for another session.
    4. Access: A design partner supplies representative data, involves colleagues, or makes room for implementation.
    5. Economic commitment: The customer enters a paid pilot, signs a contract, or completes the real purchasing process.
    6. 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:

    1. 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.
    2. 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.
    3. Ship the smallest reusable improvement. Prefer a change that tests the underlying job across the target segment over a bespoke implementation for one account.
    4. Measure the value path. Connect qualitative observations to activation, time-to-first-value, repeat use, referrals, and commercial progress.
    5. 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 observeWhat it may meanWhat to do next
    People join the waitlist or start signup but do not activateThe story is stronger than the product experience, setup cost, or targetingCompare the promise with the first session and remove the earliest value-path blocker before adding traffic
    Customers activate but do not returnFirst-run value is not durable, or you are measuring on the wrong cadenceIdentify the natural return trigger for the job and investigate what customers do when it occurs again
    The core ICP retains while adjacent segments do notYou may have a valuable wedge rather than a broad marketDeepen the core workflow and resist premature expansion
    Retained customers refer peers, renew, or expandValue is beginning to generate organic and commercial pullTest whether new cohorts from repeatable channels show similar behavior
    The launch cohort performs well but later cohorts weakenThe initial audience or channel may have produced an unusually favorable sampleReproduce acquisition and retention with less concentrated cohorts before increasing spend
    Demand rises but every implementation requires founder interventionCustomer value may be real while delivery remains operationally fragileProductize 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
  • From IC to Manager: Proven Strategies to Avoid Pitfalls and Lead High-Impact Teams

    From IC to Manager: Proven Strategies to Avoid Pitfalls and Lead High-Impact Teams

    The leap from individual contributor to manager looks straightforward on paper, yet it’s one of the trickiest transitions I’ve seen in high-growth environments. In my role at HighLevel, I’ve watched brilliant engineers stumble when the job changes from building the product to building the people who build the product. The difference isn’t incremental—it’s a complete shift in identity, incentives, and daily habits.

    Most startups get it wrong because they promote for technical excellence and throughput, then keep the new manager doing their old job with “a little people stuff on the side.” That’s a recipe for burnout and underperformance. The first principle is simple: management is a different job. Success is no longer measured by your code, but by your team’s clarity, velocity, and outcomes.

    Set expectations and goals with precision on day one. I establish a clear role charter, spell out decision rights, and align to outcomes vs output OKRs so the new manager understands what “great” looks like. We define a 30/60/90 plan that includes team health metrics, delivery goals, and collaboration routines with product and design. The aim isn’t to ship more tickets—it’s to reliably ship the right outcomes.

    To turbocharge a team’s effectiveness, I focus on operating cadence and flow. That means crisp intake, visible priorities, lean WIP, tight feedback loops, and regular retros that drive real change. I remove systemic blockers, protect focus time, and make psychological safety a non-negotiable. When people feel safe, they surface risks early, challenge assumptions, and accelerate learning.

    High-impact feedback is fast, frequent, kind, and specific. I coach managers to use situation–behavior–impact, to separate people from problems, and to balance reinforcing and redirecting feedback. Written summaries after key conversations prevent drift, while short feedback cycles create compounding growth. Recognition is not an afterthought—it’s a performance tool.

    Going from peer to manager requires an explicit reset. I encourage managers to communicate the new expectations, re-establish boundaries, and commit to fairness over familiarity. This includes confidential 1:1s, transparent decision-making, and a clear stance on performance bars. Trust grows when people experience consistency, not when they hear platitudes.

    Delaying action on low performance is one of the most costly leadership mistakes. It silently taxes your top performers, normalizes mediocrity, and corrodes culture. Diagnose if the issue is skill or will, offer targeted support with time-bound milestones, and be decisive. Managing someone out can be both humane and necessary—clarity and dignity can coexist.

    For first-time managers, I use a simple playbook. In the first 30 days, run a listening tour and baseline the team’s delivery, quality, and morale. By day 60, implement the new operating cadence, align on outcomes vs output OKRs, and tighten cross-functional rituals. By day 90, complete career conversations, calibrate performance, and publish a team charter that codifies how you plan, build, and learn.

    The throughline in all of this is ownership: own the outcomes, the culture, and the system. When you make the mindset shift from doing the work to enabling the work, you’ll find that the manager role is not a detour from impact—it’s a force multiplier. With clear expectations, disciplined execution, and courageous feedback, you’ll transform a promotion into a platform for sustained, compounding results.

    Book a consult png image
  • Scale Beyond One Product: Battle‑Tested Tactics for Ideas, Teams, and Product Reviews

    Scale Beyond One Product: Battle‑Tested Tactics for Ideas, Teams, and Product Reviews

    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.

    For ongoing inspiration and sharp thinking in product management leadership and product discovery, I regularly revisit a few resources. First Round Capital’s Newsletter: https://review.firstround.com/newsletter. The ‘Wins Above Replacement’ metaphor: https://en.as.com/mlb/wins-above-replacement-war-baseball-statistic-explained-n/. Zero to One by Peter Thiel & Blake Masters: https://www.amazon.com.au/Zero-One-Notes-Startups-Future/dp/0804139296.

    When I look across the ecosystem—Atlassian: https://www.atlassian.com/, Cash App: https://cash.app/, Figma: https://www.figma.com/, First Round Capital: https://firstround.com/, Lattice: https://lattice.com/, Notion: https://www.notion.so/, Paypal: https://www.paypal.com/, Stripe: https://stripe.com/, Watershed: https://watershed.com/—I see variations of the same pattern: disciplined product discovery, sharp resource allocation, and product review rituals that reward learning over laddered status updates.

    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.

    Book a consult png image