By Prince Singh, Chief Product Officer · October 2026
When a team loses developers and testers, the delivery date usually stays where it was. The sprint goal is the same, the stakeholders are the same, and fewer people are available to meet it. A product manager in that position has three options: ask for more time, ask for more people, or help build and test the work. The first two are often not on offer.
A growing number of product managers take the third option. They work as product manager, hands-on developer and quality assurance (QA) engineer in the same sprint. This article calls that person the tri-role product manager, and looks at what the arrangement asks of them, where it pays off, and where it stops working.
What the tri-role product manager does
The same ticket looks different through each of the three roles, because each role asks a different question about it.
- Product lens: what should be built, and why. This covers user value, business goals and what can wait.
- Developer lens: how to build it. This covers the structure of the code, the components involved and the cheapest correct implementation.
- QA lens: how it breaks. This covers edge cases, user flows, acceptance criteria and what else the change might disturb.
Take a ticket that reads "let a trainer upload a file of learners". The product lens asks who uploads it, what should happen to a learner who already exists, and what counts as done. The developer lens asks where the file is parsed and how large it is allowed to be. The QA lens asks what happens with an empty file, a file with no header row, five thousand rows, or a name with an accent in it.
Doing all three well is a matter of switching on purpose. The work goes wrong when the three lenses blur into each other and none of them gets a full look.
Where the model pays off
Intent and implementation sit with one person
In a normal handoff, a requirement passes from the product manager to a developer, who interprets it, builds it, and shows it back. The gap between "what I meant" and "what was built" shows up at review, after the work is done. A product manager who builds the ticket has no gap to close, because they wrote the acceptance criteria and know what they meant.
The same applies to scope. When a feature turns out to be harder than expected, a developer has to stop, ask, and wait for an answer. A product manager who is already in the code can decide on the spot to drop a filter, simplify a screen, or ship the first version without a setting, and the core value of the feature stays intact.
The product manager is the one person on the team who can change the commitment, and that matters more than an extra pair of hands.
The person filling the gap can also reduce the load
This is the strongest argument for the model, and it is easy to overlook. A developer who joins a stretched team adds hours. A product manager who joins it adds hours and also holds the authority to cut scope, move a date, or say no to a request. A product manager who has built part of the sprint knows which twenty percent of a ticket costs the most, and can decide whether that part is worth it.
Testing happens inside the sprint
In a reduced team, testing is usually the first thing to get squeezed. It slides to the last two days of the sprint, bugs are found when there is no time to fix them, and releases go out with known problems.
A product manager who tests as branches are finished moves that work forward. Each ticket is checked against its acceptance criteria when it is ready, not at the end. Product managers also know how people use the product, so the checks come from real workflows and real inputs, such as the learner who pastes the wrong column or the customer who uses the back button halfway through a payment.
Over a few sprints this produces something the team can keep: a short checklist for each type of change, a set of automated tests for the paths that matter most, and a quick regression pass before each release.
What to take on and what to leave alone
The tickets a product manager picks up decide whether the model works. A useful rule is that the product manager's tickets should be ones that can slip by a day without blocking anyone, because a product manager's day is interrupted by meetings in a way a developer's day is not.
Good candidates:
- Interface changes, layout fixes, and changes to wording on screens.
- Bug fixes that have a clear way to reproduce them.
- Connecting an existing endpoint to a screen.
- Configuration changes and content updates.
- Writing tests for behaviour that already exists.
Better left to developers:
- Work that other tickets depend on.
- Changes to the data model.
- Anything that touches security, payments or permissions.
- Work with a hard deadline inside the sprint.
Organising the week
Three roles in one person lead to constant switching unless the week is divided on purpose.
- Product work first. Standup, stakeholder conversations and drafting stories fit in the morning, when messages are arriving and people are available.
- Build in a protected block. Keep a block of the afternoon free of meetings and notifications. A ticket that needs one clear hour often takes three in fragments.
- QA at fixed points. Check each branch when it is ready, and run one full pass before release. Put these on the calendar.
- Reduce repetition. Existing component libraries, a utility-first framework such as Tailwind CSS, and a continuous integration and deployment pipeline that runs the tests on every change remove work that would otherwise fall on the same person three times.
Where it breaks
Marking your own work
The author of a change tests the path they built. They do not think of the input they did not plan for, because if they had, they would have handled it. A product manager who builds and then signs off the same ticket has replaced one check with none.
Two habits help. The product manager tests other people's tickets, and the product manager's own changes are reviewed by a developer and covered by automated tests that run on every change.
The product role shrinks without anyone deciding it
Code produces a visible result at the end of the day. Discovery, roadmap work and conversations with stakeholders do not. When time is short, the second kind of work is the first to go, and the team can build for months before anyone notices that nobody has been deciding what to build next. Protect that time on the calendar the same way as the build block.
One person does not make three people
A person covering three roles gets fewer hours of each. If the sprint commitment stays the same as before the headcount fell, the model hides the gap and does not close it. The honest version is a smaller commitment: the product manager says what the team can deliver with the people it has, and what it cannot.
A temporary arrangement becomes the plan
If the tri-role arrangement is still in place a year later, it is a staffing decision that was never made explicitly. Say so to leadership. Show what the team delivers with the current setup, what has slipped, and what the product manager is no longer doing.
What the team gets from it
When developers see the product manager reviewing pull requests, debugging a layout issue and writing test cases, the lines between product, engineering and QA become easier to cross. Developers learn more about why the work matters. The product manager learns what a change costs in the codebase, so estimates and requirements become more accurate, because they are written by someone who has seen the code.
The arrangement works under a few conditions: the product manager takes on work that can slip, tests other people's work, protects the product role in the calendar, and uses the authority over scope to match the commitment to the team that is actually there. Without those, it is the same overload as before, spread over one person.
Disclaimer
This article is an editorial opinion piece about product management and team structure. It is not employment, management, legal or human resources advice, and it is not a recommendation to reduce any team, or to ask any person to take on additional roles. Decisions about team composition and workload should be made against your own people, contracts and circumstances.
The examples in this article, including the file upload ticket and the structure of the week, are illustrations written to explain a pattern. They are not accounts of any real company, team or individual, and nothing in them is a measurement.
Product and company names, including Tailwind CSS, are the trademarks of their respective owners, used here descriptively. Their mention is neither an endorsement by us of them, nor by them of us, and implies no affiliation or partnership.
