# Systemic product team design

There are two types of product-led companies right now and they're having very different years

If you look around the product world right now, you'll notice something stark. There are some companies shipping at incredible velocity—building features in days that used to take weeks, making decisions quickly, and actually enjoying the work. Then there are companies where teams are drowning in process, waiting for approvals, and burning out from the overhead of getting anything done.

The difference isn't talent or resources. It's operating philosophy.

The first type has embraced trust, autonomy, and lightweight process. They hire senior people and get out of their way. The second type is still running on command and control—heavy scrum processes, detailed specifications, and handoff-heavy workflows that made sense in 2015 but are ancient today.

Today at Sero we have four people on our product team. Two engineers, one designer, one PM. If you showed me our git history and asked me how big the team was, I would have guessed 15-20 people. The four of us produce enough work for 20, and we do it without burning ourselves out. We actually enjoy the work.

There's no black magic here. But there is an intentional set of choices we made about who we hire, how we work together, and what tools we use. Those choices compound in ways that most teams—especially the ones stuck in the old model—never experience.

## People first

→Seniority
→Generality
→Personality

We only hire senior people.

Not senior in title, but senior in experience. Every person on our team has at least five to six years of real-world experience. No junior engineers, no junior designers, no one fresh out of bootcamp or college.

Yes, this isn't the most inclusive approach (and it won't scale beyond a certain point) but right now it is the best approach for velocity. When everyone on your team has been around the block a few times, you can operate very differently from teams that need constant oversight and detailed specifications.

Our team has worked across industries, tech stacks, and development philosophies. This shared context creates massive leverage and a shared understanding of which corners can be safely cut and which absoutely cannot.

Consider technical debt. A junior engineer might panic about any deviation from the 'right' way, treating every simplification as a sin against clean code. Someone more senior knows that some technical debt is not just acceptable but valuable—temporary shortcuts that let you learn faster and ship sooner.

We're also all T-shaped. Our engineers are full-stack but they also have great design and business sensibilities. Our product and design folks ship PRs. We can all chip in across the board, which creates incredible flexibility when priorities shift—and they always do. Instead of bottlenecks waiting for "the person who knows X," we can all make good decisions independently.

But raw knowledge isn't enough. We also hire for three personality traits that matter more than any quantifiable skill:

High bias to action. We hire people who can take an idea and turn it into a shipped feature without constant direction. This autonomy is especially important when you're competing against teams that need approval for every decision.

Comfort with ambiguity. The "right answer" is rarely clear, so we hire people who thrive in uncertainty rather than getting paralyzed by it. These are people who can adapt quickly when situations change while maintaining a high quality bar.

Pleasant to work with. None of this is fun if you don't like your teammates. We select for people who are collaborative rather than ego-driven, who can give and receive feedback constructively, and who assume good intentions. Pleasant people are the only ones who can work effectively in the high-trust environment we need to move fast.

This hiring strategy enables everything else we do. While other teams are managing junior developers and navigating personality conflicts, we're focused on building product.

## Process as a tool, not a destination

→Process dynamism
→Public by default
→Push down decisions

Many teams get stuck on the idea that there's a "right" way to work. This is a trap. Process isn't a destination—it's a temporary way of working that should change based on what you're building and who you're building it with.

Our core operating principles are simple: Autonomy means the people closest to the work make the decisions. Ownership means you're responsible for outcomes, not just tasks. Trust means our default assumption is competence and good intentions.

Within that framework, our actual process stays fluid. Currently, we look more like Kanban than Scrum, but we pull practices from wherever they're useful. We'll use Scrum ceremonies when we need them and Shape Up bets when we want to limit investment. If we think a practice might be useful, we add it—and as soon as it stops being useful, we drop it.

Our meeting structure reflects this philosophy: One daily standup and one weekly call that's open to the whole company. That's it for standing meetings. Everything else happens when it needs to happen.

We work in public by default. Conversations happen in public Slack channels instead of DMs. This means information is always accessible, new people can choose their level of involvement, and onboarding becomes incredibly fast. It also creates institutional memory automatically—no more wondering why we made certain decisions six months ago.

But the fundamental difference between our process and traditional product development isn't in the ceremonies or tools. It's in how we think about collaboration.

Most teams operate with a handoff model where product defines detailed requirements, design makes them pop, and engineering implements as specified. Feedback happens through formal channels at predetermined checkpoints, like a relay race where each runner waits for the baton before they can start moving.

We can be much more fluid because everyone is senior and multi-disciplinary. Everyone helps define the best product, with requirements serving as starting points rather than ending points. Everyone has both the authority and the obligation to improve on original specs, and collaboration is continuous rather than a series of handoffs.

This leads to what might be our most radical stance: blindly following the spec is grounds for firing.

Engineers are expected to push back on bad ideas, designers are expected to influence the roadmap, and product managers are expected to weigh in on schema design. Everyone has not only the authority, but the obligation to make the product better.

While other teams are waiting for the next sprint planning meeting to surface problems, we're solving them in real-time.

## Tools for individual productivity

→Personal AI tooling
→Constant testing
→No functional boundaries

While most teams standardize on tools for consistency, we optimize for individual productivity. Each team member gets a personal AI tool budget with complete autonomy in how they spend it. Cursor versus Claude Code versus whatever comes next—your choice.

This extends to all roles. Engineers, designers, product managers—everyone can try whichever tools might make them more effective. The goal is maximum individual productivity, not standardization.

We also constantly test new tools as a team. In the past three months we've tried half a dozen automated code review bots, full "AI developer teammates," various linters and code complexity checkers, and even different PR management tools. Our philosophy is simple: try everything that might help, keep what demonstrably improves our work, drop what doesn't add value.

Perhaps most importantly, tool access isn't siloed across functional areas. Product and design have full repository access. We can and do make PRs. This drives engineers crazy at some companies, but it works for us because our team members know their own limitations.

Occasional regressions happen, of course, but we revert quickly. We'd rather move fast and fix than move slowly and be "safe." The benefits compound quickly—engineers can stay focused on complex feature development, designers fix the small annoyances that usually sit in the backlog forever, and product can iterate without disrupting engineering flow.

While teams stuck in the old model are debating tool procurement and fighting over repository access, we're shipping.

## The compounding effect

These practices aren't revolutionary on their own. Hiring senior people, maintaining lightweight process, experimenting with tools—plenty of teams do these things. The magic happens in how they interact, creating a compounding effect where each decision reinforces the others.

Senior people can work effectively with minimal process because they've internalized what structure they actually need. High trust lets us open up tool access and gives people the ability to act autonomously. Autonomous people can work in a collaborative environment where everyone has authority to improve the product without stepping on each other's toes.

When someone joins our team, they're not just learning a job—they're joining a system designed to maximize their impact. They get access to better tools, clearer decision-making authority, and teammates who trust them to use both well.

This isn't a giant backlog factory. This is what agile was supposed to be.

## Two paths forward

Not every team can operate this way immediately. You need the luxury of hiring senior people (which isn't always possible), enough authority to experiment with process and tools, and a culture that values outcomes over compliance.

But the underlying principles translate to teams of any size: minimal but necessary process, ownership over outcomes rather than just tasks, autonomy paired with authority, and trust as the default rather than something to be earned.

The question isn't whether you can replicate our exact approach—the question is whether you're willing to embrace the philosophy behind it.