Building Your Shipyard

Hey there, it’s been a minute. 

Professionally, I’ve been very heads down the last few months working on Pearl Planner. Personally, I’ve been working on selling our acreage in Minnesota and moving my family somewhere where the sun shines more often, the bugs don’t try to rapidly devour your flesh (and soul) and where we can have more options to be active outside year round — currently scoping Northern California. 

I try to share a mix of content that ranges from product thinking, to career development, to hands on tinkering and I realized it’s been a while since I got into more practical hands-on product leadership. Last Summer I had a chance to work with Oji and Udezue to help them get their new book launched. It’s called “Building Rocketships” and it’s potentially the most useful and applicable book for operators that I’ve been able to find. While it has some content on product thinking, strategy, etc. It’s much more grounded in proven systems, strategies, and processes that power high performing product teams. 

For this post, I chose one of my favorite foundational concepts from the book, that essentially answers the question, “How do I build a team that consistently ships high quality and high impact work?”

The Shipyard: A Proven Evolution Beyond EPD

The traditional EPD (Engineering, Product, Design) model served as the foundation of technical software product management for nearly four decades. But as Oji and Ezinne detail in "Building Rocketships," this model had a fatal flaw: no one fully owned the final solution.

EPD teams weren't truly independent. Engineers had to prioritize departmental security reviews over squad missions. Product managers wrote specifications, handed them off, and moved to the next problem. The result? Products and features that consistently missed the mark because the team was unfocused.

Spotify's 2012 innovation of autonomous EPD squads (7 engineers, 1 PM, 1 designer) showed the power of mission-focused teams. But even this improvement had a critical gap: once the squad shipped a feature, they'd "toss it over the wall" to product marketing, who lacked the context to nail the messaging.

The Shipyard Solution in Practice

The Shipyard model expands the EPD triad into a sextet that includes:

• 7 Engineers (core development capacity)

• 1 Product Manager (strategy and coordination)

• 1 Designer (user experience and interface)

• ⅓ Customer Research (user insights and validation)

• ⅓ Data Analysis (metrics and behavioral insights)

• ⅓ Product Marketing (positioning and storytelling)

Plus strong coordination with three satellite teams: Customer Support, Customer Success, and Sales.

The critical difference: Goals are organized by squad units, not departments. The Shipyard squad prioritizes their mission over departmental responsibilities, creating true end-to-end ownership.

Why This Works: Real Performance Gains

Companies like Microsoft, Slack, Meta, and Google using Shipyard models report two significant advantages:

2x Speed Improvement: Team familiarity, clear goals, and quicker decisions enable faster idea-to-market cycles. When you hold complexity constant, Shipyard squads consistently outpace traditional discipline-based teams.

Complex Project Capability: Traditional teams bog down in management overhead as complexity increases. Shipyard squads handle ambitious projects because decision-making stays within the focused unit rather than escalating through department hierarchies.

The secret isn't just the expanded skillset—it's the cycle time advantage. Each team member stays focused on one mission from start to finish, enabling rapid collaboration and problem-solving that departmental structures can't match.

The Innovation Insurance Principle

As Oji and Ezinne note, Product Systems serve as "innovation insurance"—they're the floor of innovation, not the ceiling. The Shipyard model creates conditions for consistently hitting customer outcomes ≥50% of the time, compared to much lower success rates in traditional structures.

Microsoft's failed attempt to dominate personal finance software in the 1990s illustrates why systematic approaches matter. Despite having "really smart people and much deeper pockets," Microsoft lost to Intuit because Intuit had superior Product Systems—the practices, processes, and rituals that ensure high-quality innovation.

How Does AI Change The Shipyard?

We just saw a solopreneur build and sell a business for $80M in just 6 months… let that sink in.

Maor Shlomo, founder of Base44, bootstrapped an AI-powered app builder to an over $80 million acquisition by Wix in just six months. As a solo founder with severe ADHD, he hit $1 million ARR three weeks after launch and grew to more than 400,000 users—all while navigating two wars in Israel and never raising outside funding.

This is a rare "edge case" that I suspect we'll start to see more often, but it makes you think about how lean a team can really be.

The Shipyard model works because it eliminates handoffs and creates true end-to-end ownership. But what if we could maintain those benefits while dramatically reducing team size? AI is making this possible by fundamentally changing how product development work gets done.

I'm not talking about simple automation or efficiency gains. I'm talking about qualitatively different workflows that eliminate traditional bottlenecks entirely.

The reason roles are blurring isn't just that AI makes everyone more capable—it's that the tools themselves are evolving to eliminate entire categories of handoffs. We're seeing teams skip Figma entirely and jump straight to functional prototypes. Designers are working directly in v0.dev or Cursor to create interactive components rather than static mockups. The traditional "design → prototype → development" pipeline is collapsing into a single step where the prototype IS the design artifact.

When Role Boundaries Start to Blur

What's happening isn't just that people are getting better at their jobs—the lines between roles are dissolving entirely. AI is enabling team members to contribute meaningfully outside their core expertise in ways that would have been impossible before.

The Analytics-Oriented Engineer starts picking up data science work, running their own experiments and interpreting user behavior patterns without waiting for dedicated analysts.

The Experience-Focused Product Manager begins handling foundational design work, creating interaction flows and even visual prototypes that maintain design integrity.

The Systems-Thinking Designer dives into backend logic, understanding and sometimes building the data models that power their interfaces.

The User-Obsessed Engineer conducts their own research, synthesizing customer feedback and iterating on solutions based on direct user insights.

The analytics-oriented engineer doesn't become a data scientist overnight, but AI helps them apply their analytical thinking to user data in ways that inform better technical decisions. More importantly, they're no longer waiting for a separate handoff—they can act on insights immediately.

The Death of the PRD? (and Other Documentation)

Traditional product requirements documents are becoming obsolete. Why write a 10-page spec when you can build a working prototype in the same time? I am seeing Product Leaders use Cursor and repos to organize their documents along with their prototype code. This approach puts your context in front of the coding agent and lets you have more control over the specific context you want it to use in every response. The prototype handles the detailed specifications because it IS the specification. This shift from documentation to demonstration eliminates the interpretation layer that caused so many products to miss the mark. When the PM builds a working prototype, there's no ambiguity about what the feature should do or how it should behave.

Chemistry > Headcount

What I'm realizing is that team success becomes less about the exact size and more about the team's chemistry and "genetic" makeup. The critical advantage comes from building a team of people whose natural attributes and skills outside their core role create multiplicative effects.

The best teams I've been part of had this quality. Out of all the companies, teams, and structures I've worked in, I still love how 10up structured their pods. I was a team lead and Senior Product Manager with direct management responsibility over everyone on my team—engineers, UX, design, devops, etc. I had a technical/engineering counterpart who helped keep teams focused on solving the right problems in the best way possible. He and I would think through the high-level strategy to support their success and then divide and conquer to ensure we had enough ground-level support across our projects.

What made it work wasn't the structure—it was the people and how they complemented each other's natural strengths and working styles.

I've been playing music with the same 3 brothers since I was 14. We don't play as much as we used to, but through high school and college, we could go into the music room and just start playing without saying a single word to each other. Whether it was playing through our songs or writing something entirely new, there was a collective flow state we hit and a certain level of excitement that peaked every time one of us jumped in and did "that perfect thing" for the song.

That's what the best product teams feel like—a collective flow state where everyone's natural abilities amplify each other's work, creating something that none of them could build alone.

What Will Teams Do With New Capacity?

When AI eliminates 60-70% of routine execution work, teams suddenly have capacity to focus on higher-leverage activities. Instead of spending weeks on implementation, they can: - Run more experiments: Test 3-4 approaches instead of committing to one based on assumptions - Go deeper on user research: Actually talk to customers instead of making educated guesses - Explore strategic opportunities: Investigate new markets or user segments that previously seemed too resource-intensive - Improve quality: Focus on polish, performance, and edge cases that get cut when teams are stretched thin The best teams I've observed use this newfound capacity to become more thoughtful and strategic rather than just moving faster on the same activities.

Building for Chemistry and Capability

When building your own Lean Shipyard, focus on these qualities:

Natural Cross-Pollination: Look for people whose interests and aptitudes naturally extend beyond their primary role. The engineer who thinks deeply about user experience. The designer who gets excited about technical constraints. The PM who loves diving into data.

Complementary Problem-Solving Styles: Some people attack problems analytically, others intuitively. Some prefer to prototype quickly, others think through edge cases first. The best teams have a mix of approaches that create more robust solutions.

Shared Standards for Quality: Everyone needs to care deeply about the end result, even if they contribute to different parts of it. AI amplifies both competence and incompetence—teams of people who don't deeply understand quality will produce sophisticated-looking garbage at scale.

Learning Velocity: In rapidly changing environments, the ability to learn and adapt matters more than existing knowledge. Look for people who get excited about new tools, approaches, and challenges rather than those who prefer established patterns.

Tool Fluidity: Look for people who adapt quickly to new tools and aren't attached to specific software or workflows. The landscape is changing so rapidly that tool preferences from six months ago may be irrelevant. Teams need members who can evaluate new capabilities and integrate them effectively.

The Future of Team Building

The Lean Shipyard represents more than just an efficiency improvement—it's a fundamentally different approach to building products. By eliminating traditional handoffs and enabling true cross-functional collaboration, small teams can move with the agility and responsiveness that markets now demand.

This evolution builds on the proven Shipyard foundation while leveraging AI to eliminate the coordination overhead that traditionally required larger teams. The result is faster learning, better products, and more engaging work for everyone involved.

The question for product leaders isn't whether this change is coming—it's whether you'll lead the transition or be forced to catch up.

What's your experience with lean team structures? Are you experimenting with any of these AI-enhanced workflows? I'd love to hear about your early experiments and the challenges you're discovering.

For more on related topics, check out my articles on the rise of generalists, technical knowledge for product roles, and Prompt Design.