Trade-offs: Product-Based vs. Project-Based Teams
This tests your grasp of how funding models impact team ownership and code quality. Contrast project (temporary, build-only) vs. product (durable, continuous) teams, linking the latter to better knowledge retention and architecture.
What's really being asked
This question assesses your ability to connect organizational design and financial models to engineering outcomes. The interviewer wants to see if you understand the second-order effects of "project-based funding" versus "product-based funding" on things like team velocity, knowledge retention, code ownership, and architectural integrity. It's a test of strategic thinking beyond just writing code.
The full answer
A strong answer contrasts the two models across several dimensions. First, define the core difference: project funding is for a pre-defined solution and ends on delivery, while product funding is for a durable team to solve a business problem over time. Second, explain the impact on the team: project teams are temporary, leading to knowledge loss and orphaned code when they disband. Product teams are long-lived, fostering deep domain expertise and ownership. Third, discuss the effect on technical health: project teams are incentivized to hit a deadline, often accumulating tech debt that a future team must fix. Product teams live with their decisions, so they are incentivized to maintain architectural integrity and manage debt continuously. Finally, touch on velocity: product teams achieve higher long-term velocity through reduced cycle times and the ability to truly iterate, whereas project teams have high ramp-up/ramp-down overhead.
The mistakes people make
A common red flag is describing the difference between projects and products without connecting it back to the funding model. Candidates will say "product teams have more ownership" but fail to explain that this is a direct result of being funded continuously to "build and run" the system, rather than just "build and hand off." Another mistake is treating the models as purely a matter of preference, rather than a strategic choice with clear financial and technical trade-offs. Saying one is "good" and the other "bad" without nuance is a junior-level response.
What usually comes next
Be prepared for follow-ups like: "How would you transition a company from a project to a product model? What are the biggest challenges?" or "In what situations might a project-based approach still be appropriate?" or "How do you measure the success of a product team if not by delivering a pre-defined scope on time and on budget?"
A concrete example
Imagine a company wants a new retirement calculator. In a project model, they fund a 500k project for 6 months. A temporary team builds it and disbands. A year later, tax laws change. A new project must be spun up, costing 250k, because the new team spends weeks relearning the old code. In a product model, a "Financial Planning" team is funded $1M annually. They build the calculator in 4 months. When tax laws change, they already have the expertise and can ship the update in 2 weeks as part of their ongoing work, using their existing budget. The long-term cost of ownership is lower and the response time is faster.
Interview question
When an organization primarily funds development using temporary, project-based teams, what is the most likely long-term consequence for its software and teams?
- a.Faster overall delivery velocity, because teams focus on a single goal without ongoing maintenance duties.
- b.Increased developer specialization, as engineers can be hand-picked with the perfect skills for each project.
- c.Improved long-term budget control, as each initiative is individually scoped and costed before work begins.
- d.Fragmented code ownership and knowledge silos, as teams are not incentivized for long-term system health.Correct
Why? this is the answer
This is correct because project-based teams are temporary and disband after delivery, leading to orphaned code and lost knowledge. A tempting distractor is 'Improved long-term budget control', which is incorrect because this model often increases total cost of ownership due to expensive rework and maintenance cycles.
Just read this? Test yourself on what you have been reading.
Read the original → martinfowler.com
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on agile — each one lists the topics its interview covers.
See open roles