Learn how Harness CEO Jyoti Bansal scales product innovation across 16 autonomous teams using the "startup within a startup" model and product-market sales f...
How to Build 16 Startups Within a Startup: The Ultimate Framework for Scaling Product Innovation
Key Insights
- Startup Within Startup Model: Harness operates 16 autonomous product teams as independent startups, each with product managers acting as CEOs with full P&L responsibility
- Product-Market Sales Fit: Beyond product-market fit, successful founders must achieve product-market-sales fit by designing products and go-to-market strategies in tandem
- Binary Differentiators Required: New products cannot launch without achieving table-stake parity capabilities plus at least one clear binary differentiator that competitors don't have
- Founder-Led Sales is Non-Negotiable: Every new product requires founder selling to achieve first 20-25 successful customer outcomes before scaling sales teams
- Continuous Improvement Culture: Organizations that reduce autonomy as they scale create bureaucracy; the key is balancing structured frameworks with expanded autonomy at all levels
Understanding Product-Market Sales Fit: Why Most Founders Get It Wrong
When you think of going to market, most people discuss product-market fit. But Jyoti Bansal, co-founder and CEO of Harness, introduces a more nuanced concept: product-market sales fit. This distinction fundamentally changes how you approach company building from day one.
The conventional wisdom suggests you should build the best product possible and let go-to-market strategy follow naturally. This approach fails more often than not. Why? Because product design decisions directly depend on your go-to-market approach. If you're building for enterprise sales, your product architecture, complexity, flexibility, and user experience need to differ significantly from a product designed for product-led growth (PLG) in the mid-market segment.
Enterprise products require extensive capabilities and configuration flexibility that mid-market customers don't need. Conversely, mid-market products demand simplicity and viral adoption features that enterprise customers won't value. The companies that succeed recognize this from the beginning. They design products with the sales model baked in, not bolted on afterward.
Bansal's experience demonstrates this principle. At Harness, the team made deliberate architectural decisions that allow the same platform to serve both enterprise and mid-market segments without compromising either. This wasn't accidental—it was the result of understanding that product design and sales strategy must evolve together. If you haven't figured out how to sell your product, you may need to redesign it fundamentally.
The Enterprise vs. Mid-Market Paradox: Why Companies Get Stuck
Most software companies start in the mid-market and struggle to transition to enterprise. Why? Because they build organizational muscles and cultures optimized for PLG and high-velocity inside sales—the cheapest, fastest path to early revenue. These same muscles become liabilities when trying to serve enterprise customers who demand sales-led approaches, account management, custom implementations, and longer sales cycles.
The problem runs deeper than sales tactics. Product managers work differently with go-to-market teams in each segment. Financial planning changes completely. The type of people you celebrate as top performers shifts. Your company's DNA crystallizes around mid-market muscles, making it extraordinarily difficult to build something different in parallel.
Bansal articulates this challenge clearly: when you build your culture and organizational structures around PLG and cheaper inside sales, you've created an engine optimized for velocity and volume. Shifting to enterprise-grade sales, with expensive account executives, partner channels, and multi-year decision cycles, requires not just hiring different people but fundamentally restructuring how your company operates.
However, dominating enterprise from the beginning and later moving downmarket is nearly impossible. Enterprise-focused products are too complex; enterprise sales cycles are too long. Yet Bansal discovered a way to thread this needle at Harness. By designing with both segments in mind from inception, the platform maintains the enterprise capabilities and flexibility while preserving the simplicity and product-led characteristics that appeal to commercial and mid-market customers.
This approach required discipline. Harness targets an 80/20 enterprise-to-commercial split, but Bansal deliberately aims to shift it to 70/30. Why maintain mid-market focus when enterprise is so much more profitable? Because mid-market customers keep you honest. They force product simplicity, accountability, and the discipline to avoid unnecessary complexity. Moreover, mid-market companies grow. When they become enterprise-scale, they should become your customers, not your competitors' customers.
The Netflix Decision: When Your Biggest Customer Becomes Your Biggest Problem
One of Bansal's most difficult decisions at Harness illustrates the tension between customer success and company health. Netflix was one of Harness's earliest customers, arriving around the second year. At that time, they represented a unique scale—they were managing 300 servers when they needed CI/CD solutions. Within years, they scaled to 30,000 servers on cloud infrastructure.
Netflix's growth created tremendous value for Harness and forced rapid product maturation. But as Netflix's needs expanded, they consumed a disproportionate amount of engineering resources. Eventually, Netflix became so large relative to Harness's customer base—larger than customers ranked 2 through 20 combined—that they monopolized the engineering roadmap. The team couldn't serve other customers' needs. New feature requests and product improvements stalled because the company had become Netflix's dedicated engineering department.
This situation forced Bansal to make the painful decision to part ways with the company that had catalyzed their product's maturation. It was, by his own account, one of the hardest decisions he's made as a founder. But it was the right one. By freeing up engineering capacity, Harness could serve 200 other customers waiting for attention. The company's growth accelerated. The lesson: even the most important customer can become a constraint on your company's future if the relationship isn't bounded and properly managed.
Building a Predictable, Scalable Sales Organization: From Deals to Capacity
Most founders manage their sales organization around specific deals. "We're going to close this deal this quarter" or "We'll hit our target because we have a pipeline of big accounts." This approach creates unpredictability and makes it impossible to scale reliably. Bansal advocates for a fundamentally different model: build your sales organization around predictable capacity, not specific transactions.
Here's how this works in practice. Establish your demand generation funnel's unit economics. If you generate 5,000 leads, how many convert to demos? How many demos convert to opportunities? What's your average deal value, and what percentage of opportunities close? Your sales cycle gives you a specific timeframe—say six months for enterprise deals.
Now you can make a simple calculation: if your demand generation team produces X leads per month, your sales team will close Y million dollars in ARR in the next quarter, based on historical conversion rates. With this model, you don't obsess about individual deals. You know that with a defined team of 50 sellers, each ramping at a predictable rate, each generating a certain amount of qualified selling capacity, you'll produce approximately $18 million in revenue that quarter, closing at roughly 90% of your pipeline capacity.
This shift from "deals" to "capacity" transforms your entire business planning. When you want to scale from $50 million to $100 million in revenue, you don't say "we'll close these big accounts." Instead, you say "we need X additional sellers with Y ramp time, generating Z capacity, which produces the revenue we need." This creates predictable, repeatable, scalable systems.
Diagnosing Product Problems vs. Go-to-Market Problems: The Customer Success Acid Test
One of the most common questions Bansal hears: our product isn't selling and go-to-market isn't working well. What's broken?
His diagnostic approach is elegant and immediately actionable: How many happy, successful customers do you have?
If the answer is "none" or "very few," you have a product problem, not a go-to-market problem. Most founders conflate these issues, spending money on sales teams and marketing campaigns when the fundamental issue is that the product doesn't deliver the promised value.
Product-market fit, in Bansal's definition, isn't about sales. It's about value delivery. He defines true product-market fit as having 25 customers (in enterprise software) who have achieved the specific outcomes you promised them. This means:
- During the sales process, you defined clear, measurable outcomes (deployment frequency increasing from once per two weeks to once daily; deployment time decreasing from six hours to 30 minutes)
- You implemented the solution with the customer
- Six months later, they achieved those outcomes
- They're not just happy—they're experiencing real, quantifiable ROI
This last point is crucial. A customer might be happy even if they haven't gotten value. They might like your product, appreciate the support, or enjoy your team. But that's not product-market fit. Product-market fit means they've gotten exactly the value they expected when they purchased.
Once you have these 25 successful outcomes, most products should scale. If you've achieved this milestone but go-to-market still isn't scaling, you have a different problem. Something has changed in your competitive environment, market positioning, or sales execution. But at least you've separated the product problem from the distribution problem.
Hiring Your First Sales Leader: Experience, Approach, and the Recruitment Imperative
Many first-time technical founders make critical mistakes when hiring their first VP of Sales. Some try to hire junior reps and then bring in a manager. Others, like Bansal initially, try to do it themselves because they lack experience evaluating sales talent.
His current advice: hire the most senior sales leader you can afford and attract. If you can't interview and evaluate sales reps, you shouldn't be trying to manage them directly. A senior VP of Sales understands the hiring, training, and process architecture required to build a scalable sales organization. More importantly, you can learn from them.
However, there's a nuance. The ideal first VP of Sales shouldn't come from an enormous sales organization where they've been many layers removed from frontline selling. If they've spent the last eight years managing regional VPs without directly managing reps, they may struggle to adjust downward to a lean, early-stage organization. Instead, seek someone who has led 15-20 person teams recently, preferably with enterprise sales experience.
What defines the best sales leaders across all of Bansal's experiences? Four critical competencies:
1. Recruiting Excellence: The number one differentiator. The best sales leaders are obsessive about recruiting. They understand that sales scaling is ultimately about attracting and retaining the right people. This requires constant focus, energy, and a systems approach to sourcing and evaluation.
2. Enablement Mastery: Hiring people is only half the battle. Great sales leaders enable reps to succeed. They understand the ramp period, provide targeted training, create clear processes, and ensure reps have what they need to hit quota. Poor enablement leaves good people floundering and departing.
3. Disciplined Sales Process: The best sales leaders run tight, documented sales processes. They track deal stages, identify risks early (like unidentified competitors entering a deal), build champion relationships, and create accountability. They don't rely on optimistic forecasting. They manage by facts and metrics.
4. Extreme Ownership: Top sales leaders take complete ownership of results. They can articulate their quota achievement history (not in vague terms, but specifically: "2022: 110% of target; 2023: 108% of target"). They understand the mechanisms behind misses or overages. They never blame external factors. They own the number.
When interviewing potential sales leaders, Bansal focuses on narratives. Tell me about a deal you lost—and describe your sales process and what you learned. Tell me about a deal you won—and detail how your process created that win. Most importantly: tell me about a time you missed target, why it happened, and what you changed. Someone who doesn't know their numbers or can't articulate this narrative is a red flag.
The Discipline of First-Principles Product Development: Table Stakes and Binary Differentiators
In a crowded market, releasing yet another "pretty good" competitor product guarantees failure. Bansal operates with a strict framework: never launch a product without both table-stake parity and at least one clear binary differentiator.
Table-stake capabilities are the baseline features any customer expects. If you're building a continuous integration product, you need declarative pipelines, cloud support, and all the standard CI features every competitor offers. Table-stake parity doesn't make you special—it just makes you credible.
A binary differentiator is something materially different that solves a real customer problem in a way competitors don't. At Harness, when building their CI product, they analyzed the market and identified the real pain point: builds were slow. Developers waited 30-40 minutes for feedback on code submissions. Why? Because CI systems ran every test in the suite.
Harness developed "test intelligence"—an AI model (built before LLMs existed) that learns which tests are actually affected by each code change. For a 50-line change, instead of running 3,000 tests, it runs perhaps 300-400. This delivers 4x faster builds, which is a genuine, provable differentiator. When launching, Harness could say: "We do everything other CI tools do, but 4x faster through test intelligence."
Similarly, when entering the cloud cost management market dominated by established players, Bansal's team recognized that most FinOps tools provided visibility and reporting—dashboards showing where money was being spent. That's table-stake. But they noticed the real problem: visibility without action is useless. Financial teams see the wasteful spending, report it, and then chase engineers to fix it, who resist changing working systems.
Harness's differentiator was automated remediation. Instead of reporting waste to engineers, Harness could implement automated fixes—right-sizing instances, shutting down idle resources, and optimizing configurations without human intervention. This transformed FinOps from a reporting exercise to an operating system that continuously reduces cloud costs. That's a binary differentiator worth building around.
The Startup Within Startup: Scaling Product Innovation Without Losing Autonomy
Harness operates 16 "startups within a startup," each running as an independent business unit with a product manager as CEO, their own P&L, customer acquisition targets, and revenue goals. Each startup progresses through familiar funding stages:
- Seed Stage: 5-6 person teams with no minimum revenue requirement
- Series A: $1 million in ARR
- Series B: $5 million in ARR
- Series C: $20 million in ARR
- Series D: $50 million in ARR
This structure creates several advantages. First, seed-stage startups can fail fast with minimal company cost. If a new product can't find a path to $1 million in revenue, pivot or shut it down. This experimentation happens at low cost, similar to the startup ecosystem.
Second, it preserves accountability. Harness doesn't bundle products. Each module is sold independently, competing against its true market alternatives. If your product is part of a bundle, you lose motivation to build something best-in-class. You can succeed even if your module is mediocre, as long as others in the bundle are strong. By requiring each product to win on its own merits, Harness ensures every module aspires to best-of-breed status.
Third, it creates a compound growth effect. If every product starts at $1 million in year one, reaches $3-4 million in year two, and $8-10 million in year three, and you launch three new products annually, the revenue waterfall creates powerful compound growth. Meanwhile, established startups continue scaling, creating a portfolio effect that accelerates overall company growth.
The structure requires a specific PM profile: extreme ownership and entrepreneurship. These aren't product managers managing features for a monolithic company. They're founders, responsible for everything—product development, customer acquisition, revenue, retention, and expansion. Half of Harness's startup founders are former entrepreneurs, which helps because they've already experienced the end-to-end responsibility. But former founder status isn't required. What's required is an entrepreneurial mindset: you cannot succeed by building a good product and assuming sales will happen.
Each startup within startup also benefits from shared infrastructure—platform services, enterprise security, deployment infrastructure, and go-to-market support. This shared platform dramatically accelerates progress. When Harness acquires small companies to accelerate product development (which it does frequently), they completely rewrite the acquired code to align with the platform in six months. That exercise extracts the expertise and key people while integrating the technology cleanly. What might take two years to build organically takes a year or less with this model.
Autonomy and Structure: The Paradox of Scaling Without Bureaucracy
The typical physics of scaling companies is that autonomy decreases. Early-stage startups move fast because decisions happen quickly, with minimal approval required. As companies grow, they add process, governance, and layers of approval—creating bureaucracy that slows execution.
Bansal has a different vision: scaled autonomy within structured frameworks. The goal is to expand autonomy as the company grows, not restrict it.
At Harness, this plays out across product, sales, and operations. The "startup within startup" model expands autonomy for product teams. But they operate within a structured platform framework—shared services, standardized go-to-market practices, and clear product development playbooks. Similarly, the sales organization runs with structured discipline around process and metrics, but sales leaders have significant autonomy in how they manage their teams, territories, and customer relationships.
This balance requires intentional design. You need frameworks and structures that enable, not constrain. At the product level: common platform infrastructure, shared services, standard security and compliance packages. At the sales level: standardized sales process, defined pipeline stages, clear compensation models, but flexibility in how managers coach, develop, and structure their teams.
The critical insight is that structures and autonomy aren't opposites. The right structures enable autonomy by removing decisions that don't matter and focusing autonomy on decisions that do. When everyone understands the sales process framework, compensation model, and metrics, they can operate with tremendous autonomy on how to win their territory or account. When product teams have access to platform infrastructure, they can move fast without building foundational components over and over.
Continuous Improvement as Organizational Culture
Most companies claim to embrace continuous improvement. Few actually do. The difference lies in how you respond when things go wrong—and in early-stage companies, things constantly go wrong.
Bansal's approach: no blame games, only learning. When something fails, the organization conducts intellectually honest postmortems. What happened? What could we have done differently? How do we improve for next time? The spirit is one of curiosity and improvement, not judgment.
This requires psychological safety. People need to feel safe surfacing problems early, before they cascade. If people hide failures to avoid blame, you get blindsided by larger problems downstream. If people openly discuss what's not working, you catch issues early and adapt.
This cultural principle plays out in transparent communication. Leaders don't hide challenges or pretend everything is optimized. Instead, they say: "These things are working well. These things aren't. Here's what we're learning and improving." A quarter later, they show progress. This transparency normalizes continuous improvement across the organization.
The alternative—waiting until everything is perfect before discussing it—guarantees stagnation. By the time you're ready to discuss something, it's too late to adapt. Continuous improvement requires acknowledging problems early, transparently, and moving forward together.
Customer Value Delivery as the North Star
Every major decision at Harness traces back to one principle: customer value delivery. It's the metric Bansal mentions most frequently to his team. It's the lens through which product teams evaluate priorities. It's the framework for competitive decisions.
Does this feature deliver value to customers? Will this product capability increase the value customers receive? Are we solving the problem our customers will pay for, and will they achieve measurable ROI?
This approach doesn't require ignorance of competitors. Harness monitors competitive activity. But it doesn't obsess over them. Instead, the organization focuses on the customer value framework. If you're constantly delivering increasing value—through new use cases, deeper capabilities, or better execution of existing features—you'll attract and retain customers regardless of what competitors do.
Customers choose solutions that deliver the outcomes they need. If you build that obsessively, everything else—including go-to-market success—follows. If you chase competitors or optimize for features competitors have, you'll miss the value axis entirely.
Lessons from Amazon: The Influence of Scale Without Bureaucracy
When asked about outsized influences on his thinking about company building, Bansal immediately cites Amazon and Jeff Bezos. Specifically, he admires how Amazon expanded from books to everything while maintaining a culture of ownership and autonomy. Despite becoming a massive organization, Amazon preserved the startup mentality at each business unit level.
This manifests in Amazon's famous principle: ownership and responsibility at different autonomous levels. A team running a particular product or service operates with significant autonomy and ownership, holding themselves accountable for outcomes. Meanwhile, the broader company maintains cohesion through shared principles, shared customers, and aligned incentives.
Harness applies this principle directly through the "startup within startup" model, borrowing the DNA of how Amazon scales. The goal isn't to become a massive monolith that moves slowly. It's to become a platform that enables many autonomous businesses to scale in parallel while benefiting from shared infrastructure and customer relationships.
The Founder Sales Imperative: Why Every Founder Must Sell
Technical founders often resist sales. They want to build products and delegate selling to hired professionals. Bansal's view is uncompromising: you must learn to sell, and you must do founder sales yourself early.
This doesn't mean you become the VP of Sales. But every founder should directly sell to early customers. Why? Because founder sales serves multiple purposes simultaneously:
Product feedback at the source: When you're selling, you hear directly how customers think about problems, what they value, and what they struggle to understand. This informs product decisions in real time.
Market education: Early prospects don't understand your space. They need education on what's possible, what's important, and how to think about solutions. The founder can provide this context in ways generic salespeople can't.
Sales process design: By selling directly, you discover what messaging works, what objections arise, and what sequences convert prospects to customers. This informs the sales process you'll teach to future salespeople.
Credibility establishment: Customers want to meet the founder. Meeting you signals that the company cares about their success, not just closing the deal.
Validation of product-market fit: You'll know immediately whether customers see your product as essential, nice-to-have, or completely missing the mark.
At AppDynamics, Bansal's experience reinforces this. He was an engineer uncomfortable with sales initially. But when an investor challenged him—"Do you really believe in this? Then why are you still in your job?"—he committed fully. He combined daytime fundraising pitches with nighttime coding. This forced him to develop sales and business skills in parallel with building product.
At Harness, Bansal made a different choice. Because he had sales experience from AppDynamics, he didn't hire a head of sales until the company reached $1 million in ARR. Instead, he hired several reps and worked directly with them and customers. This kept him close to the market and customer problems, feeding product development with real signals.
His advice to early-stage founders echoes this: learn to sell. You'll be forced to confront whether you're solving a real problem that customers will pay for. You'll discover gaps between what you built and what the market needs. Founder selling is the fastest feedback loop you'll ever have.
From AppDynamics to Harness: Lessons from a $3.7 Billion Exit
Bansal's journey from AppDynamics' IPO flirtation and eventual $3.7 billion acquisition by Cisco offers crucial lessons about founder strategy, investor alignment, and long-term company building.
AppDynamics' story reflects the challenge many founders face. The company was on the cusp of going public—they had the road show planned, employees in New York for the bell-ringing ceremony scheduled for Thursday. Three days before the IPO, Cisco made an unsolicited offer. The price initially declined. Then Cisco offered 1.5x the expected IPO valuation. Then 2.5x.
The decision was agonizing. Bansal had built an exceptional product and one of the best sales organizations in enterprise software. The company was growing 65% annually with strong revenue trajectory. But the final factor proved decisive: misalignment between the founder and board on long-term vision. Without alignment on what kind of company to build and how long to sustain that vision, execution becomes uncertain.
The lesson from this experience shaped Harness's founding. Bansal was deliberate about choosing investors and building a board aligned on a long-term vision for what the company should become. At AppDynamics, he spent roughly 25% of his time managing board dynamics and shielding the team from conflicting strategic directives. At Harness, through careful composition of the board, he spends perhaps 1-2% of his time on board management—allowing him to focus fully on building.
For founders raising early rounds, Bansal's advice on investor selection matters. Look for investors who believe in your vision and you as a founder, not because the deal is hot. Conduct reference checks. Talk to other entrepreneurs they've invested in. Understand their philosophy on founder-board relationships and governance. Where are the boundaries? What role do they see for themselves as board members?
As Bansal reflects, getting divorced is easier than removing someone from your board. Choose wisely.
Conclusion: Building for the Long Term
Jyoti Bansal's approach to building Harness reflects hard-won lessons from AppDynamics and a systematic philosophy about scaling without losing the startup mentality. The framework he's built—product-market-sales fit, startup within startup, autonomous teams within structured frameworks, customer value as north star—works because it addresses the fundamental challenge of scaling: how to maintain speed, innovation, and entrepreneurship while developing the processes and organizational infrastructure required to serve large enterprises.
The most actionable insight for founders: start with the end in mind. Understand how you'll sell before you finish building. Invest in your go-to-market DNA from day one. Hire or develop great sales leaders. Build products with clear differentiators, not just competence. Focus obsessively on customer value delivery, not competitive positioning. And remember that continuous improvement isn't a program—it's a cultural foundation requiring consistent reinforcement and psychological safety.
For teams building at scale, Harness demonstrates that autonomy and structure aren't opposing forces. The right frameworks enable autonomous teams to move fast while maintaining alignment. This paradoxical approach—expanded autonomy within structured systems—may be the most important lesson for companies trying to scale without calcifying into bureaucracy.
Original source: How Harness runs 16 “startups within a startup” at scale | Jyoti Bansal (Co-founder and CEO)
powered by osmu.app