Are We Entering the Era of the Full-Stack Product Manager?

A few weeks ago, I interviewed for a role with a title I had not seen very often before: Full Stack Product Manager. I ultimately did not get the position, but the experience stayed with me because the interview process itself felt very different from the traditional product management interviews I have gone through in the past. More importantly, it gave me a chance to see what this kind of role could actually look like in practice and why I think the skills associated with it may become increasingly valuable, regardless of whether “Full Stack Product Manager” becomes a widely adopted title.

What immediately stood out to me was how the conversation started. The person interviewing me had already spent time looking at my background, but they were interested in more than my previous job titles or the bullet points on my resume. They had seen the workshops I have led, the speaking engagements I have done, the communities I have built, and the work I have been sharing around product thinking and AI-assisted development. Because of that, one of the first things they asked me to do was give a live demonstration of how I teach Vibe Code 101.

I had never experienced that in a product interview before, and I found it fascinating. Before we got deep into my resume or started discussing hypothetical product scenarios, they wanted to see me actually do something I had positioned myself as being good at. They wanted to understand how I communicated ideas, how I explained this new way of building, and whether the work I had been talking about publicly translated when I was asked to demonstrate it in real time.

That experience made me think differently about the role visibility can play in a person’s career, particularly in product management. I have spent a lot of time over the last few years teaching workshops, speaking at events, building communities, experimenting with new tools, and sharing what I am learning as I go. I do those things because I genuinely enjoy the work, but they have also created a public record of how I think. Someone can see that I am not simply adding “AI” to my resume because it is currently popular. They can see the workshops, the products, the experiments, and the conversations I have been having around this space.

There is an old saying that if you can talk the talk, you should be able to walk the walk. I think we are starting to see a version of that emerge in hiring, particularly for roles that sit at the intersection of product and AI-assisted development. It is becoming easier for someone to look beyond what you claim you can do and ask you to demonstrate it. In my case, the public-facing work was part of what got me into the conversation, and then I had to show that I could actually do the work behind it.

After the teaching portion, the interview moved into a completely different direction. We opened Lovable and started building.

I cannot share the exact exercise or the client context behind it, but the general idea was that a particular customer had a specific need, and my job was to think through that need and turn it into a working prototype. What interested me most was not necessarily the fact that I was building something during an interview. It was the product philosophy behind why I was being asked to build it.

The way I understood the model was that you could have a larger product with an existing foundation of data and information, while still creating more tailored experiences for different groups of customers. One customer might interact with that information through one type of application because of the way their organization works, while another customer might need an entirely different experience built around their own workflow. The underlying foundation could remain similar, but the way the product is packaged and experienced could change depending on the problem being solved.

That opens up an interesting possibility for how products could evolve as AI-assisted development makes software faster and less expensive to prototype. Instead of assuming that every customer has to fit into one standardized interface, product teams may have more opportunities to create smaller, specialized experiences on top of a shared foundation. If a particular solution works for one customer and the team later discovers that thousands of other customers have the same need, that experience could potentially grow into a more permanent part of the larger product.

This was where the idea of a Full Stack Product Manager really started to click for me.

When I first heard the title, I could easily imagine someone interpreting it as a product manager who is also expected to be a full-stack engineer. After going through this interview, I see the idea a little differently. I think the “full stack” part may be less about mastering every technical discipline and more about being able to move across more of the product development process than product managers traditionally have.

A product manager might begin by speaking directly with a customer and understanding a problem, but instead of immediately translating that conversation into a requirements document and waiting for the idea to move through an entire development cycle, they may now be able to create an initial version themselves. That version does not need to be production-ready, nor does it replace the work of experienced engineers and designers. Its purpose may simply be to make an idea tangible enough to test, discuss, and learn from.

That difference is important because product management has always involved making decisions under uncertainty. We try to understand what customers need, determine which problems are worth solving, and make decisions about where teams should spend their time. Historically, testing many of those assumptions required significant resources. Even relatively small experiments could require design work, engineering capacity, prioritization discussions, and time on a roadmap.

AI-assisted development is beginning to change that relationship. A product manager who can create a functional prototype may be able to explore an idea before asking a larger team to invest heavily in it. They can sit with a customer, understand a problem, build an early version, put it in front of someone, and learn from the response. If the idea goes nowhere, the team may have saved weeks of work. If the idea shows promise, everyone now has something more concrete to work from.

This does not mean that product managers should become one-person product teams. I think that interpretation misses the point entirely. Great products still require deep technical expertise, strong design, research, data, security, infrastructure, and all the other disciplines that go into building software that works reliably at scale. The opportunity is not to replace those people. The opportunity is to give product managers another way to investigate problems and validate ideas before pulling more resources into the process.

I also think this creates one of the best learning opportunities we have seen for people who want to become product managers.

Breaking into product has always had a frustrating contradiction built into it. Companies want candidates with product experience, but it can be difficult to develop meaningful product experience without first being given a product role. This is one of the reasons aspiring PMs often create case studies where they redesign an existing product or explain how they would approach a hypothetical problem. Those exercises can demonstrate thinking, but they usually stop before the point where product management becomes most interesting: when a real person actually interacts with what you created and proves some of your assumptions wrong.

Today, an aspiring product manager has the ability to go much further. You can identify a problem in your own community or industry, talk to people who experience it, determine what you believe the smallest useful solution could be, and then use AI-assisted development tools to create something that people can actually interact with. From there, you can observe what happens, ask better questions, make changes, and document what you learned throughout the process.

That is where I believe the real opportunity is. Learning how to use an AI-assisted development tool does not automatically make someone a product manager, just as knowing how to use Figma does not automatically make someone a product designer. The tool is simply giving you access to another part of the process. What matters is whether you understand the problem you are trying to solve, who you are solving it for, what assumptions you are making, and how you will determine whether your solution is actually useful.

For someone learning product management, this means you no longer have to limit your portfolio to explaining what you would build. You can build enough of it to learn whether your thinking holds up. Your portfolio can show the original problem, the conversations you had, the decisions you made, the prototype you created, the feedback you received, and the changes you would make as a result. Even if the product never becomes a company or reaches thousands of users, you have gone through a much more realistic version of the product development process.

My interview experience also reinforced something I have been thinking about regarding thought leadership in product. I sometimes think the term “thought leader” has become associated with simply posting opinions online, but I believe there is a much more useful version of it. If you are consistently doing the work, learning from it, and then teaching others what you have discovered, your public presence can become a living portfolio of your expertise.

That is essentially what happened to me. The workshops I had taught and the work I had shared publicly were not separate from my professional experience. They became part of the reason someone wanted to talk to me in the first place. Then, instead of simply trusting that body of work, they asked me to demonstrate it.

I did not ultimately get the position, and of course I would have loved the opportunity. At the same time, I do not look back at the process feeling that there was one obvious thing I did wrong. This is still an emerging type of role, and I imagine companies experimenting with titles like Full Stack Product Manager are also still defining what the ideal candidate looks like. One organization may want someone with a stronger engineering background, while another may value customer discovery, prototyping, communication, or industry expertise differently.

What I took away from the experience was confirmation that the direction I have been moving in has value. The combination of product thinking, teaching, public speaking, building, and experimenting with AI-assisted development is no longer something that sits outside of my product management experience. Increasingly, I see those things as connected.

I do not know whether Full Stack Product Manager will become the next major title in product. Titles change constantly, and the industry has a habit of creating new names for responsibilities that are still being figured out. What feels more important to me is that the behavior behind the title is already emerging.

Product managers now have access to tools that allow them to participate more directly in the creation of the things they are responsible for shaping. That does not mean abandoning the fundamentals of product management. In fact, I think it makes those fundamentals even more important. When building becomes easier, knowing what to build, who to build it for, and why it should exist becomes even more valuable.

For anyone trying to enter product management today, I would learn both sides. Study customer discovery, product strategy, prioritization, metrics, experimentation, communication, and all the fundamentals that make someone effective in the role. At the same time, learn how to use AI-assisted development tools well enough to take an idea beyond a slide deck or a product requirements document.

Build something based on a real problem. Put it in front of someone. Find out where you were wrong. Make it better. Then be able to explain the entire process.

You may never have “Full Stack Product Manager” as your official title, but I have a feeling that being able to move between understanding a problem, communicating a solution, and creating enough of that solution to learn from it is going to become an increasingly valuable way to work in product.

My biggest learning from the interview was not that every product manager needs to become a developer. The distance between thinking and building is getting shorter, and the product people who learn how to operate within that new space may have an opportunity to become much more effective at both.