I’ve worked in a development house, I’ve worked with startups, and now I work with a product team. And there’s something I’ve noticed again and again — team compositions follow certain patterns, whether we like it or not.
The smaller the company, the fewer people you’ll find. Roles are shared, hats are worn sideways and upside down. One person is designing the UI, writing the release notes, and fixing production bugs. The bigger the company, the more specialized the roles become — and suddenly there’s a person whose full-time job is to manage the backlog grooming meeting.
This isn’t good or bad. It’s just how it is.
So here’s a breakdown of common roles and what I’ve personally learned from working with and without them.
🧭 Project Manager
This role shows up 99% of the time when you’re outsourcing development. Sometimes you’re told it’s “included” (spoiler: you’re still paying for it). Outsourcing companies love having a PM as a buffer and coordinator — and in many cases, they’re right to do so.
But if you’re building a product with your own internal team — and it’s a mature, independent, self-managed team — you might not need a project manager at all. That’s the case in my current team, and it works beautifully.
That said, PMs become necessary when you start scaling:
- Multiple teams need alignment.
- Priorities shift constantly.
- Someone needs to rebuild the roadmap every other week.
- Forecasting and reporting becomes a full-time job.
The real trouble begins when the PM ends up as a glorified translator between business and engineering. That’s when you know you have a communication problem, not a staffing one.
📝 Business Analyst / Product Owner / Documentation Writer
These are technically separate roles, but let’s be honest — they’re often just different flavors of “writing things down.”
And while in early stages many teams skip this, I personally like to bring documentation in early. Even simple documentation helps reduce friction later. It builds a source of truth, supports onboarding, and makes future planning way less painful.
You don’t need a full-time technical writer, but having someone (anyone!) consistently documenting product decisions, flows, edge cases, and why you made that weird API choice in sprint 6 — that’s gold. I don’t want to undervalue a Product Owner or Business Analyst role, they do mroe than document. But here I’, just pointing out the documentation aspect importance.
🎨 Designer
Now here’s a fun one. I know a fellow company doing $30M/year, and they still don’t have a designer.
Their product works, their users use it, and a lot of people (including me) call their web app… well, ugly. Would they make more money if their UI was prettier? That’s a speculative question. UI fans will say yes. I say: they’re making smart choices about where to invest.
Would I personally go without a designer? Probably not. But I get the logic.
If you’re building a user-facing product, a designer — even part-time — is a huge help. It’s not just about pixels. It’s about making sure the user doesn’t need a user manual to click “submit.”
But if you’re early and scrappy, and your co-founder “knows Figma,” it might be enough for now.
☁️ DevOps / Infrastructure / Cloud Setup
Here’s my take: DevOps is a role worth having — but not necessarily full-time.
A lot of senior engineers can handle deployments, basic infra, and CI/CD. But when you work with a proper DevOps who really knows AWS, Azure, or whatever stack you’re on — it’s a different experience.
They can:
- Optimize cost (AWS bills can be brutal).
- Improve performance.
- Catch things before they break in production at 2 AM.
It’s definitely a role worth investing in — if the hire is good. And if your product’s success depends on performance, reliability, or scaling, this can really save you more than it costs.
🧑💻 Fullstack vs. Frontend + Backend
Ah, the eternal debate.
Fullstack developers are super convenient — they help each other out, backlog management becomes simpler, and you don’t have to worry whether a ticket is frontend or backend. Everyone can, more or less, pick it up.
But there’s a catch: specialized frontend and backend developers usually bring better speed and deeper quality in their area. They’re more expensive, yes — but they’re faster in the long run and often better at the details that matter.
My personal preference? A mix.
- A few strong frontend devs focused on polish and performance.
- Solid backend devs who live and breathe API structure and data flow.
- And then a couple of fullstackers to balance things out and jump into either side when needed.
This setup gives you both depth and flexibility.
🧪 Testers / QA / QC
In a good team, everyone is a bit of a tester. In my team, before each release, we do test camps — the whole crew jumps in to test the latest iteration. And we don’t just find bugs — we also reflect: Does this make sense? Can we make this better for the user? What did we miss?
That said, when your product grows, not having a dedicated tester can become a disaster. You simply won’t be able to keep up with regression testing across the entire application every time you ship something.
That’s where automation becomes critical. Developers should handle unit tests and some integration tests, yes. But for proper end-to-end testing, you need a tester who can think like a user, knows how to break things, and can help build a sustainable QA process.
🧠 Final Thoughts
It is an art to put together the right team composition that creates the perfect triangle of budget, speed, and quality.
Another art is picking the right people to fit each role you define. And seniority? That’s a whole separate story (which I’ll probably write a post about soon).
At the end of the day, it’s not about following best practices, or copying what someone else’s org chart looks like.
You need to ask:
- What stage is your product in?
- Will you be rewriting this, or is it the foundation?
- How quickly do you need to produce results?
- What’s your budget?
- Is this a new team, or one that’s worked together before?
- Can they self-manage?
- And who’s going to keep things moving without adding unnecessary complexity?
Because in the end, it’s not about ticking off role boxes. It’s about shipping good stuff, with good people, in a way that actually works.
Need help building an internal team or reviewing a proposal or staffing model? Happy to chat — just drop me a message.