Building Rockstar MVPs: Lessons in Technical Leadership with Will Barrett
How Startup and Enterprise Teams Can Innovate, Prioritize, and Scale Without Losing Their Edge
In this webcast, I sit down with Will Barrett of Barrett Ventures, a veteran Fractional CTO and startup technical leader, to break down the real-world challenges of building Minimum Viable Products (MVPs), driving innovation, and scaling organizations-without falling into the traps of over-engineering or bureaucratic inertia.
We explore why so many teams build products nobody wants, how architecture choices shape business outcomes, and why leadership clarity is the secret weapon for cross-functional success.
As someone who’s spent years in the trenches of product and engineering leadership, I’m always fascinated by the gap between what we say we should do and what actually happens on the ground. That’s why I was excited to host Will for this episode.
"It's wild how many folks get way down the product development cycle and spend an enormous amount of money on something they haven't sufficiently tested"
Will’s career spans CTO roles at Tranzito, software engineering across a dozen languages, and guiding nearly twenty startups as a leader, advisor, or board member. He’s seen firsthand how technical decisions ripple out to shape business fate-sometimes in ways founders never expect.
Will’s perspective is refreshingly pragmatic. He doesn’t just talk about technology for technology’s sake; he’s laser-focused on how teams can create products people actually want, and how companies can avoid burning money on features nobody needs.
Why Most Startups Fail: Building What Nobody Wants
Will opened with a hard truth: “Most startups fail because they build something nobody wants.” It sounds obvious, but in practice, teams often charge deep into development without ever validating their assumptions. I’ve seen this myself-engineering teams working overtime, budgets ballooning, and only at the end do we realize there’s no real customer demand.
Will’s advice is simple but crucial: get out of the building. Talk to users early and often. Don’t let your engineering team become a factory for unused features. This echoes what Steve Blank and Eric Ries (Lean Startup - https://hbr.org/2013/05/why-the-lean-start-up-changes-everything) have championed for years, but Will’s experience shows just how often companies ignore it-sometimes at their peril.
"We need to identify what the differentiator is and test that - that's the only thing that matters"
Real-world example: At Tranzito, Will led the creation of a new tech-enabled bus stop for Los Angeles. Instead of assuming what the city needed, his team worked closely with stakeholders to define requirements, iterate quickly, and validate each step. The result was not just a product, but a solution that fit real-world constraints and needs.
The Nature of Innovation: Possible, Accessible, Affordable
Will breaks technical innovation into three buckets:
Making something possible that wasn’t before (true technological breakthroughs)
Making something accessible that was previously out of reach (think new distribution or delivery models)
Making something less expensive, opening up new markets (cost innovation)
He used the example of encyclopedias: what was once a luxury became universally accessible with Wikipedia, fundamentally changing the value proposition and market.
When you’re evaluating a new initiative, ask:
Are we creating something truly new?
Are we making an existing solution more accessible?
Or are we driving down costs to expand our reach?
Each requires a different approach to architecture, go-to-market, and team structure.
Example: In the AI space, Will points out that early offerings are expensive and unoptimized, but innovation is already driving costs down. Companies that focus on architectural improvements-optimizing compute, storage, and delivery-will win as the market matures.
Architecture as a Strategic Lever
One of the most insightful parts of our discussion was how architecture choices must evolve as a company grows:
In early-stage startups, speed is everything. You need to get a working MVP out the door, test your core differentiator, and avoid over-optimizing.
In the mid-market, the focus shifts to adoption and customer experience. Flexibility becomes more important.
At enterprise scale, cost control and efficiency dominate. The architecture must scale, and every inefficiency is multiplied.
"At the beginning, you're optimizing for ‘how do we get stuff done quickly’. In the middle, you're optimizing for how we change stuff quickly. And then at enterprise, you're like, 'okay, how do I drive the cost down?' And that's three different architectures,"
Will has worked with clients who lost money on every customer because of early architectural decisions-choices that made sense at the time, but became an anchor as the business grew. This is a classic pitfall I’ve seen at both startups and established firms: what worked for a team of three doesn’t work for a team of three hundred, and the architecture that worked for 1,000 users, can’t effectively scale to 100,000 users.
Example: Will described a client whose data storage costs were crippling due to early technical decisions. Fixing this required not just technical skill, but a willingness to rethink the architecture and align it with the company’s new scale and priorities.
Avoiding the Trap of Over-Optimization and Vendor Lock-In
A recurring theme was the tension between flexibility and efficiency. Too many teams try to build for scale or flexibility before they have product-market fit, leading to wasted effort and complexity. On the flip side, waiting too long to address technical debt can be equally disastrous.
Will’s take: use abstraction wisely. Don’t rebuild everything from scratch to avoid vendor lock-in, but don’t tie yourself so tightly to one provider that you can’t adapt. There are libraries and tools that make it easier to switch between services like AWS SQS, RabbitMQ, or Google BigQuery. The key is to focus on the class of service you need, not the specific implementation.
Personally, I’ve seen startups insist on microservices architecture from day one, only to drown in complexity. Will’s advice is clear: if you’re a small team, build a monolith, get to market, and only break things apart when you have the scale and team size to justify it.
The Leadership Imperative: Clarity, Focus, and Empowerment
Perhaps the most actionable insight came when we discussed cross-functional teams and leadership. Too often, organizations confuse activity with progress. Teams are busy, velocity is measured, but nobody is sure if the most important thing is actually being worked on.
Clear direction and delegation are essential. When teams have misaligned incentives - like one group focused on driving traffic while another is measured on reducing technical debt - conflict is inevitable. The solution is unified leadership with clear priorities that cascade throughout the organization.
In my experience working with startups and established companies alike, this alignment is often the difference between success and failure. When everyone understands the single most important goal and has the authority to make decisions that support it, innovation flourishes.
When to Optimize, When to Innovate
As products mature, the nature of innovation shifts. Early on, it’s about finding product-market fit and validating your core differentiator. Later, it’s about optimizing for cost, performance, and scale.
Sometimes, the biggest breakthroughs come from the unsexy work of backend optimization-think Netflix’s chaos engineering or Google’s data center innovations.
But as Will noted, not everyone thrives in every phase. Some leaders are best at zero-to-one, others at scaling or optimization. Recognizing where you-and your team-add the most value is critical for long-term success.
Moving Forward: Practical Implementation
As you consider your own product development approach, ask yourself:
Do you know what type of innovation you're pursuing, and is your architecture aligned with that goal?
Are you building something people actually want, or are you "burning money" on unvalidated ideas?
Does your team have clear direction about the single most important priority?
Are your architectural decisions appropriate for your current stage of growth?
Final Thoughts
Talking with Will reminded me that the fundamentals never go out of style: validate your assumptions, architect for your current phase (but with an eye for the future), and lead with clarity and courage. Whether you’re building your first MVP or optimizing a global platform, the same principles apply.
If you have your own stories of architectural pivots, leadership challenges, or MVPs that went off the rails, I’d love to hear them. These are the conversations that move our industry forward.
Host: AJ Bubb
Co-Host: Will Barrett, Fractional CTO and Startup Technical Leader
Let’s keep building things people want-and building them the right way.