Oji Udezue on The Shipyard Squad Model, Solving Customer Problems, and Building Rocketships
Product State Q&A
Oji Udezue is the co-author of Building Rocketships. Formerly, he was CPO at Typeform, Head of Product at Twitter, CPO at Calendly, CPO at Parsable, Head of Product at Atlassian, Founder at Kernel Fund, Director at Spiceworks, and PMM at Microsoft.
Website / LinkedIn
EC: What does a ‘Squad’ look like for product-led organizations?
OU: The Shipyard Squad Model is a new-ish way of thinking about product-led organizations.
After years of building products at Microsoft, Atlassian, Calendly, and Twitter, I've seen how traditional product team structures fall short. Here's why we need to evolve:
Traditional product teams were built around the EPD triad:
1. Engineers
2. Product Managers
3. Designers
But these teams were never truly autonomous. They relied on external departments that became bottlenecks for shipping products customers love.
The Shipyard expands the core squad to six essential functions:
1. Engineering (typically 7 engineers)
2. Product Management (1 PM)
3. Design (1 designer)
4. Customer Research (⅓ time)
5. Data Analysis (⅓ time)
6. Product Marketing (⅓ time)
This is a complete product team that can actually ship autonomously. In addition:
- Faster Execution: Squads can deliver at 2x speed when shipping to customers
- Better Decisions: Full context and data at every step
- End-to-End Delivery: Teams own the complete customer experience
But even the Shipyard Squad needs to maintain close connections to customer support, customer success, and sales. These teams provide vital customer insight that helps squads identify and solve sharp problems.
Caveat: The Shipyard squad model will NOT work if team members are fully beholden to their department heads.
Squad objectives take priority over departmental responsibilities.
Unless there's an emergency, Shipyard squads stay focused on their team mission.
EC: How important is it for product leaders to focus on problem-solving?
OU: We heard this daily at Calendly: 'Why don't you build your own calendar app?'
Our customers wanted it. Our investors suggested it. Even our team pushed for it.
But here's what we understood:
Our customers didn't actually want ANOTHER calendar. They wanted their scheduling headaches to disappear. Meeting coordination was eating up their time and leading to lost opportunities.
By staying focused on that core problem - making scheduling painless regardless of what calendar you use - we delivered exactly what customers needed.
The result? We grew from $25M to nearly $100M in annual revenue during my time as CPO, and later raised $350M at a $4B valuation.
Take customer feature requests with a big grain of salt. Keep your eye on the big picture. Our most successful strategy was focusing on being the best scheduling layer ON TOP of existing calendars, not competing with Google and Microsoft head-on.
Your job is to solve the sharp customer problem, not build every feature they ask for.
EC: After leading product teams while building a few rocketships, how do you define 'product strategy?’
OU: It is inevitably about choice. A software company (or any company, for that matter) has limited resources relative to its ambitions, especially early on, so it needs to prioritize.
A good strategy outlines the best campaign possible given its resources (human, culture, and capital), its customers, and the competitive and market environment.
Strategy is as much about what to do to win, but also about what NOT to do. Every choice in strategy should have a well-articulated opportunity cost in order to really evaluate if the affirmative choices are the best that are possible given the circumstances.
Good strategy flows from four main ingredients:
1. Market environment (20% of strategy)
2. Customers (50% of strategy)
3. Culture and talent (15% of strategy)
4. Company ambition (15% of strategy)
As always, knowing thy customer is the priority. Conduct rigorous (and ongoing) customer discovery and the rest of your strategy will follow.
Oji’s book ‘Building Rocketships’ is available now:
“Your job is to solve the sharp customer problem, not build every feature they ask for.”
- Oji Udezue
