Light PMing As a Designer

There has been a lot of discussion about the lines between product roles getting blurrier.

Designers are increasingly taking on PM-adjacent work, especially in smaller teams, AI/product-led teams, and ambiguous 0→1 projects. Maybe in the near future, we won’t even be hiring strictly for “designers” or “PMs.” Maybe more teams will simply be looking for builders: people who can understand the problem, shape the product, and help bring it to life.

On our team, we don’t have a dedicated PM, so I’ve been doing a fair amount of light PM work. Product-development roles are becoming more fluid, and more people are operating across design, product, engineering, research, and marketing. Here are some of the things I’ve noticed myself doing more of — things that are not always described as a “designer’s job,” but are increasingly part of the work.

Product discovery

As I mentioned in my last post, I’ve been running user interviews, synthesizing insights, identifying opportunity areas, and shaping product direction before a PM has fully defined it.

The formal process was new to me, but the instinct behind it felt familiar. For anyone who has worked in a startup-like environment, this kind of discovery probably comes somewhat naturally. You talk to users, look for patterns, and try to understand what problem is actually worth solving.

The new learning for me was in doing it more intentionally: learning how to conduct interviews properly, avoid leading questions, synthesize findings, and frame product opportunities in a way that the team could act on.

Writing briefs and mini-PRDs

I’ve also been creating more product docs: defining goals, user stories, requirements, scope, non-goals, edge cases, and success criteria.

This was a big one for me because I had never really written a PRD before, especially one that involved technical requirements. It turned out to be a fun and surprisingly clarifying exercise. With the help of AI, I was able to create a scaffold quickly, then iterate with engineers to shape the product scope until we had something concrete enough to build.

The design did not start with pixels. It started with defining what the feature needed to do, what it should not do, and what tradeoffs we were willing to make.

Prioritization and roadmap influence

I’ve also been more involved in helping decide what matters most: which problems are worth solving, which features should come next, and where the team should invest its energy.

This is not always work owned by a designer, but it is definitely work owned by a design lead. A design lead should not only make the interface better. They should also help the team understand what user problems deserve attention and how design decisions connect to product direction.

For me, this also meant bringing more transparency to the team: clarifying what we were currently working on, what was coming next, and how different pieces of work connected to a larger roadmap.

Yes, some of this is work traditionally owned by PMs. But it is also work owned by leads.

The distinction is important: good designers are not just “doing PM work.” They are bringing product judgment into design. They are connecting user needs, business goals, technical constraints, and product strategy before the pixels get made.

Maybe this is part of a larger shift. As AI takes on more of the manual production work — from prototyping to writing scaffolds to synthesizing research — more of us are being pushed upstream. We are being asked to make better decisions, shape direction, and contribute beyond the boundaries of our original job descriptions.

In that sense, maybe we are all becoming a little more like leads.

That is exciting, but it comes with its own challenge: when everyone has more leverage, everyone also needs better judgment.