Hey,

I’ve spent over 20 years in the IT industry - from engineer to CTO to board member of an international product company. Through consulting with product leaders and teams, I’ve focused on helping them embody the principles that make Silicon Valley’s best companies succeed. Recently, I’ve been working on Ship It, and by joining forces with , under SuperHero.Tech I’m hoping to accelerate that work and bring you even more useful tools and insights.

Working with Wojtek has been both wildly successful and, honestly, a bit of a bromance. Together, we’ve trained over 600 people through AI Product Heroes (NPS of 80, second edition looking even better), and now we’re aiming to bring our combined teaching reach to 100K people. And why stop there? ;)

What changes for you?

You’re now getting insights from both of us instead of one. More case studies, more perspectives, more practical examples. Same subscription, expanded value.

Why does this matter?

AI collapsed the barriers between business, product, and technology. Engineers can now prototype designs. Designers can ship working code. PMs can build without waiting for engineering. The role emerging from this shift is what we call the Product Builder - someone with a core skill who acquired 2-3 adjacent skills to eliminate handoffs and ship autonomously.

The bottleneck was never individual speed. It’s the gaps between people. Product Builders close those gaps themselves. Small teams, massive impact.

That’s what we’re writing about. Between us: 32 years of product and technology experience. Track record of training 35,000+ people and scaling products at Booking, Allegro, CD Projekt, Displate, GOG.com.

What Superhero.tech is?

A consulting and education platform for product people. Newsletter, podcast, webinars, courses, and community. The training ground for Product Builders - teaching the full product development lifecycle for the AI era.

What you’ll get?

• The SuperHero Formula: Framework for building products that succeed in the market

• Real cases from AI Product Heroes: What worked and failed for 600+ builders

• Product builder insights: Navigating the emerging role that combines business and AI-powered execution

• Personal AI productivity: Simple hacks and tricks anyone can implement, regardless of technical background

• Long-form analysis: What makes products work and what doesn’t

• Product and AI industry news to keep you up to date in this ever-changing world

The first full newsletter article goes out today. You’re already subscribed - no action needed.

From there, regular long-form commentaries, concept breakdowns, and direct takes on building in the AI era.

Thanks for being part of this journey so far. Very excited for the future.

Why You Should Care

I've seen countless products fail not because of poor execution but because of poor direction. One of the most painful lessons I learned was watching a team spend six months building features that perfectly matched our roadmap but completely missed evolving market needs. I have my share of scar tissue.

You can build a roadmap, and you can build a GOOD roadmap.

Here's what a good roadmap does:

1. It provides a strategic context for daily decisions

2. It aligns stakeholders around common goals

3. It makes prioritization discussions more productive

4. It helps teams say no to ideas that don't serve the current strategy

And perhaps most importantly, it forces you to think. Funnily enough, creating a roadmap for the first time can sometimes provide more value than the roadmap itself.

11 Principles of Great Product Roadmaps

A great product roadmap isn't a list of features or a Gantt chart. It's a story about how you'll solve customer problems and achieve business outcomes.

I won’t be advocating for any framework - I will point to some notable examples, but I want to arm you with something stronger - principles that will last.

Through my 20 years of dancing with the roadmaps, the best ones I've found consistently demonstrate these eleven core principles:

1. Great Roadmaps are Strategy-Driven. Your roadmap is not a collection of random features but a direct, logical result of your Product Strategy. When I look at a roadmap, it should be very, very obvious what your strategy is. You can read more about the Strategic Pyramid here. I've seen too many roadmaps that are just a collection of feature requests from sales or executive pet projects. These inevitably lead to products that lack coherence and fail to move key metrics. The best roadmaps I've created started with a clear strategic foundation—every item can be traced back to core strategic objectives. Strategy is your first check when prioritizing features. Does it fit your strategy? If yes, consider it. No? Park it.

2. Great Roadmaps are Outcome-Oriented. Focus on the impact and outcomes rather than just feature completion. Shipping features and marking them as "Done" doesn't mean they were successful. You need to measure against actual business and user goals. I recall so many celebrations about shipping something, only to realize we hadn't moved the needle on any meaningful metrics—sad panda. Great roadmaps define success in terms of customer and business outcomes, not feature completions. This shift in thinking transforms how teams approach problems and often leads to more straightforward solutions that actually work. Every item that you decide to work on should have a goal and the actual result, like so:

   

3. Great Roadmaps are not focused purely on development. Avoid rushing into development. I've watched too many teams jump straight to building without understanding the problem. Follow a structured approach:
   

   1. Wonder (Problem definition, opportunity assessment)

   2. Explore (Solution definition, prototypes)

   3. Make (Building and releasing)

   4. Impact (Assessment and iteration planning)

   All phases besides Make are quite cheap. Jump between phases, build only when you're confident. The most successful products I've worked on took time to understand the problem space before writing a single line of code.

4. Great Roadmaps are Prioritized. Use clear prioritization frameworks. As a starting point, consider the ICE prioritization framework. After many painful quarters of trying to do everything, I went with something simple. We started using these simple criteria to compare everything:

   • Potential Impact of the feature (1-10) on

   • Easiness of shipping it to production (1-10)

   • How much data we had to feel Confident about it (1-10)

   Then you multiply it, compare, and have some conversations. Score features based on these criteria to make informed decisions:

   

   Psst: The prioritization framework matters less than having a consistent, transparent way to make decisions. I've seen teams get paralyzed trying to perfect their prioritization framework while missing the point entirely. The best prioritization approaches create clarity and alignment, not mathematical precision. All frameworks can be hacked.

5. Great Roadmaps are Not Greedy. Balance your resources between new development, keeping the lights on, and technical debt. Don't go all in - distribute. I've seen many teams forced to spend 90% of their time on new features, only to watch their velocity grind to a halt as technical debt accumulated after 6 months. The most sustainable products I've managed to maintain this balance religiously, even under pressure to deliver more features. Your future self will thank you for this discipline. Here's one way to distribute it:

   

6. Great Roadmaps are Diverse. Use what I call the boulder-rocks-pebbles approach:

   • Boulders (20%) - Large, high-impact initiatives with a high level of uncertainty

   • Rocks (50%)- Medium-sized investments with a lower level of uncertainty

   • Pebbles (30%) - Small, straightforward improvements
     

   The magic happens when you find the right mix—big enough wins to move the needle, medium initiatives to show consistent progress, and quick wins to maintain momentum and address urgent needs.

7. Great Roadmaps are Evidence-Based. Don't rely on gut feelings - I've made this mistake too many times and paid for it dearly. Support decisions with user research, market data, technical feasibility studies, and success metrics. It's not about having perfect data (you never will), it's about making decisions based on the best available evidence. Use Confidence meter (for example, in ICE prioritization) - the stronger the data, the more points you'll have:

   

   The strongest roadmaps I've built combined quantitative data with qualitative insights, creating a complete picture of what users do and why they do it. Remember, the goal isn't to eliminate uncertainty but to reduce it enough to make informed decisions.

8. Great Roadmaps are Continuous. Don't treat roadmap planning as an annual event. Your roadmap should be rolling, evolving, and regularly reviewed and updated. Think of it as a living document that gets sharper the closer you get to execution. The best roadmaps I've managed were reviewed every other week with the team and monthly with stakeholders, allowing us to incorporate new learnings and market changes without losing sight of our long-term objectives. This continuous approach keeps your roadmap relevant and credible.

9. Great Roadmaps are Long-Term Focused. Maintain a 12-month rolling view while being more detailed in the near term: high precision for the current quarter, medium precision for the next quarter, and directional beyond that. This isn't about predicting the future - it's about providing enough context for strategic decisions while maintaining flexibility. This approach helps manage expectations with stakeholders who want certainty while giving teams the freedom to adapt as they learn more. The key is being explicit about the confidence level of each time horizon.
   

10. Great Roadmaps are Open & Transparent. Make your roadmap accessible to anyone in the organization. This transparency isn't just about sharing information - it's about building trust and enabling better decisions across the company. When I started making roadmaps truly open, something magical happened: sales teams started planning better, marketing became more aligned, and engineering could make better technical decisions with the bigger picture in mind. Yes, some will misinterpret it as a commitment, but that's a coaching opportunity, not a reason for secrecy.

11. Great Roadmaps are Run by Competent People. Ensure your roadmap is managed by people who understand the market, know the technology, can make strategic decisions, and communicate effectively. This might seem obvious, but I've seen too many roadmaps handed off to project managers or junior PMs who lack the context to make good decisions. The best roadmaps I've seen were led by product managers who could hold their own in technical discussions, understand business implications, and effectively communicate up and down the organization. They weren't necessarily experts in everything, but they knew enough to ask the right questions and facilitate good decisions.

These principles might sound obvious, but even experienced product leaders often miss these fundamentals. I certainly did early in my career. The key is working together to create roadmaps that focus on problems rather than solutions, embrace uncertainty while providing direction, and align teams around outcomes rather than outputs.

Looking back at all the roadmaps I've created, I see that the successful ones consistently followed these principles. The failures? They usually violated several of them. Of course, following these principles doesn't guarantee success, but ignoring them almost certainly guarantees failure.

If you want to translate these principles to Jira field / Excel columns / whatever you use, it would look something like this:

Remember, a great roadmap isn't about predicting the future perfectly—it's about providing a framework for making better decisions today. In my next section, I'll provide a practical example of implementing these principles.

How to implement it step-by-step

1. Add Product roadmap to your Transformation roadmap

2. Communicate the start of work on the practice to the team.

3. Assemble a strike team to work on the practice.

4. Define your Strategic Pyramid, or at least work on: Product Vision and Product Strategy

5. Set Strategies and Metrics

   Define your key strategic initiatives that align with business goals and establish measurable metrics for each strategy. These strategies should directly support your overall product vision and have clear success criteria.

   
   Example #1
   Strategy name: Personalization

   Goal: Enhance user engagement through tailored experiences

   Metrics:

   • Increase user session duration by 25%

   • Improve content engagement rate by 30%

   • Reduce bounce rate by 15%
     

   Example #2:

   Strategy name: Gamification

   Goal: Increase user retention and product stickiness

   Metrics:

   • Increase daily active users by 40%

   • Improve user retention rate by 25%

   • Achieve 50% completion rate for core features
     

6. Add Features Per Strategy

   For each strategy, identify specific features that will help achieve your goals, making sure to consider technical requirements and dependencies. Include both user feedback and market demands in your feature selection process.

   
   Example:

   Personalization features

   • AI-powered content recommendations

     • Machine learning algorithm development

     • User behavior tracking system

     • Content tagging framework

   • Custom dashboards

     • Drag-and-drop widget system

     • User preference storage

     • Widget marketplace

   • Smart notifications

     • Time-zone based delivery

     • Behavior-based triggers

     • Notification preference center

7. Prioritize features
   Evaluate each feature by rating its Impact, Confidence, and Ease on a scale of 1-10, then calculate the ICE score (Impact × Confidence × Ease) to create a prioritized list. Use these scores to make data-driven decisions about feature priority.

   

8. Decide What to Do and When

   Take your prioritized features (but use your judgment, you should decide, not scores!) and organize them into time horizons (Now, Next, Later), considering both resources and dependencies.

   • Now should contain precise, well-defined items that are committed for the next quarter,

   • Next should include items that are planned but may need more discovery for the following 2-3 quarters,

   • Later should encompass strategic initiatives and ideas that need significant research or are dependent on earlier deliverables.

   Balance the need for quick wins with longer-term strategic investments.

   

9. Repeat

Regularly review and adjust your roadmap based on actual results and new information, typically on a quarterly basis. Update your metrics, reprioritize features, and adjust timelines to keep the roadmap aligned with business goals and market needs.

Here's a rhythm example:

Monthly Check-ins

• Track metric progress

• Adjust feature specifications

• Update timeline estimates

Quarterly Strategy Reviews

• Evaluate strategy effectiveness

• Update ICE scores

• Reprioritize feature backlog

• Adjust resource allocation

Annual Planning

• Review and update product vision

• Set new strategic initiatives

• Plan major feature releases

• Adjust long-term roadmap

PS: If you need help with implementing the Product roadmap, contact me. I have 20+ years of commercial experience working with bigger and smaller companies, upgrading product, design, and engineering teams to the next level. I can also connect you with experts on this subject.

Product Roadmap Template

This template walks you through the process of creating the strategy and corresponding metrics, through generating features and prioritizing them in the simple Now, Next, Later roadmap.

Download links:

Coda template

Common Anti-patterns

1. The Feature Factory: Listing features without connecting them to outcomes

2. The False Promise: Pretending you can predict exact delivery dates

3. The Perfect Plan: Creating a beautiful roadmap that doesn't survive contact with reality

4. The Kitchen Sink: Trying to make everyone happy by including everything

5. The Time Trap: Spending more time maintaining the roadmap than talking to customers

Conclusion

A roadmap is just a tool. Its real power lies in the conversations it enables and the decisions it drives. The best roadmap doesn't predict the future perfectly—it helps your team make better decisions today.

I still get it wrong sometimes. But I've learned that being roughly right is better than being precisely wrong. Your roadmap should be a guide, not a guarantee. Use it to start conversations, not end them.

Linked cards

Here are other practices related to the Product roadmap:

• Product Strategy

  Product strategy provides the logical sequence of big bets (projects, value streams) that will take you to Product Vision.

• ICE prioritization

  ICE prioritization is a framework for ranking ideas based on their Impact, Confidence, and Ease of implementation.

• Product Requirement Doc

  PRD (Product Requirements Document) is a detailed blueprint that defines a product's purpose, features, and success criteria to align stakeholders and guide development.

• Empowered Teams

  Empowered Autonomous Teams can decide what to build to solve the problem they're being assigned, without any excessive oversight.

• Product goals

  Product goals provide targets on the list of metrics product team is asked to achieve.

Hope that's useful!

—

Piotr

PS: Support my work by clicking on the ♥️ ↙

If you’re wondering — I’ve renamed Product Blocks to Ship It and updated the brand colors to be consistent. :)

And without further ado, here’s my guide on structuring your teams using Team Topologies.

Designing organizations is hard.

I started my career as an engineer and quickly found myself designing organizations. I've made my share of mistakes. When you're knee-deep in the turbulence of scaling a company, no manual tells you exactly how to repeat the success of what worked for one team in order to structure other teams for maximum effectiveness.

Everyone is mindlessly copying the Spotify model, SAFe, Scrum—you name it. All without understanding why they're doing it or what problem they're trying to solve. It's cargo cult thinking at its worst. I've seen executives lose millions implementing frameworks that worked for other companies without considering their unique context. They grab playbooks from successful companies without grasping the principles behind them, then wonder why they don't get the same results. Go figure.

The hard truth is that most team structures evolve accidentally rather than intentionally. They're shaped by historical accidents, personalities, politics and temporary crises that somehow became permanent fixtures. But you do have control over how these structures evolve, and shaping them is an art. I'll take an intentionally designed organization over an accidental one any day, even if the design isn't perfect.

Team Topologies addresses just that. While everyone else was frantically reorganizing their org charts every six months, Team Topologies offered something different: a coherent system for thinking about how teams should work together. I've since used it to turn around multiple failing delivery organizations. The brilliance isn't in complex frameworks but in its laser focus on reducing dependencies and respecting cognitive limits.

What challenges does this help with?

I'd put Team Topologies on your radar and read on, if you're facing these challenges:

• Too many team dependencies

  Too many team dependencies can slow progress, as teams must wait for each other to complete tasks before moving forward.

• Limited team autonomy

  Your teams have no decisions about what they’re building or even how they’re building. They seek approval for most things.

• Communication issues

  The most common issues within the organization. You probably won’t be able to get rid of this, once you have a scale, but you can (and should) try to fight it as hard as possible.

• High cognitive load

  High cognitive load means that the team has too many things on their shoulders, making them slower to move or to think.

• Failed transformations

  Failed transformations occur when attempts to adapt or improve a product or process result in setbacks or do not achieve the desired outcomes.

Not Properly Designing Organizations Costs You Money and Happiness

Most leaders drastically underestimate the cost of poor organizational design. Let's assume you're waiting on the right things. Think about the last time you waited for someone to proceed with work. Now multiply it by the number of days and number of people. You're burning millions (often billions) of dollars due to people sitting idly.

But it's not just about money. I've watched talented engineers become cynical and burned out after years of fighting bureaucratic structures designed by people who have never shipped anything meaningful. They join companies to build things, not to attend coordination meetings and file tickets requesting permission to make changes.

Your best people will leave if they spend more time navigating organizational complexity than solving customer problems—the ones who stay become increasingly disengaged. I've seen entire engineering departments fall to mediocrity because the organizational structure made excellence impossible.

I've seen what happens to high performers in poorly designed organizations, and the pattern is clear: they either leave or become mediocre. Your 10x engineers become 0.5x engineers when they spend most of their day navigating absurd approval processes and explaining the same thing to several different stakeholders. The real tragedy isn't just losing your best people—it's that they tell everyone they know not to work for you. Your organizational dysfunction becomes your employment brand.

Team Topologies offers a way out of this mess. It provides practical patterns for reducing dependencies, clarifying responsibilities, and letting teams deliver value without drowning in organizational overhead.

Team Topologies That Most Know (But Implement Poorly)

Most people who have heard of Team Topologies fixate on the four team types and three interaction modes. They are important, but implementing them without understanding the underlying principles is like flying an airplane after you played a few hours on Microsoft Flight Simulator.

For the people who have not heard of them, let's get these basics first:

Four Team Types:

Team types are the basic categorization for every team you'll find in a tech organization—no more, no less:

• Stream-aligned teams deliver direct value to customers along a value stream. They own the outcomes.

• Platform teams create services that accelerate stream-aligned teams, removing complexity.

• Enabling teams enable some capabilities in other teams, then move on.

• Complicated-subsystem teams handle complex components requiring specialist knowledge.

Click here to see a full example of team types in one Netflix-like company

Three Interaction Modes:

These define how your teams should work together:

• Collaboration: Working closely together (high bandwidth, high cost)

• X-as-a-Service: Consuming or providing with minimal interaction (low cost, clear boundaries)

• Facilitating: Helping remove obstacles (temporary and focused)

Applied thoughtfully, these team types and interaction modes can transform your organization. Unfortunately, most places I've consulted treat them as a simple categorization exercise—"You're a platform team now, you're stream-aligned"—without addressing the fundamental patterns of work. When leaders check the "Team Topologies implemented" box without doing the hard work, they make real change even harder. It's organizational theater at its worst.

Beyond What Most Know: The Nine Principles and Six Patterns

Don't be fooled by the pretty diagrams of team types—that's just the surface. The real power of Team Topologies lies in the foundational principles that determine whether value flows or stagnates in your organization:

The Nine Principles:

The Nine Principles inform Team Topologies by establishing fundamental organization design values around flow, trust, stability, and complexity management.

1 - Focus on Flow, Not Structure

Flow is how quickly work moves from idea to customer value without getting stuck in organizational bottlenecks. Structure only matters if it helps ideas become reality faster. I've seen perfectly designed org charts produce nothing but meetings and documentation. Elegant structures mean nothing if the value moves slowly to your customers.

2 - High Trust Is Non-Negotiable

Trust shouldn't just be a corporate buzzword—it's the foundation that everything else relies on in great organizations. Low trust means trouble. Low trust environments build excessive documentation and wasteful, defensive processes that slow everyone down. I've watched organizations waste millions on process frameworks built around lack of trust in their people.

3 - Keep Teams Together

I'll take a team that's worked together for years over a newly assembled group of rock stars any day of the week. Stable teams develop shared context and communication patterns that dramatically accelerate delivery. The hidden cost of constantly reshuffling teams is astronomical, yet most organizations do it without a second thought.

4 - Respect Cognitive Limits

Teams can only handle so much complexity before breaking down. Each new tool, responsibility or domain your team is given taxes their mental bandwidth. Competent teams become ineffective when leaders keep adding to their plate without taking anything away.

5 - Make Changes Small and Safe

Teams that can ship small improvements daily will always beat teams making big, risky releases quarterly. This applies to both product changes and team adjustments. The goal is to deliver value continuously in small, safe increments rather than betting everything on massive rollouts that might fail spectacularly.

6 - Connect Teams Directly to Customers

Many teams never talk to the people using their products—they receive directives filtered through three layers of management. This game of telephone distorts customer needs and slows everything down. Teams with direct customer contact make better decisions faster because they understand the real problems. This connects back to trust—you must trust your teams to interpret customer needs correctly, rather than micromanage every interaction.

7 - Embrace Complexity, Don't Fight It

Modern software systems are too complex for perfect prediction and planning. Organizations waste enormous energy fighting this reality instead of designing for adaptability. I've watched countless projects fail because they assumed they could plan everything ahead. Like Mike Tyson once said, everybody has a plan until they get punched in the face.

8 - Foster Continuous Discovery

Great ideas don't come from fancy offsites or executive brainstorms. They come from teams that have time to experiment and try new things. Sorry, not sorry. When you crush teams with endless backlogs, they stop innovating and mindlessly crunch tasks for you. I've seen teams deliver twice the value when given just one day a week to explore new approaches. This isn't optional work—it's where your next breakthrough will come from.

9 - Eliminate Team Dependencies

Nothing kills productivity faster than one team waiting on another team. Most companies obsess over making individual teams more efficient while ignoring the massive delays that happen between teams. I've watched organizations hire more people and ship less because their teams were still waiting for each other. Fix the handoffs, not just the teams.

The Six Patterns:

The Six Patterns provide concrete implementation structures that organizations can apply to optimize team interactions and value delivery.

1 - Four Team Types

Don't overthink this. Every team in your organization fits into one of these four types.

• Stream-aligned teams deliver direct value to customers along a value stream. They own the outcomes.

• Platform teams create services that accelerate stream-aligned teams, removing complexity.

• Enabling teams temporarily boost skills in other teams, then move on.

• Complicated-subsystem teams handle complex components requiring specialist knowledge.

• Adding more types or creating hybrids just confuses everyone. I've seen companies try to create "hybrid platform-stream teams" and other nonsense that always ends in disaster. Stick to these four—they cover everything you need.

2 - Three Interaction Modes

Most team dependencies are messy because nobody defines how teams should work together. These three modes solve that by making it crystal clear when teams should collaborate closely, provide services to each other or offer temporary assistance.

• Collaboration: Working closely together (high bandwidth, high cost)

• X-as-a-Service: Consuming or providing with minimal interaction (low cost, clear boundaries)

• Facilitating: Helping remove obstacles (temporary and focused)

No more ambiguous "we need to coordinate better" mandates that solve nothing.

3 - Managing Team Cognitive Load

Just as overloaded CPUs slow down computers, overloaded teams make poor decisions and move slowly. Actively monitoring and reducing unnecessary complexity is key to maintaining team effectiveness. I've seen leadership pile responsibilities onto teams until they break, then blame the team for "underperforming" when the real problem was cognitive overload.

4 - Thinnest Viable Platform (TVP)

Most internal platforms become bloated monstrosities that slow teams down rather than accelerate progress. The TVP approach creates platforms that provide just enough capability without unnecessary complexity. A good platform should make stream-aligned teams move faster, not generate more dependencies to manage.

5 - Flexible Team Boundaries

Team boundaries shouldn't be fixed permanently; they must adapt as products and technologies evolve. Organizations that allow teams to adjust their responsibilities based on local knowledge avoid painful reorganizations. The best companies enable teams to negotiate boundary changes directly rather than wait for top-down directives.

6 - Continuous Adaptation

Organizational design is never "done"—it must evolve as business needs, technologies and people change. Building feedback loops that identify when adjustments are needed helps prevent organizational debt from accumulating. Small, frequent adjustments are far less disruptive than massive reorganizations forced by accumulated problems.

Thanks for reading so far! You’ll find the full version of this article on ShipIt.cards:

See full guide on Team Topologies

What You'll Find in the Full Article:

I've shared the basics of Team Topologies' four team types and three interaction modes, along with the nine principles that underpin effective organizational design. But this preview is just the beginning.

When you continue reading the full article, you'll discover:

• Detailed explanations of all nine principles with real-world examples

• Practical implementation strategies for each of the six core patterns

• Common obstacles organizations face and exactly how to overcome them

• Key success factors that separate organizations that succeed with Team Topologies from those that fail

• Convincing frameworks to help you gain buy-in from skeptical stakeholders

Don't settle for accidental organizational design. Learn how intentional team structuring can transform your delivery capabilities, reduce dependencies, and create an environment where your best people thrive instead of burning out.

See full guide on Team Topologies

Explore More in the Ship It Catalog:

Beyond this Team Topologies article, the Ship It catalog offers additional methodologies and frameworks for building better products, including:

• Stream-aligned Teams and Platform Teams implementation guides

• Product Trio collaboration models

• Value Stream Mapping techniques for identifying bottlenecks

• Cross-functional team structures that accelerate delivery

• SPACE framework for measuring engineering productivity

Other practices to build great products

See you soon!

—

Piotr

It’s been a while. Let me get you up to speed.

You can watch the video or read about it below.

Over the last year, quite a few people have asked me to help them improve the way they build products as an advisor (sometimes hands-on), which kept me busy for a while. With the remaining time, I’ve been working on two big products. And I’m ready to share the news with you.

I’m Shipping Two Big Products This Year

We're expecting a second baby in mid-May! Currently pumpkin-sized and growing strong. If you count our two cats, that’s a full house. Thrilled for this new chapter, even if it means revisiting the land of sleep deprivation. 🫠

Product Cards → Ship It

After months of development, I have some big news to share with you about my passion card product (now called Ship It).

For those unfamiliar:

Ship It is a collection of digital and physical cards to reinvent how you build products.

Each card represents a good practice from companies that consistently ship great products.

Every card is connected with a no-bullshit guide on learning and adopting the practice, including step-by-step recipes and ready-to-use templates you can plug & play.

These are not just-workshop-cards. It’s a complete system to inspire yourself and your team and transform the way you work.

Whether you're struggling with slow delivery, low product impact, communication issues, or high technical debt, Ship It provides step-by-step guidance to generate more customer value while reducing costs.

They're perfect for people with product, engineering, design, agile, and leadership hats.

Launch in a few weeks

The digital version of Ship-It will launch in April, and the physical version will be released soon after.

It will contain 76 cards with guides from me and some fantastic industry veterans.

Early Access is Available Now

I've just launched a landing page where you can:

1. sign up for early access

2. get a free card featuring a comprehensive guide on Team Topologies (created with the invaluable help of , the co-author of Team Topologies book)

The response so far has been great. Nearly 500 people have signed up to become early adopters. Those who tried Ship It gave it an average rating of 8/10. I’ll take that as good fortune. :)

If you're interested in building products customers love, want early access to Ship-It, or want to get the free Team Topologies guide, visit Ship It today:

Get Ship It Early Access

And expect to hear from me really soon!

PS: If you want to support me, repost this.

I often hear questions like: How do we build a good roadmap process? How should discovery be done? How do we measure software delivery? Why are we so slow?

These aren’t bad questions, but in most cases, they don’t touch the root of the problem.

The problem with processes

Processes are easy to write down, measure, and optimize. They give a sense of control, which many leaders hunger for. Processes can help less experienced people keep up with the organization. But here’s the problem—they also slow down your top performers.

Think of processes like a lifeboat—they keep those who can’t swim from drowning but also hold back those who are ready to fly.

Processes can kill creative thinking. They grow out of control, especially as the company scales. Processes create bureaucratic structures.

And that’s a fast track to losing the speed you had as an agile startup. And that’s the number one offender when it comes to good people leaving your company - because they’re being slowed. That’s not how you build great products.

Let’s use agile as an example. You’re not agile if you’re adopting process frameworks like Scrum or, worse yet, SAFE. You can be agile (in the word’s true meaning) if you follow the principles stated by the Agile Manifesto. These were created before those frameworks.

What if you already have too much process?

A few suggestions:

1. Don’t let process people take over the organization. Look out for overzealous COO, CFO, and agile coaches. Talk sense to them.

2. Keep the number of processes to a minimum. Do an inventory, determine the Minimum Viable Process, and kill the rest.

3. Stop trying to control every exception with processes. In 80% of cases, nothing bad will happen if you let people figure the problem out on their own instead of creating a heavy process to hold them by hand. That’s where you get resilience and innovation.

4. Guide your teams with operating principles instead of relying on processes. These principles should be part of your company’s DNA and influence every team decision.

Examples of operating principles

Operating principles are not just cringy hashtags you print and place on your walls for people to smirk about when you’re not in the room. It’s a list of guides that tell the team how to do their job and what to prioritize.

What operating principles should good product organizations have? Here are a few to inspire you:

Start with the problem, not with features.

Forget about new features for a moment. The main question should always be: Which user problem from our list do we want to solve? For each problem, there are multiple solutions. Then, start thinking about the features.

PS: An excellent framework to force you into this mindset is the Opportunity Solution Tree.

Think big, work small.

Have a vision for where you want to be in a few years. Break that down into strategies to get you there. Then, plan specific projects to move the metrics you care about.

This is your roadmap—strategy-driven, vision-based, cause-and-effect. You can read more about it here.

Ship fast, ship early, ship often.

Stop holding onto things until they’re perfect. Deliver features quickly, often, and early. Measure, gather feedback, and iterate.

Remember the Pareto principle—80% of features won’t succeed. Find the successful 20% as quickly as possible. Use prototypes before you put a single line of code.

Outcomes > outputs.

What counts in the end isn’t how many features you release but the results you achieve. Does your product solve your customers’ real problems? Are your customers happy?

These are the main reasons you should be happy about, not that you’ve shipped something (that nobody uses).

Trust > control.

Stop micromanaging. Teach people to think like you, give them context (for example, using Strategic Pyramid), be present, care for them, and help them from the backseat. Delegating and trusting multiply the talent.

This fosters resilient, motivated teams that can innovate, bringing more value to the company. Plus, you’ll stop being the bottleneck.

Innovation > predictability.

Predictability kills innovation. Choose a side. If you want innovation, stop obsessing over deadlines, give your team some breathing room, and yes, stop obsessing over processes.

Learning > failure.

Foster a culture of experimentation. A “failed” feature isn’t a failure if you’ve learned something and you can apply this learning in the future.

Don’t fear mistakes. Don’t penalize mistakes too much. Otherwise, your team will stick to safe bets, and safe bets rarely make first-page news.

Data > ego.

I believe in leaders’ intuition. But remember, you’re human, with biases and habits. Data are facts. Data should guide your decisions no matter how attached you are to your ideas. Trust your gut, but don’t rely on it too much.

How to start?

Intrigued how to implement your own list of operating principles?

1. From the list above, copy the principles you like. Expand on them using your own words in the context of your company.

2. Ask your leadership team to work on the final list of principles.

3. Communicate it to your teams.

4. Embed it into your existing employee handbook, hiring, and performance management processes. Adjust your meetings and the way you make decisions to follow these principles. Start living by it.

5. Remind your teams about it every once in a while.

6. Revisit the list every 6/12 months and adjust if needed.

Conclusion

If you live by these principles, you don’t need any specific process or framework to build products loved by millions worldwide. If you live by these principles, you should have a good strategy, constant customer contact, frequent deliveries, and a motivated, impact-driven team.

Instead of creating processes that force your team to fill out another spreadsheet they don’t understand why, guide them using operating principles. Next time, they may know why filling that pesky spreadsheet is important.

Operating principles become your DNA, your true foundation. And THEN, you can start figuring out where you need the process and where the principle is enough.

Good luck!

90% of engineers I talked to think their job is to write good code. That's a problem. Not only is it not how you build good products, but it will likely cause you to fail big time, and people in your team will get fired.

Don't get me wrong. Out of my 25 years in the industry, 15 years I've been an engineer. I've seen things. Writing good code is certainly important, but it is not the ultimate goal of engineering teams. What is? If you have to remember one sentence from this post, get this:

The ultimate goal of tech teams is to create value for customers and your business.

This is what I mean by Product Engineering mindset. You need to get that message to your teams - engineers and engineering leaders. That's how you win. 

Stakes are high because if you're not bringing value to customers, you're burning money. Quite a lot of money since engineers get big paychecks. Burn enough cash, and you'll get defunded.

Defunded means they'll fire you and close down the company. It may take a year or five, but it will happen eventually. It did happen to others before, and it will happen to you. If you're not bringing enough value to your customers, your competitors will eventually. You're ripe for disruption. 

How to fix that?

No, don't kill the batman. That's plain wrong. 

Here's how to fix it:

Engineers - instead of focusing on code, focus on customer value.

And with every team I work with, I expect engineering leaders to understand it and spread the love to their teams.

In this post, I will explain why writing good code is not enough and how you can increase customer value by shifting the mindset from code-centric to value-centric. And yes, you'll still be able to do fancy tech. The difference is that someone will use this tech.

A tale of two engineering teams

Imagine two engineering teams working on similar products in the same market. Both teams have talented and experienced engineers who write good code. Both teams use agile methodologies and follow best practices. Both teams deliver their products on time and within budget.

However, there is one big difference between the two teams.

Team 🅰️ is focused on writing good code.

• They spend most of their time and energy optimizing their code, adding impressive patterns and even more scalable technology.

• Microservices, message queues, cloud, containerization, all the fancy stuff.

• Even though they don't have that many customers, they aim for high uptime and fantastic website performance.

• Every edge case is covered.

• New feature? Let's add five more microservices.

• Are they talking to their customers? Come on, they don't want to be bothered, and they have all this refactoring to be done - someone just violated one of the SOLID principles. No, no, no, no. Not on their watch.

Team 🅱️ is focused on creating value.

• They spend most of their time and energy understanding their customers' problems, needs, and desires.

• Getting this knowledge takes time, so their code might not be so fancy. They still have a monolithic architecture and a single database. They have some microservices, but they know this architecture also has some costs, so they’re careful.

• They have some tech debt, and sometimes it hurts. They don’t neglect it but don’t obsess about it.

• New feature? They A/B test it using simple scripts until they know it works. Only then do they “properly” code it.

• They frequently talk to customers and other stakeholders.

• They feel successful if customers like and use their product more with every change they make.

• They are very strategic about what they build and iterate until they find value. Only then do they care about scaling things that need scaling.

Which team is more successful? Which team brings more impact? Which team makes customers happier, causing them to use their product more, leading to higher revenue for their business? You know the answer; I do not need to tell you.

Why writing good code is not enough

Why is writing good code not enough? Isn't that what engineering teams are supposed to do? Well, yes and no.

Yes, writing good code is a necessary condition for engineering teams. But it is not enough.

Writing good code does not guarantee that you are creating value. You might be writing elegant, efficient, and error-free code, but it is not creating value if it does not solve a real problem, meet a real need, or deliver a real benefit. It is just a waste of time and resources.

Think about it. How often have you seen technically impressive products that fail to attract or retain customers? How often have you seen products full of features but no clear value proposition? How many times have you seen products that are well-coded but poorly designed? I've seen enough. Hell, I've built some of them myself. That was a hard lesson for me.

If you're building an impressive product that does not bring value, you're not building a good product, no matter how great the tech you use. This product will fail eventually.

And no, thinking it brings value without validating it with customers doesn't mean it brings value. Everyone thinks their feature will work. 80% will not. Building products is a numbers game. 

What products will you get from code-centric and value-centric mindsets?

Code-centric products are driven by the technical aspects of the code rather than the product outcomes. Code-centric products are optimized for the engineer's satisfaction rather than the customer's satisfaction. Code-centric products are doomed to fail.

Value-centric products are driven by the value that the code creates for customers and the business. Value-centric products are connected to the customer's reality and aligned with the customer's goals. Value-centric products are optimized for the customer's satisfaction and the business's success.

How to make the mindset shift

So, how can you shift the mindset from code-centric to value-centric?

It is not easy, but it is possible.

It requires a change in how you think about and approach your work. It requires a change in your attitude, your behavior, and your culture.

Here are some tips to help you and your team make the mindset shift:

• Start with the why. Before you write any code, ask yourself why you are writing it. What problem are you trying to solve? What need are you trying to meet? What benefit are you trying to deliver? How will this code create value for customers and your business?

• Prototype solutions before writing code. Coding is the most expensive way of testing a hypothesis. Grab your product designers and send them with paper/Figma prototypes to your customers. Then, once you know this is what your customers want, code.

• Define success metrics. Once you have a clear why, define how you will measure the success of your code. What are the key performance indicators (KPIs) that will show that your code is creating value? How will you track and report these metrics?

• Prioritize your work. For every problem, there are five ways you can solve it. Find the lowest-hanging fruits. Use data to help you with prioritizing.

• Validate your assumptions. Don't assume that you know what customers want or need. Validate your assumptions by talking to customers, conducting user research, testing prototypes, and getting feedback. Learn from your failures and iterate on your solutions.

• Collaborate with other teams. Don't work in silos. There is no business and IT distinction. In tech companies, tech teams are the business. Collaborate with other teams that create value, such as product, design, marketing, sales, and support. Align your goals, share your insights, and leverage your strengths.

• Keep learning and improving. Don't settle for good enough. Keep learning and improving your skills, your processes, and your products.

• Learn the balance. You don’t need microservices, especially at the start. You don’t need to switch frameworks. You can live with some of the tech debt out there.

Conclusion

Writing good code is not enough for engineering teams. The real job of engineering teams is to create value for customers and your business. And that requires a mindset shift from being code-centric to being value-centric.

What's your take? Let me know in the comments below.

💬 In this week's issue:

♣️Product Card: What’s new?

I am happy about the progress on the digital version of Product Cards.

If you’re new here and want to learn about Product Cards, check it here.

I want digital cards to have a similar feeling to the physical edition, so I’m playing with some fancy animations of tilting cards with holo effect:

You can still sign up for free Product Cards early access (digital version) and get access to the preview 100+ cards to learn and improve all things product, engineering, agile, and design:

Get Product Cards Early Access

📕 Interesting reads

The Next Next Job, a framework for making big career decisions

by Andrew Chen • 9 mins

The "Next Next Job" framework is a way to organize thinking about career moves in chaotic situations with many different opportunities. It starts with the question, "What do you want to be your next next job? And why can't you get it right now?" From there, you can identify the different buckets of potential next next jobs and start researching and networking with people in those roles. It also emphasizes the importance of identifying gaps in skills, network, experiences, mentors, and ideas and developing a superpower that can overcome those gaps.

Senior Engineer to Staff Engineer

by • 8 mins

Alex provides some really good insights into the role of a staff engineer and the skills required to get promoted to the position. While hard skills such as programming languages and tools are important, soft skills such as leadership, coaching, and negotiation are crucial for the role. A must-read for every senior engineer who thinks about the next big step in their career.

Measuring developer productivity? A response to McKinsey

by and • 14 mins

The article discusses McKinsey's methodology for measuring software developer productivity and offers a more sensible approach. While McKinsey claims to have an approach for measuring software developer productivity, George and Kent argue that the thinking behind the methodology is absurdly naive and ignores the dynamics of high-performing software engineering teams. And I agree. The article suggests a mental model of the software engineering cycle and explores the need for measuring productivity. It also analyzes the measurement tradeoffs in software engineering and argues that the McKinsey framework will most likely do more harm than good to organizations.

Aging Code

by Vadim Kravcenko • 8 mins

Vadim compares the concept of aging money in budgeting to the importance of aging code in the world of technology. He argues that older codebases are often more robust and stable, having been debugged and improved over time. He cautions against the temptation to constantly rewrite code with new frameworks, emphasizing the value of stability and the potential loss of conceptual integrity and simplicity that can come with constant changes. As always, the key is to find a balance between mature systems and innovative technology.

Staying on the path to high-performing teams.

by Will Larson • 5 mins

Will provides a framework for managers to understand and improve the performance of their teams. He categorizes teams into four states: falling behind, treading water, repaying debt, and innovating. Each state requires a different approach to improve performance, and managers must identify the appropriate system solution for each state before providing tactical support.

Transformation Anti-Patterns: Management Consultancies

by Marty Cagan • 2 mins

Transformation efforts often fail due to common anti-patterns, including one associated with big management consultancies. Although these consultancies employ intelligent individuals and companies are willing to invest in their services, the structural nature of these firms makes them unable to effectively support transformations. This can be compared to a power utility company seeking help from the fossil fuel industry to transition to renewable energy. The consulting firms are unlikely to advocate for changes that go against their own institutional interests, making it necessary for companies to bring in-house capabilities for successful transformations. While hiring individuals from these firms can be beneficial, it is essential to have someone experienced in the product model to effectively utilize their skills.

To Build a Top Performing Team, Ask for 85% Effort

by Greg McKeown • 7 mins

To build a top-performing team, managers need to shift their mindset away from the outdated belief that "maximum effort = maximum results" and towards a new formula: "optimal effort = maximum results." The 85% rule suggests that to reach maximum output, employees need to refrain from giving maximum effort, as operating at 100% effort all of the time can lead to burnout and ultimately less-optimal results. Managers can help their teams operate at this level by creating a "done for the day" time, asking for a little less than maximum capacity, encouraging 85%-right decisions, watching out for high-pressure language, and ending meetings 10 minutes early.

💡 Food for thought

🙂 Weekly smile

Good luck, have fun, and see you in a bit!

Piotr 👋

I spent quite some time showing Product Cards to people, seeing how they play with it, and gathering feedback.

The interest I got is heartwarming. There are still a couple hundred people constantly nudging me about letting them in as early adopters - I thank you for the support and ask you to be more patient. :)

This week, I wanted to quickly get you up to speed with the current state of Product Cards.

Roadmap

Here is the product roadmap so far:

What’s new in Product Cards?

Since the announcement in May, I’ve spent much time refining the card design based on your feedback. I wanted to make the cards more straightforward, helpful, and fun.

New cards

I’ve been working hard to create more cards for Product Cards. Currently, there are 112 cards in total, in different stages of progress.

Introduced Card category

I introduced a concept of card category to help you navigate hundreds of cards.

A card category is a visual cue that points to a specific area the card belongs to.

Want to work on improving your team’s Direction? Look for 🟧 orange borders. Looking for all the Challenges out there? Grab the 🟥 red-border cards.

This way, you can easily find the cards you’re looking for, especially in the physical version where you don’t have a set of filters in the UI.

Added back-side

For the physical version of Product Cards, I’ve designed a back-side for each card. 

The back side contains practical tips and examples on applying the concept from the front side.

It also provides links to other cards (marked with a bolder font and an icon) and a handy QR code to expand the concept further. 

New cover art-style

After playing around with a few design concepts, I finally settled on one art style. It keeps the sci-fi vibe, but it’s more cohesive and intriguing. 

Here are some examples of the new designs:

I will update all the existing cards with the new style soon.

Updated visual design

Card designs have been overhauled. They’re cleaner and simpler now.

Bigger cards

To fit more useful content on the physical cards, I’ve decided to increase the card size. They are now 88mm x 145mm, compared to 63.5mm x 88mm before.

This also makes them easier to read and handle.

Here is a comparison of the old and new sizes:

Removed card rarity

The first version of the card had a rarity indicator inspired by RPG or TCG games. The rarity was supposed to reflect how common or uncommon a particular practice was in the industry and how impactful it could be for your team. For example, product vision is less common than Scrum, so that it would have a higher rarity.

However, I decided to remove this feature because it created unwanted bias - people favored “rarer” cards over “common” ones. Rarity does not always mean better. For example, the SAFE framework is rather rare, but I don’t recommend it.

Public alpha (Digital version) in Q4

I plan to launch a public alpha version of Product Cards (Digital version) in Q4 this year.

You will be able to access and use Product Cards online without waiting for the physical version.

The digital version will have some features that are not possible with the physical version, such as:

• Search and filter cards by category, keyword, or connection

• Save and share your favorite cards or collections

• Rate and review cards and give feedback

• Suggest new cards or edits to existing ones

• And more!

I will share more details about the public alpha soon, so stay tuned!

People who already signed up for early access will have the priority. You can still sign up for the early access list here.

What’s next?

I plan to roll early alpha to more and more people in the coming months.

My areas of focus for the next year are:

1. Official digital version of product cards

2. Physical cards

3. Detailed guides for each card (digital version)

4. Mobile companion app

I hope you enjoyed this update and are as excited as I am about Product Cards.

I’m still working hard to make Product Cards the best tool for improving your teams.

Let me know in the comments section below if you have any questions, comments, or suggestions.

I truly appreciate your support so far. ❤️

Until next time, Piotr.

P.S. If you haven’t signed up for the early access list yet, don’t miss this opportunity to get Product Cards before anyone else. Just click on the button below and enter your email address. It’s that simple!

Sign for Product Cards Early Access

💬 In this week's issue:

• Using Event Storming to explore complex domains

• Lessons learned from an engineer applying to Datadog, Spotify, and Shopify

• Average Manager vs. Great Manager in 10 illustrations

• CTO’s framework to manage your priorities and energy

• How to start Continous Discovery

• The difference between Product Owner and Product Manager Explained

• … and more!

♣️Product Card Spotlight: Event Storming

Event storming is a powerful technique for collaborative modeling and domain-driven design. It helps teams understand complex business problems, identify gaps and inconsistencies, and design solutions aligned with the domain experts' vision.

But what is event storming exactly? How does it work? And why should you use it?

Event storming is a workshop format involving stakeholders (usually developers, domain experts, and product managers) who use sticky notes to map out the events, commands, aggregates, policies, and external systems involved in a business process. The goal is to create a shared understanding of the domain, discover the core concepts and behaviors, and identify the pain points and opportunities for improvement.

Some of the benefits of event storming are:

• It is fast and fun. You can cover much ground quickly and generate energy and enthusiasm among the participants.

• It is visual and tangible. You can see the big picture of the system, as well as the details and interactions. You can also quickly move, modify, or remove sticky notes as you go along.

• It is inclusive and collaborative. You can involve people from different backgrounds and perspectives and leverage their collective knowledge and creativity. You can also foster a common language and vision among the team.

To run a successful event storming session, you need to:

• Prepare the space and materials. You need a large wall or board, plenty of sticky notes in different colors and sizes, markers, and some dot stickers for voting or prioritizing.

• Define the scope and goal. You need to decide what business process or scenario you want to explore and what outcome you want to achieve (e.g., a high-level model, a user story map, a backlog, etc.).

• Invite the right people. You need diverse roles and expertise, including domain experts who can provide the business context and validate the assumptions.

• Facilitate the session. You need to guide the participants through the steps of event storming, such as:

  • Start with the events. Ask the participants to write down the events that happen in the business process, using the past tense and a noun-verb structure (e.g., "Order placed," "Payment received," etc.). Then stick them on the wall in chronological order.

  • Add the commands. Ask the participants to write down the commands that trigger the events using the imperative mood and a verb-noun structure (e.g., "Place order," "Receive payment," etc.). Then stick them above the corresponding events.

  • Add the aggregates. Ask the participants to write down the aggregates that are responsible for executing the commands and emitting the events using a singular noun (e.g., "Order," "Payment," etc.). Then stick them below the corresponding events.

  • Add the policies. Ask the participants to write down the policies that define the business rules or logic that govern the system's behavior, using an if-then structure (e.g., "If an order is placed, then send confirmation email"). Then stick them between the events and commands that they relate to.

  • Add the external systems. Ask the participants to write down the external systems that interact with or influence the system, using a proper name or acronym (e.g., "CRM," "ERP," etc.). Then stick them on the edges of the board.

  • Review and refine. Ask the participants to review the model for completeness, accuracy, consistency, and clarity. Encourage them to ask questions, challenge assumptions, make suggestions, and resolve conflicts. Use dot stickers to mark hot spots, issues, or priorities.

• Wrap up and follow up. Summarize the main findings and insights from the session. Take photos of the board and document the model. Decide on the next steps and actions to take.

Event storming is a great way to kick-start your product development process. It can help you to discover your domain, design your system, define your requirements, and deliver value to your customers.

To learn more, watch this video from Alberto Brandolini.

This practice is part of Product Cards - 100+ cards to learn and improve all things product, engineering, agile, and design.

Start using Product Cards

📕 Interesting reads

I failed 3 job applications, here's what I learned

by • 9 mins

Alex shares his experience of failing three job applications and the lessons he learned while applying to Datadog, Spotify, and Shopify. He provides key takeaways for those in the job market, including not wasting time on specialist positions if you have a generalist skill profile, not applying to companies you don't resonate with, and practicing interviewing skills - must-have for people thinking about finding a new gig in tech.

Average Manager vs. Great Manager in 10 illustrations

by • 2 mins

Julie Zhuo, the author of The Making of a Manager, illustrates the difference between average and great managers in 10 sketches. She shows how great managers focus on outcomes, feedback, collaboration, and vision, while average managers focus on tasks, news, control, and plans.

Manage your priorities and energy

by Will Larson • 11 mins

Will Larson, the CTO of Calm and a former engineering leader at Uber and Stripe, discusses how to manage your priorities and energy as a leader. He introduces a framework for decision-making that balances the needs of the company, the team, and yourself. He also shares some tips on how to avoid burnout and stay motivated.

Imperfect Product Org Survival Guide

by • 7 mins

Paweł Huryn, a product coach and author, offers some practical advice on surviving and thriving in an imperfect product organization. He covers topics such as dealing with politics, managing stakeholders, prioritizing work, and building trust.

The difference between Product Owner and Product Manager Explained

by • 8 mins

David explains the difference between a product owner and a product manager. A good comparison of roles’ the skills, responsibilities, and challenges of each role.

Everyone Can Do Continuous Discovery—Even You! Here’s How

by • 17 mins

Teresa discusses the concept of continuous discovery and how it can be implemented in any organization. She breaks down the framework into 11 habits and suggests identifying hidden assumptions. In the article, you’ll also find addressing different scenarios, such as organizations that operate like a feature factory, organizations in the messy middle, and organizations that revert to old habits. Pure gold for companies who want to start product discovery.

Technical Debt: How much is a good thing?

by Jo Rabin • 8 mins

Jo explores the concept of technical debt and how to manage it effectively. He argues that technical debt is not always bad and that it can be used strategically to achieve business goals. He also gives some guidelines on how to measure, prioritize, and communicate technical debt.

Team Health Check Methods: How To Assess Your Team’s Performance And Wellbeing

by Tim Metz • 5 mins

A comparison of different methods for assessing and improving team health and performance.

💡 Food for thought

🙂 Weekly smile

Good luck, have fun, and see you in a bit!

Piotr 👋

💬 In this week's issue:

• How to organize your teams using the Team Topologies framework

• How to Pass Any First-Round Interview

• On Becoming a VP of Engineering

• Lessons from Implementing Netflix’s “Dream Team” Model at 3 Hypergrowth Tech Companies

• What to Do When You Don’t Have Enough Traffic To A/B Test

• Alignment > Autonomy

• Transformation Anti-Patterns: Management Consultancies

• 20 employee engagement survey questions you should ask

• From Prioritization to Accountability (and Autonomy)

♦️Product Card Spotlight: Team Topologies

Have you ever wondered how to organize your teams for fast flow, high collaboration, and increased customer value? If so, try to check out Team Topologies, a straightforward, easy-to-follow approach to modern software delivery emphasizing optimizing team interactions for flow.

Team Topologies proposes four types of teams and three interaction modes to help you design your organization for agility and effectiveness.

Team Types:

• Stream-aligned team - Aligned to a single work stream and empowered to deliver value independently and quickly.

• Platform team - Enables stream-aligned teams to deliver work with substantial autonomy by providing self-service capabilities and APIs.

• Complicated-subsystem team - Deals with complex and specialized system parts that require deep expertise and low cognitive load.

• Enabling team - Helps stream-aligned teams overcome obstacles and acquire new skills or technologies. Acts as a temporary coach or mentor.

Interaction Modes:

• Collaboration - Two or more teams work together to discover new solutions or deliver a piece of work. Requires high communication and feedback.

• X-as-a-service - One team provides something as a service to another team, such as an API, a platform, or a tool. Requires clear boundaries and contracts.

• Facilitating - One team helps other teams to overcome a challenge or improve their working methods. Requires active listening and empathy.

Team Topologies can help you achieve business and technical agility by aligning teams with business domains, reducing cognitive load, applying Conway's law, and enabling evolutionary change.

How to take it from there?

• I recommend reading a book by Matthew Skelton and Manuel Pais - Team Topologies.

• I had the pleasure of discussing Team Topologies in more detail on Mariusz Gil's podcast here (🇵🇱 Polish version only)

• Last month, I had a chance to present it at the PHPers Summit conference. I've included the slides here.

📕 Interesting reads

How to Pass Any First-Round Interview

by Coach Erika

A fantastic piece by the author of The Career Whispers. Full of practical advice on how to ace your first-round interviews. Super useful for people who are looking for a job in tech.

On Becoming a VP of Engineering

by Emily Nakashima

Emily shares their experience of being promoted to VP of Engineering at Honeycomb. Interesting piece for people who inspire to become VP or CTO, showing some of the role responsibilities and traits that can help you land it.

Lessons from Implementing Netflix’s “Dream Team” Model at 3 Hypergrowth Tech Companies

by Tom Willerer and Kevin Bechtel

A great piece outlining the four critical components of a Dream Team: executive leadership, informed captain, cross-functional team members, and highly aligned, loosely coupled relationships. Inside you’ll also find five steps for creating fast, aligned teams: setting strategy, establishing teams, getting aligned, providing context, and getting out of the way.

What to Do When You Don’t Have Enough Traffic To A/B Test

by Teresa Torres

Some great advice from the author of a great Continous Discovery Habits on a typical problem startups may face - not enough traffic to prove A/B test statistical significance. In the article, you’ll find how to apply other discovery techniques like interviews, paper prototyping, and competitive research.

Alignment > Autonomy

by Jean-Michel Lemieux

This a great piece by the former CTO of Shopify on the importance of alignment. Alignment is the hardest part of building a company. Without it, autonomy is squandered. Companies must focus on alignment and autonomy to ensure that strategy is understood and followed. Every leader must work towards aligning with peers and bosses to make better decisions. It takes active work to build and maintain, which is mandatory in leadership.

Transformation Anti-Patterns: Management Consultancies

by Marty Cagan

Legendary Marty Cagan with a fantastic piece in the transformation series. Transformation efforts often fail due to common anti-patterns, including one associated with big management consultancies. Marty claims that even though these consultancies employ very smart people, effectively supporting transformations stands in the way of their business—a must-read for companies planning significant change.

20 employee engagement survey questions you should ask

Lexi Croswell

Employee engagement is the enthusiasm and connection employees have with their organization. It is a measure of motivation and commitment. In her article, Lexi provides a list of 20 employee engagement survey questions covering topics such as pride, recommendation, commitment, motivation, leadership, enablement, alignment, and development.

TBM 230: From Prioritization to Accountability (and Autonomy)

by John Cutler

John with another thought-provoking piece on product investment and governance frameworks. His post advocates for companies to have a progressive funding model and accountability for how company money is used. This encourages a shift in mindset from merely delivering features to becoming stewards of investment and growth.

🐤 Tweet of the week

🙂 Weekly smile

🎯What am I working on?

What does the future hold? Currently, I am focused on releasing Product Cards, 100+ cards to learn and improve all things product, engineering, agile, and design in a fun and engaging way. More than a hundred people are still waiting to get their hands on Product Cards via early access. Physical cards are coming soon. I hope to bring some good news in the coming weeks and months.

You can learn more here:

Product Blocks

Announcing Product Cards - A Game Changer for Tech Teams

As leaders and managers, we face many challenges in our daily work. The most common questions we need to answer are: Which problems to solve first? Which solutions will solve our problems? How to convince the stakeholders to listen to us? How to improve…

Read more

3 years ago · 11 likes · 2 comments · Piotr Kacała

Good luck, have fun, and see you in a bit!

Piotr 👋

One of the biggest challenges for product, design, and engineering leaders is measuring and improving team productivity.

Team productivity is a controversial and complex concept. It involves many factors that affect how well your team works together and delivers software products. You can’t just use one metric to measure it. You need a holistic and multidimensional approach covering all team productivity aspects. Luckily for all of us, that’s what the SPACE framework offers.

The SPACE framework is a research-based technique that allows you to measure and understand team productivity from five dimensions:

• Satisfaction

• Performance

• Activity

• Communication

• Efficiency

It allows you to avoid common pitfalls and biases when measuring team productivity, such as focusing on output over the outcome, quantity over quality, or activity over value.

SPACE framework card comes from the Product Cards deck I created. There are 100+ more cards like this to learn and engage with your team.

Here’s a short video:

In this blog post, I’ll tell you about the SPACE framework, why you should use it, and how to implement it in your organization.

Grab a good cup of coffee, and let’s explore the SPACE together. ☕️

What is the SPACE framework?

SPACE framework is a research-based approach to measuring, understanding, and improving team productivity.

It was developed by a group of researchers from GitHub, Microsoft, and the University of Victoria, and it encourages product, design, and engineering leaders to take a holistic approach to productivity.

SPACE stands for:

• Satisfaction and well-being: How happy and healthy are your team members? How do they feel about their work environment, culture, and tools?

• Performance: How good are the outcomes of what your team is delivering? Are your customers and business happy? Is your team meeting the organization’s quality, security, and reliability standards?

• Activity: What are the artifacts of your team’s work? How do they spend their time and energy? How do they balance different types of tasks and priorities?

• Communication and collaboration: How well do your team members communicate and collaborate with each other and stakeholders? How do they share information, feedback, and knowledge? How do they coordinate their work and resolve conflicts?

• Efficiency and flow: How smoothly and quickly are your team members completing their work? How often do they encounter interruptions, distractions, or blockers? How do they cope with uncertainty and complexity?

These five dimensions capture the most critical aspects of team productivity. They are interrelated and interdependent. For example, a team member's satisfaction can affect their performance, their activity can affect their communication, and their efficiency can affect their flow.

Why should you use the SPACE framework?

Here’s how I convince people:

• It puts people first.

• It aims to increase the happiness of customers, employees, and business stakeholders. You get the whole package.

• It’s suited toward team performance as a whole.

• It recognizes that team productivity is not a single number or dimension but a complex phenomenon that depends on various factors and contexts.

• It helps you avoid common pitfalls and biases when measuring team productivity, such as focusing on output over outcome, quantity over quality, or activity over value.

• It is based on actual research and empirical evidence from real-world software development projects.

• It provides a common framework to compare your productivity across different projects, teams, or organizations.

If you want to measure productivity the right way, SPACE is the answer.

Five S.P.A.C.E. dimensions of team productivity

Now that you know the SPACE framework and why you should use it, let's dive deeper into each dimension of team productivity and see how you can measure them.

Satisfaction

Satisfaction is how happy and healthy your team members are. It reflects their emotional state, motivation level, and well-being. Satisfaction is important for team productivity because it affects engagement, creativity, and retention.

To measure satisfaction, you can use surveys or interviews to ask your team members about their feelings, opinions, and preferences regarding their work environment, culture, and tools.

You can use metrics such as:

• employee satisfaction score (ESS),

• employee net promoter score (eNPS),

• employee engagement index (EEI)

Example questions you can ask on your own to measure satisfaction:

• How satisfied are you with your current job?

• How likely would you recommend working at this company to a friend or colleague?

• Do you feel valued for the work you do?

• How much autonomy do you have to decide how you work?

• Do you have the resources and support to do your job well?

• How do you rate your work-life balance?

Performance

Performance is how good are the outcomes of what your team is delivering. It reflects their impact, quality, and reliability.

To measure performance, you can use metrics such as:

• all sorts of product metrics (feature usage, customer retention, customer activation, conversion rate, CSAT, NPS)

• lead time (time needed from getting from “todo” to production),

• cycle time (time needed from getting from “in progress” to production),

• time from incident to recovery (MTTR),

• the number of released defects,

• code coverage

Activity

Activity is what your team members do daily. It reflects their workload, prioritization, and allocation.

To measure activity, you can use metrics such as:

• deployment frequency

• lines of code (LOC)

• commits

• number of pull requests

• issues completed

• story points

• tests

Communication & Collaboration

Communication is how your team members communicate and collaborate with each other and stakeholders. It reflects their information sharing, feedback exchange, and knowledge transfer. Communication is essential for team productivity because it affects learning, innovation, and coordination.

To measure communication, you can use metrics such as:

• PR merge times

• Quality of meetings

• Focus hours total in a week

• Cross-team review times

• Cross-team collaborations

Or ask:

• How effective are your meetings?

• How do you rate communication between our teams?

• What’s the quality of feedback you’re getting?

Efficiency and flow

Efficiency is how smoothly and quickly your team members complete their work. It reflects their speed, flow, and waste.

Example questions you can use to measure efficiency:

• How many handoffs are there in a process, and how many involve different teams?

• How easy or hard is it to stay focused and finish work without distractions?

• How often, when, and how much are you interrupted, and how does that affect your development work and flow?

• How long does it take for a system to complete a task, how much time is spent on adding value, and how much on waiting?

How to implement the SPACE framework in your organization?

If you want to implement the SPACE framework in your organization, here are some steps that you can follow:

1. Explain why you want to measure team productivity. People may fear you’re not trusting them. Be open and clear about why it’s important and how you’ll handle objections. Get everyone to agree on continuous improvement. SPACE framework is designed to help everyone in the organization. Not to spy on your team. Measuring development productivity correctly and using the results can boost product quality, delivery speed, and people's happiness.

2. Define your productivity goals and objectives. Before you start measuring your productivity using the SPACE framework, define what productivity means for you and what you want to achieve.

3. Choose the data sources and methods that you will use to measure each dimension. Based on your productivity goals and objectives, you need to choose the data sources and methods that are reliable, valid, and relevant to your context and that can provide you with both quantitative and qualitative data.

4. Collect and analyze your data. Once you have chosen your data sources and methods, start collecting and analyzing your data. You need to apply the appropriate techniques and tools to process, visualize, and interpret your data and use multiple dimensions of the SPACE framework to get a holistic view of your productivity.

5. Communicate and act on your productivity insights and recommendations. Communicate and work on your productivity insights and recommendations. Share your findings and suggestions with your team and stakeholders using clear and compelling stories and visuals. Implement your recommendations using evidence-based and agile practices.

6. Monitor and evaluate your productivity progress and outcomes. Track your productivity metrics and indicators over time and compare them with your goals and objectives. Assess the impact of your actions on your productivity outcomes and learn from your successes and failures.

Start with one team and just a handful of metrics. Get easy wins, share success, and scale to the rest of the organization.

Best practices for using the SPACE framework

Now that you know how to measure each dimension of team productivity using the SPACE framework, here are the best practices that you can follow to use it effectively:

• Use multiple data sources and methods to measure each dimension. Don't rely on a single metric or source of data to measure team productivity. Instead, use quantitative and qualitative data from different sources and methods, such as surveys, code reviews, commits, pull requests, issues, bugs, tests, deployments, etc. This will help you get a more accurate and comprehensive picture of your productivity and avoid potential biases or errors.

• Use relative and contextual comparisons to interpret your measurements. Don't compare your productivity measurements across different projects, teams, or organizations without considering the context and the goals of each. Instead, use relative and contextual comparisons to interpret your measurements and understand how they align with your expectations and objectives. For example, you can compare your current measurements with your previous ones, your targets or benchmarks, or similar projects or teams within your organization.

• Use the SPACE framework as a diagnostic tool to identify problems and opportunities. Don't use the SPACE framework as a prescriptive tool to dictate what you should do or how you should do it. Instead, use the SPACE framework as a diagnostic tool to identify problems and opportunities for improvement in your productivity system. For example, you can use the SPACE framework to determine which dimensions are underperforming or overperforming, which are correlated or conflicting with each other, or which dimensions are most important or relevant for your situation.

• Use the SPACE framework as a communication tool to share insights and recommendations. Don't use the SPACE framework as a communication tool to blame or praise individuals or teams for their productivity. Instead, use the SPACE framework as a communication tool to share insights and recommendations with your stakeholders and collaborators. For example, you can use the SPACE framework to communicate your productivity goals and expectations, achievements and challenges, or productivity actions and plans.

Further reading materials

If you want to learn more about the SPACE framework and how to use it, read the original paper: "The SPACE of team productivity: There's More To It Than You Think"

There are 100+ more practices like this

This practice is part of Product Cards.

Product Cards is a curated set of 100+ cards to help you improve your teams.

They describe 20+ most common challenges and 80+ best practices to overcome them.

They cover all areas from product, design, engineering, agile, management, and leadership to culture.

You can use them solo or in your teams to learn, discuss and improve your ways of working. All at your fingertips.

It’s like having a personal advisor in your pocket to help you build successful, high-performing teams and organizations.

Here is a 2-minutes demo of Product Cards:

Sign up for free Product Cards early access and get access to the preview decks of Heroes, Problem, and Solution Cards.

Get Early Access

How are you measuring your team's performance?

Good luck, have fun, and see you in a bit!

Piotr 👋

The most common questions we need to answer are:

• Which problems to solve first?

• Which solutions will solve our problems?

• How to convince the stakeholders to listen to us?

• How to improve communication and collaboration in our organization?

• How to prioritize ideas worth building?

• How to innovate and increase the value of our work?

• How to measure and improve the performance of our teams?

• How to create and execute a strategy to take us to the next level?

• How to align our teams in one direction?

• How to attract talent and retain good people in our teams?

Wouldn’t it be great if you had answers in your pocket?

That’s what Product Cards can do for you. It’s 100+ cards to learn and improve all things product, engineering, agile, and design.

What are Product Cards?

Product Cards is a curated set of 100+ cards to help you improve your teams.

Those cards describe 20+ most common challenges and 80+ best practices to overcome them.

They cover all areas from product, design, engineering, agile, management, and leadership to culture.

You can use them solo or in your teams to learn, discuss and improve your ways of working. All at your fingertips.

It’s like having a personal advisor in your pocket to help you build successful, high-performing teams and organizations.

Here is a 2-minutes demo of Product Cards:

They’re a combination of 20 years of my experience working with different companies and practices used by like-minded leaders from successful tech companies, like:

Product Cards come in two forms:

1. Digital

2. Physical (coming soon)

Why I Created Product Cards

I made Product Cards because I saw many tech teams struggling to keep up with best practices, especially during scaling moments.

There are many resources out there, but they're scattered, lengthy, hard to follow, and apply in your teams.

Product Cards is possibly the most extensive collection of industry best practices that help you and your team work better.

How Do Product Cards Work?

Currently, Product Cards contains three types of cards:

1. Hero Cards

2. Challenge Cards

3. Solution Cards

1️⃣ Hero Cards

The first type of card is Hero Card.

Hero Cards represent key actors in product companies:

• company leaders

• team leaders and managers

• engineering leaders and managers

• product leaders, product managers, product owners, and growth hackers

• design leaders and managers

• agile coaches, scrum masters, and lean practitioners

• individual contributors who want to improve their teams

All of those roles can directly benefit from using Product Cards.

You can identify Hero Cards by a yellow border around them.

Picking Hero Cards provides you with recommendations for two other types of cards:

1. Challenge Cards representing the most common problems a role may be facing

2. Solutions Cards representing solutions to overcome those challenges

2️⃣ Challenge Cards

The second type of card is Challenge Card.

Challenge Card represent one challenge - a specific problem to solve or an opportunity to seize.

You can identify Challenge Cards by a red border around them.

Example Challenge Cards:

• Setting the Right Team Structure

• Measuring and Improving Your Team Performance

• Increasing the Value Your Teams Are Delivering

• Increasing the Speed of Your Teams

• Managing Tech Debt

• Creating Strategy

• Prioritizing Your Roadmap

• Managing Technology Roadmap

The back side of each Challenge Card provides links to Solution Cards that help you to overcome the challenge. Additionally, each Challenge Card has a QR code that provides a detailed guide on solving your problem.

3️⃣ Solution Cards

The third type of card is Solution Card.

Each Solution Card represents one practice to adopt in your teams.

Solutions Cards help you solve problems represented by Challenge Cards. If you played any trading card game, think of Solution Cards as the cards countering “monster” Challenge Cards.

You can identify Solution Cards by the elixir icon in the upper part of the card. They have different colors, depending on their rarity.

Example Solution Cards:

• SPACE framework (helps to overcome the “Measuring Your Team Performance” challenge card)

• Product vision (helps to overcome the “Increase your team focus” challenge card)

• ICE roadmap prioritization framework (helps to overcome the ”Increase the value of product teams” challenge card)

• Team Topologies (helps to overcome the “Setting the right team structure” challenge card)

Front-side

The front side of each Solution Card will give information on the following:

• What’s the Rarity of the card?

  • Rarity combines the industry popularity of particular practice with how much impact you can expect from adopting it.

  • Rarities used in Product Cards:

    • ⚪️ Common

    • 🟢 Uncommon

    • 🔵 Rare

    • 🟣 Epic

    • 🟠 Legendary

• What’s the estimated impact of adopting this practice from 1-10?

• What’s the estimated effort needed from your team from 1-10?

Back-side

The back side of each Solution Card expands information on the practice. Additionally, each Solution Card has a QR code linking to the Card Guide.

Card Guide

Card Guide is a detailed guide on specific Solution Card practice:

You can find there:

• Necessary information on the practice

• List of companies using this practice

• List of arguments to convince people to adopt the practice

• When to use this practice

• Step-by-step guide on how to apply this practice

• List of Challenge Cards this Solution Card can counter

• List of similar Solution Cards that can help you

• Further reading materials

• Card rarity (explained in the Front-side section)

• The estimated impact of adopting this practice from 1-10

• The estimated effort needed from your team from 1-10

Together they provide you with all the necessary knowledge to learn, convince and adopt the practice.

How to use Product Cards?

There are multiple ways to use Product Cards, either solo or in teams.

You can:

• Brainstorm problems in your teams and find ways to improve in the workshops.

• Use them during one-on-one coaching sessions.

• Use them as your “ace” to convince stakeholders to adopt new ways of working.

• Run team audits using specific cards. Score teams’ practices from 1-5. Rank areas that need the most attention.

• Plan and manage your transformation roadmap using cards.

• Use them to communicate things during team-wide presentations.

• Share your ways of working in job descriptions to attract top talents.

This is just a few ways to use the cards. People who used Product Cards found some really creative ways. :)

Why should you use Product Cards?

Product Cards can help you in lots of different ways, depending on how you use them:

• They will help you grow your career as a leader and manager

  • They will help you learn new things

  • They will help you maximize your impact, get noticed, and get promoted

  • They will help you impress people during a job interview

  • They will help you to switch your career track to management/leadership

• They will help you improve how you work

  • They will help you to improve your teams’ alignment, communication, innovation, and collaboration

  • They will help you convince your stakeholders to use new ways of working

  • They will help you establish a solid product culture

  • They will help you plan and manage organizational change

• They can even help you start your own company

• They can increase your team’s engagement

Product Cards allow you to change how you work and have fun doing it at the same time. And fun is important. It’s so easy to forget to have fun at work.

Think about this - doing things that make us happy boost our energy, motivation, and productivity, leading to better results for you and your teams.

Product Cards are designed with that philosophy in mind.

How to get started with Product Cards?

If you are ready to start your journey with Product Cards:

1. Sign up for free Product Cards early access (digital version) and get access to the preview decks of Heroes, Problem, and Solution Cards.
   
   

   Get Product Cards Early Access

2. Join the waitlist for the limited physical version of Product Cards. Five random people will get them for free when they become available later this year.

3. Subscribe to be notified about Product Cards’ development progress and new cards added.
   
   

   Subscribe now

4. Take this 5-minute survey and tell me what you think about Product Cards and how you would improve them.

5. Share this post with your network and help me spread the word about Product Cards.

So, are you ready to become a legendary tech company?

Let me know in the comments what you think about Product Cards.

What cards would you add to the deck?

Yours, Piotr. 👋

Is the traditional hierarchy of tech companies becoming a thing of the past? Some major players in the industry, like Shopify and Meta, are shaking things up by flattening their organizations and asking managers to become individual contributors or leave the company. What does this mean for the industry and people? Let's explore.

Why are they doing this?

Some big tech companies are following a trend of flattening their organization structure, which means reducing the number of layers of management and empowering individual contributors to make decisions and take ownership of their work. This can have several benefits, such as:

• Faster decision-making and execution, as there are fewer layers of bureaucracy and approval.

• Lower costs and higher efficiency, as there are fewer salaries to pay and less duplication of work.

• More empowerment and autonomy for employees, as they have more direct access to senior leaders and more responsibility for their work.

Sounds good? Well, not so fast. There are also some risks involved in this approach.

What are the risks?

Flattening the organization can also have some drawbacks, such as:

• Reduced morale, culture, and performance, as middle managers play a vital role in motivating, developing, and retaining talent and fostering collaboration and communication across teams.

• Increased workload and stress for senior leaders and employees, as they have to take on more tasks and roles that middle managers previously handled.

• Decreased innovation and quality, as middle managers act as brokers of ideas and feedback between different levels and functions of the organization.

• Creating confusion and ambiguity about roles and responsibilities

• Reducing career advancement opportunities for high-performing individual contributors

These risks can be mitigated by providing clear expectations, guidance, support, and feedback to individual contributors and creating alternative career paths and rewards for them. However, this can work only with a specific type of culture. And it will still require a significant effort and commitment from the company and the employees.

Is this the trend in big tech?

Some big tech companies like Meta, Shopify, Twitter, Google, Amazon, and Microsoft have reduced the number of middle managers in recent years. This suggests that this is not a temporary fad but a long-term shift in how tech companies operate and compete in the market.

My take on it

While smaller and flatter organizations generally operate better, getting rid of good managers can be a double-edged sword. Good managers amplify the work of their people.

Instead of firing their managers, some companies ask them to “step back” to individual contributor roles. The issue is that management and IC are different tracks, so it’s not a step back. Great engineers are rarely great managers. Great managers are not great because they were great coders.

So is flattening the honest answer here?

A few other potential explanations:

• The tech industry underwent rapid hiring during the pandemic when demand for online services and e-commerce surged, but now they need to adjust to a post-pandemic reality and reduce their costs.

• The current geopolitical and economic landscape makes companies want to reduce their costs even more.

• Our industry can be influenced by social contagion, in which companies imitate what others are doing without much evidence or rationale, creating a domino effect of layoffs.

Ultimately it can play out differently for different companies. It depends on their culture, the leaders left in the team, and how severe they will go with these cuts.

I am in a management position. Now what?

Engineering managers and directors affected by this change might face challenges finding new jobs or roles matching their skills and interests. They might have to compete with a larger pool of candidates with more recent hands-on experience or technical expertise. They might also have to adjust their expectations and preferences about what kind of work they want to do and where they want to do it.

How to prepare?

If you are an engineering manager or director facing this situation, don't panic. There are still ways to prepare yourself for the future and make the most of this opportunity. Here are some tips:

1. Stay hands-on as much as possible. Keep your technical skills sharp and up-to-date by working on projects, learning new tools, taking courses, or contributing to open source. This will help you demonstrate your value as an individual contributor and increase your chances of landing a new role or project.

2. Expand your network and reach out to other engineering managers and directors who have gone through this transition. Learn from their experiences, insights, advice, and referrals. You might find new opportunities or connections that you didn't know existed.

3. Explore different options and possibilities. Don't limit yourself to one type of role or company. Be open-minded and curious about what else is out there. You might discover new passions or interests that you didn't realize before.

4. Be flexible and adaptable. Don't resist or resent the change; embrace it as a chance to grow and evolve. Be willing to try new things, take risks, make mistakes, learn from them, and improve yourself. Some companies may (partially) revert their decision to reduce the number of middle managers.

Closing thoughts

Flattening the organization structure of tech companies is a complex and controversial topic with pros and cons. Some companies might benefit from it, while others might suffer from it. The tech industry is constantly evolving and changing, as are its leaders' and workers' roles and expectations.

• What do you think about reducing the number of managers inside product and engineering organizations?

• What do you think will be the next trend in tech organizations?

• Are you preparing somehow?

Share your thoughts and opinions in the comments below. 👇

Leave a comment

Opening a Slack channel for public appreciation can be a great way to boost morale and spread positivity in your workplace. Whether a small team or a large organization, having a dedicated space for team members to give shoutouts and express gratitude can create a culture of appreciation and recognition. It's a simple and effective way to acknowledge your colleagues’ hard work and contributions, and it can also help strengthen relationships and build a sense of community.

Plus, who doesn't love receiving a little recognition for their efforts?

Example #kudos

Here are a few examples from Displate’s #kudos channel

1️⃣ Kudos to @PaladinOne for all the magic and spells you cast for Project Y to work!

2️⃣ kudos to whoever made blueberry muffins today for Charity Breakfast. they are insane!

3️⃣ Kudos to @OneOfTheTeams and the rest of the people involved in launching Lumino for the heart and dedication behind what you do. ❤️

How to do it?

1. Create a channel on Slack called #kudos.

2. Set a description like:

Give your colleagues kudos and show your appreciation and gratitude! 🙏

3. Announce the channel via email or existing Slack channels. Feel free to copy the template below:

Hello team,

We're excited to announce the launch of our new #kudos channel! This channel is dedicated to recognizing and appreciating the hard work and achievements of our colleagues.

👉 Here's how it works: simply post a message in #kudos with the person's name and a brief description of why they deserve recognition. It can be anything from going above and beyond on a project to simply being a positive influence in the office.

Let's spread positivity and show our colleagues how much we appreciate them! #kudos to all!

4. Give first kudos on the channel to somebody.

5. Ask your colleagues to do the same.

6. Watch the magic.

7. Repeat the importance of public appreciation until it hooks into your team/company culture.

There. Try it, it takes 15 minutes, and you have all the ingredients. What could go wrong? :)

Click the map to learn a hundred more practices like this that good companies have:

Leave a comment

Have a great week, everybody!

Piotr 👋

PS: What’s the best kudos you saw or someone gave to you?

PS2: Kudos to my entire Displate team for printing light on metal.

Today I am sharing with you some books that have been instrumental in my journey to becoming a Chief Technology Officer and a management board member. As someone in the tech industry for 20 years, I can attest that there's no one-size-fits-all formula to success, but reading those books has helped me gain a broader perspective and sharpen my skills.

These books cover various topics, from leadership and strategy to technology and management. They have something valuable to offer anyone looking to grow and excel in their career.

So, whether you're just starting out or looking to take your career or company the next step, these books will inspire you and provide valuable insights. Let's get started!

Book Categories

I put them in those categories.

• Leadership and Management (15)

• Product Development (8)

• Product Management (6)

• Product Marketing (6)

• Product Design (5)

• Entrepreneurship (5)

• Strategy (4)

• Data (3)

• Personal development (3)

ℹ️ You can click on each image below to get Amazon links to individual books.

👉 What’s the one book you recommend to other people the most?

—

Have a wonderful week!

Piotr 👋

Finding and keeping people in the company, especially good people, is becoming more challenging. The average working tenure for a person in the tech industry is two years. That can hurt, especially If you count the costs of hiring and onboarding a new person after someone leaves.

There is this saying:

People do not leave companies; they leave managers.

It's an oversimplification but shows a manager's critical role in keeping good people in the company.

So let's briefly talk about the role of the manager in a company:

• The manager's job is not just to run status meetings and review the tasks of people reporting to you.

• The manager's job is not just to retain good people

• The manager's job is to keep people in the company and actively coach them to do the best jobs of their lives. 

• The manager's job is to unlock people's potential, literally 10X their performance.

I find one technique is particularly powerful when it comes to 10-xing your people. I call it Expectation Agreement.

What is Expectation Agreement?

Expectation Agreement is a simple workshop method that allows having an honest two-sided conversation about: 

1. what are the expectations between two people

2. how they see success behind their roles. 

The end result looks like this:

This is a must-have for the manager-report situation.

You can also have those workshops between closely collaborating people inside the company, for example, Head of Product and Head of Engineering.

How to do the Expectation Agreement workshop?

Here are the steps to follow:

Step 1️⃣ Invite the right people

👉 If you're a manager: book an hour in your report calendar and send them this post so they can prepare.

👉 If you're an employee and want clarity on your expectations: book an hour in your manager's calendar and send them this post so they can prepare.

Share

Step 2️⃣ Set the scene

👉 If you're in the office: Prepare two different colors of post-it notes, two markers and a room, ideally with some whiteboard.

👉 If you're remote, copy this Miro board I've prepared:

Miro board

I strongly recommend meeting in the office for this this workshop though.

Each of you gets two colors of post-it notes. Pick colors. One color represents you, and the other - the other person. 

Step 3️⃣ Write down expectations for both sides

Take 20-minutes to write on post-it notes:

1. What can the other person expect of you? (on "your color" post-its)

2. What do you expect from the other person? (on "other person color" post-its)

Here are a few examples of post-it notes for inspiration:

• You can expect me to provide you with timely feedback

• Those can be reverted. As a report, you can say: I expect you to provide me with timely feedback

• I expect you to provide me with a career plan

• You can expect me to report our team KPIs every first Thursday of the month

• I expect you to hold your promises.

• You can expect me to care about you as a person

• I expect you to be as transparent as you can be

• You can expect me to empower our team so you can make decisions on our own within those boundaries

• I expect you to do great things, or tell me what prevents you from doing that

• You can expect me to set a strategy for our team

• I expect you to make mistakes, and that's fine with me

• You can expect me to make

• I expect you to give recognition to your colleagues

• You can expect me to follow our team principles

By the end of this step, you should end with a few dozen post-it notes in two colors. One color represents expectations toward you, and the other represents expectations toward another person. 

Step 4️⃣ Discuss

Now it's time to discuss every post-it.

Take one post-it note and read it out loud, for example:

You can expect me to set a strategy for our team

Then discuss it, for example:

• Does it make sense to the other person?

• Does the other person agree and commit to this?

• What do you both mean by strategy? Maybe you should get more specific here.

Once the post-it note is discussed and agreed upon, place it on the board under the person's name.

Take turns:

• Person A:

  • You can expect me to (…)

    • <discussion>

  • I expect you to (…)

    • <discussion>

• Person B:

  • You can expect me to (…)

    • <discussion>

  • I expect you to (…)

    • <discusscion>

Repeat this process until both of you put all your post-it notes on the board.

Step 5️⃣ Shake hands

Once you're happy about the contents on the board, you shake hands. This is your contract; you both agree to it.

Step 6️⃣ Use it

Document the board (miro/photo) and use it on your one-on-ones and performance reviews. Hold yourselves accountable to your agreements.

Step 7️⃣ Repeat it

Repeat it every six months or whenever something significant happens (promotion, a big change in the team, etc.). You'll be amazed by the results.

Why Expectation Agreement is so powerful?

• It provides clarity: The technique allows the manager and employee to clarify what is expected of each other, reducing ambiguity and misunderstandings that can lead to decreased performance.

• It increases accountability: When both parties are clear about their expectations, it increases accountability for each person to fulfill their obligations and deliver on their promises.

• It encourages open communication: The workshop format of the technique allows for an open and honest conversation between the manager and employee, creating an environment of trust and mutual understanding that can lead to improved performance.

• It helps identify areas for growth: Through discussing expectations, both parties can identify areas where they can improve and set goals for growth and development.

• It fixes performance reviews: The documented agreement can serve as a reference point for performance reviews, making it easier to evaluate and discuss performance against agreed-upon expectations.

• It icreases job satisfaction: When employees feel that their expectations are being heard and considered, it can increase their overall job satisfaction and motivation, leading to improved performance.

When to run the Expectation Agreement?

• As soon as possible with people who don't have their Expectation Agreements

• On one of the first one-on-ones with new employees

• Every six months to iterate on the agreements made before

Conclusion

They say: 

"Behind every successful company, there are people who made it happen." 

No matter how innovative your technology or how fancy your office space is, your company will only thrive with the right people. After all, who else will come up with those groundbreaking ideas, solve those pesky problems, and keep the coffee flowing? So if you want to build a successful company, remember to invest in the essential resource you have: the amazing and talented human beings who make it all possible.

—

Have a wonderful week!

Piotr 👋

Over my 20 years in tech, I worked with a handful of product companies in various roles - from individual contributor to leader and coach. 

Common complaints are:

• Teams have issues prioritizing items on the roadmap

• Teams are not bringing any significant business results

• There is no clear focus, and teams are all around the place

• There is a misalignment between different departments

• There are many communication and coordination issues between the teams

Rings a bell?

Those issues tell that you may be lacking a strategy. 

In this post, you’ll learn how to fix those issues by creating a strategy step-by-step using Netflix as an example.

What is the Strategic Pyramid?

Strategic Pyramid documents your entire strategy.

• It paints the picture of the future your company is trying to unlock.

• It describes the direction company wants to take to get there.

• It illustrates the journey from a high-level mission to a day-to-day roadmap.

• Its goal is to give teams inspiration, direction, and focus. 

Strategic pyramid layers

Every layer is an answer to one question:

1. Mission 👉 Why do we exist as a company?

2. Vision 👉 What’s the future we want to unlock in 2-3 years?

3. North Star Metric 👉 What is the single, most crucial metric that best captures the core value that our product delivers to its customers?

4. Strategy 👉 What is the sequence of big bets that will take us to that future?

5. Metrics & Goals 👉 How will we measure progress on those bets?

6. Roadmap 👉 What tactics are we planning to launch to move those goals?

Why Pyramid?

Pyramid is a good metaphor because:

• The strategy has multiple connected layers.

• Layers provide the base for the other layers. 

• Lower layers guides the upper layers.

• The sequence of layers matters. 

Why do you need Strategic Pyramid?

• To achieve better business results

• To allow teams to prioritize their work better

• To scale your company

• To provide your teams’ information necessary to make decisions

• To provide focus

• To align teams

• To measure progress

• To inspire and motivate

Netflix’s Strategic Pyramid Example

I’ll show you what Netflix’s strategy could look like using Strategic Pyramid.

I used some insights from Gibson Biddle (Netflix ex VP of Product). As for the rest - I’m speculating here.

1. Mission:

• Question: Why do we exist as a company?

• Answer: to entertain the world anywhere, anytime.

2. Vision: 

• Q: What’s the future we want to unlock in 2-3 years?

• A: to become the go-to entertainment platform providing memorable experiences to people globally

3. North Star Metric: 

• Q: What is the single, most crucial metric that best captures the core value our product delivers to its customers?

• A: the number of hours customers spend streaming content on its platform. 

4. Strategy: 

• Q: What is the sequence of big bets that will take us to that future?

• A: Here are the major strategic bets:

  • Getting into gaming

  • Adding short video content

  • Embracing interactive storytelling

  • Investing in original content (continue)

  • Expanding globally (continue)

  • Personalizing the viewing experience (continue)

5. Metrics & Goals: 

• Q: How will we measure progress on those bets?

• A: 

  • Original Content → % of members who watch at least 10 hours/month of Original Content

  • Watching experience → % of customers who watch at least 30 hours/month

  • Getting into gaming → % of members who played Netflix Games 

  • Adding short video content → % of members who engage with short video content

6. Roadmap: 

• Q: What tactics are we planning to move those goals?

• A: Here’s the rolling four-quarter roadmap per each strategy:

I hope you see why there is a specific sequence and how each layer feeds the next one.

Read below if you’re interested in how I came to those answers. 

Strategic Pyramid layers step-by-step 

1. Mission

Mission answers a question: 

Why do we exist as a company?

A company mission is a single sentence that defines its reason for existence.

Netflix’s mission could be: ”to entertain the world anywhere, anytime.”

Netflix’s mission statement emphasizes the company’s purpose of using innovative and engaging storytelling to entertain and connect people worldwide. This focus on accessibility reflects Netflix’s strategy of disrupting traditional media distribution channels and becoming a global entertainment platform.

Hint: If you’re stuck, use ChatGPT to help you create your mission (example: write an inspiring single-sentence company mission statement about this company: «company context»)

2. Vision:

Vision answers a question: 

What’s the future we want to unlock in 2-4 years?

Netflix has existed for more than 20 years. Their vision has changed over time, but I imagine their previous vision statements gravitated around:

DVD by mail → Streaming → Expansion worldwide → Original Content

Based on Netflix’s experiments with gaming and short video content, my guess for current Netflix’s vision for the next 2-4 years could be: “to become the go-to entertainment platform providing memorable experiences to people globally.”

At this point is quite clear Netflix’s ambitions are higher than just streaming.

Although gaming may seem insignificant now, it’s worth remembering that in January 2007, Netflix started with just a few hundred streaming titles to support its DVD rental service. And now, the company has become one of the biggest players in the market.

Hint: If you’re stuck, use ChatGPT to help create your vision statement.

3. North Star

The North Star answers the question:

What is the single, most crucial leading metric best captures the core value our product delivers to its customers?

It’s like a compass that helps guide the business in the right direction to achieve its ultimate goal.

Netflix North Star metric fifteen years ago was the number of DVDs in a new member’s queue. This was a leading indicator that helped improve their retention.

Since Netflix shifted from DVD by mail to streaming, its current North Star metric could be the number of hours customers spend watching or engaging with the content on its platform. 

This metric directly reflects the value that Netflix provides to its customers, which is high-quality and engaging content. By focusing on increasing the number of hours customers spend streaming, Netflix can ensure that it delivers sufficient value to its customers and achieves long-term growth. If they hit their North Star metric, other metrics, such as customer retention, subscriber growth, and revenue per user, will follow.

4. Strategy

Strategy answers the question:

What is the sequence of big bets that will take us to that future?

A good strategy should tick all the boxes:

1. provide value for the customer

2. increase company profits

3. is hard to copy by competitors

Current Netflix strategies include:

• Getting into gaming: Developing or acquiring games that tie in with Netflix original content or partnering with game developers to bring Netflix content into the gaming world.

• Adding short video content: Creating or acquiring short-form video content, such as snackable clips, to keep subscribers engaged and attract new ones.

• Embracing interactive storytelling: Developing or acquiring content that allows viewers to make choices and affect the story’s outcome, creating a more immersive and engaging experience.

• Investing in original content: Continuing to produce and acquire exclusive, high-quality original content to differentiate themselves from competitors and keep subscribers engaged.

• Expanding globally: Continuing investing in local content and partnerships to better serve international markets and tapping into new, untapped subscriber bases.

• Experimenting with new business models: Continuing testing new pricing structures, such as a lower-cost, ad-supported option or offering discounts for longer-term commitments.

• Personalizing the viewing experience: Netflix continues using subscriber data to tailor recommendations and create a unique, personalized experience for each user.

As you can see, strategies are not features or other tactics. Each strategy should provide an answer to why areyou doing specific tactics.

Strategy also answers which bets you’re not willing to take.

Here are strategies that Netflix decided not to follow now:

• Social aspects of watching: recommendations based on friends’ watchlists or shared watching. Netflix has experimented with that in the past but did not succeed. I guess no one wants the world to know what weird stuff you’re into. ;)

• Investing in cutting-edge technologies, such as virtual and augmented reality, to offer a more immersive viewing experience.

5. Metrics and goals

Every strategy should include a metric to measure progress.

In Netflix’s case, these could be:

• Original Content → % of members who watch at least 10 hours/month of Original Content

• Watching experience → % of customers who watch at least 40 hours/month

• Getting into gaming → % of members who played Netflix Games 

• Adding short video content → % of members who engage with short video content

Once you have a metric assigned to strategies, you can set goals (for example, using OKRs):

• Strategy: Original Content

• Metric: % of members who watch at least 10 hours/month of Original Content

• Goal: increase it by 2% in the next 3/6/12 months

6. Tactics & roadmap

A roadmap answers the final question:

What tactics will we use to progress the goals we’ve set, within the strategies we picked, that should get us closer to our vision?

By tactics, I mean products, projects, features, and experiments.

Here’s what Netflix rolling four-quarter roadmap may look like:

A very common mistake is to create a roadmap before the strategy.

I strongly advise against it as it removes all the thinking needed beforehand, ultimately leading to lower business outcomes and teams jumping from one thing to another. Do your homework.

Conclusion

Providing strategy to teams is the most important job for a leader. It can seem scary, but if you use a simple model like Strategic Pillar, you’ll have it done within weeks. Do your job, leaders! If you need help, here’s how I can help.

Other reads

Product Blocks

GERM Ranking —How to Provide a Strategy for Your Teams in 7 Simple Steps (FREE Slides Deck inside)

As the organization grows, there is an increased need for a clear direction for teams to focus on. Providing strategy can often be paralyzing, especially if you haven't done it before. In this post, I'll show you how to create a strategy by defining and ranking your four pillars…

Read more

3 years ago · 3 likes · Piotr

Product Blocks

👉 Discover 100+ practices used by successful tech product companies

Read more

3 years ago · 5 likes · Piotr

Have a wonderful week!

Piotr 👋

The Product Culture Maturity Model evaluates your company's product culture maturity by determining its current maturity out of 5 stages.

The 5 stages of product culture maturity are:

1. 🔴 Missing - Good product practices are not existing or are being ignored.

2. 🟠 Limited - Good product practices are uncommon and often done carelessly without considering their significance.

3. 🟡 Emerging - The company has embraced an agile mindset, appointed product leaders, and increased release frequency.

4. 🔵 Integrated - Companies have the right roles, structure, and process. Positive outcomes are happening, but there is no consistency.

5. 🟣Consistently delivering value - Companies innovate on behalf of the customers and achieve consistent and exceptional product outcomes. 

Factors in Product Culture Maturity

Improving product culture maturity requires increasing maturity across several different factors, including:

• Operating principles

• Innovation level

• Strategic Context

• Practices and processes

• People & Structure

• Outcomes delivery

• Consistency

Companies must progress in all these dimensions to reach high levels of product culture maturity.

Five Stages of Product Culture Maturity

Here’s a more detailed listing of all stages:

Stage 1 - Missing 🔴

At this stage, the company either isn't aware of good product practices or thinks they don't matter. The strategic context is missing, teams release features rarely (every couple of months), and product metrics are not moving in the right direction (if measured).

👉 To progress from this stage, organizations should focus on the following:

• Understand the benefits of shaping mature product culture (in short - better products = more happy customers  = better business results)

• Understand the principles and best practices used by the most successful product companies (here are more than a hundred best practices I recommend)

Stage 2 - Limited 🟠

At this stage, the company most likely adopted an agile framework like Scrum to their development teams. It still runs like a feature factory. There is no cohesive strategy. Stakeholders are still running the product roadmap, while teams are responsible for releasing features and moving to the next thing on the roadmap.

👉 To progress from this stage, organizations should work on the following: 

• hiring and establishing product leaders (product management, engineering, product design)

• changing the way teams deliver (more frequent, smaller increments)

Stage 3 - Emerging 🟡

At this stage, the company most likely adopted an agile mindset, hired leaders of the product organization (product management, engineering, product design), and switched to more frequent release cycles.

👉 To progress from this stage, companies should:

• define their strategic context, namely product vision and product strategy, 

• bring product trio to all teams and assign them product goals

• empower product teams (giving them autonomy limited only by goals and strategy)

Stage 4 - Integrated 🔵

At this stage, the company has made good progress on most of the building blocks of the right product culture:

• Strategic Context is defined

• Teams have solid foundations for doing discovery and delivery

• Teams are staffed with the right roles

• Teams are empowered and are assigned product metrics to move

Teams start to deliver positive outcomes, but there needs to be more consistency, and innovation levels are not quite there.

👉 To progress from this stage, companies should:

• establishing good product discovery foundations like prototyping and customer interviews.

• work out the shared values and operating principles

• Increase cross-functional alignment between product and other departments

Stage 5 - Consistently delivering value🟣

Companies consistently innovate on behalf of the customers and achieve exceptional product outcomes. The organization is aligned and can quickly validate ideas with customers and deliver solutions to customers consistently. There is a handful of top companies that operate at that stage.

Progressing Through Each Stage

A realistic goal, regardless of your current level, is to advance to the next level. Don’t try to jump through a few stages. It takes at least a few quarters (often years) to progress from one stage to another. It also takes effort to stay at the current stage because; you can go back to a lower maturity stage as your company scales up.

Evaluating Your Company’s Product Culture Maturity

It's essential to assess a company’s product culture maturity from all angles. This means checking work practices, talking with the people involved, understanding their operating principles, and reviewing processes, structure, and deliverables.

👉 Self-assessment quiz

A good first step for assessing the stage your company is in is to take a 10-minute quiz. I find it an excellent way to spark some conversations.

Assess your product culture stage

Conclusion

Knowing where your organization stands regarding product culture maturity is vital. You'll be able to see what you're doing right, what you need to work on, and what improvements you can make. This knowledge helps turn product culture into a part of your organization's DNA so that good practices stick around.

Let me know how it goes for you!

Piotr 👋

💬 In this week's issue:

• 👉 Best practice spotlight: Inspire your teams by providing a compelling vision of the future you want to unlock

• ➕ … and three other best practices

• 👉 A product discovery technique - Opportunity Solution Tree

• 👉 How can paying technical debt 2x your team’s impact?

• 👉 6-step guide to take control of your calendar.

• 👉 Ethics in product design

🔍 Best practice spotlight: Provide inspiring vision

A vision describes an exciting future you want to unlock.

Example of vision: Create the most compelling car company of the 21st century. (Tesla)

Learn more:

• Why should you care about setting the vision?

• What are examples of great vision?

• What are the characteristics of a great vision?

• How to create a great vision?

• Who should be involved?

• What else, besides vision, should be in your strategic context?

• How to create a strategy once you have a vision?

• Templates & more things to read

  • The Product Vision Template

  • Product Vision FAQ

  • Vision vs. Mission

  • Vision vs. Strategy

  • Company Vision Workshop Miro template

Learn more about Product Vision

Other best practices

A few other best practices to pick your interest:

• 👉 Prototype things before you ask engineers to code

• 👉 Drive towards continuous delivery

• 👉 Shorten new employee onboarding time by creating a checklist

Explore 100+ best practices

Other good reads

Three Product Teams

by John Cutler

Comparison of three popular models for product teams

1. Sprint, Story, and Backlog-Centric

2. Team and Mission-Centric

3. Engineer-Centric (with Rockstar PMs)

Opportunity Solution Trees: Visualize Your Thinking

by Teresa Torres

A helpful product discovery technique to visualize and chart the best path to your desired outcome.

Technical debt: Can investing in it unlock 2x team impact?

by Will Larson

A good, outcome-oriented approach to paying technical debt with a simple 4-steps guide on how to start today.

Designing Your Time as a Leader

by Don Neufeld

6-step guide to take control of your calendar.

Are You Solving the Right Problems?

by Thomas Wedell-Wedellsborg

A longer post on how powerful problem-reframing can be, including 7 practical exercises to do on your own.

6 Questions all experienced designers should be able to answer

by Koos Looijesteijn

Great, thought-provoking post about ethics in product design.

🐦 Tweet of the week

🍞 Food for thought

😄 Weekly smile

Have a great week!

Piotr 👋

Creating a successful product is like making a good jazz album. You need the right combination of talented people who can play together in harmony despite playing different instruments.

What is Product Trio?

A Product Trio is a product team leadership group—the product manager, product designer, and tech lead. 

They collaborate to build solutions that are:

• valuable to the customer

• easy to use by the customer

• doable with existing technology

• in line with their business

• ethical to do

Product Trio principles

Having those three roles in the team doesn’t guarantee success. There are a few principles to follow if you want to see the impact:

1. United they stand

The whole trio should be treated as a single unit, even though each member brings different skills and perspectives. They all share the same goals and are held accountable for the team's success. They share the wins and share the losses.

2. Collaborate all the way

Everyone in the product trio is involved in one way or another in product discovery and product delivery.

A common anti-pattern I see is a waterfall process with no collaboration between those three roles. Essentially work is being handed over from one role to another:

1. Product Manager writes requirements and hands it to the designer

2. Designer designs the UI and hands it to the engineers

3. Engineers write code based on the UI and release it to the customers

It looks like throwing the brick:

Or like in a factory. A feature factory.

In most cases, this is what happens:

• Engineers are unable to implement a feature as handed over due to some technical restrictions

• Designer lacks critical customer insights

• The final solution not meeting the requirements

• All three roles are frustrated with each other and create memes about how they cooperate

• No one feels responsible for the solution

• There is a lot of finger pointing 

• Projects end up late

• Quality is low

• There is no real impact of the solution

So if there is one thing you should take from this article: Do not allow for work handoffs. Create an environment where people can collaborate.

3. Collaborating in everything

While product trio is all about collaboration, each role has a different perspective and distinct responsibilities. You’ll see more of one role in some activities while less in others.

Examples:

Angle #1: Discovery and Delivery

• During the Discovery phase (interviewing, prototyping, problem definition), you’ll see extensive collaboration between Product Managers and Product Designers, while Tech Lead will most likely be just informed or consulted.

• During the Delivery phase (building and iterating on the solution), however, you’ll see many more discussions between Engineers and Product Designers iterating on building the solution. During that phase, Product Managers are kept in the loop, but their time commitment is lower.

Angle #2: Tackling the Discovery risks

I’ve mentioned earlier that the product trio collaborates to build solutions that are:

• valuable to the customer

• easy to use by the customer

• doable with existing technology

• in line with their business

• ethical to do

I recommend a single role to be driving each:

• valuable to the customer → Product Manager

• easy to use by the customer → Product Designer

• doable with current technology → Tech Lead

• in line with their business → Product Manager

• ethical to do → Product Manager

Drivers collaborate with two other functions, but they have the final saying.

Angle #3: Individual activities

Similarly, some roles are better drivers for specific activities than others.

For example:

• Product Managers and Engineers should be part of the customer interviews, even though Product Designers may be driving it. 

• Product Managers and Product Designers should be testing the final solution, even though Engineers may be driving it.

• Engineers and Product Designers should be part of the discussions when deciding on the product roadmap, even though Product Managers may be driving it.

4. No rockstars

Every role in the product trio is equal - there are three leaders in the team (taking aside who’s reporting to who).

Think of the product trio as a three-legged stool. If you make one leg shorter, it will trip. 

To be clear: I do not advocate seeking consensus in every decision:

• Product Managers or Product Designers shouldn’t decide on the technical architecture. 

• Engineers shouldn’t have a final saying in what problems the team is solving. 

5. Not limited to product teams

Even though I’m focusing on the product teams, the same principles apply all the way up. In most cases, your most senior technology function (Chief Technology Officer / Head of Technology, etc.) and most senior product function (Chief Product Officer / Head of Product) should have the same goals and be very closely collaborating.

10 tips to strengthen Product Trio in your company

1. Make sure your product teams are stable and not temporary (for example, project-based). Product trio is a long-term, relationship-building game.

2. Clarify Product Trio roles and responsibilities, for example, using a role registry.

3. Make sure you have all three roles that fit those responsibilities inside each product team.

4. Make sure everyone in the trio understands their role and two other roles’ responsibilities. 

5. Make sure all three roles understand Product Trio Principles (link them to this post)

6. Set shared goals for Product Trio.

7. Establish a good collaboration platform for the trio - a dedicated meeting and a channel is a good start.

8. Encourage and reward collaboration and teamwork via cultural artifacts like team mission statements or values lists.

9. Celebrate successes and learn from mistakes as a team. Quick way: public appreciation channel

10. Use integration budgets generously to strengthen product trio relations further.

Behind Every Great Product

Marty Cagan once said:

Behind every great product, there is someone working tirelessly—who led the product team to combine technology and design to solve real customer problems in a way that met the needs of the business.

I agree with the general sentiment, but I would state differently:

Behind every great product, there is a close working product trio. 

A product team is like a three-piece band. The PM sets the beat, the designer adds the melody, and the tech lead rocks the technical aspects.

Together they fill stadiums with fans.

There is more

Building companies is like building with plastic blocks you used to play with as a child. Product Trio is one of those blocks:

Explore other from 100+ best practices used by successful product tech companies:

Discover 100+ best practices

Practices include:

• Creating Product vision and strategy

• Roadmap prioritization

• Technical debt handling strategy

• Delivery performance metrics

• Questions for hiring good PMs, product designers and engineering leaders

• … and 95 more from engineering, product, design, and leadership!