The Gap in a Market That Looked Fully Occupied
New York City's Broadway theatre ticket market in the early 2000s had the look of a closed system. The established players — Ticketmaster, TKTS, Ticketron, individual box offices — had years of institutional relationships with venues, brand recognition with theatergoers, and deep distribution infrastructure. A new entrant would appear to have no obvious opening.
Ticket Sales Inc. (TSI) found one anyway, and it wasn't where most people looked for competitive advantage.
The insight: venues had a structural problem. Empty seats were a cost with no upside. Ticketmaster solved this by selling tickets on commission, shifting demand risk to the venue and pricing uncertainty to the consumer through service fees. Those fees — sometimes 25–35% above face value — were Ticketmaster's margin, and they were also the thing consumers complained about most consistently in every satisfaction survey ever run about the ticketing experience.
TSI's model was different. They would buy blocks of seats directly from venues at a negotiated discount, absorbing the demand risk themselves upfront. Venues got guaranteed revenue regardless of whether the show sold out. TSI would then resell those seats at face value, with no service fees, undercutting Ticketmaster on the one dimension consumers had always resented.
The logic was clean. Technology assessment and market research both supported it. Management had genuine conviction. But "we have a real advantage" and "we can execute the product launch" are two different problems, and the second one is where startups die.
Starting in the Right Place on the Adoption Curve
A new ticketing platform doesn't enter the mass market. It enters a small, specific segment of users who have a concrete reason to try something unfamiliar. Understanding who that segment is determines every product decision made in the first twelve months.
The product lifecycle framework provides the structure: innovators and early adopters come before the early majority. For TSI, the early adopter profile was specific and identifiable. Theatergoers who had been burned by Ticketmaster fees and were actively looking for an alternative. Budget-conscious attendees who would see more shows per year if pricing were more transparent. Tech-comfortable New York residents who already trusted online transactions and would compare options before buying.
These users share one characteristic: they have a specific, articulated reason to switch. They are not habitual Ticketmaster users who are vaguely dissatisfied. They are actively motivated by the fee problem. TSI's no-fee positioning doesn't need to reach everyone to succeed in year one — it needs to reach the people who are already primed to switch.
This distinction transforms the product brief. A product built for early adopters who hate fees needs to do exactly one thing excellently: complete a no-fee ticket purchase in fewer steps with more transparency than the competitor. It does not need a recommendation engine. It does not need personalized event suggestions. It does not need a social sharing feature. The early adopter will accept a minimal product if the core value proposition is delivered cleanly. Adding features beyond the core delays launch, burns seed capital, and risks missing the seasonal window that matters.
Broadway is also a seasonal market. Spring and fall openings dominate. The holiday window is a concentrated revenue period. TSI's go-to-market calendar was constrained by events outside its control. The development methodology had to account for that.
SDLC Selection as a Business Decision
The choice of software development methodology is often treated as an engineering decision. For TSI, it was a business decision with direct revenue implications.
The options had different risk profiles at different stages of the company.
Waterfall requires full requirements documentation before development begins. The product scope is locked at the start; changes late in development are expensive; launch happens at the end of a defined sequence. This is appropriate when requirements are stable, well-understood, and unlikely to change — when you already know what the market wants and can afford to build it completely before testing it. TSI didn't know any of those things. It was entering a market it had never operated in, with a consumer base whose behavior it had only studied in theory. Waterfall would have produced a fully-featured product optimized for hypotheses that hadn't been tested.
Agile/Scrum inverts this. Two-week sprints produce working software continuously. The backlog is constantly reprioritized based on what the previous sprint revealed. Features are built in order of validated priority, not predetermined order. For TSI, this means the first sprint might produce: event search, venue and seating information display, and a basic checkout flow. That's enough to test with early adopters. The second sprint might add seat selection visualization after learning that users were confused by section descriptions. The third sprint might add email confirmation and order lookup after the first customer service inquiries come in.
This incremental approach matches TSI's actual position. The seed-funded startup doesn't know which features drive conversion. It doesn't know whether its target users trust an unknown brand enough to complete a purchase, or whether they need to see social proof first. It doesn't know how to handle the edge cases in the bulk-purchase model — what happens when a show cancels, when a bulk block doesn't sell, when a venue partner changes allocation. These are not design problems. They are operational realities that only emerge from actual transactions, and you need to be able to respond to them in the next sprint, not the next waterfall phase.
Kanban works well for maintenance and support once the system is live, but the continuous-flow model without sprint commitments is too unstructured for a greenfield product that needs to hit seasonal milestones.
The practical hybrid: Agile for the consumer-facing product, with a more structured change-management process for the venue partner API. Venue integration requires reliability — a partner built an inventory feed connection expecting a stable API, and breaking that connection with every sprint update destroys the venue relationship. Versioned, documented API changes with advance notice to partners is a commitment that runs parallel to the internal Agile cadence.
Who to Target, in What Order, Over Three Years
The product lifecycle model structures the go-to-market timeline in a way that seed funding can actually support.
Year one is early adopters. The product needs one clear acquisition channel for this segment: probably search advertising targeted at "Broadway tickets no service fees" and similar high-intent queries. The target customer already knows what they want, is already price-motivated, and is searching for alternatives. Paid search is efficient for this audience. The product goal is demonstrating the value proposition — completing a no-fee transaction — and generating enough repeat purchase to show retention data that proves it worked.
Year two is the early majority. This is the segment that waits for social proof before switching. They use Ticketmaster by default, they're mildly dissatisfied but not motivated enough to search for alternatives. Reaching them requires word-of-mouth from the early adopter segment, press coverage ("this startup is taking on Ticketmaster"), and possibly a partnership with a media property that covers Broadway. The product at this stage needs features the early majority expects: a cleaner venue selection experience, customer reviews, a clear return and exchange policy. The trust signals early adopters waive because they're motivated — the early majority requires.
Year three is the early majority at scale and, potentially, the late majority. By this point TSI either has the venue relationships and brand recognition to compete for mainstream theatergoers, or it has found that the bulk-purchase model works better for a specific genre of show or a specific price tier and should remain a premium-niche player. The data from years one and two answer this question. The product roadmap for year three can't be written in year zero.
What a PM Should Take From This
TSI's case teaches two frameworks in combination that are rarely seen together: the product lifecycle as a go-to-market sequencing tool, and SDLC selection as a strategic risk management decision.
The product lifecycle lesson: every product launch is a process of moving from one market segment to the next. The risk of trying to serve all segments at once is that you end up serving none of them well — the product is too complex for early adopters who just need the core value, and not trusted enough for the early majority who need social proof you don't yet have. Sequence matters. Know which segment you're serving in which stage.
The SDLC lesson: your development methodology is not just a process preference. It determines how fast you can validate, how quickly you can respond to what the market tells you, and whether your team is optimised for discovery or delivery. Early-stage market entry is a discovery problem. Discovery problems require Agile. Adopting Waterfall because it feels more structured at seed stage is how you build the wrong product efficiently.
The combination: use the PLC to know which user to focus on, use Agile to learn from that user as fast as possible, and don't scale the development team until the early adopter cohort is showing the retention and word-of-mouth behavior that confirms you've built the right product.