Product management has fundamentally changed.

Depending on who you ask, or how you learned product management, you will hear different definitions of what the job is. You may hear that product managers are mini-CEOs, that they are the CEO of their product, that they own outcomes for a product line or sector of the business, or that their job is to deliver value through products that meet what customers want, what customers need, or sometimes what customers do not yet even know they need. All of that is true, and none of that is going away. What is changing, however, is how that value is delivered.

The constraint in product development is shifting from how fast we can build software to how fast we can generate signal from the market.

The Traditional Product Development Pipeline

Traditionally, product development looks something like this.

You ingest noise from the market, prospects, customers, and internal stakeholders. You separate that noise into actionable signal. You prioritize that signal based on who said it, the ARR attached to it, the TAM opportunity, and whatever other metrics your organization values.

Once prioritized, that signal becomes a full product spec. In the product spec, you write the argument for why this should exist, why the prioritization is correct, why it will be defensible in the market, what the exact workflow should look like, and what metrics will measure success. The document becomes long, detailed, and legal-document-like.

Then engineering picks it up. Engineering runs feasibility, evaluates what exists today, what needs to change, what technical constraints exist, and they write their own technical spec. They size the work, ask clarification questions, and push back. More meetings happen. Eventually, if the idea survives the process, it gets built.

Then comes internal testing. Bugs are discovered and prioritized. Some are blockers. Some are acceptable. Then it ships.

After it ships, you watch Mixpanel dashboards, talk to users, observe workflows, and gather feedback. And then you start the process all over again.

This process is robust. It is thorough. It is detailed. It is exacting. But it is also heavy.

I believe the best analogy for the traditional product development process is the big blue navy. It takes years to design the ship, years to build the ship, years to test the ship, and years to train the crew to operate the ship. It takes months to repair the ship, weeks to move the ship, and days to prepare the ship.

The system is powerful, but it is not agile and it is not fast. Increasingly, it is not what the future of product development looks like.

The Special Missions Unit Model

To continue the analogy carefully, because business and warfare are obviously not the same. There are far greater risks in actual war than there are in business, and I would not want anyone to think I am saying they are one and the same.

But the future of product development looks much closer to a special missions unit.

Think Development Group or SEAL Team Six. Think Combat Applications Group or Delta Force. Think Air Force PJs. Think the 160th SOAR, the Night Stalkers.

These are units whose job is to be ready within hours, get on a plane, go anywhere in the world, and execute a surgical mission. Small teams, fast timelines, precise outcomes with very clear reasoning behind them.

I believe that is increasingly what product development looks like.

Getting Close to the User

In my current role at TRM Labs, I own the outcomes for the financial institutions and regulators business line.

One program I have created is called Embedded PM, or Embedded Product Manager. If you are familiar with forward deployed engineering, which was popularized by companies like Palantir, this is essentially forward deployed product management on a smaller timescale.

Instead of sitting behind roadmaps and internal planning cycles, I embed directly with our customers.

I travel with an account director or someone from our go to market team. Sometimes multiple people. We go onsite to financial institutions. We sit with the teams actually using our product. We learn who they are, what they do, what jobs they are responsible for, and what outcomes they are trying to achieve.

And we listen.

We listen. We ask questions. We listen to those answers. We ask more questions, and we listen again.

We listen, and we listen, and we listen.

We gather noise.

Then we review that noise, and we translate that noise into signal.

This process alone is not revolutionary. Companies have been doing versions of this for many years at this point. What is new is what happens next.

Turning Signal Into Outcomes

During one embedded visit with a very large, globally known financial institution, we were discussing the current regulatory environment around digital assets.

During the conversation, a user asked a question about how something worked in our product and what the capabilities were. The account director answered the question well.

But something about the question stuck with me.

It revealed that the user was trying to accomplish a specific job, and our product could get them close to that outcome, but it did not give them a perfect path or workflow to achieve the desired outcome.

So I did something different.

I took the notes I was already writing and dropped them into a workflow I built using Claude that I call Product Team Room.

Product Team Room is essentially a product manager's operating system that I built using the new capabilities that these different AI tools have. It is my personal operating system for product thinking and the ins and outs and actions that my job requires.

I drop the notes I was taking into Product Team Room, and it generates a mini product spec.

Not a multiple page legal document.

Just enough to tell the story — who is the user, what role do they play, what team are they on, what job are they trying to accomplish, and why it matters.

Most of that context was already taken within the notes or in the preceding document that I had created before doing this embedded PM visit. All I needed to share were the notes themselves.

Then I take the mini spec that Product Team Room outputs and drop it into a prototype generator like Magic Patterns, Claude, or Codex.

Within minutes — sometimes seconds — I have a fully clickable prototype.

I literally turned my laptop around when there was a gap in the conversation and said, "I think this is what you were talking about. Does this look like what you would need to accomplish your goal within the workflow you were describing?"

The user can click it. They can explore it. They can interact with it. They can literally touch and feel it as much as you can with something on a computer screen.

In this particular instance, the response was immediate.

"Yes. That is exactly what I was looking for."

Then they suggested one additional tweak as the conversation went on.

I updated the prototype, and within minutes we had something extremely close to the right solution that we were going to deliver in production.

That prototype then went directly to engineering with a simple message — we have uncovered new signal. It is not noise. We need to prioritize building this next.

Engineering built the initial delivery in days. Not weeks. Not months. And the client was able to review it a few days later.

The Real Constraint Has Changed

For a long time, the limiting factor in product development was engineering capacity. Roadmaps existed because you simply could not build everything fast enough.

But the barrier to building software is collapsing. What used to take months can now take days. What used to take days can now take minutes.

And when that happens, the constraint shifts.

The constraint is no longer how fast we can build. The constraint is how fast we can generate signal.

The constraint is no longer on the R&D side of the pipeline — it is on the go to market side of the pipeline.

It is my belief that the best product managers today understand this. The pipeline is no longer blocked by engineering output. It is blocked by how much signal you can generate from the market.

Generating Signal

At TRM, I approach this through three programs designed specifically to generate signal.

Client Feedback Group

First, a client feedback group.

I run a feedback group made up of our most engaged clients — the people actually using our products every day. These are the leaders who are setting the course at financial institutions for entire digital asset programs, architecting what those look like, and leading the path forward.

These are invite only members that have access to a great network.

In each Financial Institution Feedback Group session, we show what we have recently shipped. We show what is about to ship in the coming days or weeks. Then we share what we are thinking about next.

And then we ask a powerful question.

What did you expect to see on our roadmap that you did not see today?

What is on your roadmap that is not on ours?

That simple question generates extraordinary signal when you have a group of people that are comfortable with each other and understand that this is the tip of the spear when it comes to digital assets in the financial institution space.

We convert all of that signal into mini specs, prototypes, and often new features within days or weeks.

The Financial Institution Feedback Group is seen as incredibly valuable by each of the attendees because they do not just feel heard, but they see outcomes driven by what they share in every session.

Embedded PM

The next program is the Embedded PM program.

Where the Financial Institution Feedback Group generates top level signal, Embedded PM generates deeper signal.

We sit with users. We watch how they work. We understand the workflows that exist around our product — not just the workflows we designed inside it.

Clients often say something after these visits that means a lot to me.

"We do not see you as a vendor. We see you as a partner and an architect in our digital asset program."

That is the level of relationship required to generate meaningful signal.

FI Firesides

The third way I generate signal is through a program we call FI Firesides.

These are small sessions with users across each organization — from executives running digital asset programs to frontline analysts earlier in their career using the product every day.

The goal here is empathy.

I do not just want to understand the company or the roadmap that I am trying to uncover in the feedback group.

I want to understand the person.

This transforms how we build products from "we are building for a compliance analyst at Bank X" to "we are building a product for Sarah. She is the VP of global compliance, based in New York, responsible for North American investigations at Bank X. Here is her problem, and here is how we will solve it."

When you understand your users at that level, product decisions become dramatically clearer.

You are no longer building generic features for hypothetical users.

You are building solutions for very real people.

The End of the Roadmap

The era of rigid 6, 12, or 24 month roadmaps is fading.

The era of giant product specs that read like legal documents is fading.

The era of month long implementation cycles is fading.

Not because planning is bad, but because the speed of building has fundamentally changed.

The organizations that win will operate less like the big blue navy and more like special missions units.

They will generate signal from the market — or intelligence.

Then they will deploy small teams to solve specific problems.

They will execute quickly with speed and precision.

Then they will debrief.

Then they will move on to the next mission.

The Future of Product Management

The best product managers today understand something very important.

Engineering output is no longer the bottleneck.

Signal is.

The best product managers build systems that generate signal.

They make customers comfortable sharing feedback that is signal.

They embed with users to uncover signal.

They prototype solutions immediately based on signal.

And they deploy engineering teams against real problems — the signal — not roadmap guesses.

Not because they have written the perfect spec, but because they have unmistakable signal for a user they deeply understand and are willing to serve.

It is my belief product development and product management have fundamentally changed.

The days of the big blue navy are over.

Welcome to the era of the special missions unit product development lifecycle.