Product manager vs. designer: what your startup actually needs first

Most early-stage startups don't need a product manager yet. What they need is someone who can think through product decisions and design the result, one person covering both jobs. Hiring a PM before you have anything to manage adds process, not progress. Hire for judgment first, titles later.

The question founders ask at the wrong time

I get some version of this question a lot: "Should I hire a product manager or a designer first?" It usually comes from a founder with a working product, a small user base, and a growing list of things that need deciding. Feature requests are piling up. The roadmap is a Notion doc nobody trusts. Someone told them they need "more structure," and the fastest way to buy structure feels like hiring a PM.

The problem is the question itself assumes the two roles are separate and sequential. At the stage most founders are asking this, they're not.

A product manager's job is to decide what gets built and why, then coordinate the people who build it. A designer's job is to figure out how it should work and look, then build that. Split across two people, this works well once there's enough surface area to justify two full-time roles: multiple product lines, several engineers who need routing and prioritization, stakeholders who need managing. Before that point, splitting the roles just adds a handoff where none is needed.

What a PM actually buys you (and when)

A product manager earns their keep when the coordination problem is bigger than the decision problem. If you have eight engineers across three squads and nobody agrees on what ships next, you need someone whose full-time job is alignment. That's a real problem, and it's not one a designer is positioned to solve.

But most startups asking this question aren't there. They have one or two engineers, maybe a contractor, and a founder who still reviews every pull request. The bottleneck isn't coordination. It's that nobody has sat down and worked through what the product should actually do next, then turned that into something buildable. That's not a management problem. That's a thinking-and-making problem, and it's usually cheaper and faster to solve with one person who can do both.

What a designer can absorb instead

A good product designer isn't just executing a spec someone else wrote. At the early stage, the best ones ask the questions a PM would ask before they open Figma: who is this for, what are they trying to do, what happens if we don't build it, what's the cheapest version that tells us if we're right. Then they design the answer.

This only works if the designer actually has product judgment, not just visual taste. That's the part founders often can't tell from a portfolio. A beautiful case study doesn't tell you whether the person behind it pushed back on a bad idea or just executed it faster than expected. If you're evaluating designers for this exact reason, it's worth reading how product designers and UI designers actually differ: the distinction maps almost exactly onto whether someone can absorb the PM half of this equation or not.

The gap nobody names: judgment

Here's what actually goes wrong when founders split the roles too early. The PM writes a spec. The designer executes it well. The feature ships. It doesn't move the number anyone cared about, because the spec was never stress-tested by someone who also had to live with the tradeoffs of building it. Nobody was dumb. The process just added a layer between the decision and the person who'd notice if the decision was wrong.

This is the gap Artone is built around closing. I spent years as Head of Product at a stealth startup backed by prominent Silicon Valley investors before starting the studio, and I've been designing professionally since 2016. That combination is the whole premise: founders get someone who thinks through product decisions and designs the outcome, instead of a designer waiting for a spec or a PM waiting for a designer to be free. If you've ever wondered whether design actually matters enough for a startup to justify this kind of investment early, this is usually where the answer becomes obvious: it matters exactly as much as your product decisions do, because design is where those decisions become real.

What this looks like in practice

Concretely, a founder working with someone who covers both sides gets a different kind of conversation. Instead of "here's the spec, go build it," it's "here's the problem, walk me through what you'd actually do and why." The designer pushes back on scope before it becomes a sprint. They ask what you'll measure before the first screen gets drawn. They tell you when a feature request from one loud customer isn't worth building for everyone else.

None of this requires a PM title. It requires someone who treats the design work as downstream of a real business decision, not a separate craft that starts once the decision has already been made elsewhere. If that's the gap you're feeling right now, that's usually the moment worth talking it through rather than posting two job openings and hoping the two hires sync up naturally.

The hidden cost of getting the sequence wrong

The obvious cost of hiring a PM too early is salary. A full-time product manager is a meaningful line item for a company that hasn't found product-market fit yet, and it's money that could have gone toward engineering or runway. But the bigger cost is slower, and it's the one founders underestimate: every decision now has to pass through two people before it becomes real.

That's not just slower shipping. It changes who's accountable for the outcome. When one person owns the decision and the design, there's nowhere for a bad call to hide. When the roles are split, a weak feature can always be blamed on the handoff: the PM says the spec was clear, the designer says they built what was asked. Both can be technically right, and the product still doesn't work. Founders rarely notice this pattern until they've shipped two or three features that quietly underperformed, then spent a quarter trying to figure out why.

There's also a recruiting cost nobody talks about. A combined product-and-design hire is a smaller, weirder pool than either role on its own, which makes founders default to the more familiar path: post a PM role, post a design role, hope the two people you hire happen to work well together. That's a bet on chemistry you haven't tested, made twice, instead of one hire whose judgment you can actually evaluate before you commit.

When you actually do need to split the roles

To be fair to the other side of this: the split becomes worth it eventually. Once you're managing multiple engineers who need daily unblocking, once there are enough stakeholders that alignment itself becomes a job, once your design needs are broad enough that one person genuinely can't keep up, hire the PM and let the designer specialize. That's a real inflection point, and startups that ignore it too long end up with a founder or a designer quietly doing unpaid PM work on top of their actual job, which burns people out fast.

The mistake isn't hiring a PM. It's hiring one before the coordination problem exists, because it's simply more familiar as a hire than "designer who also thinks about product," a role that doesn't have a clean job title and so gets underrated in job posts and interviews alike.

What your startup actually needs first

If you're pre-seed to Series A, with a small team and a growing list of product decisions nobody's confident about, the honest answer is neither role in the traditional sense. What you need is someone who can sit in the founder's head for an hour, understand what the business actually needs next, and turn that into something real without three rounds of handoff in between.

That's a specific kind of hire, and it's rarer than either a PM or a designer on their own. It's also, in my experience, the one that moves a startup's product forward fastest in the year that matters most.

If you're trying to figure out whether that's what you're missing, book a call and walk me through where the decisions are getting stuck. That's usually enough to tell within twenty minutes.