What I Look for in a Product Team (And What I Build When It's Missing)

The first standup I attended at a new engagement, everyone gave a status update. Twelve people went around the room. Each one described what they had worked on yesterday and what they planned to do today. Nobody mentioned a user. Nobody mentioned an outcome. Nobody mentioned being blocked.

The standup lasted 25 minutes. It produced no decisions.

That told me more about the team than any onboarding document could. Not because the standup was bad -- plenty of teams run standups this way -- but because the ritual revealed the team's relationship with their own work. They were tracking activity, not progress. They were performing collaboration, not practicing it.

I have joined teams as a fractional product leader at Kaiser Permanente, U.S. Space Force, B Lab, FLUXX Health, and Sperity Health. The domains are different. The diagnostic is the same. In the first two weeks, I check five signals. They tell me almost everything I need to know.

The five signals I check

Do rituals produce outcomes or just attendance? Standups, retros, demos, planning sessions -- every team has them. The question is whether they produce decisions. A standup that surfaces a blocker and gets it resolved in 30 seconds is working. A standup that takes 20 minutes and produces no action items is theater. At Kaiser, I found retros where teams generated the same action items quarter after quarter. Nobody tracked follow-through. The retro felt productive in the room. Nothing changed afterward.

Does the team know who their user is? Not in the abstract -- can someone name a specific user, describe their context, and explain what they are trying to accomplish? At Space Force, the CDD team built software for space launch operations but had limited direct contact with the range operators who used their tools. When we ran Discovery & Framing for the Nimbus Weather eBoard, we conducted user interviews with airfield managers and weather officers. Several engineers told me it was the first time they had spoken directly to someone who would use what they built. That gap between builder and user explained why previous build cycles had taken six months and produced unclear output.

Can the PM articulate the top priority without checking a document? If the product manager has to open a spreadsheet or a Jira board to tell you what the team is working on, the priority is not clear. At Kaiser, I coached 28 squads across 9 Experience Groups. The PMs who could answer "what is the most important thing right now?" without hesitation ran teams that shipped. The PMs who pulled up a backlog and started scrolling ran teams that were busy. Busy and productive are different things.

Is the backlog a plan or a parking lot? A backlog with 400 items is not a backlog. It is a wish list. At B Lab, the product teams had backlogs organized around individual tools -- the B Impact Assessment, the SDG Action Manager, the B Corp Directory -- rather than around outcomes. Items accumulated without being groomed, prioritized, or connected to what the team was actually trying to achieve. A healthy backlog has fewer than 30 items, each with acceptance criteria, and a clear top 5 that the team could recite from memory.

Does the team ship weekly, or do they plan to ship "soon"? Shipping cadence reveals everything. Teams that ship weekly have tight feedback loops, small batch sizes, and enough trust with stakeholders to release incremental value. Teams that ship quarterly have long planning horizons, large batches, and a release process that feels like an event instead of a habit. At Space Force, the engineering team went from six-month build cycles to two-week MVPs. That shift did not require new tools or new people. It required a delivery model that made weekly shipping safe and expected.

What healthy teams share

I have worked with over 300 teams. The healthy ones -- the ones that ship, learn, and improve -- share four traits that have nothing to do with the specific framework they use.

Cross-functional leadership that actually leads together. At Kaiser, I created the EGLT model -- Experience Group Leadership Teams -- where product, design, engineering, and delivery leads operated as a single unit. No hierarchy among the four disciplines. Shared accountability for outcomes. When the EGLT functioned well, decisions were faster because the people who needed to weigh in were already aligned. When it did not function, decisions bottlenecked at the loudest voice in the room.

Psychological safety to disagree in the room. The best teams I have worked with argue productively. They surface risks early, push back on assumptions, and change direction when the evidence warrants it. The worst teams agree in the meeting and undermine the decision in the hallway. At Kaiser, I ran an empathy mapping exercise diagnosing leadership culture resistance. The biggest finding was not that leaders were wrong. It was that teams did not feel safe telling them so.

Shared definition of success. Not velocity, not story points, not burndown charts. User outcomes. At Kaiser, success was measured by on-time and on-budget delivery. When we shifted to OKR-based measurement -- tracking member engagement, task completion rates, call volume reduction -- the teams that adopted it built better products. The framework mattered less than the shift from output to outcome. Teams that measure outputs build features. Teams that measure outcomes solve problems.

A shipping cadence measured in days, not months. This is the trait that distinguishes good teams from great ones. Great teams ship small changes frequently, get feedback quickly, and course-correct cheaply. They treat deployment as a non-event. The teams I coached at Space Force went from treating a release as a six-month milestone to treating it as a Tuesday afternoon. That shift changes everything downstream: how the team plans, how they prioritize, how they handle risk.

What I build when it is missing

When the diagnostic reveals gaps, I do not start with a presentation about how things should work. I start with the smallest change that can produce a visible result.

Rituals. A standup that surfaces blockers instead of broadcasting status. A retro that produces one concrete action item with an owner and a deadline. A demo with working software, not slides. These are not new concepts. The value is in making them specific: what exactly do we say in standup, how exactly do we vote on retro items, who exactly decides what gets demoed. At Space Force, redesigning the demo cadence -- from a monthly presentation to a biweekly working session -- changed how the team thought about what "done" meant.

Artifacts. A roadmap connected to outcomes, not a feature list with dates. A backlog with acceptance criteria, not a Jira board with 400 ungroomed tickets. OKRs with baselines and targets, not aspirational statements. At Kaiser, I built a Product Practice Guide with 40+ resources, 12 interactive workshops, and reusable templates for Now-Next-Later roadmaps, personas, service blueprints, and discovery assumptions. Over 1,150 people attended the learning events. The training guides remained in active use after I left. The artifacts worked because they were specific and practical -- not a philosophy of product management but a step-by-step guide for running your next planning session.

Capability. Coaching PMs on story writing, prioritization, and stakeholder communication. Teaching silent generation before discussion so the quietest person in the room has equal influence. Showing teams how to write OKRs that start with a baseline, not a hope. At Kaiser, I coached individual PMs on reframing confusing metrics -- turning "Increase Feature Containment" into "Decrease claims support calls from members who have used KP Claims Estimate tools." The metric did not change. The clarity did. And clarity changes behavior.

Culture. The uncomfortable conversation that names what is actually happening. At Kaiser, I wrote a candid memo to my manager diagnosing cultural barriers: a HiPPO culture where the highest-paid person's opinion drove decisions, 144 fragmented OKRs across the portfolio, year-ahead forecasting that locked teams into commitments before discovery. Naming those patterns was uncomfortable. Not naming them meant building rituals and artifacts on top of a foundation that could not support them.

The first two weeks diagnostic

When I join a new team, the first week is observation. I attend every ritual. I read the backlog. I talk to every team member one-on-one. I do not suggest changes. I listen.

The 1:1s are the most important conversations. I ask three questions: What is working? What is not? If you could change one thing tomorrow, what would it be? The answers are remarkably consistent within a team. Everyone knows what is broken. The problem is rarely a lack of awareness. It is a lack of permission to fix it.

The second week is the mirror. I present what I found back to the team -- not as a criticism but as a reflection. Here is what I observed. Here is what the data says. Here is what your teammates told me. Then I propose three changes and ask the team to pick the smallest one.

The smallest change first. Always. Teams that have been stuck need a win before they trust the process. A standup that runs in 5 minutes instead of 25. A backlog groomed from 400 items to 30. A demo that shows working software for the first time in months. One small win creates permission for the next change. And the next one. And the one after that.

The mirror, the gap, the first step

The best teams I have worked with did not need me for long. They needed someone to hold up the mirror, name the gap, and show them the first step. The rest was them.

I have done this at Fortune 50 enterprises managing $350M portfolios and at seed-stage startups with four people and a Typeform. The scale is different. The diagnostic is the same. The five signals tell you what is working. The four traits tell you what healthy looks like. The construction sequence -- rituals, artifacts, capability, culture -- tells you where to start.

The teams that improve fastest are not the ones with the best tools or the biggest budgets. They are the ones willing to name what is broken and start with the smallest fix.

---

I join teams as a fractional product leader and diagnose what needs to change in the first two weeks. If your team is stuck and you are not sure why, I can help. If you want to start the conversation, reach out.