Kill or Pivot

Welcome to the Deep Dive. Our mission, as always, is pretty straightforward. We take complex research, all the dense stuff, cut through that noise, and give you the concentrated knowledge you really need, you know, the insights for making those critical decisions. And today, well, we are wrestling with arguably the most high-stakes, honestly gut-wrenching decision in the entire startup life cycle. It's that moment. When do you save an idea with a smart strategic pivot? And when do you just have to acknowledge reality and terminate it completely? We are talking about that point where, you know, years of effort, maybe millions in capital, entire careers are all hanging in the balance. It's huge. Our Deep Dive today, it's based on looking really closely at the rigorous frameworks used by the biggest names in innovation. Think Y Combinator, IDEO, folks like that. How do they make this incredibly emotional choice more objective, more, well, rational? We're trying to move past just gut feel or, you know, being emotionally attached to that initial vision. Instead, we're using cold, hard data-driven logic. And we absolutely have to credit Chris Mullins, principal product designer at Red Cell, for the excellent research that made this entire Deep Dive possible. Yeah, it's such an essential dive to take because founders, they operate under just immense psychological pressure. It's intense. They're often drowning in information, right? Yeah. But at the same time, they face this relentless kind of insidious pressure from sunk costs. Every dollar they spend, every launch party they have, it just makes it harder and harder to be rational about walking away from the idea. And with the research from these top accelerators, what it really reveals is that the decision isn't, you know, based on some kind of magic formula. It's actually based on classification. They treat this decision very clinically, objectively. And the core distinction they make is this. You execute a pivot if there's some demonstrable traction, meaning customers are showing interest. Maybe they're engaging with some aspect of the product, but a core hypothesis, maybe it's the customer segment you chose or the way you plan to make money. That part is fundamentally wrong. Okay, so if the solution itself isn't quite working, but the underlying problem we identify, that's definitely real, that's when we pivot. We just change the attack angle, basically. Precisely, yeah. The market is giving you feedback, maybe strong feedback, but that feedback suggests a course correction is needed. Not that the whole thing is a failure. However, you kill the idea. You terminate the mission if you tried repeated pivots and they consistently failed to generate any kind of sustainable momentum. Or, and this is crucial, if the fundamental problem itself or maybe the market assumption you made is proven invalid. So if the problem you set out to solve doesn't actually exist for enough people, or maybe the competition is just simply insurmountable, then you kill it. That distinction really seems key. Is the problem real or is just our solution wrong? But spotting those signals, I mean, especially when the data is messy and you're right in the thick of it, that must be incredibly difficult. Yeah, absolutely. And that's really the goal of this deep dive for you, the listener. We're gonna spend our time identifying those essential criteria. We'll cover the hard, quantitative metrics of stuff used in what's called innovation accounting. And then we'll get into the critical, qualitative gut checks. Things like, is the founding team still aligned? How intense is the customer reaction? These are the things top mentors use to separate just a temporary setback from a dead end. It's all about being brutally honest with yourself, and making sure your decisions are informed by data, not just driven by emotion or hope. Okay, let's unpack this then. But before we jump into spreadsheets and metrics, there needs to be a fundamental shift in mindset, right? A different way of thinking about it. What's the core philosophy that these innovation powerhouses like IDEO and the big venture accelerators, what do they advise regarding, well, failure management? Yeah, it really all begins with this principle of fail early and often. That sounds like a bit of a cliche these days, but it's actually a powerful methodology when you apply it correctly. Innovation consultancies like IDEO, for instance, they structure their entire prototyping process around rapidly testing the core assumptions you have about your idea. Their goal isn't really to celebrate mistakes for the sake of it, it's to identify flaws quickly and importantly, cheaply. Before you sink massive resources, time, money into scaling something that's built on a broken foundation. You see, the primary goal in the early stage isn't really revenue, it's validated learning. You're essentially trying to learn what doesn't work as fast as humanly possible because that speed, it minimizes the capital you burn through and it maximizes the knowledge you gain for the next attempt or the pivot. I hear that and it makes sense in theory, but I have to push back just a little bit here. Isn't there a risk that celebrating failures encourages founders to quit too easily when they hit those inevitable hard problems that come with building anything worthwhile? What stops a team from just giving up on a tough but ultimately viable product just because the first MVP didn't hit it out of the park? That's a really critical distinction, you're right. And the experts, they are advocating quitting at the very first sign of difficulty, not at all. What they're advocating for is a system of measurement, one that helps you distinguish between, say, a solvable engineering challenge, something that just needs more work, and a fundamental market invalidation where the core idea is flawed. And this is exactly where the psychological safety aspect becomes, well, mandatory, not just nice to have. Leaders absolutely must create a culture where stopping work on an experiment, one that yielded negative data, is actually celebrated. It's seen as a successful learning outcome, not a failure of the team. This safety encourages teams to be rigorously honest. If the data clearly says the target customer segment won't pay, the team shouldn't be afraid they'll be judged for killing that specific project or feature. They should actually be rewarded for conserving the company's runway, the cash. Okay, that leads us straight to that huge elephant in the room, or maybe the dragon every founder has to fight, the sunk cost fallacy. I mean, imagine you've put two years of your life into this, maybe millions of investor dollars, hundreds of thousands of lines of code, perhaps. It's a beautiful product. How do the experts provide sort of tactical advice to confront that immense emotional pull, that feeling of we've come too far? Yeah, they definitely recognize that simply acknowledging the fallacy exists isn't enough. You need actual structural defenses against it. It's too powerful otherwise. So incubator leaders, they explicitly train founders to ignore the past costs. You just have to, you cannot bring back the resources, the time, the money, the effort that you've already spent. It's gone. One of the most effective tactical approaches they recommend is calculating the future opportunity cost. So instead of dwelling on say, the $2 million already spent, the founder has to force themselves to ask, what better idea could we launch with the $500,000 we still have left, six months of runway we would save by stopping this current thing now. By reframing the decision that way, moving from justifying past expense to maximizing future potential, you force a more rational choice. Ah, so you actually assign a positive value to stopping. You treat conserving that runway, that cash, as a potential profit driver for whatever comes next. Exactly, that's a great way to put it. Furthermore, experts often advise assigning a kind of neutral third party. Maybe it's a board member, a trusted mentor, sometimes just someone on the team designated as the devil's advocate. Their specific role is to review projects without the emotional attachment that the core team inevitably has. Their mandate is just to brutally assess the viability based only on forward-looking metrics and data. That neutrality is a crucial defense mechanism against the self-delusion that sunk costs can cause. Okay, now let's say the data shows there's a deep flaw, a real problem, but maybe the philosophy of reframe rather than abandon that IDEO talks about seems like it could apply. How do they suggest we harvest the good from the bad idea? Well, IDEO suggests you should really treat these failed experiments as a collection of assets, not just liabilities to be written off. You don't scrap the entire project's wholesale. Instead, you ask, what valuable insights did we gain? What functional technology did we actually create in the process? Maybe the core API, it works beautifully. Or perhaps there was a small niche demographic that absolutely loved one specific secondary feature. You then employ what they call yes and thinking. This means taking those useful validated elements, maybe it's the core tech stack or the surprisingly sticky usage you saw among a specific early group and combining them with a new hypothesis, one gleaned from understanding the failure. A pivot fundamentally should be asset heavy. It utilizes the existing learning, the existing resources to accelerate the test of the new direction you're considering. Right, it sounds like planting one foot firmly in what you've already learned, what you know works, and using that stability to quickly step test in a new direction. That's a perfect analogy, yeah. You shouldn't be starting from absolute zero unless the entire market concept is just totally invalidated. You leverage the code base you have, the user interviews you did, the team's shared history and understanding. That speeds up launching the new MVP, the new test, dramatically compared to a true start over from scratch. Okay, that brings us then to the ultimate, sometimes necessary termination, the kill scenario. We talked earlier about Linda Yates from Mach 49 and her wonderfully blunt criterion. If solving the problem requires time travel, you have to kill it. Can you make that concept a bit more operational for us? What does time travel actually look like in a real technical sense or a market sense? Sure, time travel basically means the solution you're proposing is currently infeasible. It's impossible because of limitations that are completely outside of your control, and they're very unlikely to be solved by your team or anyone in the current environment or near future. So for example, if your product relies on every single customer having access to, say, 10 gigabit fiber internet right now, or maybe it requires battery technology that's five times denser than anything that currently exists, or perhaps it demands that a major regulatory body suddenly changes a decades-old stance like next Tuesday, that's time travel. It means the obstacle is an insurmountable technical, physical, or maybe regulatory leap. Okay, so if the solution demands some fundamental change in physics or maybe a massive overnight shift in consumer behavior or global infrastructure that probably won't happen for a decade… You stop. You kill it. Absolutely. Insurmountable technical hurdles or fundamental market invalidation means termination. If you discover, for instance, that the total addressable market, the TAM, is actually $50,000 a year, not the $5 billion you projected, or if a major incumbent like Google or Amazon just launched a free, vastly superior version of your core offering, that's usually a kill signal. The Techstars mentors are really clear on this. Don't waste precious runway, precious cash, trying to fix a fundamental flaw when you actually need to kill it to preserve resources for a truly viable hypothesis down the road. Right. That brings us perfectly out of the philosophy and straight into the cold, hard numbers, which is where a lot of these decisions ultimately have to land. So once the founder has that right mindset that failure is actually data, it's learning we have to establish objective measurements. And the experts, they demand that founders track real traction, not just those feel-good vanity metrics. And this seems to rely heavily on the Lean Startup Framework's Build, Measure, Learn cycle. Yeah, that shift is absolutely mandatory because traditional financial metrics like profit and revenue, they're basically useless when you're pre-revenue or very early stage. They tell you nothing. You need a system that actually measures your learning velocity, not profit. And this is the domain of what Eric Ries termed innovation accounting. Let's deepen that a bit. We know innovation accounting is the tool set for these early stage metrics, but how, practically speaking, does a founder track validated learning when their user count might be tiny and revenue is zero? What does a typical IA experiment actually look like on the ground? An innovation accounting experiment is specifically structured to test a core hypothesis you have about customer behavior. How do you think people will react or use your product? It starts with establishing a credible baseline using an MVP, a minimum viable product. And this baseline isn't just saying we have 100 users. No, it's a detailed measure of their initial behavior within a specific funnel or flow. For example, your baseline might be of the first hundred people who see our signup page, only 10% actually activate the core feature. That's your starting point, that's the baseline. Then the founder runs rapid experiments, maybe A-B tests on the landing page copy, or perhaps those concierge MVPs we'll talk more about later. And these experiments are aimed specifically at moving that behavior metric. The hypothesis for the experiment might be something like, if we simplify the onboarding copy, we believe we can increase core feature activation from 10% to 15%. Very specific, very measurable. And the innovation accounting framework then dictates what you do next based purely on the results of that specific experiment. Exactly. If the experiment succeeds, you hit the 15% activation goal, great. You persevere on that path, maybe refine it further, and then you test the next iteration, the next hypothesis. But if it fails, activation stays at 10% or even drops. You must stop. You reassess the core assumptions. Was the copy wrong? Or was the feature itself just not valuable enough? And then you decide whether to pivot, meaning you change the fundamental hypothesis about the customer or the solution. Or maybe, if enough experiments fail, kill the concept entirely. Okay. If the goal of these very early experiments is really to validate desirability, do people even want this thing? What are the quantitative signals that truly matter before we even think about scaling up? Right, before scaling, the single most powerful quantitative signal, almost universally agreed upon, is retention. If customers come back repeatedly, if you have sticky usage and you measure this through things like cohort retention rates, how often they come back, session frequency, or how much time they spend when they do that is the highest indicator of early product market fit, much more than just signups. Innovation accounting really requires you to evaluate your progress based on these actionable metrics, these behavioral metrics, rather than just raw download numbers or registered users, which can be misleading. Okay, let's talk about the gold standard then for validating that sort of indispensable quality, the Sean Ellis 40% rule. It sounds simple, but what makes it such a powerful benchmark in accelerators and VC circles? Yeah, the 40% rule, it's kind of brutal, actually, because it measures urgency, not just mild preference or liking something. Sean Ellis, who helped grow companies like Dropbox, he popularized this concept based on a simple survey question. You ask your active users, and that's key, not random people, but people actually using the product, how would you feel if you could no longer use this product? And if 40% or more of them answered that they would be very disappointed, you've likely hit product market fit or PMF. 40% saying very disappointed, that's a really high bar. It implies the product isn't just solving some minor annoyance, it's solving a critical, perhaps painful problem for a significant chunk of your users. Correct. It means the product has achieved something close to must-have status for that core group. Companies like Dropbox, Slack, HubSpot, and many others have historically shown that crossing that 40% threshold correlates really strongly with future hypergrowth potential. And conversely, if you consistently can't hit that mark, even after trying different things, it forces a really hard look. It strongly suggests you need to pivot. Either the customer segment you're targeting is wrong, or the problem you're solving is just a nice-to-have, not a need-to-have. But let me just introduce a little bit of friction here. Is that 40% rule truly universal? I'm thinking about, say, early-stage B2B tools. They often solve very niche corporate compliance problems, maybe not something that evokes daily disappointment if it vanishes. How do we adjust or think about this benchmark for enterprise software or these highly specific niche markets? That's a crucial challenge, and you're right. It's not always a perfect fit, especially for B2B. For those kinds of tools, yeah, the 40% benchmark might be slightly aspirational, but the underlying principle measuring the intensity of the need remains critical. So maybe only 25% say very disappointed, or perhaps another 50% say they'd be somewhat disappointed. That still signals significant engagement and dependence. However, in those cases, the qualitative follow-up becomes absolutely vital. You have to dig deeper. In a B2B context, you might substitute or supplement the disappointment question with ones about productivity loss or direct monetary costs. For instance, if this tool were gone tomorrow, how much more money would your team likely spend, or how much revenue might be lost due to doing this manually or using alternatives? If the answer points to a significant measurable financial impact, that can justify a lower quantitative threshold on the disappointment scale, because the pain relief is clear and quantifiable in dollar terms. The key, really, is that the survey or the interview must effectively measure pain relief or essential utility, not just superficial approval or liking. Okay, that makes sense. So moving past those PMF surveys, what are the key leading indicators? Make four key ones that incubators and early-stage investors watch really closely, the numbers that predict viability even when a revenue is low or zero. Right, they prioritize signals that predict future financial viability, even in the absence of current profit. So first, real willingness to pay or sign up cold. Is your customer acquisition completely dependent on the founder's personal network or heavy discounts and free trials? That's okay initially, but it can't stay that way. If you put up a simple landing page describing the value proposition, maybe with a clear price, and people you don't know are willing to put in their credit card information or at least sign up for a paid pilot, that is powerfully validated demand. If acquisition is basically zero outside of your friends, family, and personal pleading, that's a major red flag about the broader market appeal. Second, repeat usage and the depth of engagement. We look beyond just daily active users, DAU, versus monthly active users, MAU. The DAU ratio itself is a good stickiness metric. If a product is genuinely indispensable, used daily or weekly, that ratio will be relatively high. But we also need to look at the adoption rate of the core features. Are users just signing in and poking around or are they actually deeply utilizing the central value proposition, the thing the product is supposed to do? Low core feature adoption combined with high early churn just screams low utility. It's a sign the product isn't delivering on its core promise effectively. And what about the sustainability check? Especially critical when you're burning through cash every day. Yeah, that brings us straight to the third key point, unit economics. Now, calculating lifetime value, LTV, is highly theoretical, almost guesswork, for very early stage startups, we know that. But founders must constantly monitor the relationship between their customer acquisition cost, see hazy, how much it costs to get one new customer, and their projected LTV, however rough that projection is. For an early stage company, LTV is often projected using early engagement metrics as proxies for future value. For instance, you might find that users who complete your core activation loop within 24 hours are five times more likely to stick around for three months than those who don't. You then use the behavior of that higher retention cohort to model your potential LTV. Now, if your CAC driven by testing different marketing channels is steadily rising and is approaching or even exceeding even that theoretical best case LTV, well, you're systematically destroying capital with every new customer. The model is broken. Yeah, that's a trap many founders fall into, isn't it? Only measuring the volume of new users, not the cost or the quality, the LTV of that volume. And that leads directly to the fourth major quantitative red flag, which ties into a concept we touched on earlier, success theater. This is that insidious practice of presenting impressive looking raw user growth figures, we added 100,000 users, while conveniently hiding massive, crippling churn rates underneath. If users sign up in droves, but then quickly drop out maybe 90% churn within the first 30 days, that means the product is fundamentally flawed or isn't delivering value, regardless of how many new users you acquire each month. You're essentially just pouring water into a leaky bucket. Looks like you're adding water, but the level never actually rises. Can you give us maybe a more concrete example of what success theater looks like in practice? Sure, think of maybe a mobile social app that puts out a press release saying, we hit 1 million registered users this quarter. That sounds fantastic to investors, to the press. But if behind the scenes, the data shows that 95% of those users logged in exactly once, never completed their profile, never invited friends, and never returned after day one. The actual active user base might be shrinking relative to the cost of acquiring each of those million registrations. Success theater keeps the founder, and maybe the investors, focused on the easier metric to influence acquisition, rather than the harder, more important metrics, retention, engagement depth, and ultimately lifetime value. So the quantitative red flags demanding action are really clear. If your user or revenue growth is flat or even shrinking despite your best efforts, if you can't validate any real willingness to pay outside of heavy discounts, and if your CAC is sky high and cannot be justified by any reasonable LTV projection, you're very likely at a kill moment, or at least need an urgent, traumatic pivot. Okay, so while the numbers, the quantitative stuff, provide that rigorous reality check, qualitative evidence is absolutely critical. Particularly in the very early stages, you know, when quantitative signals might be scarce, or the numbers are so small, they're not statistically reliable yet. The sources we looked at emphasize that founders interview a median of 30 customers before even committing fully to building an idea. And that's precisely because the qualitative signal, the human reaction, often precedes the quantitative one. You hear it before you can measure it. 30 interviews, wow. So what are we actually listening for in those conversations? It can't just be politeness, right? People being nice because you ask them. No, absolutely not. Politeness is often the silent killer of early stage startups. People don't wanna hurt your feelings, so they say, oh, that's interesting. What you need to look for, actively listen for, is evidence of intense pain or intense excitement. You're listening for urgency in their voice, in their language. Potential customers, if the problem is real for them, they should use dramatic language when describing their current situation, the problem you aim to solve. They might say things like, oh my God, this problem is driving me absolutely crazy, or we literally have to hire two extra people just to manage this process manually right now. That's pain. Or alternatively, when you present your proposed solution, even just a concept, they should express genuine, palpable excitement. They should immediately lean in and ask, okay, where do I sign up? Or seriously, can I get beta access to this today? If your prospective users are just sort of indifferent or silent, or they just offer vague niceties like, yeah, that's neat, that is probably the most damaging signal of all. It means it's not a priority for them. Right, as one startup coach memorably put it, criticism is better than crickets. That's a really powerful distinction. Why is intense criticism often actually assigned to pivot, not necessarily to kill the whole idea? It's powerful because criticism, even harsh criticism, means they care enough about the underlying problem to actually engage with your proposed solution, even if they hate the solution itself in its current form. They are invested, emotionally or practically, in the outcome you're promising to deliver. If they criticize your pricing, that's way too expensive, or the usability, I couldn't figure out how to do X, or the features, needs to do Y and Z, they're actually giving you a roadmap. They're telling you how to pivot to capture their existing demand. Silence, on the other hand, or that polite indifference, means the problem just isn't urgent enough for them to spend mental energy on it, let alone open their wallet for a solution. So yeah, no inbound interest, no feature requests, maybe even no complaints. That's often a death sentence for the current approach. It signals the product isn't solving a compelling enough problem for anyone right now. Okay, so before we double down on engineering, building out the full product based on maybe just a handful of these interviews, how do experts advise founders to test this market viability quickly, using primarily qualitative methods, getting that signal before committing big resources? Yeah, you absolutely must run low-fidelity experiments first, gauge that interest before writing potentially thousands of lines of code. You really don't need a fully functional product just to test initial demand. This often involves using techniques like a concierge MVP or maybe a Wizard of Oz MVP. A concierge MVP is where you, the founder or the early team, manually fulfill the service for the first handful of customers. You are the product initially. If they're willing to pay you for that manual, perhaps clunky service, you validated the core value proposition before automating anything. The Wizard of Oz MVP is slightly different. It looks automated to the customer on the front end, maybe a simple website interface, but it's actually powered entirely by a human behind the curtain manually doing the work. Again, it checks viability without a significant tech build. And the red flag in this early testing phase, what tells you it's not working? The biggest red flag here is a failure to generate any significant inbound interest, even with a simple promise, a simple concept. If you launch, say, a high-quality landing page, clearly explaining the proposed solution and its benefits, and you can't get even, say, 100 people to provide their email address for a free beta invite, you almost certainly won't get them to pay real money for a polished solution later. Consistently lukewarm feedback across many tests or observing a massive gap between people signing up, maybe for the free offer, and actually engaging or using the concierge service, that forces a pivot. The value isn't landing. Let's shift focus a bit to external red flags now, things related to the broader market structure. What kind of market signals demand a kill decision rather than just another pivot? Yeah, the biggest external red flag is usually fundamental market invalidation. This happens when a core assumption you made about the market fails catastrophically, and it's not something a pivot can easily fix. Examples might include discovering that the niche market you targeted is simply way too small to ever support the unit economics needed for a venture-scale business. Or maybe realizing the problem you identified well-real is already adequately solved by a free or deeply entrenched alternative that customers are happy enough with. Or perhaps discovering that customer behavior just cannot be shifted in the way your product requires. Maybe people absolutely refuse to adopt the necessary hardware or change a longstanding workflow. You also have to constantly watch for abrupt competitive or market shifts, things happening outside your control. The sudden emergence of powerful new technologies, think about how generative AI is suddenly rendering certain types of data analysis tools obsolete almost overnight. Or maybe a major regulatory shift happens that suddenly makes your primary business model illegal or unviable. These kinds of shifts can create an insurmountable hurdle. If major incumbents have such a deep, defensible moat, maybe through network effects or proprietary data, that even a clever pivot would only lead you to a tiny marginal niche. You might have to kill the original grand vision. Okay, finally, let's turn inward. Because sometimes the numbers might be just okay, maybe not great, but not terrible, but the team itself is falling apart under the strain. How do incubators like Y Combinator assess the founders themselves in this process? This is such a crucial internal check. Team and vision alignment. Y Combinator in particular places immense value on founder passion, resilience, and cohesion. Aaron Harris, one of the YC partners, suggests founders must ask themselves two core questions with absolute brutal honesty. First, do I still genuinely want to work on the company I would build if we actually solve these problems? This really assesses whether the founder is passionate about the future potential, the mission, which might look radically different after a pivot, or if they're just emotionally attached to the original product vision that's now failing. Right, are they wedded to the problem or just the first solution they thought of? And the second question, that gets at the team's capacity to actually execute whatever comes next. Exactly. Second question is, do I still genuinely want to work with my co-founders on it? The intense strain of near failure, of constant pivoting, often fractures founding teams, trust erodes, visions diverge. If the honest answer to either of those questions is no, then termination of the venture might actually be necessary regardless of the metrics. Persistently low team morale, open conflict between founders, or just a palpable loss of belief in the ultimate vision. These are powerful qualitative red flags that strongly favor a kill decision because you simply cannot execute a difficult, uncertain strategic pivot without total alignment, trust, and renewed energy from the core team. I want to circle back briefly to that really compelling case study you mentioned, the founder who killed his Techstars-backed startup despite having generated nearly $2 million in revenue. That seems like the ultimate example of overcoming the sunk cost fallacy. Why was that model considered fundamentally broken, even with that kind of top-line revenue? Yeah, that specific case study, which came out of the Techstars network, it really illustrates perfectly how volume without viability is a dangerous trap. It's success theater again, in a way. So this founder had developed a tool, let's imagine it was a specialized platform connecting HR departments with specific types of freelancers. And yes, they achieved that impressive $2 million revenue mark. Sounds great. However, the core issue was that the business model required extensive, costly manual intervention to actually deliver the service and acquire customers. It wasn't scaling efficiently. The high revenue was ultimately misleading because of the lifetime value, LTV, of each customer was relatively low compared to the complex, high-touch customer acquisition cost, CENK. And critically, the cost of fulfillment, the necessary human resources, the operational complexity involved in making those matches and managing the process meant the business was only marginally profitable at best. And crucially, every new dollar of revenue required a massive, unsustainable increase in human capital, in headcount. The margins just vanished as soon as they tried to scale beyond their initial highly personalized client base. He realized that to get to, say, $10 million in revenue, he'd basically need to hire dozens and dozens of specialized consultants. Ah, okay. So the brutal realization was that they weren't actually building a scalable technology company, which is what venture capital funds. They were inadvertently building a highly customized, low-margin service agency just wrapped in a thin layer of software. Exactly. That's the perfect summary. He had achieved maybe product service fit, but not product market fit for a scalable, venture-backable business. So he made the incredibly tough call to kill the company, preserving the remaining capital, and importantly, the team's talent for potentially more scalable idea down the line. He acknowledged that his past success in revenue didn't justify continuing a fundamentally broken business architecture. That right there is the definition of real founder maturity. It's painful, but rational. Okay, so let's say you've done the checks, the rigorous quantitative analysis, the honest qualitative feedback, and the conclusion is the underlying problem you identified. It's real. People have this pain. But your current solution, or maybe the customer segment you targeted, or the business model you chose, that part is wrong. If that's the case, the path forward is usually clear. Pivot. And a pivot, properly defined, isn't just flailing around. It's a structured course correction, as Eric Reisz puts it. It's specifically aimed at rigorously testing a new fundamental hypothesis, while importantly, reusing as much of your validated learning and existing assets as possible. Right, pivots are often viewed negatively, maybe as a sign of failure or chaos, but the Lean startup methodology actually formalizes them into specific, repeatable patterns that give structure to the change. Let's maybe detail some of the classic forms a pivot can take, starting with those that primarily affect the scope or focus of the product itself. Yeah, let's cover the five most common types identified in the research. The first is the zoom-in pivot. This typically occurs when your initial product is maybe quite complex, multi-featured, ambitious. But when you look closely at the data, the user retention, the session frequency, feature usage stats, it shows that users only consistently, maybe obsessively, utilize one small feature, or one narrow aspect of the product. The absolute classic textbook example here is Instagram. It originally started as a boob-in, which was this overly ambitious app trying to combine location check-ins, Foursquare-style features, photo sharing, future planning, social gaming elements. It did too much. The founders, Kevin Systrom and Mike Krieger, looked closely at their early usage data, and they saw that the only thing users were consistently doing day after day was using the photo sharing functionality and applying those cool filters. Everything else, pretty much ignored. Wow, so they saw that clear signal in all the noise of the other features. Absolutely. They made the bold decision to zoom in. They stripped away all the other noise, the check-ins, the planning features, the gaming complexity, and focused the entire product exclusively on that simple, delightful photo sharing and filtering experience. That radical zoom-in pivot fundamentally created the Instagram we know today. Okay, and the reverse of that, the zoom-out pivot, when would that apply? That happens when you realize your initial product, maybe successful in its own right, is actually too narrow. It solves a small, specific niche problem, effectively. But you realize through customer feedback or market observation that the customer actually needs or wants a much broader platform or ecosystem solution. And your original product, successful as it might be, is really just one feature within that larger potential framework. Yelp is often cited as a good example here. It initially started, believe it or not, as just an email-based referral system for getting local recommendations from friends. But the founders quickly realized the much greater value, the bigger opportunity, was in creating a comprehensive user-generated platform for local search, reviews, photos, community forums, the whole ecosystem. The original email referral idea became almost obsolete, just a tiny piece compared to the overall platform value. They zoomed out to capture a much larger market need. Okay, moving beyond just the product scope, let's talk about the market itself. How does a customer segment pivot work? And what's the telltale sign that this specific type of pivot might be necessary? Right, this pivot involves targeting a completely different user group or customer base than you originally intended. The telltale sign is often when your product is being used, sometimes intensely, but by people you never expected or designed it for. They find value in it for reasons you didn't anticipate. The core technology might stay largely the same, but the language you use, the marketing channels, the pricing, the sales strategy, all of that has to shift radically to serve this new, unexpected customer segment. Slack is the absolute defining, almost mythical case study here. Slack, as many people know, was born out of the ashes of a failed attempt by Stuart Butterfield's company, TinySpec, to launch a quirky multiplayer online game called Glitch. The game itself failed to gain traction, but the internal communication tool they had built just for their own distributed team to coordinate while building the game, that tool was proving highly effective, highly sticky. When they looked at their own internal usage data, they saw incredibly high DIMAU ratios, intense communication threads, high engagement, primarily among their non-gaming internal staff, the designers, the marketers, the engineers. Ah, so they listened to that unexpected data point, their own team's obsessive usage, and realized the real value proposition was in the collaboration tool itself, not the game they were trying to build. Precisely. They made the pivot, they shut down the game, took that existing internal tool, cleaned it up, polished the user interface, and launched it commercially for general business teams. That customer segment pivot, from consumer gaming to B2B enterprise collaboration, launched them into a massive new market and transformed a potential failure into a multi-billion dollar success story. Okay, what if the customer segment seems right, but the pain you thought they had isn't actually their biggest pain point? They need something related, but different. That sounds like the customer need pivot. It's exactly right. This is when you realize, through interviews or usage data, that your product, maybe using its existing technology or core competency, could actually solve an adjacent, but perhaps much more urgent or valuable, problem than the one you initially set out to address. You leverage what you've already built, but you point it at a different, newly identified pain point for the same or similar customer. Pinterest apparently performed this kind of shift early on. Their initial concept, called Tote, was much more focused on being a replacement for paper shopping catalogs, browse items, save them, get notified of price drops, so it's quite commercial. But the founders observed that users weren't primarily using it for immediate shopping. They were using the site to collect and organize images for inspiration for future projects, for mood boards, for visualizing ideas. So they pivoted the core concept away from direct shopping facilitation towards becoming a social ID board or discovery engine. They addressed that deeper human need for collection, curation, and visual inspiration, which turned out to have much higher engagement and broader appeal. We also see this pattern with B2B companies, like Lattice, which initially started focusing just on OKR objectives and key results, software. They found that while OKRs were a tool used by some companies, the much broader and more acute pain point for HR departments and managers was comprehensive performance management. So they pivoted. They expanded their offering to address performance reviews, continuous feedback, goal setting, career development, leveraging their underlying enterprise software infrastructure to serve a more pressing and much larger customer need within the same general HR tech space. Okay, and finally, we need to discuss pivots that are less about the product or customer and more about the money, the business architecture or value capture pivot. This sounds like it often happens when the unit economics just aren't working out. Yeah, this is fundamentally a pivot focused on achieving financial sustainability. The product might actually be well-liked, maybe even have decent engagement, but the way you're charging for it or the fundamental market structure you're operating in, like B2C versus B2B, is proving to be broken or unprofitable. So a business architecture pivot refers more to shifting the fundamental market structure you operate in. A common example is moving from a high-volume, low-margin B2C model, which often requires a massive scale, to a lower-volume, but much higher-margin B2B enterprise sales model. Slack, again, provides an example here. While their initial pivot was customer segment-driven, gamers to businesses, their subsequent choice to focus heavily on high-margin enterprise licensing deals, rather than just relying on individual user upgrades, was a crucial business architecture pivot that really fueled their revenue growth and ensured long-term viability. A value capture pivot, on the other hand, involves changing the specific monetization mechanism itself. This could be switching from selling a product as a one-time purchase to a recurring subscription model, SaaS, or maybe introducing a freemium tier to drive wider adoption before upselling. These value capture pivots are often necessary if your analysis shows that your customer acquisition cost, and the cost, is just too high to be recouped by a single one-time purchase, or if the product's value naturally accrues to the customer over time, making a recurring revenue model a much better fit for both the customer and the business. Okay, so the data points towards a specific type of pivot. It's clear a change is needed. What are the key strategic steps a founder must follow to execute this? Because it can't just be a chaotic, let's try something new, scramble, right? It needs to be a rigorous, measurable framework, like you said. Absolutely, it must be rigorous. The chaotic, emotional, throw spaghetti at the wall pivot almost always fails, burns cash, and demoralizes the team. So the research points to roughly five key strategic steps. Step one, confirm the signals and ruthlessly avoid success theater. Before you pivot, you must dedicate focused time to rigorously auditing the data one last time. Bring in that neutral third party if necessary. Challenge the team and yourself to articulate every reason why the current model failed using hard evidence. You have to force yourself to stop explaining away those stagnant retention rates or those rising CACs. Face the brutal facts. This step sounds like it requires the most founder discipline, fighting that powerful urge to self-justify or hope things will magically turn around. It really does, it's often the hardest step. Step two, define the new hypothesis clearly. Once you've accepted the need to pivot, you must clearly articulate what exactly is changing. Is it the target customer? The core problem you're solving? The business model? The value proposition? Use tools like the lean canvas or the business model canvas to map out the new assumptions very explicitly. You need to define this with precision. Our new hypothesis is that shifting to an enterprise subscription model priced at $25,000 per year, targeting Fortune 500 HR departments, will allow us to generate a positive LTV to CAC ratio within 12 months, specific and measurable. Step three, prioritize rapid falsifiable experiments. Now translate that new clear hypothesis into the smallest possible testable experiment. What's the quickest, cheapest way to get data on whether this new direction has legs? Ash Morya, another lean startup advocate, advises setting bold, measurable outcomes for this new MVP test. You need to identify the single riskiest assumption underlying your pivot. What has to be true for this pivot to work? And then design the cheapest, fastest way to test just that assumption. For instance, if the riskiest assumption of your enterprise pivot is that large HR departments will actually take a meeting and consider buying, your first MVP isn't writing new code. It's crafting a compelling sales deck and trying to get 10 meetings. Step four, set clear decision criteria and a budget. This is critical for avoiding endless zombie testing. Define success for the experiment upfront. You must say something like, we will test this new customer segment hypothesis for the next three months, spending no more than $100,000 in marketing and sales effort. If we do not hit the 40% Sean Ellis benchmark with early pilot users, or secure at least three paid pilot contracts within this period, we will pivot again, or we will kill the entire concept. Having clear boundaries prevents indefinite testing and wasted resources. And finally, step five, align stakeholders transparently. Communicate the rationale for the pivot, the data that drove the decision, and the clear plan for the new hypothesis and experiments to everyone involved, the team, your investors, maybe even key early customers or partners. Pivots are inherently stressful and can risk high team churn if handled poorly. Transparency reinforces that the pivot is a strategic data-driven choice born of learning, not a sign of panic or incompetence. This helps ensure team buy-in and maximizes morale for the intense sprint ahead. And then tactically, what happens immediately after that strategic decision is made and communicated? In the execution phase, how do they effectively leverage those existing assets, the learning, the code that we talked about earlier? Right, the execution needs to be swift and importantly, economical. Resource efficiency is key during a pivot. So the team needs to immediately adjust the product roadmap based on the new hypothesis. If it's a zoom-in pivot, like Instagram, you need to be ruthless about pruning features that confuse or dilute the newly focused value proposition. Get rid of the clutter. If it's a customer segment pivot, like Slack, the user interface copy, the website positioning, the marketing messages, all that must be immediately revised to speak the specific language and address the specific needs of the new target user. But the absolute core tactical directive during execution is to maximize asset reuse. Founders and teams should be constantly looking at the existing code base, the existing designs, and the past user research. If the old authentication system worked perfectly well, reuse it, don't rebuild it. If the old database structure is functional for the new direction, repurpose it. Don't re-architect unless absolutely necessary. Ideally, you want the execution of the pivot to involve repurposing maybe 80% of what you already learned and built and only spending about 20% of your effort on the truly new feature set or adjustments required to effectively test the new hypothesis. This accelerates development dramatically and minimizes cash burn during that critical uncertain testing period. Hashtag tech outro. So I think the overarching takeaway from all this research, from all these frameworks is that the decision to pivot or kill should never be viewed as a reflection of personal failure by the founder or the team. Instead, it's really the highest strategic act of validated learning. It's proof that you're listening to the market, analyzing the data honestly, and making rational choices. The signal just has to be clear and founders need the courage to act on that signal with speed and honesty. Yeah, remember those core rules distilled from the frameworks? If the market seems to be pulling you, even just slightly, if there's some signal of intense need, but your specific approach or solution is clearly wrong, that's when you pivot, reusing all that valuable learning you've accumulated. But if the core foundation is crumbling, maybe the problem doesn't actually exist for enough people or the market itself is fundamentally invalid or the unit economics are just irrevocably broken and unsustainable, that's when you have to make the tough call to kill it, to preserve your precious resources for the next better idea. And hopefully you now have a clearer picture of the tools to use. Employ innovation accounting to establish those rigorous baselines and measure validated learning, not just vanity metrics. Apply benchmarks like the 40% rule for a tough validation of product market fit. And exercise that brutal honesty about some costs maybe by actively calculating the future opportunity costs of continuing down the current path versus stopping. Burn cash slowly, iterate fast on learning, but know when it's truly time to cut the cord. And maybe never forget that really powerful qualitative distinction we discussed. Indifference or silence from the market, that's usually assigned to kill, but criticism, even loud complaints, that's often assigned to pivot because it signifies that someone, somewhere, cares deeply enough about the underlying problem you're trying to solve to actually give you feedback, even if it's negative. That attention, that engagement, it's a form of currency in the early days. So we'll leave you with one final thought to mull over, something to consider in your own ventures or observations. If you are getting intense engagement, maybe loud complaints, strong feature requests, but they're consistently coming from the entirely wrong demographic, or they're asking for something tangential to your vision, that attention is still arguably better than silence. The really tough question for any founder in that situation is, how much negative attention or misplaced demand constitutes enough of a pull signal to warrant yet another difficult, perhaps resource-intensive pivot, instead of finally making the call for a graceful kill? Where is that line? Hopefully, using these structured frameworks we've discussed today can help you apply measured logic to your own projects, your own observations, and turn that kind of uncertainty into a more strategic, data-informed choice. Thank you for diving deep with us today.