People. Product. Process. What I Look for First in Every Hardware Program.

Every engagement I take on at Momentum Labs starts with a conversation. Not a pitch. Not a checklist. Not a deep dive into the spec sheet or the Gantt chart. Just a conversation about where the team is and where they're headed.

But I'm not just making small talk. I'm listening for specific patterns across three dimensions that, after 20+ years of shipping hardware, tell me more about where a program is headed than any document ever will.

People first. Always.

The first thing I pay attention to is the people. Not their resumes. Not their titles. How they work together.

Who owns the critical decisions? Not on the org chart, but in practice. Is that clear to everyone, or just assumed? You'd be surprised how often I ask three different team members what the product priorities are and get three different answers. That's not a disagreement. That's a clarity problem.

I listen for how the team talks about tradeoffs. Are they debating openly, or is one voice dominating while others stay quiet? Are engineering and product management aligned on what matters most, or are they operating from different assumptions about what the product is supposed to be?

I also pay attention to where decisions get stuck. If everything escalates to one person, that tells me something. If decisions happen at the edges without context, that tells me something different. Both can be problems. The question is whether the team has intentionally designed how decisions flow, or whether it just evolved by default.

The people dimension isn't about whether you have the right talent. Most hardware teams I work with have talented people. It's about whether those people have the clarity and trust to move fast without stepping on each other.

Product second. Definition before execution.

Once I have a sense of the people dynamics, I start listening for how the team talks about the product itself.

The most important question at this stage is deceptively simple: is the product definition locked, or still evolving?

Both are fine. But they require completely different approaches. A locked definition means the team should be converging on implementation, testing specific solutions against clear targets. A definition that's still forming means there are assumptions to test, user needs to validate, and technical feasibility questions to answer before locking anything down. That's not a problem. It's just an earlier phase.

The issue is when teams don't know which phase they're in. When the definition is still evolving but the team is executing as if it's locked, you get expensive rework. When the definition is locked but people keep reopening it, you get churn. Knowing where you are changes everything about what the right next steps look like.

When the definition is locked, I listen for whether it's locked clearly enough that engineers can make daily tradeoff decisions without escalating everything. Has the team agreed on what the product IS, what it ISN'T, and what the cost, schedule, and experience targets are?

I listen for whether the team has separated the "what" from the "how." The product definition (what we're building and why) should be stable. The implementation (how we're going to build it) is where the engineering creativity lives. When those two get tangled together, you end up with a team that's simultaneously questioning whether they're building the right thing AND figuring out how to build it. That's a recipe for churn.

I also pay attention to how the team handles cost. Is there a clear cost target with an agreed boundary? Does the team understand the difference between what they're aiming for and what's acceptable? Or is cost a vague aspiration that nobody has pressure-tested against real sourcing data?

The product dimension isn't about whether the idea is good or whether the definition is locked yet. It's about whether the team knows what phase they're in and whether their actions match that phase.

Process third. The invisible infrastructure.

Process is where most people's eyes glaze over. But it's the connective tissue that holds everything together.

I listen for how information flows between disciplines. In a well-functioning hardware team, a problem in mechanical design surfaces quickly in electrical, thermal, and firmware because the team has built communication pathways that make that natural. In a struggling team, problems stay siloed until integration, and then everything blows up at once.

I pay attention to the rhythm of the program. Is there a regular cadence of design reviews, build readiness checks, and cross-functional alignment meetings? Or does everything happen by exception, with fire drills replacing routine?

I also look at how the team handles change. Not whether things change (they always do in hardware development), but whether there's a framework for evaluating change. When someone proposes a modification after architecture lock, does the team have a structured way to assess the ripple effects across cost, schedule, certification, and manufacturing? Or does every change trigger an ad hoc scramble?

The process dimension isn't about adding bureaucracy. It's about removing ambiguity. The best hardware teams I've worked with have lightweight processes that create enormous clarity. The worst have either no process (chaos) or too much process (paralysis).

The pattern underneath

Here's what I've learned after doing this across startups and established companies, across consumer electronics, connected devices, and physical products: the teams that ship great products almost always have all three dimensions working together. Clear ownership and trust (people), a product definition that matches the team's phase of development (product), and lightweight systems that keep information flowing and decisions moving (process).

When one of these is off, the symptoms show up in the other two. Unclear product definition creates people conflicts because teams are fighting over scope instead of solving problems. Poor process means product decisions don't stick because there's no framework to hold them. People problems masquerade as technical problems because nobody feels safe raising the real issue.

Most of the time, teams don't need more resources. They need more clarity on one or more of these three dimensions. And that clarity usually doesn't require a reorganization or a new tool. It requires someone who can see the pattern from the outside and help the team name what's actually going on.

That's the conversation

This is what the first few conversations at Momentum Labs are about. Not auditing. Not judging. Just listening for where the energy is flowing and where it's stuck, across people, product, and process.

The value of experienced pattern recognition isn't in having all the answers. It's in knowing which questions to ask first, and helping the team see what they're too close to see themselves.

If you're leading a hardware team and something feels off but you can't quite name it, that's exactly the kind of conversation I have every week. Sometimes one conversation is all it takes to shift the trajectory.

Let's talk.