Have a Whole Product Team without Having a $1m Payroll

Why You Need a Whole Product Team

If you are:

• An entrepreneur with a validated idea
• A technology startup
• A profitable business looking to increase revenue opportunities

Then you need a whole product team.

So why then do most of us conclude that what we need is a developer?

I believe the intangibility of internet products has something to do with it.

For example, if you were going to produce a film you would surely agree you’ll need more than just a 2nd AD to get it written, filmed, edited and distributed?

With film we can see how big the effort is- from building sets and sewing costumes to holding lights and mics- but with web all we often see is one person writing code on their laptop.

The fact is: building software is a production as involved as making a movie, and hiring just a developer (or two) isn’t going to get you there.

What is “Whole” and Why Does it Matter?

“To be great, be whole.”

Fernando Pessoa

Having a whole product team doesn’t (have to) mean having one or more people on payroll for every function.

What it means is ensuring that the point of view of every function is expertly represented by the team you have.

Let’s examine these roles by their primary mode of inquiry.

Product Manager. Essential question: “Is it valuable?” The product manager owns the tension between creating value for customers and creating value for businesses. When the team dives head first into solutions mode, the product manager encourages further investigation into what is the problem, who are we solving it for, and (why) is that important?

Business Stakeholders. “Is it viable?” The adjective viable refers to a thing being able to function properly and even grow. Key representatives from the business have idea seeds to plant, they want to give life to the PnL.

User Experience Designers. “Is it usable?” Experience designers are rightly concerned with whether the product design allows users to accomplish the tasks they want to and whether that experience is most desirable. Note: precisely the decisions many developers don’t concern themselves with at all.

Tech Lead. “Is it feasible?” Feasibility assesses the relative strengths or weaknesses of a plan. It can inform viability, but in this context it tends to be focused on the technical implementation details; how we will do it once we’ve decided that we will do it.

Developers. “How should we get the work done?” If you’ve ever designed a database you understand there’s a million ways to organize schema – and that’s just one example of the kind of micro problems developers have to solve daily when building products. Daily problems at the development level further emphasize the value of a Tech Lead (or Scrum Master) who can provide not just overarching guidance, but daily direction.

Project Managers. “Are we on track?” Depending on the scale of the organization, Product Managers may need to act in the capacity of Project Managers, but the concerns here are far more tactical. Project Managers move people and tasks along toward finite delivery dates. In fact, project management is so tactical it can be difficult to remember to zoom out and see the bigger, strategic picture. That’s one good reason for separating the roles.

QCs. “Does it work as intended?” Well, does it? Did you check it?

Introducing the Team-as-a-Service Model

Understanding that there are so many different product functions, and that the conflicting responsibilities of those functions can make it hard for any one person to play too many roles at once (for example: Tech Leads coding instead of leading Coders; Project Managers forgetting to ask “why,”) is good evidence for staffing whole teams.

But whole teams may not seem like an available option when you:

• Are working to launch a new product company
• Early in your product journey and trying to reduce risk of hiring too soon, firing too often
• Already staff a product team (who is too busy / not as effective as you’d like)

This is where Team-as-a-Service becomes a powerful alternative to both insourcing and offshoring.

vs Insourcing

Insourcing a whole product team is the goal. But sometimes we rush so quickly toward this goal that we ignore the friction that comes with the approach.

For starters, a whole product team in most markets means a minimum payroll of $1 million.

And funded or not, it’s very hard (and costly) to recruit and train a product team if you’re non-technical, new to digital product, or operating out of a city with a hot job market (SF, LA, NYC) or a small talent pool (Midwest).

New teams spend a lot of time in the storming and norming phases before they perform.

When you build your team in-house, you must also factor in the cost of learning and prepare for missed opportunity in the form of delays.

Insourcing is a path to sustainability, but not necessarily the fastest path to reaching the goal.

vs Offshoring

Let me bust some myths that highlight how offshoring isn’t really a 1:1 alternative to Team-as-a-Service or Insourcing.

MythBuster 1: A $20 developer hour, spent four times over to correct a ticket that wasn’t delivered to specification is equal to the cost of one quality local developer hour.

MythBuster 2: Offshoring is no longer the “low cost” solution

MythBuster 3: There is no way around figuring out the details. If you push loose requirements toward developers without adequate input from other product team members, the details will have to get figured out at the code level in the form of correcting the work (see also point #1) and you will play the role of product manager, project manager, experience designer and tech lead – perhaps at 5am depending on your time zone?

Three Benefits of Choosing TaaS

Fractional Cost

Team-as-a-Service gives you the benefit of a whole product team without the full expense because it’s based on a fractional / augmentation model.

At The Development Factory, we reverse engineer our TaaS agreements based on the roles you have already staffed and the right levels of support for each role you need staffed. This way you don’t pay for support you don’t need even while you’re extending the expertise of your current team.

If you’re starting from scratch, we can provide whole product teams beginning at $18,000 per month – and scale bandwidth up and down as needed for as long as you like (typically 6 to 24 months). That’s as little as 25% of the upfront cost of staffing.

Performance on Demand

Another benefit of engaging a whole team is fast tracking performance.

By removing the getting to know you / establishing process phase (which our high-performing teams are well beyond), we can drop right into the work and even help your organization begin to learn and adopt valuable rituals and protocols that will till the soil for when you’re ready to insource.

A Whole New Perspective

Team-as-a-Service is built on the promise of representing all product team functions, not just staffing bodies.

This means that you don’t need to debate between hiring a Designer or hiring a Developer – you can have both and so much more.

Bonus: Recruiting that Works

We believe in insourcing when the time is right.

At The Development Factory, we help all our clients transition to in-house teams by assisting with talent recruitment, training, and knowledge transfer.

The result is a frictionless move from the highly effective, short-term strategy of TaaS into the sustainable, long-term strategy of insourcing with less waste and less headache.