If We Can Conjure Anything, Do We Still Need PMs?

The challenge for those of us who work on product right now isn't that we can't think of features. It's that we think of millions of them, and on top of that we can vibe code them out fast (way, way too fast).

Our team at finetunes is really into music and sound, so ideas keep coming, for customer-facing and behind-the-scenes features alike (mostly Delightful features, let's be real, not the Critical Path). We want to put (read: cram) every one of them in, so I keep having to rein myself in: does the user really want this, or do we just want to build it? . . .

Less is more. Keep it lean. That's what I tell my team members, and what I have to keep reminding myself of, too (teaching others is easy; doing it yourself is another story).

It matters even more now that AI makes "Make it exist" so easy it's almost magic, and there's a question I hear more and more: in an age where we can conjure anything, do we still need PMs?

The Made-to-Order PM

PM, or Product Manager, is one of the hottest roles, because the tech world is (or at least looks like) a world where the pay is good, the work is fun and things are exciting. It's also a tech role you can get into without a technical hard skill, unlike developer, QA or designer roles, so a lot of people from outside tech jump in.

Zoom all the way out and the classic software development cycle has three stages:

1. Scoping and planning (requirements gathering and planning)
2. Making it visible and tangible (design and prototyping)
3. Writing the code that turns it into something that works (coding and development)

Each stage costs more money and resources than the one before it. That's why each one gets signed off before it moves on: catching a mistake or a scope change early saves both time and money.

Working this way makes the builders (designers and developers) the bottleneck. As a result, a software house often has one Project Manager (Project Manager, to be clear, not Product Manager) running many projects at once, sometimes ten.

For projects, I get it. For a product in a Product Company, I really don't think it should work this way. That person can't focus and has no time to obsess over the product and push it to grow. Run a Product Manager like a Project Manager, ten products at a time, and you get the Made-to-Order PM, who works just like a made-to-order food stall (in Thailand we call it "ahan tam sang", literally "food as you order"). Whatever the customer orders gets cooked, and nobody has time to ask whether the requirement should exist at all.

When Building Is No Longer the Bottleneck

Generative AI is disrupting every role right now, and the clearest thing it unlocks is speed. Every part of the work gets faster, and you can conjure almost anything. If you're a bit of a wizard across skills, you can cover the whole thing alone, even run a one-person business. (Of course, a non-dev coding with AI still can't beat a dev coding with AI, because the fundamentals are missing. Running a one-person business doesn't mean being a wizard at everything, either. You just need to know enough to be dangerous.)

One way tech teams work now: the PM builds the prototype, the devs take it from there, and the designer comes in at the end to tidy up and polish (non-designer + AI can't beat designer + AI either). You get finished work in a very short cycle.

That turns the question around: do we still need PMs? We used to sign off stage by stage because fixing scope at the end was so expensive. With AI, changing scope or iterating costs a lot less. You can build several versions to compare, or throw in every feature you want.

My answer: yes, definitely, and the PM's job gets even clearer and more important. Look at where the bottleneck used to be: building. Once building gets really fast, the bottleneck moves to deciding what to build, and what not to. When building isn't the bottleneck, deciding what to build is.

This reminds me of what Elon Musk calls "The Algorithm", the five steps he uses to build things (from Walter Isaacson's biography of him).

The order matters. Elon says the most common mistake smart engineers make is optimizing something that shouldn't exist in the first place. AI helps a lot with steps 3 to 5, but steps 1 and 2 are still ours. Skip them, and AI just helps us optimize the wrong thing faster than ever.

Steps 1 and 2 are the PM's job: planning, designing and deciding what the product should be. That takes good Product Taste, talking to customers, collecting feedback systematically, and framing the problem sharply. A Made-to-Order PM juggling ten products has no time for any of it (and even if they had the time, they wouldn't have the energy or focus).

Curator

Let's step out of tech and into the art world for a moment (fine art, I mean, not designers working to a brief). Walk through a gallery or museum and you'll notice the exhibition has a pattern. The pieces belong together, relate to each other and tell a story, usually around a theme.

Now picture features and interactions as the works on display. In a mid-sized gallery, one without unlimited money, one person sources, selects and arranges what gets shown. That person is the "Curator".

A Curator chooses under all kinds of constraints, then tells a story the audience understands and is moved by. The constraints are what prove the skill: did they choose well, and do the pieces work together? A PM does the same job, curating features and interactions for a product under constraints of their own.

A gallery doesn't even show everything it owns. Most of the collection sits in the archive, and each exhibition uses only a handful of pieces (PMs have an archive too, called the backlog).

Some might argue that a Curator picks from works that already exist, while a PM creates new things. Most features are remixes of something that came before, though (nothing is new under the sun). Both jobs come down to choosing from a huge range of options, then putting the choices together to suit the place, the audience and the moment.

The Gallery That's Too Rich

Today, it's as if the gallery's limit on works has been lifted. (Welcome to the SaaSpocalypse, doomsday for SaaS: software stocks fell across the board in early 2026 as people came to believe that anyone who knew enough could use AI and vibe coding to build the software they needed themselves.)

Imagine the gallery can now afford any work from anywhere in the world. Pile every artwork on earth into one place and of course it's a mess: nothing connects, nobody can follow it, and it's not much of a visit.

However rich the gallery gets, every piece still needs looking after. Features are the same. Building got cheaper, but looking after what you built didn't. Every feature needs someone to maintain it and someone to support it, and users have to learn it too.

Shipping lots of vibe-coded features can also make us forget about structure. Best practice and infrastructure matter as much as ever. Vibe coding can get you a working prototype, but without solid infrastructure everything breaks the moment you scale. (Like a gallery that keeps adding rooms without checking the foundations. The day the crowds come, the building sinks.)

Why not put everything in and let an A/B test decide? A/B tests are good, but to run one, you need to have already thought through and designed each room, room A against room B. That's worth doing. A/B testing is step 3, and it only means something after steps 1 and 2. Building unlimited features and shipping all of them is a different story. That's piling every piece into one room.

In an era when AI lets us build almost any feature, the job isn't to build as many as possible. It's to choose the right ones and make them fit together, then show how they relate so people get it. That's the Curator's job, steps 1 and 2. A Curator has principles and, above all, Taste in choosing the works. A PM needs good Product Taste in the same way.

A product that solves everything solves nothing.

Doing Less, but Getting It Right

An example I love is Whoop. Feature for feature, Whoop loses to the Apple Watch by a mile: fewer features, no screen, no notifications. It can't even tell you the time. Whoop never wanted to be a smartwatch, though. It set out to be a health coach on your wrist 24 hours a day for people who train seriously, answering one question: how ready is my body today? Go hard, or rest? Having no screen turns into a strength. You can wear it day and night, the battery lasts a long time, and nothing interrupts you. When the Apple Watch took off, Whoop was pressured to add a screen and chose not to. That's step 2 for real: cutting what everyone thinks a wearable must have.

Whoop does less, and that's exactly why the right people choose it.

Just as Whoop doesn't want to be the Apple Watch, finetunes doesn't want to be Spotify. We chose from the start to make music for businesses, not personal listening. That's the screen we cut. Even after that cut, the ideas keep coming, like letting users customize anything at all. It sounds cool, but we have to keep holding ourselves back, or the product gets so cluttered that shop owners can't use it.

Taste Can Be Trained

Devs learn to code, learn the tools and understand software architecture. Designers learn to design, frame the problem and deliver UX/UI. PMs need to know the market, break requirements down properly, and train their Product Taste.

What is Product Taste, then? For me, it's knowing when to stop. It's understanding the customer's problem well enough to know which features belong and which don't, instead of brute-forcing in whatever a stakeholder asks for. It's knowing what should and shouldn't go together, because some ideas contradict each other in principle. It's also knowing how to introduce a feature so people understand it. Taste tells us which requirements to question, and gives us the nerve to cut. (Notice I said stakeholder, not customer.)

Taste can be trained. Beyond the textbooks, it comes from trying, playing and seeing a lot, until you start to sense which combinations work and which don't. Here's what I think helps:

• Use products end to end. Don't just download one and look at the first screen. Sign up, pay, cancel. Think about the whole journey like a service designer.
• Compare the same flow across apps. Haunt Mobbin. See how onboarding differs across five apps in the same category, then ask why.
• Look at apps that aren't competitors. Find interesting features or workflows in other industries and usage patterns, then apply that inspiration to the problem you're solving.
• Look at what they chose not to do. Find a product you like on Product Hunt and see what it left out. What's missing often tells you more than what's there.
• Read a wide range of case studies. The ones that soared and the ones that crashed.
• Test your Taste against real customers. Taste that has never met a real customer is just personal preference. You are not your customer. A Curator puts on an exhibition for the audience, not for themselves.

I did the third one myself when we designed the preboarding for finetunes. Most music apps are simple: open the app and the music plays. Ours is heavily personalized, so the journey is longer than a typical music platform's. For our homework we didn't stop at music apps. We studied onboarding across all sorts of apps, especially personalized fitness apps: how they explain things clearly, and how they keep people from bailing out too early.

What about devs with good Taste? They definitely exist, but the two skills rarely live in the same person. Devs are experts at building; PMs are good at framing problems and deciding. It's like architects and engineers: someone who's both probably exists, but usually they're two different people (if you find one, snap them up fast).

PMs often come from outside tech, and that has an upside: it's easier to break out of traditional frames and constraints. (That said, a PM still needs to understand tech somewhat, so the team can actually hand work to each other.) Still, the lines between roles are fading for devs, designers and PMs alike. How far they'll fade, I'm not sure myself.

Cutting Is Harder Than Adding

Sounds easy, right? Question, then cut. In real life, the hardest part of step 2 isn't the decision. It's telling the people who want something "no".

Every feature has someone who wants it: the big customer who asked for it, the sales team that already promised it, the executive who saw a competitor has it, or even our own team, who want to build it because it's cool (yes, I'm one of them. Who doesn't want an AI button on every page these days?). Put it in and internal stakeholders are happy. Cut it and someone sulks. Meanwhile, the people who actually use the product aren't happy at all. There's too much of everything, it eats their cognitive load, and in the end they don't use it.

AI makes "no" even harder to say. We used to be able to say "the devs are busy" or "it won't make it in time". Now everyone knows a prototype takes no time at all, and that excuse is gone.

Fast to build doesn't mean free, though. Every feature that goes in needs looking after forever, with the team's time, energy and focus. Most people asking for it don't see that, so we have to explain: yes, we can build it, but it isn't worth maintaining, or it doesn't fit our product. That's a lot harder to say than "we won't make it in time".

That's what separates the Made-to-Order PM from the Curator. A made-to-order stall never turns down an order. A Curator turns down good work every day, because it doesn't fit the exhibition.

To say "no" without becoming the stubborn one, you need to come armed: understand the customer's problem better than the person asking, have feedback collected systematically, and be able to explain which of the product's principles the feature goes against. "I don't like it" doesn't count (that's personal preference, not Taste).

"No" doesn't have to mean forever, either. Often it means "not yet". Cutting the wrong thing now and then is fine. Elon even says that if you don't end up adding back around 10% of what you cut, you haven't cut enough.

The Specials Menu

What if a PM wants to try something really new? Something unproven, where we don't know yet if it adds real value or if anyone wants it. Merge it straight into the main platform and the team's work gets harder, maintenance gets harder, and users face even more stuff, all before we know it's useful.

Think about how a restaurant tests a new dish. They don't reprint the whole menu, rearrange it and reshoot every photo (before anyone says it: even with today's digital menus, you still have to arrange and present things). They put it on as a special first and see how people respond. If it's good, really good, it joins the main menu.

Claude Design launched the same way. Anthropic released it as a research preview under Anthropic Labs instead of merging it into the main platform. From what I've used, it's completely separate and shares only the login. It looks and feels the same, but it's really a different platform, and moving work between them is more of a handover than a seamless flow. From a product development angle, that makes total sense.

A special is how you test a hypothesis without disrupting the core product.

The Restaurant People Queue For

Are PMs still needed, then? More than ever. "Make it exist" is now very, very easy. AI handles steps 3 to 5 faster than ever, but steps 1 and 2 still need people. A PM may not need a technical hard skill, but Taste has always been a hard skill. There's nothing new about it. It just matters more today than it ever has.

Made-to-order stalls can still get by. The restaurants people happily queue for, though, usually have only a few dishes and make each one really, really well. (If a place sells curry rice, pasta, pad kra pao, sushi, pizza, kimchi, hot dogs . . . RUUUUUUN.)