The Multidisciplinary & Modern ‘Shipyard’
Why your product squad needs more than just engineering, design and product management, to reach orbit
In the last couple of years,
and I developed an idea we called - Product Systems. We wanted to contextualize leading technology product building as a system, in enough detail that lets you examine if you’re set up to do it well. These ideas cut across the technology, product, and business layers of a technology company. It's a set of ideas, principles, frameworks, and methods that you can assemble to build good products, borne out of our collective experiences and the many amazing influences we’ve had throughout our careers.We know developers have many of these guiding principles (Agile, TDD, CI, Code Reviews, etc) to solve their different craft and human issues. So did design (Design sprints, HCI, UXR). But Product Management still largely and stubbornly exists as a bespoke discipline bound only by a vague commitment to requirements prioritization and roadmaps. This is despite product managers running the most profitable companies in the world - Microsoft, Google, Facebook, and many more.
—------
Before we dive into more product systems, we want to tell you about our new book, Building Rocketships: Product Management for High-Growth Companies.
This book is a culmination of our careers as product leaders at some of the world's best tech companies. We share everything from how to discover sharp problems, to pricing and virality, to product leadership and (you guessed it) building product systems.
Building Rocketships is the book we wish we had when we started our careers as Product Managers. We hope it will be valuable for you.
Right now, you can pre-order the book (including our Pro Edition) for 20% off. Use the code ROCKET20 at checkout. Pre-Order Building Rocketships. Thanks! Now on to Product Systems.
—-------
The Shipyard: A better way to collaborate
Product systems are systems of systems (product management wraps engineering and design + more, into a coherent whole), making them somewhat ephemeral and invisible to many people in a company. So to really see the product system, we need to break it down into its component parts.
Product systems are not just for the product management discipline alone. It is intended for product managers and their multidisciplinary peers—the entire range of creative collaborators they need to ship useful products that move the needle for businesses. PMs can’t accomplish much without their multidisciplinary peers.
Product-led product management teams are tasked with building rocketships—it’s only fitting to imagine our product system as a Shipyard.
The Shipyard: A new model for building products
The Shipyard is a model for building product systems that are collaborative and multidisciplinary. It’s built on a fundamental building block often referred to as a squad—a small, multidisciplinary team that can build and ship almost autonomously.
Squads are given the responsibility of achieving key product and business goals, which they accomplish by executing on key projects through a prioritized roadmap. The larger and more complex the project, the more squads (quantity) that will be assigned to work on it. Multiple squads can be tasked to go after big goals.
Squads have been around since the dawn of software product management in the 1980s, but The Shipyard reimagines them. Squads were originally composed of the EPD triad: Engineers, Product Managers, and Designers. EPD squads exemplified the value of multi-skilled, self-sustaining teams that could execute a single mission. Their key innovation was decreased product cycle time, or the freedom to see a project from start to finish before moving on to the next one.
By focusing on one important thing/feature/product, an EPD squad could collaborate more rapidly to solve creative problems and deliver on related business goals. Each squad member’s focus meant a faster cycle time. Dedicated EPD squads worked so well that almost every advanced technology company has adopted them, and many business teams across the economy that use technology as inputs, are following suit.
In theory, EPD squads could work quickly and independently to deliver products and features. In practice, EPD squads had two limitations that hurt their productivity:
EPD squads were never fully autonomous. The EPD triad still relied on outside departments and resources to ship products: Research, data analysis, product marketing, and more. These were often organized as service organizations, and these unaligned resources could become cycle time bottlenecks.
EPD squads were often beholden to their departments, not their project goals. If the head of engineering wanted to do a security review, engineers had to prioritize that over their squad duties. PMs were also often not dedicated to a single EPD; they would write specifications, hand them off to the designers and engineers, and move on to the next problem to solve. Sometimes, no one fully took responsibility for the final solution (storytelling, release and market performance), and when they did it was a major hassle to align efforts productively, resulting in products and features that missed the mark. EPD squads were often unfocused, and the results showed.
The Shipyard model removes these limitations to fully unleash the power of squads. The first change is expanding the EPD triad into at least a six-part team:
Engineering
Product management
Design
Customer research
Data analysis
Product Marketing
Each Shipyard squad has dedicated resources (a full professional person or time-based focus) from each of these domains, making each team truly autonomous. And the squad can increase its creative and execution capabilities:
Product marketing can be fully involved from the beginning of a product- or feature-planning cycle, helping craft more nuanced product and launch stories.
Engineers can be deeply embedded in the customer research process so the quality of their build tradeoff recommendations can improve.
Data analysis from data analysts informs every function within the Shipyard squad and helps the team make better decisions and iterate more quickly.
The Shipyard squad must also have close ties to three other departments: customer support, customer success, and sales. Squads need a constant feed of customer insight data from these teams to address customer problems and requests quickly. Communication is a two-way street; shipyard squads can also help address more technical customer support and sales questions needed by customer teams.
Here is the critical feature of the Shipyard model: Local priorities are no longer set by departments, but rather by squad units.
Shipyard squads need to work as a single unit that balances their team objectives with departmental responsibilities. Each department usually has a tax which means product marketers or PMs are answerable to their department heads.
However, the Shipyard squad is encouraged to prioritize their team goal higher than the department’s in most cases. Unless there is an emergency, Shipyard squads should be left to focus on their top priorities, as long as they are aligned with product/company.
The Shipyard squad expands on the principles of the original EPD squad: focused, multi-skilled teams that have a singular mission. Specifically, Shipyard squads create two key advantages:
They can move faster. This is because of team familiarity, clear goals, quicker decisions and mandates, and the ability to go from idea to market quickly. If you hold complexity constant, some squads can deliver at 2x the speed of traditional EPD teams when counting the time it takes to get products in the hands of actual customers.
They can handle more complex projects. Traditional discipline-focused teams can often get bogged down because managers need to absorb fine levels of detail from the team to help manage complexity vs. having the team use domain familiarity to solve complexity by itself. As the technology industry contemplates more and more ambitious projects, we need better ways to manage complicated projects and still deliver usable and lovable products.
Shipyard squads improve collaboration, reduce cycle time, and most importantly, can often deliver end-to-end product experiences that delight customers and maximize outcomes.
How about startups?
Multi-disciplinary shipyards can only happen when a company gets to scale. Earlier on, there is a lot of ‘doubling up’ of roles and responsibilities. We’ll tackle modern shipyards in the context of resource-constrained startups next.
—---------
Want to learn more about building product systems that consistently develop great work? Pre-order Building Rocketships today and read the first 3 chapters immediately. Get 20% off by using the code ROCKET20 at checkout:
Pre-Order Building Rocketships
Plus, don't miss the Pro Edition of the book, which comes with dozens of tools, templates, and scripts that we use every day in our work. We plan to make a version of the book free for product managers, builders, and founders in the global south in March 2025.
Happy building!
 | A guest post by
|