Better Products. Faster. is a high-velocity manifesto for tech founders and executives who've watched their companies drown in process. It exposes how today's frameworks have become the enemy of speed and quality, and introduces Dynamic Track and the Product Director role to help you ship products people actually love.
Better Products. Faster. is a high-velocity manifesto for tech founders and executives who've watched their companies drown in process. It exposes how today's frameworks have become the enemy of speed and quality, and introduces Dynamic Track and the Product Director role to help you ship products people actually love.
Fry's Electronics, Palo Alto, 2001
My cousin witnessed something extraordinary at Fry's Electronics in 2001. He was working there when a group of teenagers gathered around a new display. They'd never seen an iPod. These kids were the target market - already carrying portable MP3 players. Those players weren't bulky, but they had tiny storage (typically 64-256MB) and clunky interfaces with small screens that made navigation a chore. They stood there examining this strange new device, turning it over, clicking the scroll wheel.
One kid was clearly the alpha of the group. He held the iPod, spinning the scroll wheel with his thumb like he'd been doing it his whole life. Then he looked at his friends and delivered the verdict that would define what great product development actually means:
"Damn, that's some cool shit."
That's it. That's the moment where the rubber met the road. Your target user, trying your offering.
When’s the last time you heard anyone say that about Microsoft Teams, Workday, or Salesforce? Probably never. And that’s the problem this book is going to solve.
Who This Book Is For
This book is for anyone who decides what gets built and how. The founders who want speed without chaos. The executives who've watched productivity vanish into meetings. The product leaders who know their teams are capable of greatness but feel trapped in process. The board members who've watched a portfolio company get lapped by a five-person startup because it couldn't ship fast enough. You're the ones who can change how this industry works.
The Numbers Don't Lie
Let's start with some uncomfortable truths.
Here's what the research actually shows: 30-40% of new products fail to meet their commercial objectives, according to peer-reviewed studies tracking over a thousand business units across multiple industries. You may have heard the "95% of products fail" statistic attributed to Harvard professor Clayton Christensen. He's denied ever saying it, and researchers who contacted him directly found no source. The real failure rate is bad enough without exaggeration.
Research tracking actual consumer behavior found that 25% of new products stop selling after just one year. By year two, that number climbs to 40%. And these aren't just startups. Established companies with resources, experience, and brand recognition face failure rates of 30-40% for new product launches. That's still a catastrophic failure rate. If a third of bridges collapsed, we'd shut down the industry. But here's where it gets really interesting. The failure isn't happening because we can't execute. We have incredibly talented engineers, brilliant designers, and capable project managers. The failure is happening at a deeper, more systemic level.
Consider this data from Pendo's 2019 study. They analyzed 615 software companies over three months and discovered something shocking: 80% of features in the average software product are rarely or never used. Only 12% of features generate 80% of daily usage. Let that sink in.
Based on their analysis, Pendo estimated that publicly-traded cloud software companies collectively invested up to $29.5 billion developing features that are rarely or never used. Nearly thirty billion dollars. That's not a rounding error. That's the GDP of a small country, spent on features that deliver zero value to users.
The Standish Group found similar results: only 20% of software features are often used, 50% are hardly ever or never used, and the remaining 30% get used occasionally. So when you add up all that "occasionally used" stuff with the never-used garbage, you're looking at 80% waste.
If any other industry operated with this level of waste, they'd be out of business. Imagine if a car manufacturer built vehicles where 80% of the components served no purpose. Imagine if a building contractor installed 80% of materials that would never be used. They'd be laughed out of the industry.
Yet in software, we not only accept this waste, we've built entire methodologies around generating it faster.
What the iPod Got Right
Now let's talk about what happens when you get it right.
The iPod launched in October 2001 with Steve Jobs' famous promise: "1,000 songs in your pocket." By 2006, it was generating 40% of Apple's total revenue. At its peak in 2007, the iPod captured 75% of the digital music player market. By April 2007, just five and a half years after launch, Apple had sold 100 million units. Total sales eventually reached 450 million devices.
The competitive landscape tells you everything you need to know. Creative's CEO literally "declared war" on the iPod in 2004. Samsung vowed to take the top spot by 2007. SanDisk ran an anti-iPod marketing campaign called "iDon't." Every one of them failed. They had the technology. They had the distribution. They had the engineering talent. But they didn't understand what the iPod understood: they built music players. Apple built desire.
Here's what most people miss about the iPod's success. It wasn't just about better technology. The Toshiba hard drive Apple used was available to everyone. It wasn't about first-mover advantage - MP3 players had been around since the late 1990s. It was about obsessive focus on the user experience. Every detail mattered. The click wheel felt perfect. The white earbuds became a status symbol. The iTunes integration was seamless. The industrial design was beautiful. And critically, the display was large enough to actually be useful - you could read song titles and navigate your library without squinting at a tiny green LCD.
When users picked up an iPod, they had an emotional response. They wanted to show it to their friends. They talked about it at parties. They became advocates.
And that's where the economics get really interesting.
The Advocacy Economics
Customer acquisition cost is the number one expense in marketing. Always has been, always will be. You can have the best product in the world, but if nobody knows about it, you're dead. Traditional companies spend enormous sums on advertising, sales teams, and marketing campaigns to acquire each new customer.
But here's what changes when you build something people actually love: your customers become your marketers.
Nielsen's Global Trust in Advertising Survey found that 92% of consumers trust recommendations from friends and family above all other forms of advertising. McKinsey reports that word of mouth is the primary factor behind 20-50% of all purchasing decisions. When someone tells their friend "you have to try this," that recommendation carries more weight than any ad campaign.
This creates a compounding effect. Lower customer acquisition costs mean higher profit margins. Higher margins mean more resources for product development. Better products mean happier customers. Happier customers mean more advocacy. The cycle reinforces itself.
And here's the kicker: when you build products people love, you also dramatically reduce other costs. Fewer returns. Lower customer service and support costs. When users can figure out your product intuitively, they don't flood your support channels with basic questions. When the product just works, you're not processing returns or dealing with angry customers.
Business leaders understand this intellectually. They all claim to put customers first. But when you look at how they actually operate, you see something very different.
And the data backs this up. Design-centric companies, those that truly put user experience at the core of everything they do, have consistently outperformed the S&P 500 by over 200% across ten-year periods. The Design Management Institute's Design Value Index showed 228% outperformance in 2013 and has remained above 200% in subsequent years. These are correlations, not proof of causation, but the pattern is striking. McKinsey's 2018 study of 300 companies over five years found that design-led organizations had 32% higher revenue growth and 56% higher total returns to shareholders. This isn't about making things pretty. This is about understanding users deeply and building products that solve their problems elegantly.
The Distance Problem
Let's examine the typical startup. Two founders: one's a business person, one's an engineer. They came together because they both saw the same problem and both want to solve it for real users. The business person worries about product-market fit, cost feasibility, business model, value proposition. The engineer worries about architecture, implementation, scalability. But here's the critical part: they stay in their lanes while helping each other constantly. They move fast. They iterate. There's no bureaucracy slowing them down. And most importantly, both are obsessed with whether users will actually love this thing.
When the user picks up their product, both founders understand what that user is experiencing. They know if it's great because they've been there for every decision. That's where the rubber meets the road - the actual user interaction with the actual product.
Now fast forward five years. The company has 500 employees. There's a CEO, COO, CFO, CMO. And here's where it gets interesting: at many companies, especially in tech, none of these executives actually understand the product at a technical level.
I've worked at software companies where the C-suite literally couldn't describe the difference between a document database like MongoDB and a relational database like PostgreSQL. These are fundamental architectural decisions that affect everything from performance to scalability to cost. But the people making strategic decisions about the company's direction don't understand these tradeoffs.
The gap between where decisions are made and where the rubber meets the road has become vast. And that gap is killing products.
Think about why Steve Jobs was successful. Was it because he was a great fundraiser? No. Was it because he was a brilliant operations executive? No. It's because he understood products. He understood users. He could look at a design and know if it was right. He could use a product and feel if it was wrong. He stayed connected to where the rubber meets the road.
Same with Richard Branson. Same with Elon Musk. Same with any CEO who consistently ships products people love. They're not focused primarily on raising money or managing operations or planning exits. They're focused on the product. They understand the technical decisions. They can have intelligent conversations with their engineering teams about tradeoffs. They know what good looks like because they've spent time with users.
But most CEOs today are focused on everything except the product. They're in fundraising meetings. They're talking to private equity firms. They're worried about quarterly numbers and operational efficiency and organizational structure. The actual product - the thing users interact with - becomes someone else's problem. Usually someone three or four layers down who has no real authority to make bold decisions.
The Structural Problem
Here's the thing that most people miss: this isn't a failure of execution. It's a failure of structure.
Modern management didn’t come from business. It came from the military. The hierarchy you see on every org chart was designed to command soldiers, not to build products. The model worked for war because obedience and coordination mattered more than speed or creativity. For product teams, it’s poison.
Look at any corporate org chart and you'll see it: clear chain of command, strict reporting lines, functional silos. This structure made perfect sense for manufacturing in the industrial era. It made perfect sense when you needed to coordinate large numbers of people doing repetitive physical tasks.
It makes no sense whatsoever for product development.
In the military, success means executing a plan that was decided at the top. Soldiers don't question orders. They don't iterate on strategy in real-time. They follow the chain of command. That works when you're trying to coordinate thousands of people to take a hill or defend a position.
But product development isn't like that. Product development requires constant feedback, rapid iteration, tight collaboration between disciplines. It requires the people making decisions to be close to the users. The military structure actively prevents this from happening.
As companies scale, they add layers. Each layer adds distance between decision-makers and users. Each layer adds time to decisions. Each layer adds political considerations that have nothing to do with building great products. Pretty soon, the organization is optimized for internal coordination rather than external value creation.
And that's when you start building products where 80% of the features go unused.
The Process Problem
The structure wouldn't be quite so catastrophic if we had better processes. But instead, we've institutionalized waste.
Take the modern software development process. Product managers write PRDs. UX designers design interfaces. Engineers implement the designs. Three separate groups, working in sequence, each with their own goals and incentives.
What happens? The product manager needs to justify their existence, so they keep writing more PRDs. The designers need to stay busy, so they keep designing more features. The engineers need tickets to work on, so they implement everything that lands in their queue. Nobody is incentivized to say "we have enough features" or "let's remove the stuff nobody uses."
The organization becomes a feature factory. More features, more updates, more progress. But no rules for deprecating features. No discipline around maintaining a focused, coherent product experience. Just endless addition.
Look at enterprise software like SAP or Oracle. These systems have become so bloated that companies need to hire specialized consultants just to configure them. New employees require weeks of training to perform basic tasks. The software comes with thousand-page manuals because the interface is incomprehensible without documentation. One technology executive I know estimated that his team uses maybe 15% of SAP's features, but they're paying for - and drowning in - all of it.
This is what Agile was supposed to fix. But Agile has become part of the problem.
Enter Agile (Exit Value)
When the Agile Manifesto was written in 2001, it was a genuine attempt to fix broken software development. The principles were sound: individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, responding to change over following a plan.
But then something happened. Agile became an industry. Consultants needed to sell Agile transformations. Companies needed to show they were being Agile. And the focus shifted from the principles to the ceremonies.
Now we have Agile coaches who've never shipped a product. We have Scrum Masters who spend all their time organizing standups, sprint planning, retrospectives, and demos. We have two-week sprints that create artificial urgency without creating actual value. We have velocity metrics that measure activity instead of outcomes.
The data on Agile waste is staggering. According to the Scrum Guide's own recommended timeboxes, teams spend roughly 20% of their sprint capacity in ceremonies alone, and practitioners report this climbs to 30% or more when meetings run long or teams juggle multiple projects. Context switching between tasks reduces productivity by up to 25%. And the more teams scale, the more coordination overhead compounds.
McKinsey - yes, the same McKinsey that helped popularize Agile transformations - now admits that most organizations struggle with Agile at scale. Their research found that when companies adopt Agile, they often do so with "an industrial mindset focused not on value but on work." Teams track task completion instead of customer outcomes. Efficiency becomes more important than results. The process becomes the product.
Harvard Business Review has been even more direct. They point out that Agile is "too often used as an excuse to avoid careful planning and preparation." Instead of taking time to think deeply about what users actually need, teams get locked into two-week sprints, thinking in bite-sized chunks based on the resources they currently have. The methodology that was supposed to increase responsiveness to change becomes a constraint on ambitious thinking.
One of the original creators of the Agile Manifesto, Dave Thomas, gave a presentation in 2015 titled "Agile is Dead." His point wasn't that the principles were wrong. His point was that the movement had been co-opted, corrupted, and turned into exactly the kind of rigid process it was meant to replace.
Nearly 90% of companies report struggling to roll out organization-wide Agile transformations, even after succeeding with small-scale projects. The overhead of managing Agile ceremonies, coordinating between teams, and maintaining the process infrastructure often exceeds any productivity gains.
And through all of this ceremony, all of this process, all of these transformations, we're still building products where 80% of the features go unused.
Because Agile addresses symptoms, not root causes. It tries to make the existing structure more efficient. It doesn't question whether the structure itself is fundamentally wrong.
What This Book Will Do
Here's what we're going to cover in the pages ahead:
We'll explore the history of great user experiences - from 2,500 years of theater to 4,700 years of architecture to 200 years of fine dining. These disciplines all figured out something that software has forgotten: you need a single Product Director, and you design the entire experience before you start executing.
We'll examine what actually works when you need to move fast. I'll share the story of how my team designed and built a complete product for the intelligence community - including industrial design, mechanical engineering, a custom PCB, and custom firmware - in 30 days. No bullshit ceremonies. No endless standups. Just a co-located team with a Product Director and a clear goal.
We'll introduce Dynamic Track, a methodology that replaces the sprint treadmill with an approach that actually delivers results. It's not theory. It’s what I used as a consultant to consistently beat competition on time-to-market by 30% or more. Compound that over a few years and you don't just win, you dominate.
We'll talk about controversial truths that most business books won't touch. Like why remote work creates significant coordination overhead for high-velocity product development. Like why "everyone gets a say" produces mediocre products. Like why your CEO should understand technical tradeoffs instead of focusing primarily on fundraising.
And we'll give you a practical framework for actually implementing this in your organization. Not theory. Not aspirations. Actual tactics that work.
The Promise
By the end of this book, you’ll understand why most products fail and exactly how to fix it. You’ll know how to structure teams so decision-makers stay close to users. You’ll learn how to eliminate the waste of the feature factory and replace it with a system that moves faster and builds better.
You’ll know how to create products that make people stop and say, “Damn, that’s some cool shit.”
When that happens, when users genuinely love what you’ve built, everything changes. Acquisition costs drop. Support costs drop. Churn drops. Growth compounds. Teams come alive because they’re building something that matters.
That’s not just better business, it’s better work. And that’s what everyone in product development actually wants.
So let’s build that.
KEY TAKEAWAYS
30-40% of products fail to meet commercial objectives, and the cause is structural. The gap between where decisions are made and where users interact with products has become too large. This creates products that miss the mark no matter how well they're executed. Design-centric companies have consistently outperformed the S&P 500 by over 200% because they keep decision-makers close to users.
80% of features go unused, representing up to $29.5B in wasted investment among public cloud companies alone. This isn't a development problem, it's a process problem.
Great products create advocacy loops that compound. When 78% of people talk about their favorite experiences weekly, customer acquisition cost drops dramatically. Plus, great design reduces returns and support costs. But you can't fake this - the product actually has to make users feel something, like the iPod did in 2001.
CEO ACTION ITEM
It's impossible to unknow your own product - to truly experience it for the first time again. But you can still try.
Start fresh. Pretend you’ve never seen your own product. Set it up like a customer would, notice every stumble, every drag, every moment that makes you hesitate. That’s where the truth lives, because that’s what your users feel every day.
Then ask yourself one question: Would this make someone say, "Damn, that's some cool shit?"
If not, you know what to do. And if your executives can't explain why it feels the way it does - how the design, architecture, and implementation come together to create that experience - that's where your real work begins.
In Better Product Faster, Soudy Khan delivers an energetic and unapologetic critique of modern product development. Written as a manifesto, the book challenges founders, executives, and product leaders to rethink how products are built. The core argument is simple and uncomfortable: most companies are drowning in processes that weaken both speed and quality.
The book begins by explaining why most products fail, using practical examples and data to show how the distance between decision-makers and users leads to massive waste. The author highlights a striking truth: around 80% of product features are rarely or never used, yet teams continue to build more instead of better. From there, the book moves into foundations, where Khan takes direct aim at agile methodologies. He claims that what once promised freedom has become a rigid ceremony, due to the daily stand-ups, sprints, and endless meetings that often create the illusion of progress without real outcomes.
The heart of the book lies in its proposed solution: Dynamic Track. This approach replaces sprint-driven development with small, co-located teams led by a single Product Director who owns the full product vision. The author draws inspiration from the filmmaking industry, stressing the importance of one clear decision-maker to maintain coherence and momentum. The result is fewer wasted features and products that people genuinely love.
What stands out most is the author's tone. Khan is direct, confident and refreshingly honest. He uses stories, such as the first iPod moment when users simply said, “That’s cool”, to remind readers that great products create emotional reactions, not just metrics. His writing is filled with real experiences rather than theory.
Keep in mind that the book may feel confrontational to readers deeply invested in agile frameworks or remote-first cultures. Some statements are intentionally polarizing, and not every organization will find the proposed model easy to adopt. Still, these differences are something for the readers to strongly consider.
Overall, Better Product Faster is ideal for leaders who feel frustrated by bureaucracy or worried that their teams are busy but not effective. It is a motivating call to strip away excess, stay close to users, and build products that truly matter.