Modern Product Transformation

Why this exists

Most of the roles I've taken have been some version of the same job. Helping an organization build a proper product management function.

Sometimes I was hired to do exactly that. Other times I was hired just to ship new products or features. As I got acclimated, I'd often find the organization was shipping products/features reactively with no real product practice.

For me to do the job of shipping product, I'd have to help them implement true product management. So, I'd drive the change, through influence, without anyone handing me the mandate. Reactivity doesn't allow you to be forward thinking, only competing against the current moment, ultimately, putting you behind your competitors or even worse, closing the doors.

If you're in product, and the place you're working is reactive or lacks proper product management functions, you likely want to help make the transitions I've discussed above. It's one of the most satisfying things you can do in this career.

Do it enough times, across enough industries and company sizes, and the same patterns keep showing up. They aren't tied to any one company, and they aren't theory. They're what works when you move an organization from projects to product. And none of them are a secret. The hard part isn't knowing them. It's installing them.

Here's the pushback you'll hear, usually from someone who's been around a while. This is just the latest transformation flavor of the month. We've watched these come and go. Fair. A lot of them do. But the patterns below aren't trendy. They recur because they work. What comes and goes is the execution. When a transformation fails, it's almost never because the patterns were wrong. It's because the people running it had never done it before.

The core move: projects to product

Far too many companies still organize themselves around projects. You can be on a product team, but you don't really own the product. You just get handed down new features to build and release. They have a deadline you'll report against and that deadline is what matters most.

Not the outcome you achieve, but the fact that you built the thing in the time allotted.

Sometimes these teams are put together for a project, other times they are persistent. Regardless, if you do the former, you need to stop. In this process, you give people an opportunity to gather domain knowledge and then shift them to something new. Making that domain knowledge effectively worthless.

While projects end, products persist. When a team stays with a customer problem, they build up context, they own the outcome, and they stop throwing work over the wall. The work never ends, either. Solve one problem and you've likely created the next one, so the discovery starts over.

This is the fight nobody warns you about. The gravity in most organizations runs the other way, toward project management. Holding the line is the job underneath the job.

From there, a handful of patterns follow. Read this as a survey. Each earns its own deeper treatment later. Here I'm just naming them so you can see the whole shape.

The patterns, in brief

Outcomes over outputs. Shipping features isn't the goal. Moving a metric that matters to the customer and the business is. Everyone nods at this and then violates it constantly, because outputs are easy to count and outcomes are hard. Define success as a measurable change in the world, then let the team build toward it. (The full argument lives in Results Matter Most.)

Empowered teams with real decision rights. You can't ask a team to own an outcome and then deny them the power to decide anything. Empowerment isn't a vibe, it's structural. The organization owns the strategy, the constraints, and the outcomes it's accountable for. It sets the destination and the guardrails. The team owns the route there.

I've run this exact arrangement. A team standing up a big internal mission, given the calls to make, with me acting as a snowplow: killing the useless meetings and clearing the corporate nonsense out of their path. When it went well, they got the credit. When it didn't, I took the hit. That's why they took real ownership.

Discovery before delivery. The most expensive thing you can do is build the wrong thing well. As someone who's sunk real money into products nobody ever wanted, I can tell you that one stings. Before a team scales up delivery, they need evidence the thing fits into the desirability, viability, feasibility and ethicality venn diagram. Discovery isn't a phase you run once at kickoff. (How to run discovery is its own section.)

Standards that enable, not standards that constrain. There's a real tension between consistency and autonomy, and it gets sharper the bigger the organization. The fix is lightweight standards teams actually want to use because they remove friction, not heavy process they're forced to follow. A good standard feels like an accelerator, an easier default than rolling your own. That's the line between a playbook and a bureaucracy.

A few signals, watched closely. You don't need a dashboard with forty numbers. You need a small set that matters: outcome metrics tied to business results, team-health signals that tell you whether a team is set up to win, and adoption signals that tell you whether anyone actually uses what you built. Review them on a cadence so you catch a stalled product or an over-committed team early. (Which signals, and how to read them, is its own deep treatment later.)

Think big, start small, scale fast

Here's the pattern that decides whether the rest of them ever take hold. Sequencing.

You don't install a new operating model by announcing it, and you don't flip the whole org to product on a Monday. One of my favorite mantras comes from the Agile world: think big, start small, scale fast.

So you pick one area. Big enough to matter, small enough to actually win. You prove the model there, where the value is real and visible. Sequence the work to capture value early instead of backloading the benefits to a distant finish line. Then let that proof pull the rest of the org along.

I've done the small-scale version with a single team in a waterfall shop. You don't roll out the whole methodology at once. You start with just standups. Then demos of real work, not a slide deck of pictures. Then you open those demos up and down the line so the rest of the org sees the new way working. Then sprints, then retros. Culture change is habit change. You can't do it all immediately, but small daily changes compound into a different organization.

This is why change comes through followership, not mandate, the same truth from Selling Your Ideas. People adopt a new way when they've seen it work and want in, not because someone announced it. They often want in because they know how they're working today isn't right. They want something better, but haven't found it yet (until now).

Expect the energy to dip after the first wins. Expect that not everyone makes the shift. Keep selling the whole way through, and shape the method to the team in front of you. Use it to solve problems better, not because it's the buzzword of the month.

The patterns are the easy part

None of this is novel, and that's the point. These are the moves that hold up across every serious attempt to modernize how product gets built.

Knowing them isn't the hard part. Doing it is. Knowing which move to make first. Seeing where the resistance hides. Reading whether an org is ready for the next wave or needs another proof point before it'll budge. Keeping the momentum alive long enough for the new model to stick.

That judgment only comes from experience. Installing it is the work.