Tag: founder-led GTM

AI-Native Startup Execution: A Practical Operating System

Your startup can produce impressive demos every week and still learn slowly. If model behavior, customer evidence, and deployment feedback move through separate queues, faster shipping only creates more uncertainty.

If you are deciding how to run an AI-native startup, use one standard: how quickly can your team turn a real customer artifact into an evaluated product change and a measurable customer outcome? That standard should shape your wedge, ideal customer profile, team design, sales motion, and operating cadence.

Build the smallest closed learning loop

An AI-enabled company can add a model to an existing product process. An AI-native company has to organize the process around intelligence itself: the data entering the system, the judgment the model makes, the action produced, the evaluation of that action, and the feedback that improves the next decision.

That makes a long AI feature list the wrong starting point. Begin with the smallest end-to-end loop that proves the product’s central claim. In a security product, for example, the loop might start with suspicious activity, produce a risk judgment, stop or downgrade a threat, and capture enough evidence to assess whether the intervention was correct. A polished dashboard without that closed loop is packaging, not proof.

Use three gates before committing to a wedge:

The customer can quantify the problem. Ask for frequency, severity, operational burden, or another observable consequence in the customer’s own workflow. General concern about AI is not enough.
The wedge can create value within one buying cycle. If proving value requires a broad platform rollout, several integrations, and organizational change across multiple functions, you have probably selected a destination rather than an entry point.
Product use improves your data advantage. Determine what feedback the product will capture, whether you can legitimately use it, how quickly it arrives, and which evaluation or model decision it improves. Data volume alone does not create an advantage.

Failing any one of these gates weakens the loop. Urgent pain without accessible data leaves the model blind. Useful data without a near-term outcome produces an experiment that customers may admire but will not adopt. A fast result that teaches you nothing can become a services engagement disguised as software.

Your first version should feel narrower and less polished than the roadmap in your head. It may require manual review, a rough operator interface, or close founder involvement. That is acceptable when the roughness is visible and recoverable. It is not permission to hide model failure, skip evaluations, or make consequential actions impossible to inspect. Cut breadth before you cut control.

Define completion around the loop rather than the interface. You are done with the first proof when a target customer can supply the relevant input, receive the intended outcome, show whether it helped, and feed the result back into a repeatable evaluation. Everything else competes with learning speed.

Choose an ICP that maximizes learning density

The largest market is rarely the most useful starting market. Your early ideal customer profile should concentrate urgency, usable data, workflow access, and a reachable decision maker. Those conditions allow one customer interaction to improve both the product and the go-to-market motion.

Create a one-page ICP card with four evidence fields:

Urgency: What is happening now that makes the buyer act rather than merely agree that the problem matters?
Data pathway: Which alerts, cases, decisions, errors, or other operational artifacts can enter the product and its evaluation process?
Workflow position: Where will your output appear, who will act on it, and what existing step must change?
Success signal: What observable customer outcome would justify adoption, renewal, or expansion?

Rate each field as high, medium, or low, but require an evidence note beside the rating. A founder’s conviction is not evidence. A buyer who can describe the cost of the problem, provide representative artifacts, identify the operator who owns the workflow, and agree on a success signal gives you something testable.

Keep adjacent customer segments out of the first learning loop when they require different data, integrations, evaluation criteria, or buying logic. A larger pipeline can make progress look healthier while mixing incompatible requirements into the roadmap. The practical test is simple: if two prospects would judge the same model behavior by different definitions of success, they should not share an early product plan merely because they could buy from the same company.

Founder-market fit helps here, but it is a compression mechanism rather than proof of product-market fit. Deep domain experience can sharpen the problem statement, reduce translation with buyers, and establish credibility. It cannot substitute for evidence that customers will change a workflow around the product.

Founder-led sales should therefore operate as a structured discovery system. For every lost or stalled opportunity, record the exact objection, the stage at which it appeared, the evidence offered by the buyer, and the suspected root cause. Do not turn each objection into a feature request. Cluster the objections, identify the two most common root causes, and turn those into experiments within a sprint.

Look beyond compliments when judging early product-market fit. Stronger signals appear when customers escalate a problem to your team, volunteer data that can improve the system, or invite you into the workflow where decisions are made. None is conclusive alone, but each requires the customer to spend trust, attention, or organizational effort. That makes them more informative than enthusiasm during a demo.

Organize the team around evaluation and deployment

A conventional feature organization separates product definition, engineering delivery, model work, implementation, and customer support. That creates handoffs precisely where an AI-native startup needs rapid feedback. Organize durable units around a customer outcome, with the people who can inspect data, change the system, deploy it, and evaluate the result.

The exact titles can vary, but the unit needs four capabilities:

Product judgment: Choose the scenario, define the customer outcome, and decide which uncertainty deserves the next experiment.
Model and data judgment: Design evaluations, diagnose failure patterns, and understand whether a change improves one scenario while damaging another.
Product engineering: Turn model behavior into a reliable workflow with usable interfaces, permissions, integrations, and operational controls.
Frontline deployment: Work safely in live customer environments, resolve implementation friction, and return generalizable learning to the product.

Forward deployed engineers and solutions engineers are especially valuable when the product has to enter complicated workflows. They can shorten the distance between a live failure and a product decision. They can also become an unofficial custom-development queue. Prevent that by attaching three fields to every customer-specific change: the broader pattern it tests, the product owner responsible for reviewing the result, and the condition under which the work will be standardized, stopped, or kept outside the core product.

AI fluency should also change your hiring process. Model vocabulary on a resume tells you little about how someone will reason under uncertainty. Give candidates a work sample built around a realistic failure: model performance changes across scenarios, the data distribution is moving, and customer trust is at risk.

Ask the candidate to define the evaluation, explain the consequences of false positives and false negatives, diagnose a precision-recall tradeoff, and translate the technical result into a product decision. The strongest response will not jump straight to a model change. It will clarify the scenario, inspect the evidence, identify what the current evaluation misses, and explain the tradeoff in terms an operator or buyer can use.

Use the same discipline for founder and leadership disagreement. Write down the principle in dispute, the evidence each side is using, the decision owner, the time box, and the condition that will trigger a review. Debate the principle rather than multiplying competing implementation plans. Once the decision is made, commit until the agreed review point. This preserves speed without pretending that an uncertain decision has become permanently correct.

Run model and business evidence on the same cadence

An AI-native startup needs two connected scoreboards. One shows whether the system is becoming more reliable. The other shows whether customers are receiving enough value to adopt, retain, and expand. Reviewing them separately makes it easy to celebrate a model improvement that does not change customer behavior, or a short-term commercial win built on fragile product performance.

Evidence layer	Question	Measures to inspect	Decision it should inform
Scenario quality	Does the system make the right judgment in each important situation?	Precision and recall by scenario; recurring misclassification patterns	Evaluation coverage, data work, model changes, and acceptable operating thresholds
Change detection	Does the system recognize when its environment is moving?	Drift, data freshness, and time to first signal for an emerging pattern	Refresh cadence, investigation priority, and new evaluation cases
Operational experience	Can the customer use the output without creating a new burden?	Alert-fatigue reduction and latency under load	Workflow design, prioritization, and deployment constraints
Business value	Is reliable behavior turning into durable adoption?	Activation, expansion, and Net Recurring Revenue	ICP focus, onboarding, positioning, and roadmap investment

Do not collapse these measures into one composite score. Aggregation hides the failure mode you need to fix. A model can improve overall precision while degrading a high-consequence scenario. Activation can remain flat even when evaluation results improve because the output arrives too late, lacks an escalation path, or does not fit the operator’s workflow. The broken link between the two scoreboards is often the most valuable finding in the review.

Make the weekly customer debrief evidence-based. Bring actual alerts, misclassifications, escalations, and deployment failures rather than a verbal account of how the customer feels. For each material artifact, record the hypothesis it challenges, the evaluation that can reproduce it, the next bet, and the owner. That written log becomes organizational memory when priorities change quickly.

Use an evaluation gate for every consequential release:

Run the relevant scenario-level evaluations, not only an aggregate benchmark.
Inspect newly introduced failure modes as well as improvements to the target case.
Check latency and operational behavior under the conditions the customer will actually use.
Name the owner of monitoring, escalation, and rollback before deployment.

This is not process for its own sake. In an AI product, observability is the control center for trust. It tells your team whether the model still deserves the authority the workflow gives it. Demo speed cannot compensate for an inability to see, explain, and correct failure in production.

Key takeaways for your next operating cycle

Define the product as a closed loop from customer signal to verified outcome, not as a list of AI capabilities.
Commit to a wedge only when the problem is quantified, value can appear within one buying cycle, and legitimate product use improves the data advantage.
Select the first ICP for urgency, data access, workflow access, and a clear success signal. Keep adjacent segments separate when they require different definitions of success.
Turn founder-led sales into a discovery system by logging every rejection, clustering root causes, and testing the two most common causes within a sprint.
Build durable customer-facing units that combine product, model, engineering, and deployment judgment.
Review scenario-level model evidence and business outcomes together, then investigate the link whenever one improves without the other.

For your next planning cycle, choose one ICP, one end-to-end loop, one scenario-based evaluation set, and one customer outcome. Give a single owner responsibility for showing the connection between them. If the team cannot trace that chain with production evidence, the roadmap is still too broad. Narrow it before adding another feature, segment, or model.

References

Shivam.Consulting Blog – Inside Artemis’ AI vs AI Security War: Hiring at Speed, PMF Signals, and Founder-Led Sales

April 21, 2026

From Engineer to CEO: Hard-Won Lessons on GTM, Cloud-First Bets, and Must-Do Focus

Making the leap from engineer to CEO demands an almost entirely new skillset. I’ve felt that jolt firsthand: the tools that serve you as an IC or even a product leader—system design, crisp PRDs, elegant roadmaps—only get you about 20% of the way. The rest is learning to orchestrate go-to-market strategy, finance, hiring, culture, and product positioning with just enough depth to make sound, fast decisions while empowering true experts to execute.

My operating heuristic is the 80% rule. As CEO or GM, I don’t need to be the best marketer, seller, or finance leader; I need to understand 80% of each function well enough to set a compelling product strategy, ask the right questions, and catch the second-order effects. That breadth unlocks speed, quality of judgment, and the conviction to say no when the organization is tempted by what it can do rather than what it must do.

The clearest illustration comes from the journey that turned Apache Kafka—originally built at LinkedIn—into Confluent, a publicly traded enterprise software company. The technical insight was powerful, but the real lift came from translating that insight into a repeatable go-to-market engine. That required building new muscles: founder-led GTM, enterprise sales orchestration, and open source monetization without alienating the community that fueled adoption.

Early on, the product was “embarrassing” by enterprise standards—thin features, sharp edges, and a long tail of operational gaps. Shipping anyway was the point. A thin vertical slice into the market created learning loops with real customers, not hypotheticals. That uncomfortable speed became a superpower, especially when the company decided to push toward a cloud-first business in the face of widespread opposition.

The messaging challenge was just as hard as the technical one. Most marketing fails because it starts with what we built, not what customers must achieve. A simple product marketing pyramid—vision at the top, category framing and points of parity in the middle, crisp value props and proof at the base—helped explain Kafka to the world in customer language. When the narrative snaps into place, adoption accelerates. In Kafka’s case, one well-timed blog post clarified the “why now” and unlocked a step-change in community and enterprise pull.

There’s a pivotal distinction leaders underestimate: the gap between what a company can do and what it must do. I use a must-do filter before every planning cycle: What moves are non-discretionary for durable product-market fit? For Kafka and Confluent, that meant ruthless prioritization on managed cloud services, reliability, and platform scalability—even when it jeopardized short-term revenue or required retooling how engineering, sales, and support worked.

Fundraising strategy mirrored this clarity. Planning to raise before building the full product wasn’t about hype; it was about matching capital to the physics of the problem. If your category requires enterprise credibility, global infrastructure, and 24/7 SRE, you finance those table stakes early. That’s first principles decision making: instrument the constraints, then design the sequence that gets you to scale with the fewest irreversible mistakes.

In the early years, every product decision felt like a trade between polish and learning. The team essentially bludgeoned its way into a cloud-first posture—less because the initial product was ready, and more because the market’s must-do was obvious. That’s the essence of founder-led GTM: get into the field, close lighthouse customers, and use their arcs to shape the roadmap. It’s also where open source monetization matures from downloads into durable, enterprise value.

As the organization scales, excellence often erodes—the Chipotle problem. Process hardens; quality blurs; the magic decays. The antidotes are simple but hard: a few non-negotiable product quality bars, a short set of product-market fit metrics that everyone can recite, and empowered product teams who own outcomes over output. This is where organizational development matters as much as code: design clear interfaces between product, sales, and success, and you’ll keep velocity without losing standards.

Contrary to popular lore, founder optimism is overrated. Constructive realism wins. I try to model “probabilistic optimism”: assume we will win, but instrument the journey like an SRE runs an incident. Set leading indicators, rehearse failure modes, and make pre-commitments to the must-do path so you’re not swayed by the latest anecdote. It keeps the team out of a failure mindset while making room for rigorous course correction.

Giving up the right things at the right time is a CEO superpower. As complexity grows, I hand off decisions that benefit from specialization and keep only those tied to company narrative, must-do prioritization, and talent bar. CEO time management becomes a portfolio problem: ensure each week contains deep product time, frontline customer exposure, and one compounding systems fix (hiring loop, pricing rubric, or GTM enablement) that pays back for quarters.

If you’re moving from IC or PM into a GM/CEO role, here’s a practical playbook: build your product marketing pyramid; write the one-page must-do memo for the next six quarters; ship a narrow, managed cloud slice early; pick three product-market fit metrics (usage, time-to-value, retention) and publish them company-wide; and architect an enablement engine that turns field learnings into roadmap changes within one quarter. That’s how you transform technical advantage into a category-defining business.

The Kafka-to-Confluent arc reminds me that technology can open a door—but clarity of narrative, sequencing, and must-do focus determines whether you walk through it. When in doubt, bias toward shipping, talking to customers, and tightening the loop between what you learn and what you build. That’s the work of product management leadership at scale.

March 26, 2026
Inside Zipline’s Wild Pivot: My Take on Hiring Heat-Seekers and Scaling to 5,000 Hospitals

I’m consistently drawn to stories where product strategy and operational grit collide to change real lives. Zipline, the world’s largest commercial autonomous delivery system, is one of those rare cases. Serving 5,000 hospitals across multiple countries and saving an estimated 17,000 lives per year, it embodies the kind of mission-driven execution I try to model in product management. The arc—from a near-dead home robot startup to a scrappy bet on drone blood delivery in Rwanda, to 135 million autonomous miles flown—offers some of the clearest lessons I’ve seen on hiring, leadership, and product-market fit under extreme constraints.

One principle that immediately resonated with me: why Zipline doesn’t hire for experience. The idea behind “Why Zipline hires teenagers over PhDs” isn’t a dismissal of expertise; it’s a commitment to learning velocity, ownership, and unteachable hunger. The best startup employees, as described here, are “heat-seeking missiles for pain”—people who chase the hardest problems, not the shiniest projects. In my org, I look for the same signal: candidates who can move from ambiguity to action, who find the bottleneck without being asked, and who care more about outcomes than optics.

I also appreciated the unapologetic stance that “blind references are a non-negotiable.” In high-stakes builds—especially in regulated or safety-critical categories—the cost of a mis-hire compounds. I routinely validate for two traits during references: intellectual humility and accountability. “Can candidates admit when they screwed up?” is a powerful filter. If someone can’t name a hard mistake and how they specifically changed as a result, they’re unlikely to scale with the organization.

Equally important is clarity about who not to hire. The employees Zipline doesn’t want are those who optimize for status, process theater, or low-friction work. In practice, that means pressure-testing for problem-finding, not just problem-solving. I often design interviews around messy, cross-functional constraints (regulatory, operational, and financial) to see who can integrate tradeoffs, not just ideate features. That’s how we build empowered product teams that ship consequential outcomes, not outputs.

There’s a reference to “Zipline’s secret leadership playbook,” and while the specifics remain private, the spirit is unmistakable: first principles decision making, ruthless focus, and a culture that rewards radical responsibility. Translating that to my product organization, I emphasize five behaviors: orient to the mission under uncertainty, run fast but close the loop with data, communicate constraints early and often, own the long tail of consequences (especially in safety and reliability), and scale judgment by teaching the why, not just the what. That blend of clarity and autonomy is the backbone of product management leadership at any growth stage.

On the other side of the culture coin is “Why you should always fire quickly” and “The brutal firing advice that shaped Keller’s leadership.” I’ve learned (sometimes the hard way) that slow decisions erode trust and team velocity. Moving quickly doesn’t mean being harsh; it means being fair, explicit, and humane—tight feedback loops, role clarity, and decisive action when the gap persists. If your bar is clear and your coaching is consistent, acting fast protects both the mission and the team’s energy.

Strategically, the origin story reads like a masterclass in choosing the right problem. The team moved “from toy robots to drone delivery: Zipline’s pivot,” then partnered deeply with Rwanda, where “How Rwanda’s health minister changed everything” is a pivotal moment. It wasn’t a linear climb—”How Zipline almost died – twice” and “Why Zipline’s launch was a ‘complete disaster’” underline a tough truth: breakthrough products rarely arrive fully formed. What matters is the operating cadence that turns early chaos into repeatable reliability—especially when the stakes are measured in minutes and lives.

Scaling from 1 hospital to 5000 required more than product brilliance; it demanded systems thinking across logistics, compliance, safety, and community trust. That’s stakeholder management at its highest level. The product lessons are durable: anchor on outcomes, not artifacts; build reliability as a feature; and practice founder-led GTM where your credibility is on the line with customers and regulators. This is where first principles decision making beats benchmarking—particularly in novel categories where there are no playbooks to copy.

There’s also a hard-nosed operational takeaway in “The 10x hardware cost rule every founder should know.” My read: assume total cost of ownership will balloon once you account for manufacturing variability, support, redundancy, maintenance, and compliance. In product strategy, I treat those multipliers as design inputs, not afterthoughts. If the unit economics can’t survive these realities, the idea isn’t ready—no matter how elegant the prototype looks in a lab.

Across all of this, a few product management patterns stand out for me: build teams around outcomes vs output OKRs; hire for slope, not just intercept; make continuous discovery routine with real users (in this case, clinicians and health systems); and treat operational excellence as a product surface. When a mission is this consequential, culture becomes a safety system—and every leadership decision compounds into either speed with quality or speed with regret.

For leaders building in complex domains, this journey is a blueprint: pick problems that matter, hire “heat-seeking missiles for pain,” keep blind references non-negotiable, lead with first principles, and scale with responsibility. Do that well and even a “complete disaster” launch can become the inflection point of a category-defining company that flies 135 million autonomous miles and saves 17,000 lives per year.

March 12, 2026
Scaling Enterprise Sales from $0 to $3.5B: CRO Lessons, MEDDIC Mastery, and GTM Truths

I’ve led product organizations through multiple growth chapters, and the pattern is always the same: the tighter the alignment between product, sales, and marketing, the faster you scale. Reflecting on the journey of Chris Degnan — the first sales hire at Snowflake who spent 11 years helping scale the company from zero to $3.5 billion in revenue as its CRO while partnering with four different CEOs — I’m struck by how consistently the fundamentals win. The playbook isn’t mysterious; it’s disciplined execution, ruthless clarity, and a go-to-market strategy that matures with each revenue stage.

At $10M ARR, the CRO role is hands-on and founder-adjacent. You’re close to the product, running point on key deals, pressure-testing messaging, and building credibility with early customers. By $1B+, the job is organization design: segmentation, international expansion, forecast accuracy, enablement, recruiting, and cross-functional orchestration. The shift is from deal quarterback to system architect — standing up repeatable, auditable processes that produce reliable outcomes across regions, segments, and industries.

Sales leaders who can’t sell the product themselves don’t last. Whether you sit in product management leadership or run the field, you need to master discovery, speak the customer’s language, and translate use cases into value. That also means getting fluent in solutions engineering — understanding integrations, data paths, security, and the operational realities buyers live with. I’ve found this hands-on competence to be the fastest way to earn trust internally and externally, and to keep product strategy grounded in market truth.

The MEDDIC methodology is the foundation for every durable sales org — and, frankly, a founder’s best insurance policy. MEDDIC forces alignment on qualification criteria, from Metrics to Economic Buyer to Decision Process and Identifying Pain. When product and sales both operate to this standard, roadmap bets improve, marketing targets sharpen, and win rates climb. It’s not paperwork; it’s pattern recognition at scale.

High-output CROs obsess over the right numbers. Pipeline coverage by segment and stage; conversion rates through each gate; sales cycle length by use case; average selling price and discount discipline; consumption predictability when you have consumption SaaS pricing; and post-sale expansion velocity. The art is deciding which two or three metrics are the organization’s true north at a given stage — then designing enablement, compensation, and operating cadence around them.

On operating cadence, the week in the life at scale is predictable for a reason. Forecast reviews that surface risk early. Deal reviews that coach to MEDDIC depth, not activity theater. Enablement blocks to uplevel managers and ICs. Recruiting time — always. Customer roadshows to refine value proposition and product positioning. And standing meetings with product, marketing, and finance to keep the GTM motion, roadmap, and unit economics in sync.

Compensation is a force multiplier or a silent saboteur. Keep it simple, consistent, and aligned to the current motion. Early on, weight new logo acquisition and land quality; as you mature, balance new business with expansion, multi-product adoption, and healthy consumption. Guardrails matter — cap over-discounting, reward multi-threading, and avoid plans that create end-of-quarter cliff behavior. The best plans reinforce the behaviors you want your culture to scale.

Technical CEOs often underestimate how much narrative, segmentation, and process discipline great GTM requires. The handoff from founder-led GTM to sales-led growth is where many teams stall. My rule: prove one repeatable motion in one segment before you add complexity. Codify the buyer’s journey, instrument the funnel, and make sure product strategy and enablement move in lockstep.

Culture sets the ceiling. You have to find the fakers, manage-uppers, and passengers quickly — people who look busy but don’t move pipeline, who talk big but avoid accountability, or who ride the momentum of others. The mantra that has saved me endless time: “When there’s doubt, there’s no doubt”. Move fast, but with humanity; be clear on expectations, coach hard, and when it’s not a fit, make the change before the team does it for you.

Feedback is the operating system of a high-performing org. Leaders at every level need to be coachable — on message discipline, on forecast rigor, on how they develop people. I’ve benefited from straight talkers who hold a high bar, and I try to pay that forward. The fastest way to raise organizational IQ is to institutionalize feedback loops across sales, product, and marketing — from post-mortems to win-loss analysis to field-sourced roadmap reviews.

What separates exceptional ICs from the rest? Hunger, intellectual honesty, and a builder’s mindset. They qualify hard, align to customer metrics early, multi-thread to power and value, and partner tightly with solutions engineering. They don’t hide from gaps; they surface them, and they know exactly what they need from product, marketing, and leadership to win.

Executive teams that scale share a few traits: crisp segmentation decisions, single-threaded ownership for outcomes, and healthy conflict that resolves into commitment. Dysfunction, by contrast, looks like metrics roulette, opaque decision-making, and a tolerance for exceptions that become precedent. Make the rules explicit and the exceptions rare.

Leaders like Frank Slootman have popularized intensity, speed, and focus — and there’s real power there when paired with clarity and data. The lesson I carry forward: move fast on people decisions, keep the message simple, and measure what matters. Equally important is knowing where that approach can backfire — when speed outruns learning, or when pressure erodes cross-functional trust. The best operators balance urgency with systems thinking.

Most AI companies will face a go-to-market reckoning. Model quality won’t save a weak motion. The winners will articulate a hard-nosed ROI, solve specific workflow pain, address data governance and security head-on, and show measurable lift — not demo dazzle. In other words, the same fundamentals apply; the stakes and scrutiny are just higher.

If you’re building or rebuilding your revenue engine, start here: define your ideal customer profile and segmentation with ruthless clarity; adopt MEDDIC and teach it across product and sales; align compensation to today’s motion; instrument the funnel and inspect it weekly; and cultivate a culture where feedback is fuel. Do that, and the path from $0 to $3.5B stops feeling like mythology — and starts looking like math.

February 26, 2026
Long-Horizon Company Building: How to Operate for Decades
You are looking at a roadmap full of credible near-term work, yet none of it seems likely to change your company’s position. The team is busy, customers are asking for improvements, and every investment has a reasonable explanation. What is missing is a clear connection between today’s choices and the company you want to become.

Long-horizon company building solves that problem only when it changes how you allocate capital, sequence capabilities, learn from customers, and stop work. A 25-year ambition is not permission to wait longer for results. It is a decision filter that helps you distinguish compounding investments from activity that merely fills the next planning cycle.

Choose a problem that becomes more defensible with time

Not every company should play a decades-long game. Time does not rescue weak demand, an undifferentiated product, or a market whose underlying problem is disappearing. A long horizon is useful when the work required to serve customers creates assets that become more valuable as they accumulate.

Before you commit to a long-horizon strategy, test the problem against a few concrete conditions:
- The pain is structural. Customers are constrained by an enduring workflow, infrastructure dependency, procurement model, or service failure. The opportunity does not depend entirely on a temporary technology cycle.
- Frustration and switching costs are both high. Switching costs alone protect incumbents. Frustration alone can produce shallow demand for a convenient feature. When customers are dissatisfied but cannot change easily, a substantially better end-to-end experience can open a durable market.
- The solution requires cumulative capability. Reliability knowledge, operational data, installation expertise, distribution, hardware, service operations, or customer trust should improve with continued use. If a new entrant can reproduce your advantage quickly, waiting longer will not make the business stronger.
- The first product creates credible adjacencies. Expansion should follow the same customer, capability base, or service promise. A list of unrelated markets is not a platform strategy.
- The customer outcome can support the business model. The way you charge should reinforce the result customers buy, rather than reward complexity they would prefer to avoid.
The sharpest test is simple: explain why the company should be structurally better after years of serving customers. Your answer must identify a mechanism. More telemetry may improve diagnosis. More deployments may reduce installation risk. Deeper workflow integration may increase the value of adjacent services. Trust may lower the friction of adopting the next product. Merely having more customers or more features is not enough.

A useful thesis takes this shape: for a specific customer, a costly problem will persist because of a structural constraint; repeatedly building a named capability will improve a defensible advantage; controlling certain interfaces is necessary to deliver the promise; and observable evidence will tell you when the thesis is weakening.

If you cannot complete that logic without relying on market size, ambition, or executive conviction, you do not yet have a long-horizon strategy. You have a long-range hope.

Convert a 25-year belief into present-day decisions

A decades-long horizon should not produce a decades-long roadmap. The farther out you look, the less credible feature-level precision becomes. Preserve the direction while making the route explicitly revisable.

Separate your strategy into three layers:
- Enduring commitments: the customer you serve, the problem you believe will remain important, the experience you intend to make possible, and the principles you will not trade away casually.
- Revisable hypotheses: the product architecture, distribution motion, ownership boundary, pricing model, and capability sequence that currently appear most likely to deliver the promise.
- Disposable work: features, prototypes, internal systems, campaigns, and implementation choices. These deserve no protection beyond the evidence they produce.
This separation prevents two common errors. The first is strategic thrashing: changing the destination whenever a current bet disappoints. The second is strategic stubbornness: defending a failed implementation because it has been wrapped in the language of mission.

Meter provides a useful example of the distinction. The company maintained its commitment to a full-stack networking service while spending more than four years in early research and development. It also discarded about a year of operating-system work. The durable thesis survived; a costly implementation did not. That is what conviction looks like when it remains accountable to learning.

At each planning cycle, require every major initiative to answer four questions: Which lasting capability will this build? What customer evidence should it produce? What finding would cause you to reshape or stop it? What are you deliberately declining so the investment receives enough attention?

The stop condition matters most. Without one, patient capital quietly becomes protected capital. Teams learn to explain delays instead of testing assumptions. Write the condition while enthusiasm is high, before sunk costs and personal identity enter the decision.

Key takeaways
- Use a long horizon to define durable commitments, not detailed forecasts.
- Fund work that compounds a named capability or reduces a consequential uncertainty.
- Protect the customer problem and company promise, not the current implementation.
- Give every major bet observable evidence and an explicit stop condition.
- Treat abandoned work as a valid strategic outcome when it prevents a larger misallocation.
Own only the stack required to keep the promise

Vertical integration is neither inherently bold nor inherently wasteful. It is justified when a layer you do not control repeatedly prevents you from delivering the outcome customers believe they purchased.

Start with the promise, not the architecture. Map the complete path from customer intent to customer outcome:
- How the customer evaluates and buys the product
- How the product is installed, configured, and activated
- Which interfaces determine performance and reliability
- What telemetry reveals failure before or after the customer notices
- How support diagnoses and resolves a problem
- Which service commitment makes the outcome commercially credible
Mark every point where an external dependency can break the promise. Then ask whether tighter integration would materially improve the experience and whether the capability will compound across customers or future products. Own a layer when both answers are strong. Keep partnering when the dependency is replaceable, the layer is genuinely commodity-like, or internal ownership would add cost without improving the customer outcome.

This prevents full-stack ambition from turning into organizational vanity. Building hardware, software, installation operations, support tooling, and service delivery at once creates many ways to fail. The burden of proof belongs with the added ownership. Each new layer should remove a specific failure mode, improve a measurable part of the promise, or unlock a strategically important product that would otherwise remain impossible.

Physical-product teams should also treat geography as part of the operating design. When design, manufacturing, and iteration depend on one another, physical proximity can compress feedback loops. Meter used Shenzhen in this way during its development. The general lesson is not that every hardware company needs the same location. It is that organizational geography should follow the bottleneck: put the people making interdependent decisions close enough to learn at the speed the product requires.

The business model belongs in the same analysis. If customers want an outcome but must assemble vendors, equipment, installation, and support themselves, packaging the complete experience as a service can reduce complexity and clarify accountability. Service commitments then become part of the product, not language added after the product is built. The company earns recurring revenue by continuing to deliver the outcome, which aligns incentives more closely than a transaction that ends when equipment changes hands.

Distribution should reinforce learning during the early stages. A direct sales motion gives product and commercial leaders access to the buyer’s language, objections, procurement constraints, implementation concerns, and definition of value. That access is especially important when you are trying to establish seller-market fit: the ability to identify the right buyer, explain the value consistently, navigate the buying process, and deliver what was sold.

Before adding channel distance, verify that target buyers recognize the same problem, objections fall into understandable patterns, sales commitments survive the implementation handoff, and the economics support the promised service. A channel can scale a repeatable motion. It cannot repair one that the company does not yet understand.

Replace planning theater with a customer-learning system

Removing OKRs does not create focus. It removes one alignment mechanism. If you do not replace it with a visible decision system, priorities will depend on executive proximity, persuasive storytelling, and whichever escalation arrived most recently.

A lightweight operating system still needs a few explicit artifacts:
- A strategic narrative: the customer problem, the long-horizon thesis, the current constraint, and the choices the company is making because of them.
- A primary customer-value measure: evidence that the promised outcome is actually occurring, not merely that work shipped.
- Guardrails: reliability, service, economics, or trust conditions that must not deteriorate while the primary outcome improves.
- An unhappy-customer ledger: a shared record of broken promises, stuck use cases, escalations, and gaps between what was sold and what was delivered.
- A decision log: the assumption behind each consequential choice, the evidence available at the time, the owner, and the condition for revisiting it.
The unhappy-customer ledger is often more useful than another aggregate dashboard. A satisfaction score compresses many experiences into one number. An escalation exposes the precise boundary where your product, service, sales process, or ownership model failed.

For every serious case, capture the customer’s intended outcome, the point at which progress stopped, the expectation that was violated, the immediate resolution, and the systemic change required. Classify that change as product, operations, sales, support, or ownership-boundary work. Then look for recurring failure modes across cases.

Do not let this become a larger support queue. Closing the individual ticket is necessary, but the strategic value comes from removing the class of failure. If customers repeatedly struggle during installation, the answer may be a better workflow, different telemetry, a narrower promise, or ownership of an interface that has been treated as someone else’s problem.

This system also clarifies empowerment. A product team should know the outcome it owns, the constraints it must respect, the decisions it can make independently, and the conditions that require escalation. Empowerment without a clear outcome produces local optimization. Authority without proximity to customer evidence produces slow, brittle decisions.

The same clarity applies to performance problems. A company cannot preserve a long horizon while allowing unresolved role or behavior gaps to consume the team’s attention. Define the gap, the expected standard, the support available, the decision owner, and the process for reaching a fair conclusion. Move quickly toward clarity, while still following the appropriate people process. Delayed ambiguity is not patience.

Make patience accountable in your next strategy review

Long-horizon work will contain periods when visible output understates real progress. Research, infrastructure, reliability, manufacturing, and operational design may need to mature before customers see the complete benefit. The leadership challenge is to distinguish that legitimate incubation from drift.

Patience is working when the core customer thesis remains supported, important uncertainties are being resolved, a reusable capability is getting stronger, and customer failures are becoming better understood or less frequent. The dates may move, but the quality of evidence improves.

Drift looks different. Milestones move without producing new knowledge. Teams defend work by describing its difficulty or the effort already invested. The same customer failures return without a systemic response. Adjacent products receive attention before the original promise is dependable. Leadership keeps adding resources because it has not defined what would justify stopping.

Review the portfolio by decision, not by project status. Continue work that compounds a necessary capability. Reshape work when the thesis remains sound but the current method is failing. Stop work whose original assumption no longer holds. Keep adjacent opportunities separate until the core business has earned the capacity to pursue them.

You can run the review with the following sequence:
1. Write the customer promise in language a buyer would recognize.
2. Name the structural reason the problem should remain worth solving.
3. Identify the capability that should become more valuable as the company learns.
4. Map the interfaces, operations, and commercial dependencies that can break the promise.
5. Examine recent unhappy-customer cases for repeated failure modes.
6. For every major investment, write the evidence expected and the condition that would cause a change of course.
7. Remove work that neither improves the current promise nor builds a required future capability.
8. Assign the next consequential decision to a named owner with access to the relevant customer evidence.
Do not leave that review with a more elaborate long-range deck. Leave with fewer bets, clearer ownership, explicit learning goals, and at least one piece of work you are prepared to stop.

At your next planning meeting, ask which current investment will make the company structurally better at solving its chosen problem. If nobody can name the capability, the evidence, and the customer promise it serves, pause the work before time turns activity into strategy by accident.

References
- Shivam.Consulting Blog — Playing the 25-Year Game: Rethinking Networking, Ditching OKRs, and Owning the Full Stack
December 10, 2025

How to Scale Enterprise Sales Without Breaking Product Strategy

You have enough mid-market traction to believe enterprise should be next. Large accounts enter the pipeline, ask for security reviews, role controls, auditability, service commitments, and roadmap exceptions, then take far longer to close than expected. Sales wants more product support and more headcount. Product sees a queue of one-off requests. Leadership cannot tell whether the constraint is the product, the sales motion, or both.

The decision in front of you is not simply whether to hire more reps. It is whether you have built an enterprise deal that a capable rep can reproduce. You can answer that by testing four parts of the system: enterprise readiness, product-market-sales fit, ICP discipline, and capacity. Fix them in that order, and sales hiring becomes an investment in a working motion instead of an expensive attempt to discover one.

Treat enterprise deal friction as a product diagnostic

A stalled enterprise deal is often labeled a sales execution problem because the failure appears in the pipeline. The underlying constraint may have been created much earlier. Enterprise buyers need more than a useful product. They expect architecture that can withstand their operating environment, deep security and compliance support, robust role-based access control, data governance, audit trails, predictable service levels, and a credible path through implementation and change management.

They also need enough evidence to defend the purchase internally. A persuasive demo cannot substitute for a precise value proposition, relevant customer references, a clear implementation plan, and an answer to a basic competitive question: who do you beat, for which customer, and why?

That is why you should classify enterprise friction before committing to a remedy. Do not let every objection become a feature request, and do not let every loss become a coaching problem. Look for the pattern behind the objection.

Pattern you observe	Likely constraint to investigate	What to do next
Qualified opportunities repeatedly stop during security, governance, or legal review	Enterprise product readiness	Turn recurring requirements into a readiness backlog with an owner, a reusable evidence package, and a clear completion test.
Pilots generate positive user feedback but do not produce a buying decision	Business proof, stakeholder alignment, or change management	Define the decision criteria, economic outcome, buyer group, rollout plan, and procurement path before the pilot begins.
Deal quality and cycle length vary sharply by rep	Qualification, positioning, or enablement	Standardize the ICP, discovery questions, proof package, objection handling, and stage-exit criteria.
Customers close but do not retain or expand as expected	Product value, customer fit, or adoption	Review retention and expansion by segment, then inspect whether the promised outcome was achieved after implementation.
One prestigious account requires a large, account-specific roadmap detour	ICP discipline and exception governance	Measure the reusable value and roadmap displacement explicitly. Decline the work if it forces the product away from its native strengths.

The table gives you hypotheses, not automatic verdicts. Validate them by tracing recent opportunities from discovery through implementation. A deal that died in procurement may still have entered the pipeline with a weak business case. A security objection may conceal low executive urgency. The purpose of classification is to identify the first broken link, not the final place where the deal stopped moving.

Build an enterprise readiness contract across functions. Product and engineering own architecture, access controls, auditability, governance, extensibility, and reliability. Security and compliance own the evidence buyers need to evaluate those capabilities. Product marketing and sales own the value proposition and competitive proof. Customer success and solutions engineering own implementation, adoption, and change-management readiness. Leadership owns the exception policy when a deal asks the company to depart from its strategy.

Test this contract with lighthouse customers that closely match your intended market. A friendly pilot can confirm that users like a workflow while avoiding the hard parts of an enterprise purchase. A useful lighthouse account exercises the full system: technical validation, security review, procurement, implementation, adoption, and proof of value. The objective is not merely to secure a logo. It is to learn whether the offer survives the buying process you intend to scale.

Prove product-market-sales fit before adding headcount

Product-market fit and product-market-sales fit answer different questions. Product-market fit tells you that the product creates meaningful value for a customer. Product-market-sales fit tells you that your company can repeatedly find the right customer, communicate that value, navigate the buying process, close the deal, and retain or expand the account.

The distinction matters because headcount amplifies the system you already have. If the motion is repeatable, new sellers can extend it. If the motion still depends on founder intuition, bespoke promises, or product heroics, new sellers create more variance, more roadmap pressure, and a larger pipeline of deals the company is not prepared to win.

I would use five signal groups to evaluate repeatability:

Win rate by segment: Separate results by ICP, use case, company profile, and motion. A blended win rate can hide a strong fit in one segment and persistent losses in another.
Sales-cycle time: Measure time by stage, not only the total. This shows whether discovery, technical validation, security, procurement, or contracting is the recurring bottleneck.
Ramp time to a first deal: Track when a new rep can independently qualify, position, and advance the right opportunity. A first deal closed through heavy founder intervention is not proof of rep productivity.
Multi-threading depth: Inspect whether the opportunity includes the user champion, economic buyer, technical and security stakeholders, and procurement. A single enthusiastic contact is interest, not enterprise consensus.
Retention and expansion: Review net revenue retention and the percentage of customers that expand within two quarters. The sale is not repeatable if the value promised during evaluation fails to materialize after purchase.

Do not turn these into one composite score. Each signal diagnoses a different part of the motion. A healthy win rate with weak retention points toward customer fit, product value, implementation, or expectation-setting. Strong customer outcomes with poor win rates may point toward positioning, proof, qualification, or segmentation. Long cycles concentrated in technical review suggest a different intervention from long cycles caused by an absent economic buyer.

Use a consistent diagnostic loop for one clearly defined segment:

Define the ICP, use case, required outcome, buying group, and disqualifying conditions.
Choose a cohort of opportunities that entered the motion under comparable qualification rules.
Review win rate, stage duration, multi-threading, rep ramp, retention, and two-quarter expansion without blending other segments into the result.
Inspect representative wins, losses, and stalled deals to explain the pattern behind the metrics.
Classify the primary constraint as product value, enterprise readiness, positioning, enablement, segmentation, or execution.
Change one part of the system, then observe the next comparable cohort before declaring the motion fixed.

This discipline prevents a familiar cycle: sales asks for features, product ships them, the deals remain stuck, and leadership responds by adding pipeline or people. The intervention should follow the diagnosis. Ship when the product cannot deliver the required outcome. Improve enterprise foundations when buyers cannot approve or operate it safely. Sharpen the message when customers receive value but prospects cannot understand why it matters. Rework segmentation when success is concentrated in a narrower market than the company is pursuing.

Before approving a major increase in sales capacity, verify that a seller other than the founder can identify the right account, run discovery, explain the differentiated outcome, assemble the buying group, use a reusable proof package, and advance the account without creating an unplanned product strategy. You do not need perfect metrics. You do need enough consistency to know which constraint the new headcount is intended to remove.

Use the ICP to protect the roadmap and sharpen the reason you win

An ICP is useful only when it changes decisions. If every large opportunity qualifies because the contract might be valuable, the ICP is a marketing description rather than an operating constraint.

Make the profile specific enough to govern qualification and product trade-offs. It should identify the customer characteristics that matter, the urgent job being solved, the operating and technical environment, the expected outcome, the buying group, the conditions that create urgency, and the conditions that should disqualify the account. A segment name such as enterprise software is not an ICP. It does not tell a rep which account to pursue or a product leader which request deserves roadmap capacity.

When an opportunity produces a major request, classify it before estimating the work:

Enterprise foundation: Is this a baseline capability, such as governance, auditability, reliability, or access control, that the target market broadly requires?
Native ICP need: Does it strengthen the core outcome for many customers you deliberately want to serve?
Reusable extension: Can it be handled through configuration, extensibility, or a shared platform capability without distorting the core product?
Account-specific exception: Is it valuable mainly to this buyer, with ongoing support and complexity that the headline contract does not reveal?

The fourth category deserves an explicit decision, especially when the account is prestigious. A marquee logo does not automatically create a market. If its requirements force unnatural changes, consume disproportionate engineering capacity, or weaken the product for the customers who already value it, walking away can preserve more long-term enterprise value than closing the deal.

If leadership wants to make an exception, write down the bet. State the expected strategic value, the roadmap work displaced, the number and type of ICP customers that could reuse the capability, the ongoing implementation and support burden, and the assumption that would cause you to stop. This turns logo enthusiasm into a reviewable allocation decision.

ICP discipline also makes competitive positioning more precise. Enterprise products need points of parity and a decisive reason to win. The points of parity make the offer eligible: buyers may require security, reliability, administrative controls, data governance, and procurement readiness before they will seriously evaluate it. Those capabilities matter, but they may not determine the final choice.

The reason to win should be a binary, testable differentiator. It could be meaningfully faster time to value, a step-change in accuracy, or an economic model that changes the cost of achieving the outcome. The important word is testable. A buyer should be able to design an evaluation in which your claimed advantage either appears or it does not.

Force the positioning into one sentence: For this ICP, facing this urgent job, the product produces this observable outcome under these conditions because of this capability. Then ask a harder question: if that outcome disappeared from the evaluation, would the buying decision change? If not, you have described a benefit, not a decisive differentiator.

Build the proof package around that claim. Include relevant customer references, the evaluation criteria, the evidence required to verify the outcome, a map of common objections, the implementation path, and the conditions under which the claim does not apply. This gives sales something more useful than a broad feature comparison. It gives the buyer a defensible reason to choose.

Scale a capacity-driven sales system, not a collection of deals

Plan backward from productive capacity

A capacity-driven plan connects the revenue goal to productive sellers, qualified pipeline, territory potential, conversion, and time. It does not assume that hiring a rep instantly creates quota capacity or that a generic pipeline-coverage ratio applies equally to every segment.

Start with the capacity that can actually sell during the planning period. Separate productive reps from people who are still ramping. Use your observed ramp time, segment-level win rate, sales cycle, and deal profile to estimate which pipeline can mature in the period. If those observations are unstable, expose the uncertainty instead of hiding it inside an aggressive target.

Calibrate territories to ICP density and buying intent, not visual symmetry. Two territories with the same number of named accounts may offer very different opportunity if one contains more customers with the triggering conditions, technical fit, and urgent job your motion requires. When territory potential is weak, coaching the rep harder does not create market demand.

Your capacity review should answer concrete questions:

How much quota is carried by sellers who are currently productive, and how much depends on future ramp?
How much qualified pipeline matches the ICP and can realistically complete the remaining buying stages inside the period?
Which stage consumes the most time, and is its constraint sales capacity, technical readiness, security review, procurement, or executive alignment?
Does each territory contain enough relevant accounts and intent to support the assigned capacity?
Can solutions engineering, implementation, and customer success support the volume that sales is expected to close?

This is also why qualification quality matters more than a large top-line pipeline number. A non-ICP opportunity can occupy discovery, solutions engineering, product, legal, and executive time while contributing little probability of a repeatable win. Make disqualification visible as good judgment, not failed selling.

Encode the motion before asking people to reproduce it

A scalable playbook does not need to become a bureaucracy. It needs to preserve the decisions that make the motion work. At minimum, a seller should have:

A precise ICP and explicit disqualifiers.
A problem and outcome narrative tailored to that ICP.
Discovery questions that expose urgency, current cost, decision criteria, and buying constraints.
A stakeholder map covering the user, champion, economic buyer, technical and security reviewers, and procurement.
The binary differentiator and the evidence used to test it.
A reusable security, governance, and procurement package.
Objection handling tied to real failure modes rather than generic rebuttals.
An implementation and change-management path that makes the promised outcome credible.
Consistent pipeline stages and exit criteria so forecasts represent buyer progress rather than seller optimism.

Enablement is working when new reps use a consistent talk track, handle predictable objections without inventing promises, and know when to disqualify. Completion of training is an activity measure. Independent execution of the motion is the outcome.

Founders still need to learn the sale before this handoff. The purpose is not to make the founder the permanent closer. It is to encode customer truth into the product, positioning, qualification rules, and proof. The handoff becomes safer when the motion can be explained, observed, and coached instead of residing in the founder’s intuition.

Hire a sales builder and test how that person makes decisions

Your first senior sales leader is a leverage point because the person will shape both the team and the operating system. Look for pattern recognition in your specific segment, a builder’s ability to create useful process without unnecessary bureaucracy, rigorous pipeline hygiene, and the ability to work with product on where the company wins and why.

Past titles and quota results do not reveal enough. Use scenario loops that expose judgment:

Give the candidate an attractive but non-ICP opportunity and ask how it would be qualified or disqualified.
Present a late-stage deal stalled across several stakeholders and ask how the candidate would identify the real constraint.
Ask for a first 90-day plan that separates diagnosis, playbook construction, pipeline inspection, hiring, and execution.
Show two reps describing the product differently and ask how the candidate would coach toward a consistent message without erasing useful learning.
Ask how product feedback would be separated into enterprise foundations, repeatable ICP needs, positioning problems, and one-off account requests.

Listen for sequencing as much as content. A leader who wants to hire a large team before inspecting the segment, pipeline, and motion may be importing a scaling playbook into a company that is still discovering how it wins. A builder should be able to say what must be learned before each additional investment.

Keep product, sales, and delivery in one operating rhythm

Enterprise GTM degrades when sales reviews pipeline, product reviews output, and customer success reviews adoption in separate systems. The customer experiences one journey. Your operating rhythm should connect the promise made during evaluation to the value delivered after launch.

A weekly operating review should focus on the current constraint. Ask whether the customer’s core job was solved, whether sales and success can prove the outcome with a repeatable story, which deals are exposing a shared readiness gap, and whether the next action belongs to product, enablement, qualification, or implementation. End with a decision, an owner, and the evidence that will show whether the decision worked.

Use outcome-based objectives so teams do not confuse shipped features, completed training, or created pipeline with customer value. Product trios can keep discovery, design, and engineering close to customer evidence. Continuous delivery and deployment-frequency measures can show whether the organization has enough learning and delivery cadence, but speed cannot come at the expense of the reliability enterprise customers expect.

If you are scaling several products, give each product line clear ownership of its roadmap, customer outcome, positioning, and GTM target. Anchor those lines to shared platform capabilities for identity, data, and extensibility. This preserves the focus of a small business unit while preventing every product from rebuilding the enterprise foundation independently. Product managers then operate as owners of outcomes and business-like metrics, not merely coordinators of feature delivery.

The standard for each product should remain demanding: it must be able to win on its own merits. Bundling can improve distribution, but it should not conceal a weak value proposition. If a product cannot articulate and prove why its intended customer would choose it, sharpen the offer or stop expanding its GTM capacity.

Key takeaways

Enterprise sales friction often reveals a readiness gap in architecture, security, governance, proof, implementation, or change management. Classify the gap before prescribing more sales activity.
Product-market fit proves customer value. Product-market-sales fit proves that your company can reproduce discovery, purchase, delivery, retention, and expansion.
Measure win rate by segment, stage-level cycle time, ramp to a first independent deal, multi-threading depth, net revenue retention, and expansion within two quarters.
Let the ICP govern qualification and roadmap trade-offs. A prestigious account is still a poor bet if winning it requires product changes that do not compound across the intended market.
Meet enterprise points of parity, then win with one testable differentiator that materially changes the customer’s decision.
Plan from productive capacity, qualified pipeline, observed conversion, territory intent density, and the time remaining in the buying cycle. Do not treat newly hired reps as instant capacity.
Hire a sales leader who can build the motion, maintain pipeline discipline, disqualify intelligently, and partner with product on where the company wins.

Start with one enterprise segment and one recent opportunity cohort. Classify every win, loss, and stall across readiness, value, ICP, positioning, enablement, and execution. Pick the first shared constraint, assign one owner, and define the evidence you expect to change. Add sales capacity only when you can name the working motion it will reproduce.

References

Shivam.Consulting Blog — Scaling 16 ‘Startups Within a Startup’: My Enterprise GTM, PMF, and Sales Hiring Playbook

November 19, 2025

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

I’ve spent my career building products and teams that I intend to steward for the long haul, and I’m drawn to founders who treat company-building as a craft you can practice forever. In this analysis, I break down a journey that crystallizes what it takes: going from a teenage wholesale hustle to an API-first healthcare clearinghouse, and in the process, learning why execution isn’t a moat, why venture capital is “going pro,” and how “eating glass” can become a durable advantage.
Here’s the arc that anchored my thinking: a founder who, at 16, turned $2,500 into a wholesale empire; later bootstrapped a wildly profitable auto-parts business; then sold it to tackle “the most complicated problem” he’d ever encountered: business-to-business transaction exchange. He spent years building EDI infrastructure, threw away the entire codebase eight times, and found extraordinary traction in healthcare. The company recently raised a $70M Series B co-led by Stripe and Addition. The throughline is a consistent, high-agency approach to product management and go-to-market strategy, guided by first principles decision making.
The first customer is often the trickiest—not because demand doesn’t exist, but because the product’s value proposition, points of parity, and competitive differentiation are still coalescing. I push teams to do founder-led GTM early, speak in the user’s language, and orchestrate high-signal conversations that expose real switching costs. That’s how we avoid mistaking polite interest for product-market fit.
Bootstrapping forces rigor, but it also means being “constrained by capital.” There’s a ceiling to the speed at which you can iterate, validate, and scale. Venture capital, in the right context, is like “going pro”: you trade a bit of optionality for time, talent density, and a faster feedback loop. I often see confusion between ownership vs. control; structurally, you can design for alignment while still moving with the urgency a competitive market demands.
One theme I return to with my own teams: execution is never actually a moat. Processes can be copied. Culture can be mimicked superficially. What can’t be easily replicated is the willingness to do the unglamorous, compounding work—what the founder here called “eating glass.” It’s the daily discipline of simplifying the system, instrumenting the edge cases, and standing up operational excellence that compounds into true competitive differentiation.
When product-market fit hits in enterprise infrastructure, it can feel like “the snake swallowing a deer.” Capacity, process, and architecture are stretched to their limits all at once. I’ve experienced the same pattern: everything slows down so the organization can re-architect for scale. The trick is to make those constraints visible—measure service levels, queuing, and error budgets like you would in a production system—so you’re not flying blind.
Some of the strongest product-management instincts I’ve seen borrow from discount retail and Toyota. From discount retail, we learn to obsess over unit economics, operational throughput, and ruthless simplification. From the Toyota production system, we adopt Kanban / TPS (Toyota), continuous improvement, and respect for constraints. In software terms, this becomes fast deployment frequency, small batch sizes, and defect prevention at the source—because “All software is a cascade of miracles.”
Scaling decision-making is where most teams stall. I favor clear ownership, lightweight written narratives, and a bias for first principles decision making over committee compromise. That structure lets high-agency individuals move quickly while keeping cross-functional stakeholders aligned on outcomes vs output OKRs. It’s how you build empowered product teams without sacrificing focus.
Hiring is where philosophy becomes practice. I resonate with the onboarding mantra “everything’s your fault now”—not as blame, but as an invitation to own outcomes end to end. I look for high-agency people who demonstrate systems thinking and the capacity to simplify. Manager hiring should lag role clarity; bring in managers when coordination overhead is the limiting factor, not when it merely feels uncomfortable.
Longevity comes from founder-approach fit as much as product-market fit. Build a company you don’t want to leave by aligning operating cadence, decision rights, and cultural norms with how you actually work best. Maintain conviction in unconventional practice when the evidence supports it, while remembering that “Reality has a surprising amount of detail.” The more I zoom in on the real work—interfaces, edge cases, workflows—the more the right design emerges.
In healthcare EDI, that realism matters. HIPAA overview (HHS) sets the compliance baseline. Payer integrations with Aetna, Blue Cross Blue Shield, and Cigna demand reliability and deep domain fidelity. Cloud and back-office ecosystems—from AWS and NetSuite to Slack, Microsoft Teams, Zapier, and Clay—shape the surrounding workflow. Lessons from Amazon, Target, Walmart, and Costco inform operational rigor; supply chain analogies from Ford Motor Company and GM clarify interface contracts. Porter’s five forces helps frame market structure; perspectives from Jeff Bezos and Peter Thiel sharpen strategic posture.
If you’re building for the long run, here’s the blueprint I use with product leaders: validate painfully specific jobs-to-be-done before you scale; prefer founder-led GTM until messaging closes the intent-to-adoption gap; instrument throughput and quality like a production system; invest in people who treat ambiguity as a chance to lead; and don’t confuse speed with hurry. When the “snake swallowing a deer” moment arrives, re-architect deliberately, protect your margins, and let operational excellence carry you from product discovery to durable product-led growth.
References and resources: Aetna: https://www.aetna.com/, Amazon: https://www.amazon.com/, AWS: https://aws.amazon.com/, Blue Cross Blue Shield: https://www.bcbs.com/, Change Healthcare: https://www.changehealthcare.com/, Cigna: https://www.cigna.com/, Clay: https://www.clay.com/, Costco: https://www.costco.com/, Ford Motor Company: https://www.ford.com/, GM: https://www.gm.com/, HIPAA overview (HHS): https://www.hhs.gov/hipaa/index.html, Jeff Bezos: https://x.com/JeffBezos, Kanban / TPS (Toyota): https://global.toyota/en/company/vision-and-philosophy/production-system, Microsoft Teams: https://www.microsoft.com/microsoft-teams, NetSuite: https://www.netsuite.com/, O’Reilly Auto Parts: https://www.oreillyauto.com/, Peter Thiel: https://x.com/peterthiel, Porter’s five forces: https://www.isc.hbs.edu/strategy/pages/the-five-forces.aspx, “Reality has a surprising amount of detail”: https://johnsalvatier.org/blog/2017/reality-has-a-surprising-amount-of-detail, Slack: https://slack.com/, Stedi: https://www.stedi.com/, Summit Racing: https://www.summitracing.com/, Target: https://www.target.com/, Walmart: https://www.walmart.com/, Zapier: https://zapier.com/

November 6, 2025
Go Hard Early: Enterprise AI Lessons That Built Serval’s Magical IT Automation Agents

Go hard early is more than a mantra—it’s a product strategy. When I study the most durable enterprise companies, I see the same pattern: you win by shipping fast, obsessing over the customer’s day-to-day pains, and delivering consumer-quality experiences to business buyers. That lens is exactly why Serval’s recent momentum caught my attention and why the lessons behind it matter for every product and IT leader building in AI.

Jake is the founder and CEO of Serval, an AI-driven IT automation and service management platform that just raised $47M in Series A funding this week. Before founding Serval, Jake spent over five years at Verkada, where he led multiple products from 0-1 and helped scale the company across hardware and software. His years at Verkada taught him that winning in enterprise means delivering consumer-quality experiences to business buyers — a lesson that shapes how Serval turns complex IT automation into something that feels magical.

From my vantage point, the most counterintuitive lesson here is the power of building “in existing categories.” Rather than inventing a new market, the better move can be to redefine expectations inside a known one—where buyers, budgets, and success criteria already exist. That’s how you compress sales cycles, build trust rapidly, and create a wedge for product-led growth without boiling the ocean.

Another playbook thread I admire: turning “hard mode” into a moat. The teams that lean into gnarly integrations, real workflow depth, and enterprise-grade reliability end up compounding an advantage that’s very hard for fast followers to copy. That mindset shows up in Serval’s platform strategy and, more importantly, in how they translate complex IT work into something that feels intuitive on day one and powerful on day 100.

Customer intimacy sits at the center of that strategy. The customer interview question that unlocked the IT buyer’s hidden pain points is the kind of move I try to operationalize across product trios and forward-deployed teams. When you ask not just, “What do you do?” but, “What do you do when everything breaks?” you surface the real constraints: shadow runbooks, brittle scripts, brittle processes, and the political friction that slows down response times. That’s where durable value—and competitive differentiation—lives.

How Serval’s automation builder uses AI to generate code-based workflows is a particularly smart architectural choice. Code-first doesn’t mean hard-to-use; it means source-controlled, interoperable, and shareable across teams—exactly what IT leaders want when automation moves from side project to system of record. Tie that to agentic orchestration and you get reliable automations with clear observability, safety rails, and the ability to scale without collapsing under edge cases.

I’m also a believer in redefining engineering and PM roles with forward-deployed engineers. When engineers partner directly with customers, discovery accelerates, prioritization sharpens, and product bet quality improves. You avoid ping-ponging requirements through layers, and you raise the hiring bar for true product creators who can think in outcomes, not just output.

Keeping the hiring bar high in an AI-native startup isn’t optional—it’s existential. The best teams screen for candidates who can reason from first principles, ship quickly with taste, and articulate the value proposition in plain language. The ultimate hiring litmus test is whether someone can improve the product on day one by clarifying a user journey, simplifying a workflow, or tightening a metric that actually matters.

There’s also Why there’s a “land grab” moment right now in enterprise AI. Incumbents are strong on breadth but often slow to re-architect for AI-native workflows. New entrants that show up with opinionated defaults, pragmatic security, and crisp buyer narratives can establish points of parity quickly while extending into true points of differentiation. That’s the window to seize—especially when building for mid-market and enterprise.

Here are the core themes I took away and how I translate them into practice across product roadmapping and sprint planning, product discovery, and go-to-market strategy.

Why building “in existing categories” can be more powerful than creating new ones. Use the market’s mental models, measure against known alternatives, and win by delivering a meaningfully better experience—not by forcing buyers to invent new procurement paths.

The lessons from Verkada that shaped Serval’s platform strategy. Treat UX polish as a strategic asset, make setup effortless, and let power users go deep without friction. Consumer-grade quality is not a veneer; it’s a trust accelerator in enterprise.

The customer interview question that unlocked the IT buyer’s hidden pain points. Go beyond happy-path discovery. Ask about the 3 a.m. moments, the panic buttons, and the messy handoffs—then design for those first.

How Serval’s automation builder uses AI to generate code-based workflows. Pair AI generation with reviewability, versioning, and safe rollbacks. Make it easy to see, test, and share what the agent is doing under the hood.

Redefining engineering and PM roles with forward-deployed engineers. Collapse feedback loops by putting builders where the problems are. It’s the fastest path to product-market fit lessons and real-world reliability.

Keeping the hiring bar high in an AI-native startup. Look for taste, speed, and ownership. Optimize for people who can both prototype with gen ai and ship production-hardened systems.

Why there’s a “land grab” moment right now in enterprise AI. Move quickly, but anchor on outcomes. Land with a wedge use case, expand with measurable value, and maintain clear points of parity while you deepen differentiation.

If you want to follow or explore the companies and leaders referenced, these links are a useful starting point.

LinkedIn: https://www.linkedin.com/in/jakestauch/

Twitter/X: https://x.com/jakeserval

LinkedIn: https://www.linkedin.com/in/brett-berson-9986094/

Twitter/X: https://twitter.com/brettberson

Website: https://firstround.com/

First Round Review: https://review.firstround.com/

Twitter/X: https://twitter.com/firstround

YouTube: https://www.youtube.com/@FirstRoundCapital

This podcast on all platforms: https://review.firstround.com/podcast

References:

Alex McLeod: https://www.linkedin.com/in/alexmcleodio/

Clay: https://www.clay.com

Cloudflare: https://www.cloudflare.com

Cursor: https://cursor.sh

Filip Kaliszan: https://www.linkedin.com/in/kaliszan/

Hans Robertson: https://www.linkedin.com/in/hansrobertson

Linear: https://linear.app

Okta: https://www.okta.com

Rippling: https://www.rippling.com

Serval: https://www.serval.com/

ServiceNow: https://www.servicenow.com

Verkada: https://www.verkada.com

Workday: https://www.workday.com

Timestamps and topic highlights for easy navigation and deeper study:

(02:25) Lessons from holding different product roles

(07:29) Turning “hard mode” into a moat

(10:49) The early days of Serval

(12:59) Scratching the founder itch

(14:57) Unconventional interview techniques

(17:47) Solving core interview challenges

(21:10) Planning the early product roadmap

(23:03) The surprising power of patience

(26:12) Serval’s impressive technical advantage

(27:35) Disrupting legacy incumbents

(31:13) Building for mid-market and enterprise

(33:35) Serval’s enduring roadmap

(36:08) How to sell to an existing market

(39:16) The evolving role software plays

(43:55) Building for AI that didn’t exist yet

(49:49) Serval’s forward-deployed engineers

(58:31) The hybrid PM-GM

(1:00:27) “You can over-prioritize”

(1:02:48) The unexpected value of panic buttons

(1:04:50) What Serval looks for in new talent

(1:07:01) The ultimate hiring litmus test

(1:13:59) Building out Serval’s go-to-market function

(1:16:31) The evolving IT market in 2025

My bottom line: build where budgets already live, ship with uncompromising UX, embed engineers with customers, and hold the line on talent. Do that, and you won’t just keep up with the enterprise AI “land grab”—you’ll define the standard others have to meet.

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

Building a startup is equal parts craft and discipline. In my product leadership work, I’ve honed a repeatable approach for going from raw idea to real traction—and I often cross-check that playbook against the battle-tested experience of leaders I respect. I frequently reference insights from Gagan Biyani, co-founder and CEO of Maven, a company that empowers the world’s experts to offer cohort-based courses directly to their audience.

After being early at 3 startups that achieved over $1 million in run-rate in their first six months of going live, Gagan has learned some valuable lessons and seen a wide range of outcomes — from Udemy going on to IPO in 2021, to Sprig shutting down in 2017.

When I’m generating startup ideas, I start with open-ended exploration and a rigorous “problem inventory.” I look for founder–market fit, persistent pain points, and market signals that indicate urgency and willingness-to-pay. I also study competition to spot under-served segments or a wedge where a differentiated product discovery approach can win. The most common mistakes I see aspiring founders make are solution-first thinking, overvaluing total addressable market over real problems, and staying in stealth too long instead of testing in the wild.

Validation is where discipline pays off. I rely on minimum viable tests to rapidly de-risk assumptions and avoid false positives. My process mirrors the spirit of his “Minimum Viable Testing Process.” I define falsifiable hypotheses, run one-channel traction experiments, test willingness-to-pay early, and favor concierge or manual workflows before writing heavy code. These tight, timeboxed sprints force clarity on product-market fit signals while keeping burn low and learning velocity high.

Once the signals look promising, execution becomes a game of thoughtful sequencing. I explore multiple business models in parallel (subscriptions, usage-based, hybrid) while keeping the core value proposition crisp. Early go-to-market is founder-led GTM by design; I talk to customers daily, tune messaging, and iterate on onboarding until activation and retention curves stabilize. On the product side, I prioritize outcomes over output, set clear guardrails for roadmapping and sprint planning, and instrument the product to learn from every user interaction.

Co-founder selection and operating cadence matter as much as the idea. I look for complementary skills, shared values, and a bias for transparent conflict resolution. Before committing, we pressure-test collaboration with small, high-stakes projects, align on decision-making frameworks, and codify roles, equity, and vesting. As the company grows, I revisit these agreements to keep pace with evolving responsibilities and minimize execution drag.

If you’re eager to hear even more on finding startup ideas from Gagan, he’s teaming up with The Hustle’s Sam Parr to run an Ideation Bootcamp on the Maven platform — learn more and sign up here by May 2nd if you’re interested.

My takeaway: winning startups don’t depend on a eureka moment. They emerge from a disciplined loop—curious exploration, fast and falsifiable validation, and focused execution. If you apply these principles with persistence and empathy for the customer, you’ll increase your odds of finding product-market fit faster—and building something that endures.

Inspired by this post on First Round.

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

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

October 22, 2025
Why I’m Tuning In to “In Depth”: Tactical Playbooks for Startup Hiring, Leadership, and Growth

When I first heard, “Welcome to In Depth, a new podcast from First Round Review that’s dedicated to surfacing the tactical advice founders and startup leaders need to grow their teams, their companies and themselves,” I immediately thought: this is the kind of operating wisdom I reach for every week. As a product leader who obsesses over product management leadership and the realities of scaling teams, I’m drawn to resources that move beyond inspiration and deliver concrete playbooks I can put to work on Monday.

The promise here is refreshingly pragmatic: “We’ll cover a lot of ground and a wide range of topics, from hiring executives and becoming a better manager, to the importance of storytelling inside of your organization. But every interview will hit the level of tactical depth where the very best advice is found.” That’s exactly where the hard problems get solved—whether you’re navigating the IC to manager transition, tuning your approach to product discovery, or tackling employee retention at startups when growth forces you to rewrite the org playbook.

From my vantage point, the most valuable conversations unpack the patterns behind great executive hiring, the cadence of outcomes vs output OKRs, and how storytelling shapes alignment across product, engineering, and go-to-market. I’m eager for insights that translate directly into product roadmapping and sprint planning, lessons on product-market fit that stand up under scale, and founder-led GTM tactics that keep teams focused on what matters.

I’m all in for discussions that get specific—what to ask in a VP interview, how to structure a 30/60/90 for new leaders, and the rituals that keep quality high without slowing velocity. If you’re building, leading, or leveling up your craft, this is time well spent.

I hope you’ll join us. Subscribe to “In Depth” now and learn more at firstround.com

Inspired by this post on First Round.

October 22, 2025
Hard-Won CEO Lessons: Steve El‑Hage on Pivots, Burnout, and Rebuilding After a Revenue Cliff

I recently connected with Steve El-Hage, co-founder and CEO of Drop, an electronics company that creates products powered by feedback by a massive community of enthusiasts and experts. As I listened, I put on both my product management leadership hat and my operator lens to unpack what other product creators and founders can take into their own journeys. Reflecting on his 8-year, heads-down grind since becoming a first-time founder at 22, Steve shares the lessons that he figured out the hard way, from revenue dropping off a cliff and painful pivots, to hiring blunders and severe burnout. When I hear “revenue dropping off a cliff,” I immediately think about product-market fit lessons and the mechanics of founder-led GTM. In my experience, these moments are brutal but clarifying: they force a ruthless reordering of priorities, sharper customer segmentation, and tighter feedback loops. I’ve learned to ask two simple questions in crises like this: Which customers are truly pulling the product? What’s the smallest, fastest test that can validate our next bet without mortgaging the roadmap? The phrase “painful pivots” resonates because high-quality pivots are really about excellent product discovery under pressure. I anchor teams on outcomes vs output OKRs to avoid thrash, ensuring we change direction with purpose rather than panic. For me, the discipline is simple: re-state the problem in customer language, identify the leading indicator that proves we’re moving the needle, and then run small, compoundable experiments until the signal is undeniable. Hiring blunders are equally instructive. Early-stage teams often over-index on resumes and under-weight learning velocity, values alignment, and ownership. I’ve corrected this by designing hiring loops that test real work, not theater, and by being explicit about the IC to manager transition expectations from day one. Strong onboarding and clear career paths improve employee retention at startups, but it starts with hiring for trajectory, not just pedigree. Severe burnout is the tax we pay when pace outruns process. I’ve found that setting non-negotiable operating cadences—weekly priorities, monthly retros, and quarterly business reviews alongside OKRs (QBRs vs OKRs)—creates healthy pressure without chronic overload. Protecting maker time, limiting work-in-progress, and celebrating disciplined “no’s” are not luxuries; they are system-level safeguards that keep teams creative and resilient. What Steve’s journey underscores for me is both humbling and practical: the hardest-earned lessons become your operating advantages. If you’re navigating a pivot, rebuilding after a revenue cliff, or evolving your team through growth, lean on customer-validated insights, tighten your feedback loops, and operationalize focus. That’s how you turn hard ways learned into repeatable wins.

Inspired by this post on First Round.

October 22, 2025