A young SaaS company usually reaches a point where the founders cannot build, plan and support the product alone any more. The next hire is obvious to everyone, and everyone names a different role. The technical founder wants another engineer. The sales founder wants someone to look after customers. An adviser says it is time for a product manager. All three can be right. The answer depends on where work is stuck today.
What each role does
An engineer builds and maintains the product. More engineers means more gets built, if there is a clear list of what to build.
A product manager decides what should be built and in what order. They talk to customers, weigh requests against each other, and turn a vague need into something an engineer can build. They do not write the code.
A designer decides how the product looks and, more importantly, how it works for the person using it. A good designer removes steps and confusion.
An implementation specialist gets new customers set up: importing their data, configuring the product for them, training their team. In products that need set-up, this is where a sale turns into a customer.
Find where work is stuck
Look at the last three months and ask where things queued up.
- There is a clear, agreed list of what to build, and it is not getting built. You need an engineer.
- Engineers are waiting for decisions, or building things that customers then do not use. The list is the problem. You need product management, whether that is a hire or a founder giving it real time.
- Deals are signed and customers take months to go live. You need implementation.
- Customers ask the same “how do I” questions again and again, and demos need a lot of explaining. The product is hard to use. You need design.
A quick way to check: ask each person on the team what they waited for last week. The answers usually point to the same place.
The usual order, and when to break it
For many early SaaS companies the order is engineers first, then implementation or support once there are paying customers, then a product manager, then a designer. The founders act as product manager until there are too many customers and requests to hold in one head.
Break the order when the stuck point says so. A product sold to non-technical users may need a designer before a third engineer. A product that takes weeks to set up may need implementation before anything else, because revenue is sitting in the queue.
Mistakes to avoid
Hiring a product manager too early. With three customers and a founder who knows them all, a product manager has little to decide. They either take over decisions the founder still wants to make, or write documents nobody reads.
Hiring a product manager too late. The opposite sign: engineers build whatever the loudest customer asked for last, and the product becomes a pile of special cases.
Hiring a senior title for a hands-on job. A “head of product” or “VP engineering” from a large company may be used to leading through others. In a team of eight, you need someone who does the work themselves. Ask directly what they did with their own hands in the last year.
Solving a clarity problem with more engineers. If the team is not sure what to build, more people build more of the wrong thing, faster.
What to test in each
Engineer: a short, realistic piece of work and a conversation about choices they made in something they built. In a small team, check they can work without a tester and a reviewer behind them.
Product manager: give them three real customer requests and ask which they would build first and why. Then ask what they would say to the two customers who have to wait. Good answers involve questions about the customers before any decision.
Designer: ask them to walk through one piece of past work: what the problem was, what they tried, what they dropped and why. Then show one screen of your product and ask what they would look into first.
Implementation specialist: describe a customer with messy data and a tight deadline, and ask how they would run the first two weeks. Look for a calm plan and clear communication with the customer.
One hire at a time
Each hire moves the stuck point somewhere else. A new engineer exposes unclear priorities. A product manager exposes a slow release process. That is normal, and it is a good reason to hire one role, let it settle for a couple of months, and then ask the question again: where is work waiting now?
